自从项目组转型敏捷开发后，3个月的发布周期变为1个月，让我最头疼的问题就是回归测试。以前可以做9天的全面回归测试，现在如果照旧，那3个月内就要做9*3=27天回归，相当于在3个月内回归测试从9/30*3= 10%变为27/30*3 = 30%。敏捷测试的甜头还没有尝到，自动化的回归测试一时半会也还没法实现，回归测试的开销就要涨这么多？不妥，不妥！
前几日偶然间看到51Testing上的一篇文章“用技术提高回归测试精确度”。核心思路是通过配置管理工具对版本差异的扫描来获取改动的文件，通过用代码扫描工具对改动文件扫描得到改动的内容，再通过改动的内容扫描出关键字。最后通过这些关键字和系统功能点、回归测试用例库中的测试用例这三者的映射关系来精确找到每次要进行的测试集合。
这个想法不错吔，有的放矢。既不用做全面的回归测试，又不是仅凭测试人员的个人经验尽力而为。基于我有限的理解，技术实现上却似乎有些难度，主要是最后一步“建立关键字和系统功能点、回归测试用例库中的测试用例这三者的映射关系”。谁来维护这个关系？怎么维护？维护代价是否较高？能否坚持维护？这让我想起多年前听人宣讲的某需求管理软件，靠人工在变更和代码间建立关系，除了军方或者医疗这种对精密性要求很高的行业，我个人对维护这个关系的ROI有些怀疑，因而也对上面这个考虑手工维护3个实体关系的方法的可操作性有些疑虑。
虽然不能直接用“拿来主义”使用这篇文章的方法，但是否可以在这个思路的启发下找到一个更容易执行的有效的回归测试方法呢？
让我们想想如果仅从代码角度来看，回归测试的最小覆盖集合是什么？是否是此次版本所有的代码改动？最大覆盖集合呢？是否是所有代码？如果我们能至少保证回归测试最小集合，然后根据项目组实际资源的配备，去找到最小和最大集合之间的某个平衡点，那我们在实际工作中的信心和自由度就比较大了。例如，如果当前sprint改动不是太大，你给我2天我可以做一个最小的回归。如果下个sprint改动很大，你给我4天我可以做一个最小的回归，你若给我6天我可以做一个全面回归。简言之，在一个固定周期的sprint中，回归测试时间并不是一成不变的，而是可以根据情况选择最合适的回归策略。这样总的回归测试时间虽然不一定能缩短为10%，但也不一定需要增长到30%，实际情况下介于二者之间的某个值从ROI来看却是较佳的。
那么技术层面怎么保证““改动过的代码都被测到过”呢？具体思路如下。（注意：测到过在这里的意思是相关代码被执行过，不代表此行代码被执行时如果产生了缺陷，测试人员一定观察到了。这是一个已知风险。）
1.以当前版本为比较基准，通过配置管理工具比较上一已经发布的版本和当前版本的源码，得到被改动过的代码集
2.通过测试覆盖率工具（如我们使用的EMMA来度量Java程序的覆盖率）来得到回归测试期间所有被跑到过的代码
3.基于1和2的结果，通过工具自动比对，得到在当前版本上被改动过却未被跑到过的代码集合
4.开发人员对3的结果进行覆盖率分析，将确实属于测试人员漏测的情况进行反馈
我想使用这个方法之后，测试人员不但可以向项目干系人提供更多的测试策略的可选项，同时也可以做到在时间有限的情况下对于自己的回归测试覆盖率底线能够坚守住。这个方法对开发人员而言也是一个福音，因为相比全面回归测试的覆盖率分析，这个分析的结果集合应该更小，开发人员投入的时间也更少一些。嗯，应该试试！
版权声明：本文出自 zdlzx 的51Testing软件测试博客：http://www.51testing.com/?56882
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
