[原创-测试工作难点系列]二、测试范围管理

[原创-测试工作难点系列]一、干系人管理

 

二、测试范围管理

软件测试根据测试阶段可分为：单元测试、集成测试、系统测试、验收测试等等。

对于系统测试，可按照测试范围分为：

　　变更测试：只测试当前版本的变更内容；

　　回归测试：对未变更部分进行测试，以验证未受影响；

　　增量测试：迭代开发模型中针对新模块的测试；

　　全量测试：对当前版本所有功能进行测试。

通常系统测试会安排多个轮次，第一论进行全量测试；中间轮次根据需要进行增量测试、变更测试、回归测试中的一种或几种；最后一轮进行全量测试，以提交验收。

 

实际实施过程中，存在的问题和建议方法：

1. 如何合理的评估变更影响范围？

1）主要依据开发提供的变更说明书和实施方案。开发应明确给出变更内容影响的系统功能及非功能特性，以便测试针对性的进行测试设计和执行；
2）可进行代码比对、走查等，检查修改的代码及其相关调用，准确评估受影响的功能；

3）如果变更针对业务类功能，进行代码比对基本能够准确分析；而对于系统功能，特别是涉及架构、底层通讯等方面的改动，则需要系统架构师、项目经理等人共同评审，详细评估后进行确认。

4）测试过程中，可根据需要进行扩展。

 

2. 如何设计回归测试？

原则上，新版本中除变更、增量部分，其他都应属于回归测试范围。但实际项目中，特别是迭代较多的版本很少有时间进行完备的回归测试。

此时，主要针对重点业务流程、变更功能相关的部分进行重点回归，其他功能可留待全量测试中进行回归测试。

1）可针对系统重点业务流程、关键业务路径、重点接口进行回归测试；

2）对页面、接口、数据表等输入-输出明确的功能，分别建立短路径的自动化回归用例集（即用例依赖性低、粒度小、执行速度快）；

3）对于复杂计算等功能，建立完整的场景数据集，通过脚本等固化计算逻辑；计算逻辑如需调整，测试数据可复用。

 

 TBD