软件开发中回归测试最佳实践

　　回归测试对保证软件质量具有重要意义。要实现有效的回归测试，必须解决回归测试中的两个主要问题：

　　(1)测试用例的优化选择;

　　(2)覆盖率分析。前者决定了回归测试的效率，好的测试用例的选择可以用少量的测试用例准确地覆盖新版本中尽可能多的改动。后者是度量测试的重要指标，通过达到良好的测试覆盖率，保证了回归测试的质量。

　　本文正是通过讨论如何优化选择测试用例，用最小的代价达到最大的覆盖率，从而找到回归测试的有效解决方案。

　　存在的问题

　　测试用例的优化选择

　　对测试用例的选择，测试人员通常有两种作法。一种是，把相关的或是所有的模块的测试用例都选出来执行一遍;另一种是，仅针对被 Fixed 的 APAR/Defect 进行检验，测试用例很少或是开发新的针对这个 Fixed 的测试用例。这两种方法都存在不足。第一种方法在测试时间有限的情况下，去执行所有的测试用例，会测试到很多无需再测试的测试用例，从而导致测试资源的浪费;第二种是很难确保 APAR/Defect 改动后，被测系统没有受到关联影响，很难保证测试质量。

　　由于 Bug Fix 或者功能更新后，在新版本发布之前，我们要确保所作改动不会对已有的功能模块产生负面的影响。用所有的测试用例作回归测试， 存在着人力与时间成本过高的问题;依靠人的经验去挑选回归测试用例，存在着挑选不准确或对程序改动测试覆盖不全的问题。

　　图 1. 测试用例优化选择问题

　　回归测试覆盖率分析

　　测试用例优化选择可以有效地解决现有测试用例的覆盖问题，但在实际测试过程中，我们仍然发现存在着覆盖不全的问题。即新版本中的某些实现并不能被现有的测试用例所覆盖。这样，测试人员需要开发新的测试用例对新的功能进行测试覆盖。然后对于测试人员来说这并不实际，他们很难依靠测试经验将代码中没有被测试的地方找出来。那么如何更好的得到测试过程中的测试覆盖率，及测试结束后整个软件的测试覆盖率呢，从而使得测试人员可以针对未被测试到的地方设计新的测试用例。这里我们特别针对在版本更新过程中，那些发生了更新却没有被覆盖到的地方。

　　解决问题

　　原理

　　图 2. 测试用例优化选择原理

　　图 3. 测试用例优化选择举例

　　如上图所示，所有的测试用例都会有一个函数调用的路径。我们把这些调用路径一一记下来。对于新版本所作的改动，所有与之相关的上层调用的测试用例都能够准确地选出来，这样我们就能用这些准确的测试用例来覆盖这次改动所产生的影响。毫不相关的测试用例则不会被选出来。从而用较小的成本完成这次改动所需要的回归测试，既省时省力又保证较高的测试质量。

　　图 4. 覆盖率分析举例

　　如上图所示，在版本更新过程中受到影响的测试用例为 Test Case1， Test Case2， Test Case3 覆盖了 12 个 Node，在版本更新过程中的更新点是 4，其中被覆盖到的为 3，还有 1 个更新点没有被覆盖到，现有测试用例集合的更新覆盖能力为 75% 。这样，我们知道上一个版本的测试用例设计不够充分尚有程序模块没有被任何已有的测试用例所覆盖。由于代码的更新最有可能引起程序的缺陷甚至系统崩溃，所以需要添加新的测试用例以保证对更新的覆盖，以降低程序运行的风险。

　　对于软件的节点覆盖率，我们细化到函数粒度。我们是通过软件部署的 Binary 代码分析得知的函数情况。不需要借助源代码，因此对于软件进行测试覆盖率分析来说要求低，用较小的成本完成此次的测试用例覆盖反馈与分析。既省时省力又保证较高的测试质量。

原文转自：http://www.ltesting.net