随着软件规模的不断扩大，回归测试在测试中占据越来越大的比例。最让人痛心的是，一个很小的改动，也许是几行代码，也许只是1,2个小时的开发工时，为了线上质量的稳定，我们需要完成整整一套相关产品回归测试和冒烟测试的工作，这让测试的工时大大高于开发的公时，有些时候甚至是开发工时的好多倍的时间，于是在项目kickoff上常见的一幕就是项目经理非常疑惑的看着测试：“需要这么长时间的测试吗？一个小的改动需要这么长的时间吗？可以不做全面回归吗？”然后测试很无奈的回答：“需要，真的需要，不做回归有风险。”于是，能否合理的判断回归范围变成了考核优秀测试人员的一个很大的标准。但是如何合理的确认回归的范围，如何在对质量提供保证的同时提高测试的效率。在这里提供一个利用函数覆盖来确认回归测试用例的科学方法。
现阶段市场上能提供函数覆盖的工具已经很多了。比较普遍的针对java语言的有clover，针对C++语言的有gcov，这些工具都提供统计了函数覆盖的覆盖率的功能，也就是说在你执行任何一个testcase之后，工具会告诉你这个testcase 覆盖了系统中的哪些函数。对于shell或者php的简单脚本我们找不到合适的工具，最简单的方法就是每扫描到个函数就在函数中加入一句“打印函数名称”的代码。这个就是最简单的代码插入的原理了。
如何用函数覆盖来确定回归测试的范围呢？好无疑问，在第一轮测试的时候，函数覆盖工具是无法确认测试范围的。只能在函数覆盖未有完全覆盖的时候提供测试用例不足或者有冗余代码的信息，但是通过第一轮的测试我们很容易得出下面的一张对应关系图：其中覆盖的部分我们写1，不覆盖的部分我们写0.
测试用例与函数覆盖关系图
测试用例1 测试用例2 测试用例3 测试用例4 测试用例。。。
函数1 1 0 1 0 0
函数2 0 1 0 1 0
函数3 1 1 0 0 0
函数4 0 0 1 0 1
函数。。。 。。。 。。。 。。。 。。。 。。。
在上张表格完成之后，在第二轮测试之前，我们需要用svn diff来确认开发代码这一轮和上一轮的改动在哪些函数上。将改动函数的整行从测试用例与函数覆盖关系图提取出来，形成测试用例与函数覆盖关系图的一个子集，再将这个子集的表格按列取或，最终结果为1的测试用例就是需要回归的测试用例，为0的测试用例是不需要回归的测试用例。比如svn diff的结果是函数1和函数3发生了变化，那么按照上图的关系。我们最终的结果如下表所示：
需要回归测试用例计算图
改动的函数 测试用例1 测试用例2 测试用例3 测试用例4 测试用例。。。
函数1 1 0 1 0 0
函数3 1 1 0 0 0
或的结果 1 1 1 0 0
通过这个计算的逻辑我们可以看到，通常改动涉及的函数越少，需要回归的测试用例就越少，这和传统的思维逻辑也很接近，但是如果这个函数是main函数或者在流程图中是必经之路，那么就意味着所有的testcase的允许都必须经过这些关键函数，这些函数的任意改动都必须经过所有testcase回归，这就会变成回归测试中最头痛的地方吧。
现阶段测试人员对测试覆盖率的重视还不是很强，主要在于覆盖率本身而言对测试来说没有提供多大的便利。但是随着对测试覆盖率的加工统计，如果能在测试效率上证明对大量的测试是能够节省工时提高效率的时候，相信就是覆盖率工具真正被使用起来的时候。
相关链接：
