《16 软件测试技术与测试实训教程讲座(16 ) 第16章》由会员分享，可在线阅读，更多相关《16 软件测试技术与测试实训教程讲座(16 ) 第16章（10页珍藏版）》请在金锄头文库上搜索。
1、软件测试技术与测试实训教程黎连业 王华 李龙 黎照北京：机械工业出版社2012.05 第 16讲：第 16 章 回归测试的实用技术 回归测试（Regression Testing）作为软件生命周期的一个组成部分，在软件开发的各个阶段都可能会进行若干次回归测试，回归测试在整个软件测试过程当中占有很大的工作量比重。本章重点讨论以下内容： 回归测试概述； 回归测试用例库的维护方法； 回归测试的方法； 总结回归测试的结果； 回归测试自动化的问题； 回归测试实践总结； 回归测试文档； 人工回归测试实训和操作方法； 回归测试的自动化测试实训操作方法。 161 回归测试概述16.1.1 什么是回归测试在软件
2、生命周期中的任何一个阶段，只要软件发生修改变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，修改有可能而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误；同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响，我们就必须重新测试软件的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能，增添新的测试用例和原有的测试用例对软件再测试，这一特征为回归测试。回归测试不是一个特定的测试级别，只要对软件代码有修改，不论是修改错误还是增加新的功能或是提高性能，原则上都要进行回归测试，以保证对代码修改的
3、正确性，且不会对其余部分带来负面影响。回归测试可以通过重新执行所有的测试用例的一个子集进行，回归测试集包括三种类型的测试用例： 能够测试软件的所有功能的代表性测试用例； 专门针对可能会被修改影响的软件功能的附加测试； 针对修改过的软件成分的测试。 回归测试可以有选择地重复执行集成和系统测试的测试用例，回归测试变动比较小，同时测试所基于的实际硬件环境相对比较稳定。但回归测试要频繁地重复运行，需要的工作量很大，所以，回归测试最值得自动化。自动测试便于回归测试以非常高效的方式进行，软件开发的各个阶段都会进行多次回归测试。 16.1.2 回归测试的目的回归测试的目的是： 确认软件经过一些小的变更或修改
4、后是否仍满足所有的需求。 回归测试是重复测试，要求使用相同的方法，使用相同的测试用例和数据，在相同的环境下进行测试。16.1.3 回归测试的范围在进行回归测试的时候，必须决定回归测试的范围，具体表现为：(1) 测试所有修改或修正过的功能模块；(2) 测试与被修改的模块相关的模块；(3) 测试所有新增加的功能模块；(4) 测试整个系统。表现(1)、表现(2)和表现(3)中只进行了部分的回归测试，这样的测试是不健全的，因为在软件系统中，对本地代码的修改可能导致整个系统产生副作用。16.1.4 回归测试的基本过程回归测试的基本过程如图 16-1 所示。 识别出软件中被修改的部分； 从测试用例库中，排
5、除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库。 依据一定的策略从新的基线测试用例库中选择测试用例测试被修改的软件。 如果必要，生成新的测试用例集，用于测试新的基线测试用例库无法充分测试的软件部分。 用测试用例集执行修改后的软件。第和第步测试验证修改是否破坏了现有的功能，第和第步测试验证修改工作本身。 16.1.5 回归测试的策略回归测试需要时间、经费和人力来计划、实施和管理。为了尽可能有效地进行回归测试，需要对回归测试选择相应的策略。 （1）测试用例库的维护为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。测试用例的维护主
6、要包括： 删除过时的测试用例；改进不受控制的测试用例；3) 删除冗余的测试用例；4) 增添新的测试用例。（2） 回归测试人员的选择安排新的测试者完成回归测试。（3） 回归测试管理1）测试用例库的管理；2）回归测试执行管理；3）回归测试文档的管理。16.1.6 回归测试人员在回归测试过程当中，测试过程由一个测试经理（或组长）来监控测试工作的各个细节。而回归测试经常与系统测试和验收测试相关联，所以由测试经理（或组长）负责，确保选择合适的测试技术和在合理的质量控制中执行充分的回归测试。在回归测试工作中，回归测试人员将设计并实现测试新的扩展或增强部分所需的新测试用例，可结合自动化测试工具修改现有的测试
7、数据。在回归测试完成时，技术文档写作员负责整理并归档大量的回归测试结果，其中包括回归测试的总结报告、回归测试的结果记录和回归测试日志。回归测试人员的工作内容如表 16-1 所示。16.1.7 选择有效的回归测试包在软件测试中，测试用例库可能变得相当大，每次回归测试都重新运行完整的测试包变得不切实际，有时测试组不得不选择一个缩减的、有效的回归测试包来完成回归测试。 当测试组选择缩减的回归测试包时，要删除部分测试用例，删除哪些部分测试用例而不会让回归测试的意图遭到破坏。 要选择有效的回归测试用例组成回归测试包，选择回归测试用例的方式： (1) 再测试全部测试用例选择全部测试用例组成回归测试包，这是
8、一种比较安全的方法，但随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度，测试成本高。 (2) 选择重要的、关键的和可疑的测试用例选择重要的、关键的和可疑的测试用例，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。 (3)只测试修改的部分当测试者对修改的局部代码段有足够的信心认为没有新的错误时，可以不选择再测试全部用例的回归测试策略，只测试对修改的局部代码段；当测试者对修改的局部代码段没有信心时，要选择再测试全部用例的回归测试策略。16.1.8 人工回归测试流程人工回归测试流程如图 16-2 所示。16.1.9 自动化自动回归测试流程自
9、动化自动回归测试流程如图 16-3 所示。16.1.10 自动回归测试框架、作用和框架的技术特点1自动回归测试框架自动回归测试框架如图 16-4 所示。2 自动回归测试执行策略(1) 测试用例设计 最小分支原则; 封装、复用 ; 参数化; 动态加载。(2)脚本生成器 与测试用例设计的关系; 公用函数库 ; 对字符界面和 GUI 的支持 ; 配置管理。(3) 业务流管理器 选择测试用例，支持条件分支; 测试用例间的数据传递; 业务流管理：增、删、改、插入; 支持对同一个测试用例的多次引用和配置。(4) 数据管理器 选择业务流、测试用例 ; 显示测试用例参数列表; 方便地修改参数值。(5)测试调度
10、 预约（定时）执行 ; 选择需要执行的业务流 ; 执行测试; 出错处理。 3 自动回归测试框架的作用 降低管理难度，使用一个管理界面，隐藏管理细节 ; 测试设计和测试实现分离 ; 支持手工测试和自动测试 ; 分离技术性测试人员和非技术性测试人员的工作 ; 集成数据驱动、关键字驱动和功能分解测试的最好特征; 具备自动脚本生成功能 .4自动回归测试框架的技术特点 基于自动测试工具的测试框架，具有测试计划驱动技术的所有优点； 充分利用测试工具的功能，与测试管理集成； 基于业务流的测试，数据也是基于业务流配置的 ； 应用与自动测试框架分开； 可支持技术性测试人员和非技术性测试人员使用 ； 脚本与数据分
11、开 ； 自动测试开发与运行环境分开 ； 有专门的数据管理模块，数据维护简便 ； 自动生成代码，基本不需要编码，效率极高 ； 使用数据库，不需要手工管理大量文件 ； 采用基于组件的技术，提供预制组件 ； 支持业务功能脚本和录制脚本。 16.2 回归测试用例库的维护方法软件测试项目组在进行测试的过程中会将所用到的测试用例保存到“测试用例库”中，并进行维护，回归测试用例库的维护方法如下。16.2.1 删除过时的测试用例实用的测试用例是经过长期的工作积累而成的，但是随着项目的不同，使用环境的不同，原来成功的测试用例可能不适应新的环境，需要对原有的测试用例进行修改和删除。删除不是一味清除原有测试用例，而
12、是对原有的测试用例进行加工改造，使之适应新的应用项目。16.2.2 改进不受控的测试用例在测试用例库中，有的测试用例是可重复并且是可控制的，但是有的测试用例不是可控制的（有些对输入或运行状态十分敏感的测试用例是不容易重复而且是难以控制的，会影响回归测试的效率） ，需要进行改进，使其达到可重复和可控制的要求。16.2.3 删除冗余的测试用例在回归测试当中，有些测试用例随着项目的开展，难免会出现冗余（存在两个或者多个测试用例针对一组相同的输入和输出进行测试） ，所以需要定期的整理、维护测试用例库，将冗余的用例删除掉，并保存到回归测试用例库中，从而提高测试用例库的高效性和可用性。16.2.4 增添新
13、的测试用例测试用例随着应用的环境、功能、性能的不同，原有的测试用例库中的测试用例不能满足回归测试的要求，需要添加新的测试用例，如果某个程序段、构件或关键的接口发生了变化，那么应该开发新测试用例重新对其进行测试，并将新开发的测试用例合并到测试用例库中。新增添的测试用例事实上是对原有的测试用例库维护和更新，这样，不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个测试用例库的效率和效用保持在一个较高的级别上。16.3 回归测试的方法16.3.1 再测试全部用例把测试用例库的全部测试用例组成回归测试包进行测试，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但
14、测试时间、人员、设备、和经费成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超过了预算和进度。16.3.2 基于风险进行测试从测试用例库中选择测试用例进行回归。这种方法有一定的风险。选择测试用例首先要选择运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。16.3.3 基于操作进行测试如果测试用例库的测试用例是基于软件操作开发的，回归测试可以优先选择基于操作的测试用例，针对最重要或最频繁使用功能的测试用例，这种方法可以在一个给定的预算下最有效地提
15、高系统的可靠性，但实施起来有一定的难度。16.3.4 仅测试修改部分当测试者对修改的局部化有足够的信心时，可以仅测试修改部分，但要分析修改情况和修改的影响，回归测试尽可能覆盖受到影响的部分，但实施起来有一定的风险。在回归测试时，采用多种测试技术是常见的，表现在以下两个方面：(1) 如果测试者对一个修改的软件进行回归测试时，回归测试者可以采用多种回归测试方法，例如：采用回归测试工具，进而增加了对修改软件的信心；(2) 不同的回归测试者可能会根据自己的经验和判断选择不同的回归测试技术和方法。回归测试的方法比较如表 16-2 所示。 16.4 总结回归测试的结果在软件测试周期结束后，测试、开发人员对
16、回归测试的结果非常关注，因为他们想知道他们对 bug 修改是否达到的预期的结果，所以需要总结回归测试的结果。关于总结回归测试的结果，印度学者 Srinivasan Desikan Gopalawamy Ramesh 做了如下 5 点概括性的分析：（1）如果特定测试用例的执行结果对于以前的版本通过，而当前版本未通过，则回归未通过。需要提交新版本，并对测试用例重新设置后心头重新测试。（2）如果特定测试用例的执行结果对于以前的版本未通过，而当前的版本通过，则可以有把握地说缺陷修改有效。（3）如果特定测试用例的执行结果对于以前的版本未通过，而当前版本也通过，如果对于这个特定的测试用例没有针对缺陷修改，则可能意味着这个测试用例的执行结果应该未通过，而且在回归测试中不应该选择这类测试用例。（4）如果特定测试用例的执行结果对于以前的版本未通过，但是通过某种写入文nts
