● 其次，创建一个”影响测试的列表”（Test Impact Checklist）
这个列表可以有以下部分组成：
1、影响范围
2、对影响的描述
3、影响所影响的特定情节
4、代码变化部分，以及所影响的功能
5、开发人员所推荐的回归，我想研发过程中，养成dev在改动代码的时候向测试人员提供回归测试推荐的习惯实在是必要的。
6、对有依赖关系的特性的影响
由于要达成某种改动的目的，也许需要其他特性做相应修改。
策略
执行回归测试，分为以下三个主要类型，也相应的分为以下三个阶段：
第一阶段：
提供被新功能或有依赖关系的改动直接影响的区域。这些区域至少要完成一组小的覆盖全部特性的基本功能的测试用例。
第二阶段：
把上个开发阶段（previous release）重复发现的问题列出来——这些信息可以从上个阶段的最终测试报告中找到。（也就是说每个阶段的测试报告需要包括重复发现的问题）
同时，把客户关系和敏感的特性列出来——例如付费等。
第三阶段：
a、Hot-spot suite 这是基于前两个阶段发现的比较多的问题区域。因为，缺陷往往在比较容易发生缺陷的地方隐藏更多，所以，这样的地方是要增加人手测试的。
b、额外增加的测试，这些测试往往是由于晚期check-in代码，或者有依赖关系的特性改动。这个测试范围的定位需要再次使用”影响测试列表Test Impact Checklist”。
c、Sanity Test， 这是在产品发布给客户之前做的clean-run测试，类似于monkey test。
