回归测试最佳实践--回归测试用例的优化选择与覆盖率分析
From:http://www.ibm.com/developerworks/cn/java/j-lo-regtest/java
回归测试对保证软件质量具备重要意义。要实现有效的回归测试，必须解决回归测试中的两个主要问题：（1）测试用例的优化选择；（2）覆盖率分析。前者决定了回归测试的效率，好的测试用例的选择能够用少许的测试用例准确地覆盖新版本中尽量多的改动。后者是度量测试的重要指标，经过达到良好的测试覆盖率，保证了回归测试的质量。算法
本文正是经过讨论如何优化选择测试用例，用最小的代价达到最大的覆盖率，从而找到回归测试的有效解决方案。数据库
存在的问题编程
对测试用例的选择，测试人员一般有两种做法。一种是，把相关的或是全部的模块的测试用例都选出来执行一遍；另外一种是，仅针对被 Fixed 的 APAR/Defect 进行检验，测试用例不多或是开发新的针对这个 Fixed 的测试用例。这两种方法都存在不足。第一种方法在测试时间有限的状况下，去执行全部的测试用例，会测试到不少无需再测试的测试用例，从而致使测试资源的浪费；第二种是很难确保 APAR/Defect 改动后，被测系统没有受到关联影响，很难保证测试质量。app
因为 Bug Fix 或者功能更新后，在新版本发布以前，咱们要确保所做改动不会对已有的功能模块产生负面的影响。用全部的测试用例做回归测试， 存在着人力与时间成本太高的问题；依靠人的经验去挑选回归测试用例，存在着挑选不许确或对程序改动测试覆盖不全的问题。框架
图 1. 测试用例优化选择问题
ide
测试用例优化选择能够有效地解决现有测试用例的覆盖问题，但在实际测试过程当中，咱们仍然发现存在着覆盖不全的问题。即新版本中的某些实现并不能被现有的测试用例所覆盖。这样，测试人员须要开发新的测试用例对新的功能进行测试覆盖。而后对于测试人员来讲这并不实际，他们很难依靠测试经验将代码中没有被测试的地方找出来。那么如何更好的获得测试过程当中的测试覆盖率，及测试结束后整个软件的测试覆盖率呢，从而使得测试人员能够针对未被测试到的地方设计新的测试用例。这里咱们特别针对在版本更新过程当中，那些发生了更新却没有被覆盖到的地方。学习
图 2. 测试用例优化选择原理
图 3. 测试用例优化选择举例
如上图所示，全部的测试用例都会有一个函数调用的路径。咱们把这些调用路径一一记下来。对于新版本所做的改动，全部与之相关的上层调用的测试用例都可以准确地选出来，这样咱们就能用这些准确的测试用例来覆盖此次改动所产生的影响。绝不相关的测试用例则不会被选出来。从而用较小的成本完成此次改动所须要的回归测试，既省时省力又保证较高的测试质量。
如上图所示，在版本更新过程当中受到影响的测试用例为 Test Case1, Test Case2, Test Case3 覆盖了 12 个 Node，在版本更新过程当中的更新点是 4，其中被覆盖到的为 3，还有 1 个更新点没有被覆盖到，现有测试用例集合的更新覆盖能力为 75% 。这样，咱们知道上一个版本的测试用例设计不够充分尚有程序模块没有被任何已有的测试用例所覆盖。因为代码的更新最有可能引发程序的缺陷甚至系统崩溃，因此须要添加新的测试用例以保证对更新的覆盖，以下降程序运行的风险。
对于软件的节点覆盖率，咱们细化到函数粒度。咱们是经过软件部署的 Binary 代码分析得知的函数状况。不须要借助源代码，所以对于软件进行测试覆盖率分析来讲要求低，用较小的成本完成这次的测试用例覆盖反馈与分析。既省时省力又保证较高的测试质量。
基于对问题 1) 和问题 2) 的原理分析，咱们设计并实施了回归测试的解决方案，以下图所示。它包含了 3 个主要步骤。一是测试用例的录入；二是对新旧两个版本的变动分析；3、经过测试用例优化选择和覆盖率分析，获得相应的测试用例优化选择报告，和覆盖率分析报告。
步骤一， Trace Test Case 负责录制测试用例，并将捕获到的测试用例的 Runtime Trace 存放到数据库中；
测试用例在后台运行中的 Runtime Trace 是动态分析 (Dynamic Analysis) 中的重要信息。这些实际的运行信息为测试用例的优化选择和覆盖率分析创造了条件。下面是测试用例跟踪的框架图：
从上图咱们能够看出，测试人员触发 Trigger 以后，会启动 Agent Controller 。 Agent Controller 一直对 JVM 中的 JVMTI 进行监听，以获取部署在 JVM 上的被测应用程序。这些 Agent Controller 还负责将收集到的数据传输给 Data Collector 。又 Data Collector 将这些 Runtime Trace 写入以下表所示的数据库表中。
注意：函数的 Signature 信息做为函数的参数标识也须要记录下来。以区别同名不一样参数的函数。
步骤二， Change Analysis 用于将新旧两个版本做比较，获得 Change Report，即程序变动报告，能够精确到 Method 粒度。通常来讲代码变动有 4 种级别，分别为包级别 (Package)，类级别 (Class)，函数级别 (Method) 及语句级别 (Statement) 。
对于包级别和类级别来讲，比较的力度过粗，会影响到回归测试优化的质量。而函数级别和语句级别都能起到很好的回归测试的做用。其中语句级别由于粒度最细，等到的分析结果也最精确，回归测试质量最高。但与函数级别的变动分析相比，回归测试的质量相差颇有限，但形成了过多的执行时间代价，影响了回归分析的效率。所以咱们采用函数级别的变动分析做为回归测试的变动粒度。
肯定比较粒度以后，能够选择分析比较的方法。最简单的经常使用比较方法就是文本比较。包括源代码和可执行文件 (binary code) 的文本比较。根据 Java 语言面向对象的特色，还能够采用基于面向对象分析的比较方法。后者获得的分析粒度更细，可是所花的代价也越高。
步骤三， 在经过测试用例录制获得测试用例具体的 Runtime Trace 信息，以及经过 Change 分析获得新旧两个版本的变动信息以后，咱们能够对测试用例优化问题及覆盖率分析问题进行求解。
Test Case Prioritization 中，经过测试用例与运行的 Runtime Trace 进行匹配获得相关的测试用例。并利用测试用例优化排序算法对相关的测试用例进行排序，获得优化结果。如今的优化排序算法有多种，这里不对优化排序算法进行讨论。
Coverage Analysis 中，经过对已被相关测试用例覆盖的 Method 数量，及未被测试用例覆盖到的 Method 数量的分析，能够获得基于代码更新的覆盖率报告。测试人员获得这份报告以后，能够找到未被覆盖到的 Method，并对其进行针对性的开发新的测试用例。以完成对新功能的覆盖。
咱们能够看到步骤一，二共同服务于测试用例优化选择和覆盖率分析两个模块。有了测试用例的 Runtime Trace 和 Change Report. 咱们能够将 Change 结果与 Runtime Trace 进行匹配，找出能覆盖程序更改的测试用例。一样，对于没有被测试用例覆盖到的 Change 部分。因为没有相关测试用例被找出，咱们现有的测试用例是不足的，须要针对未被覆盖到的 Change 部分开发新的测试用例。
而覆盖率做为软件测试的一项重要指标，能够根据已经获得覆盖和未被覆盖的 method 进行求解，即已获得覆盖的 change method 数与总的 change method 之比。
基于以上的回归测试解决方案，咱们对一个有着 30 个测试用例的程序进行回归测试，获得以下测试用例优化选择分析报表：
Change Analysis Report
表 1 优化选择测试用例: 3 (of Total 30)
分析报告显示此次代码变动共有 12 个函数发生了更改。在 30 个测试用例中有 3 个测试用例与这些更改相关，它们覆盖了此次代码更改 12 个中的 10 个。而其它 27 的测试用例则与这 12 个代码改动绝不相关。
从表中咱们能够看到，通过测试用例优化选择以后，咱们选出了 3 个和函数变动相关的测试用例，达到了 83.3% 的覆盖率。同时因为 27 个与函数变动无关的测试用例不须要重测，使得 90% 的回归测试资源获得了节省。
从上图，咱们能够清楚地看到基于每一个函数改动的相关测试用例的数目，以及测试覆盖率。好比 ManageCommodityAction 这个 Class 里面，存在了 2 个 Change Method, 只有 1 个 changed method 被现有的 1 个 Test Case 所覆盖，测试覆盖率为 50% 。
上面分析报告中总共有 12 个函数发生改动，基中还有 2 个没有被任何测试用例覆盖到。那么未被覆盖的 Change Method 就须要测试人员对之进行分析而且添加新的测试用例以提升咱们的测试覆盖率 , 保证测试质量。
回归测试用例的优化选择，以最少的测试用例，准确地覆盖所做改动，极大地提升了咱们回归测试的测试效率与测试质量。
自动测试过程当中的覆盖率反馈分析，以最小的测试代价，最精确的分析，来得到当前的测试完成状况，为测试人员提升了良好的分析报告，以便测试人员改进和新增新的测试用例。大大提升了回归测试的测试效率与质量。
本文不带有任何明示或暗含的保证。文章提供的建议或最佳实践只做为通常的经验分享，做者不保证这些建议或最佳实践在任何状况下都有效。本文中任何带有主观性的陈述都只表明本文做者我的的观点，不表明 IBM 公司的官方立场。相关细节，请直接咨询做者。
学习
- “Rational Edge: 加快回归测试的步伐：累积测试分析和目标测试入门” （developerWorks，2006 年 10 月）：本文来自于 Rational Edge：一般所说的“累积测试分析（Cumulative Test Analysis）”技术向软件测试团队提供了对自动化测试更合理的方法，特别是在回归测试集的领域内。理解 CTA 如何提升您的测试效率。
- “基于 RFT 和 STAF 进行的无需人工干预的跨平台自动化回归测试”（developerWorks，2008 年 8 月）：本文随着回归测试的自动化程度不一样，而结合 Rational Functional Tester (RFT) 进行无需人工干预的跨平台并发自动化回归测试。
- 浏览 技术书店获取关于这些主题和其余技术主题的书籍。
- developerWorks Java 技术专区：查找数百篇有关 Java 编程各方面的文章。
讨论
邓俊宁，软件工程师，IBM CDL TAAS (Test as a Service) Competency Center 部门。从 2000 年开始从事 IT 软件开发设计工做，在 Java 和 Web 开发方面有丰富的经验。如今 IBM 软件开发中心从事软件测试工做，是 TAAS 自动化测试工做组的核心成员之一。
黄胜，研究员，IBM CRL Service Building Technology(SBT) 部门。如今 IBM CRL SBT 测试小组从事研究工做，是测试小组核心成员之一。回归测试解决方案的主要设计人员和开发团队 Leader。
陈旸，IBM 中国研究院实习生。回归测试解决方案开发团队的主要成员之一。