软件测试--软件测试过程
一、测试阶段的划分
1、单元测试UT；
*单元测试是针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作。
软件测试--软件测试过程##
一、测试阶段的划分###
1、单元测试UT；
*单元测试是针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作。
*单元测试的目的：是检验软件模块对《详细设计说明书LLD》的符合程度。
2、集成测试IT；
*集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。
*集成测试的目的：是检测软件模块对《概要设计说明书HLD》的符合程度。
3、系统测试ST；
*系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作。
*系统测试的目的：在于通过与《需求规格说明书》作比较，发现软件与系统需求定义不符合或者与之矛盾的地方。
4、验收测试UAT；
*当软件产品是为了特定用户开发的时候，需要进行一系列的验收，让用户验证软件产品是否满足了所有的需求；
*如果，软件是为多个用户开发的，让每个用户逐个正式的验收测试是不切合实际的，这时候，往往采用α和β测试，以发现可能只有最终用户才能发现的问题；
*在通过了内部系统测试及软件配置审查之后，就可以开始验收测试，验收测试是以用户为主的测试，软件开发人员和QA（质量保证）人员也应该参加，由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果，一般使用生产实践中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能进行确认，验收测试原则上在用户所在地进行，但如经用户同意也可以在公司内模拟用户环境进行。
*验收测试根据合同、《需求规格说明书》或《验收测试计划》对产品进行验收测试。
*验收测试的结果有两种情况：
第一种：软件功能、性能等质量特性与用户的要求一致，软件可以接受；
第二种：软件功能、性能等质量特性与用户的要求有差距，不被用户接受。
5、α测试ALPHA；
*α测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试；
*α测试时，软件在一个自然设置状态下使用。开发者坐在用户旁，随时记下错误情况和使用中的问题，这是在受控制的环境下进行的测试；
*α测试人员是除产品研发人员之外最早见到产品的人，他们提出的功能和修改建议是很有价值的；
*α测试的目的主要是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能等），尤其注重产品的界面和特色。
6、β测试BETA；
*β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试，这些用户是与公司签订了支持产品预发行合同的外部用户，他们要求使用该产品，并愿意返回所有错误信息给开发者；
*与α测试不同的是，β测试时开发者通常不在测试现场，因而，β测试是在开发者无法控制的环境下进行的软件现场应用；
*β测试中，由用户记录下遇到的所有问题，包括真的和主观认定的，定期向开发者报告，开发者在综合用户的报告后，作出修改，再将软件产品交付给全体用户使用。
7、回归测试。（比较重要，贯穿在整个测试过程中）
*软件在测试或其他活动中发现的缺陷经过修改后，应该进行回归测试（Regression Testing），所有回归测试贯穿在整个测试过程中；即回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试；
*回归测试的目的：验证缺陷得到了正确的修复；同时对系统的变更没有影响以前的功能；
回归测试的策略有两个：
1.完全重复测试：重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性；
这种方法保证了bug全被修改，并没有影响其他代码；但是工作量很大。
2、选择性重复测试：即有选择的重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序，具体可以细分为3个：
**<1 覆盖修改法：即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法；这种方法的效率是最高的，但是风险也是最大的，因为它无法保证这个修改是否影响了别的功能，该方法在进度压力很大，或者结构设计耦合性很小的状态下可以被使用。
**<2 周边影响法（覆盖修改法+扩散影响性）：该方法不但要包含覆盖修改确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有后受到不良影响；这种方法适合功能与功能之间有交互的情况，比覆盖修改法更加充分一点。
**<3 指标达成法：这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。
回归测试的流程（这个流程也同样适合于单元测试、集成测试、系统测试）
（1）在测试策略制定阶段，制定回归测试策略；
（2）确定需要回归测试的版本；
（3）回归测试版本发布，按照回归测试策略执行回归测试；
（4）回归测试通过，关闭缺陷跟踪单（问题单）；
（5）回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试。
二、测试过程子阶段###
1、软件系统测试阶段（ST阶段）
（1）系统测试（ST）计划阶段
*输入：需求规格说明书（SRS）、软件开发计划、软件测试计划；
*活动：制定系统测试（ST）计划
从管理角度制定：人，资源，时间，工作量，任务分配，风险，标准；
角色的制定：测试经理，测试组长。）
*输出：系统测试（ST）计划。
（2）系统测试（ST）设计阶段
*输入：需求规格说明书（SRS）、系统测试（ST）计划
*活动：制定系统测试（ST）方案
从技术角度制定：策略，方法，技术，工具，数据和环境；
角色的制定：高级测试工程师，测试技术专家。
*输出：ST测试方案。
（3）系统测试（ST）实现阶段
*输入：规格需求说明书（SRS）、系统测试（ST）计划、系统测试（ST）方案。
*活动：设计ST用例和规程，ST预测试项。
*输出：ST测试用例和规程，ST预测试项。
(4)系统测试（ST）执行阶段
*输入：规格需求说明书（SRS）、系统测试（ST）计划、系统测试（ST）方案、ST测试用例和规程、ST预测试项。
*活动：搭建测试环境ST预测试，全面系统测试。
*输出：ST缺陷报告，ST测试报告。
2、软件集成测试阶段（IT阶段）
(1)集成测试（IT）计划阶段
*输入：软件测试计划、概要设计说明书（HLD）。
*输出：集成测试（IT）计划。
(2)集成测试（IT）设计阶段
*输入：概要设计说明书（HLD）、集成测试（IT）计划。
*输出：集成测试（IT）方案。
(3)集成测试（IT）实现阶段
*输入：概要设计说明书（HLD）、集成测试（IT）计划、集成测试（IT）方案。
*输出：集成测试（IT）用例、集成测试（IT）规程。
(4)集成测试（IT）执行阶段
*输入：概要设计说明书（HLD）、集成测试（IT）计划、集成测试（IT）方案、集成测试（IT）用例、集成测试（IT）规程。
*输出：集成测试（IT）报告、软件缺陷报告。
3、软件单元测试阶段（UT阶段）
(1)单元测试（UT）计划阶段
*输入：软件测试计划、详细设计说明书（LLD）。
*输出：单元测试（UT）计划。
(2)单元测试（UT）设计阶段
*输入：详细设计说明书（LLD）、单元测试（UT）计划。
*输出：单元测试（UT）方案。
(3)单元测试（UT）实现阶段
*输入：详细设计说明书（LLD）、单元测试（UT）计划、单元测试（UT）方案。
*输出：单元测试（UT）用例、单元测试（UT）规程。
(4)单元测试（UT）执行阶段
*输入：详细设计说明书（LLD）、单元测试（UT）计划、单元测试（UT）方案、单元测试（UT）用例、单元测试（UT）规程。
*输出：单元测试（UT）报告、软件缺陷报告。
三、测试过程模型###
1、瀑布模型
**测试接入的比较晚；
**下一个阶段依赖于上一个的结束；
适合:小型的、需求比较稳定的项目。
2、双v模型（也称w模型）
**开发和测试的准备活动是并行的；
**测试的执行活动依赖于开发（在开发之后）；
**测试介入的较早；
**测试活动是有组织、有计划的；流程里面体现出测试各个阶段的活动：测试计划、设计、实现和执行；
**测试活动是一个验证和确认的过程。
适合:中型的、需求相对比较稳定的项目。
3、H模型
**软件测试不仅仅指软件执行，还包括很多其他的活动；
**测试是一个独立的流程，贯穿产品整个周期，与其他流程并发地进行；
**测试要尽早准备，尽早执行。
**各个不同阶段的测试除了简单的时间上的先后关系外，还存在触发、反复、迭代和增量关系。
适合：大型的、需求变更比较频繁的项目。
