回归测试中的项目质量管理应用（转自软件测试时代）

冰淇淋

1) 回归测试介绍

在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能对该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。在增量型软件开发过程中，通常将软件分成阶段进行开发，在一个阶段的软件开发结束后将被测软件交给测试组进行测试，而下一个阶段增加的软件又有可能对原来的系统造成破坏。因此，每当软件发生变化时，我们就必须重新测试原有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。

回归测试是为了确保对系统进行的更改没有影响到旧系统的正常运行。测试用例一般由两部分组成，一部分是自动测试用例，一部分是手工测试用例。

2) 项目质量计划编制
在测试计划阶段根据被测系统的特点确定测试用例的集合，由于被测试系统的软件分几个阶段进行Release，需要对系统进行分阶段测试。在测试计划阶段选定一部分测试用例作为重要的测试用例（Must Have），需要在几个阶段重复进行测试，而另一部分测试用例在整个测试的开始阶段和结束阶段要求完全覆盖，在中间阶段根据被测系统的特性分别选定。而由于自动测试用例一般不需要测试人员的参与，所以可以根据情况选择在各个阶段全部测试或类似于手工测试用例进行部分测试。

由于测试是分阶段进行的，需要记录分阶段计划及每一阶段需要对被测系统执行的测试用例。

确定测试通过的标准，测试意外的处理过程。对于每个分阶段的测试又分成测试运行阶段（ATR）和测试通过阶段（ATP）两个子阶段，确定每个子阶段测试通过的标准。

3） 质量保证
当新阶段开始的时候，要审查被测系统是否符合测试条件。对达到标准的被测系统使用计划中确定的测试用例进行测试。比较实际测试结果同计划测试结果的一致性，记录测试结果
测试用例的正确性确认，分析测试发现错误是否是有效错误，提交相应的更改错误请求（SR），并记录错误原因。

由于系统在不断的升级，所以系统的需求也在不断的更新，有些新的需求影响到了以前的测试用例，当测试时发现测试用例同原来需求的结果不一致的地方，需要和需求进行确认，如果是被测系统的错误提交相应的错误报告，如果是测试用例的错误需要对相应的测试用例进行更新。

4） 质量控制
在测试计划阶段就确定好测试各个分阶段需要执行的测试用例，从而在实际执行测试的阶段可以依照选定的测试用例对被测系统进行测试。测试结束只好对测试结果进行分析。由于实际执行时被测系统同计划阶段的需求可能会有不一致的情况，对于在执行阶段执行的测试用例同计划阶段要求执行的测试用例不一致的地方要进行分析和记录原因，并由相关负责人进行确认。
对于实际执行测试中没有通过的测试用例的原因进行分析，确定原因分布。

5） 测试完成标志
当回归测试阶段结束时，测试经理要提交各个阶段的测试用例分布，测试结果，测试发现的错误点，发现的错误是否确认原因以及发现的错误是否已经解决。
测试计划中确定的测试用例分布和实际测试用例分布对应表及意外原因。
对于本阶段的测试进行经验总结，以为下一阶段的测试作为指导。