二、测试范围管理
软件测试根据测试阶段可分为：单元测试、集成测试、系统测试、验收测试等等。
对于系统测试，可按照测试范围分为：
变更测试：只测试当前版本的变更内容；
回归测试：对未变更部分进行测试，以验证未受影响；
增量测试：迭代开发模型中针对新模块的测试；
全量测试：对当前版本所有功能进行测试。
通常系统测试会安排多个轮次，第一论进行全量测试；中间轮次根据需要进行增量测试、变更测试、回归测试中的一种或几种；最后一轮进行全量测试，以提交验收。
实际实施过程中，存在的问题和建议方法：
1. 如何合理的评估变更影响范围？
1）主要依据开发提供的变更说明书和实施方案。开发应明确给出变更内容影响的系统功能及非功能特性，以便测试针对性的进行测试设计和执行；
2）可进行代码比对、走查等，检查修改的代码及其相关调用，准确评估受影响的功能；
3）如果变更针对业务类功能，进行代码比对基本能够准确分析；而对于系统功能，特别是涉及架构、底层通讯等方面的改动，则需要系统架构师、项目经理等人共同评审，详细评估后进行确认。
4）测试过程中，可根据需要进行扩展。
2. 如何设计回归测试？
原则上，新版本中除变更、增量部分，其他都应属于回归测试范围。但实际项目中，特别是迭代较多的版本很少有时间进行完备的回归测试。
此时，主要针对重点业务流程、变更功能相关的部分进行重点回归，其他功能可留待全量测试中进行回归测试。
1）可针对系统重点业务流程、关键业务路径、重点接口进行回归测试；
2）对页面、接口、数据表等输入-输出明确的功能，分别建立短路径的自动化回归用例集（即用例依赖性低、粒度小、执行速度快）；
3）对于复杂计算等功能，建立完整的场景数据集，通过脚本等固化计算逻辑；计算逻辑如需调整，测试数据可复用。
TBD