16 软件测试技术与测试实训教程讲座16 第16章.docx
《16 软件测试技术与测试实训教程讲座16 第16章.docx》由会员分享，可在线阅读，更多相关《16 软件测试技术与测试实训教程讲座16 第16章.docx（16页珍藏版）》请在冰豆网上搜索。
16软件测试技术与测试实训教程讲座16第16章
软件测试技术与测试实训教程
黎连业王华李龙黎照
北京：
机械工业出版社
2012.05
第16讲：
第16章回归测试的实用技术
回归测试（RegressionTesting）作为软件生命周期的一个组成部分，在软件开发的各个阶段都可能会进行若干次回归测试，回归测试在整个软件测试过程当中占有很大的工作量比重。
本章重点讨论以下内容：
★回归测试概述；
★回归测试用例库的维护方法；
★回归测试的方法；
★总结回归测试的结果；
★回归测试自动化的问题；
★回归测试实践总结；
★回归测试文档；
★人工回归测试实训和操作方法；
★回归测试的自动化测试实训操作方法。
16．1回归测试概述
16.1.1什么是回归测试
在软件生命周期中的任何一个阶段，只要软件发生修改变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，修改有可能而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误；同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响，我们就必须重新测试软件的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能，增添新的测试用例和原有的测试用例对软件再测试，这一特征为回归测试。
回归测试不是一个特定的测试级别，只要对软件代码有修改，不论是修改错误还是增加新的功能或是提高性能，原则上都要进行回归测试，以保证对代码修改的正确性，且不会对其余部分带来负面影响。
回归测试可以通过重新执行所有的测试用例的一个子集进行，回归测试集包括三种类型的测试用例：
★能够测试软件的所有功能的代表性测试用例；
★专门针对可能会被修改影响的软件功能的附加测试；
★针对修改过的软件成分的测试。
回归测试可以有选择地重复执行集成和系统测试的测试用例，回归测试变动比较小，同时测试所基于的实际硬件环境相对比较稳定。
但回归测试要频繁地重复运行，需要的工作量很大，所以，回归测试最值得自动化。
自动测试便于回归测试以非常高效的方式进行，软件开发的各个阶段都会进行多次回归测试。
16.1.2回归测试的目的
回归测试的目的是：
★确认软件经过一些小的变更或修改后是否仍满足所有的需求。
★回归测试是重复测试，要求使用相同的方法，使用相同的测试用例和数据，在相同的环境下进行测试。
16.1.3回归测试的范围
在进行回归测试的时候，必须决定回归测试的范围，具体表现为：
（1）测试所有修改或修正过的功能模块；
（2）测试与被修改的模块相关的模块；
（3）测试所有新增加的功能模块；
（4）测试整个系统。
表现
（1）、表现
（2）和表现（3）中只进行了部分的回归测试，这样的测试是不健全的，因为在软件系统中，对本地代码的修改可能导致整个系统产生副作用。
16.1.4回归测试的基本过程
回归测试的基本过程如图16-1所示。
①识别出软件中被修改的部分；
②从测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库。
③依据一定的策略从新的基线测试用例库中选择测试用例测试被修改的软件。
④如果必要，生成新的测试用例集，用于测试新的基线测试用例库无法充分测试的软件部分。
⑤用测试用例集执行修改后的软件。
第②和第③步测试验证修改是否破坏了现有的功能，第④和第⑤步测试验证修改工作本身。
16.1.5回归测试的策略
回归测试需要时间、经费和人力来计划、实施和管理。
为了尽可能有效地进行回归测试，需要对回归测试选择相应的策略。
（1）测试用例库的维护
为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。
测试用例的维护主要包括：
删除过时的测试用例；
改进不受控制的测试用例；
3）删除冗余的测试用例；
4）增添新的测试用例。
（2）回归测试人员的选择
安排新的测试者完成回归测试。
（3）回归测试管理
1）测试用例库的管理；
2）回归测试执行管理；
3）回归测试文档的管理。
16.1.6回归测试人员
在回归测试过程当中，测试过程由一个测试经理（或组长）来监控测试工作的各个细节。
而回归测试经常与系统测试和验收测试相关联，所以由测试经理（或组长）负责，确保选择合适的测试技术和在合理的质量控制中执行充分的回归测试。
在回归测试工作中，回归测试人员将设计并实现测试新的扩展或增强部分所需的新测试用例，可结合自动化测试工具修改现有的测试数据。
在回归测试完成时，技术文档写作员负责整理并归档大量的回归测试结果，其中包括回归测试的总结报告、回归测试的结果记录和回归测试日志。
回归测试人员的工作内容如表16-1所示。
16.1.7选择有效的回归测试包
在软件测试中，测试用例库可能变得相当大，每次回归测试都重新运行完整的测试包变得不切实际，有时测试组不得不选择一个缩减的、有效的回归测试包来完成回归测试。
当测试组选择缩减的回归测试包时，要删除部分测试用例，删除哪些部分测试用例而不会让回归测试的意图遭到破坏。
要选择有效的回归测试用例组成回归测试包，选择回归测试用例的方式：
（1）再测试全部测试用例
选择全部测试用例组成回归测试包，这是一种比较安全的方法，但随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度，测试成本高。
（2）选择重要的、关键的和可疑的测试用例
选择重要的、关键的和可疑的测试用例，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。
（3）只测试修改的部分
当测试者对修改的局部代码段有足够的信心认为没有新的错误时，可以不选择再测试全部用例的回归测试策略，只测试对修改的局部代码段；当测试者对修改的局部代码段没有信心时，要选择再测试全部用例的回归测试策略。
16.1.8人工回归测试流程
人工回归测试流程如图16-2所示。
16.1.9自动化自动回归测试流程
自动化自动回归测试流程如图16-3所示。
16.1.10自动回归测试框架、作用和框架的技术特点
1．自动回归测试框架
自动回归测试框架如图16-4所示。
2．自动回归测试执行策略
（1）测试用例设计
★最小分支原则;
★封装、复用;
★参数化;
★动态加载。
（2）脚本生成器
★与测试用例设计的关系;
★公用函数库;
★对字符界面和GUI的支持;
★配置管理。
（3）业务流管理器
★选择测试用例，支持条件分支;
★测试用例间的数据传递;
★业务流管理：
增、删、改、插入;
★支持对同一个测试用例的多次引用和配置。
（4）数据管理器
★选择业务流、测试用例;
★显示测试用例参数列表;
★方便地修改参数值。
（5）测试调度
★预约（定时）执行;
★选择需要执行的业务流;
★执行测试;
★出错处理。
3．自动回归测试框架的作用
★降低管理难度，使用一个管理界面，隐藏管理细节;
★测试设计和测试实现分离;
★支持手工测试和自动测试;
★分离技术性测试人员和非技术性测试人员的工作;
★集成数据驱动、关键字驱动和功能分解测试的最好特征;
★具备自动脚本生成功能.
4．自动回归测试框架的技术特点
★基于自动测试工具的测试框架，具有测试计划驱动技术的所有优点；
★充分利用测试工具的功能，与测试管理集成；
★基于业务流的测试，数据也是基于业务流配置的；
★应用与自动测试框架分开；
★可支持技术性测试人员和非技术性测试人员使用；
★脚本与数据分开；
★自动测试开发与运行环境分开；
★有专门的数据管理模块，数据维护简便；
★自动生成代码，基本不需要编码，效率极高；
★使用数据库，不需要手工管理大量文件；
★采用基于组件的技术，提供预制组件；
★支持业务功能脚本和录制脚本。
16.2回归测试用例库的维护方法
软件测试项目组在进行测试的过程中会将所用到的测试用例保存到“测试用例库”中，并进行维护，回归测试用例库的维护方法如下。
16.2.1删除过时的测试用例
实用的测试用例是经过长期的工作积累而成的，但是随着项目的不同，使用环境的不同，原来成功的测试用例可能不适应新的环境，需要对原有的测试用例进行修改和删除。
删除不是一味清除原有测试用例，而是对原有的测试用例进行加工改造，使之适应新的应用项目。
16.2.2改进不受控的测试用例
在测试用例库中，有的测试用例是可重复并且是可控制的，但是有的测试用例不是可控制的（有些对输入或运行状态十分敏感的测试用例是不容易重复而且是难以控制的，会影响回归测试的效率），需要进行改进，使其达到可重复和可控制的要求。
16.2.3删除冗余的测试用例
在回归测试当中，有些测试用例随着项目的开展，难免会出现冗余（存在两个或者多个测试用例针对一组相同的输入和输出进行测试），所以需要定期的整理、维护测试用例库，将冗余的用例删除掉，并保存到回归测试用例库中，从而提高测试用例库的高效性和可用性。
16.2.4增添新的测试用例
测试用例随着应用的环境、功能、性能的不同，原有的测试用例库中的测试用例不能满足回归测试的要求，需要添加新的测试用例，如果某个程序段、构件或关键的接口发生了变化，那么应该开发新测试用例重新对其进行测试，并将新开发的测试用例合并到测试用例库中。
新增添的测试用例事实上是对原有的测试用例库维护和更新，这样，不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个测试用例库的效率和效用保持在一个较高的级别上。
16.3回归测试的方法
16.3.1再测试全部用例
把测试用例库的全部测试用例组成回归测试包进行测试，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试时间、人员、设备、和经费成本最高。
全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超过了预算和进度。
16.3.2基于风险进行测试
从测试用例库中选择测试用例进行回归。
这种方法有一定的风险。
选择测试用例首先要选择运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例。
16.3.3基于操作进行测试
如果测试用例库的测试用例是基于软件操作开发的，回归测试可以优先选择基于操作的测试用例，针对最重要或最频繁使用功能的测试用例，这种方法可以在一个给定的预算下最有效地提高系统的可靠性，但实施起来有一定的难度。
16.3.4仅测试修改部分
当测试者对修改的局部化有足够的信心时，可以仅测试修改部分，但要分析修改情况和修改的影响，回归测试尽可能覆盖受到影响的部分，但实施起来有一定的风险。
在回归测试时，采用多种测试技术是常见的，表现在以下两个方面：
（1）如果测试者对一个修改的软件进行回归测试时，回归测试者可以采用多种回归测试方法，例如：
采用回归测试工具，进而增加了对修改软件的信心；
（2）不同的回归测试者可能会根据自己的经验和判断选择不同的回归测试技术和方法。
回归测试的方法比较如表16-2所示。
16.4总结回归测试的结果
在软件测试周期结束后，测试、开发人员对回归测试的结果非常关注，因为他们想知道他们对bug修改是否达到的预期的结果，所以需要总结回归测试的结果。
关于总结回归测试的结果，印度学者SrinivasanDesikanGopalawamyRamesh做了如下5点概括性的分析：
（1）如果特定测试用例的执行结果对于以前的版本通过，而当前版本未通过，则回归未通过。
需要提交新版本，并对测试用例重新设置后心头重新测试。
（2）如果特定测试用例的执行结果对于以前的版本未通过，而当前的版本通过，则可以有把握地说缺陷修改有效。
（3）如果特定测试用例的执行结果对于以前的版本未通过，而当前版本也通过，如果对于这个特定的测试用例没有针对缺陷修改，则可能意味着这个测试用例的执行结果应该未通过，而且在回归测试中不应该选择这类测试用例。
（4）如果特定测试用例的执行结果对于以前的版本未通过，但是通过某种写入文档的迂回方法可以通过，而且测试人员也对这种迂回方法感到满意，则可以认为对于系统测试周期和回归测试周期都通过。
（5）如果测试人员对迂回不满意，则可以认为系统测试周是未通过，但是回归测试周期是通过的。
总结回归测试结果的内容通过归纳，如表16-3所示。
16.5回归测试自动化的问题
对于回归测试自动化工具的问题，目前有回归测试自动操作工具的供应商，但是需要考虑的组件和方面有：
（1）系统应是自动构造程序。
表现为：
服务需要自动编译、自动部署。
（2）回归测试自动化工具可以构造与实际使用场景相似的测试用例。
（3）回归测试自动化工具一般只可以进行框架的测试。
（4）使用回归测试自动化工具产生统一的结果报告，这样不用重复花时间去检验测试执行结果。
16.6回归测试实践总结
回归测试工作是一件有意义的工作，但是，在实际工作当中，回归测试需要反复不断地进行，使得回归测试变得非常繁琐，表现为重复性地工作，容易使测试者感到枯燥无味，工作积极性不高，以至于降低测试效率。
在实际工作中可以采用以下途径克服这类问题。
1.组织回归测试时需要注意的问题
组织回归测试时需要注意两点：
（1）各测试阶段发生的修改一定要在本测试阶段内完成回归测试，以免将错误遗留到下一回归测试阶段；
（2）回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改、集中回归。
2.重新进行回归测试时需要注意的问题
重新进行回归测试时需要注意的问题有四点：
（1）安排新的测试者完成回归测试；
（2）分配更有经验的测试者开发新的回归测试用例；
（3）在不影响测试目标的前提下，鼓励测试者创造性地执行回归测试用例（变化的输入、按键和配置有助于激励测试者揭示新的错误）；
（4）在回归测试当中，可以将回归测试与兼容性测试结合起来进行。
3.回归测试人员应掌握的测试手段
测试人员应该尽可能的从以下几个方面掌握回归测试的手段：
（1）要熟悉系统的业务流程，对业务需求以及相关联模块要非常清楚，保证回归测试的质量和效率；
（2）及时更新和维护回归测试用例库当中的测试用例，确保执行的回归测试用例是最新的；
（3） 要掌握回归测试的测试用例优先级别，对优先级高的功能模块优先进行回归测试测试；
（4）使用回归测试自动化工具进行测试；
（5） 回归测试人员应及时与开发人员进行有效的沟通，及时地反馈回归测试测试情况；
（6）回归测试人员应该熟悉并掌握系统开发的各种计算机类语言。
16.7回归测试文档
16.7.1工作开始前所需的文档
回归测试进行前需要以下文档资料：
★测试计划；
★需要进行的测试列表；
★被测程序源码；
★回归测试用例。
16.7.2工作结束后递交的文档
回归测试结束后需要递交以下文档资料：
★回归测试的总结报告；
★回归测试的结果记录；
★回归测试日志。
16.8人工回归测试实训和操作方法
人工回归测试实训和操作的内容主要包括：
回归测试持续执行的改进计划;人工回归测试的输入输出图;针对手机信息管理系统模型进行人工回归测试的测试用例、实训和操作方法。
1．回归测试持续执行的改进计划
对于回归测试的一些基本的理论和实用的技术，在前面16.1节~16.7节里已经做了详细的介绍，在这里，我们直接给出人工回归测试持续执行改进计划图,如图16-5所示。
从图16-5中就可以看出，回归测试是在不断的“计划->执行->检查->改进”过程中进行的。
2.人工回归测试的输入输出图
人工回归测试的输入输出图,如图16-6所示。
由图16-5和图16-6，我们就知道了接下来的工作：
对未被修改和已经修改的内容，进行重新测试，包括重新运行以前执行过的测试，确保当前测试与原来测试获得相同的结果。
回归测试的测试用例书写起来是比较简单的，它包括两个部分，一个是已经存在的测试用例，另一个是发现bug后我们要针对这些bug可能影响的地方进行书写的用例，这两个部分的测试预期结果也是已知的。
3.针对手机信息管理系统模型进行人工回归测试的测试用例、实训和操作方法
针对手机信息管理系统模型进行人工回归测试的测试用例、实训和操作方法，如表16-4所示。
16.9回归测试的自动化测试实训操作方法
自动化回归测试实训和操作的内容主要包括：
自动化回归测试工作中的问题;自动化回归测试解决方案;手机信息管理系统回归测试案例。
16.9.1自动化回归测试工作中的问题
自动化回归测试需要频繁的执行，再执行，去检查曾经使用过的执行已经通过的测试用例是否因为软件的变动而执行失败。
自动化回归测试需要反复执行，并且单调乏味。
怎样才能做好自动化回归测试文档化的工作呢？
通常的做法是采用列有产品特性的列表，然后对照列表检查。
这是个很好的开始，自动化回归测试检查列表可以告诉你应该测试哪些方面。
不过，自动化回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。
16.9.2自动化回归测试解决方案
在开始自动化回归测试之前，我们需要完善回归测试检查表，决定采用什么样的测试方法，确定测试中所用到的数据，并给出设计数据的完整方法。
如果一个项目的工期充足，我们应该制定一个详细回归测试设计方案。
设计方案是应当仔细检查缺陷跟踪库中与待测模块相关的所有已经关闭的缺陷，针对每个缺陷，重新编写能够发现该问题的测试执行操作。
在回归测试方案中应该明确表明哪些部分适合使用自动化测试。
测试项目计划中，每个测试阶段采用什么样的测试方式，手工或者自动化，那么我们在回归测试时也要根据项目计划来采用哪种方式进行测试。
关于测试的方法我们就不在多说，同其他阶段的测试执行一样，回归测试只是其他测试阶段的重复劳动而已。
16.9.3手机信息管理系统回归测试案例
下面我们来看以手机信息管理系统为例进行讲解一个完整的自动化回归测试。
1．测试背景情况
本次测试为针对功能测试进行自动化回归测试，各个监测点详见表16-6。
表16-6为本次测试的测试模块、检查目标以及检查方法和工具。
自动化回归测试的测试用例需要进行增加、修改等操作应及时修改并进行保存，便于后续工作的开展。
如表16-7中测试所用到的测试用例。
被测软件模型手机信息管理系统为自行开发版本没有后续版本的问题，不存在原先版本测试用例的复用机审查工作，假如需要增加新工作，进行回归测试的目的也就体现出来了，目的在于检查原有测试用例在新添加功能点后是否适用，假如不适用就需要重新修改制定。
切忌要注意，不要对原先已执行通过的测试用例不进行任何验证性操作就使用，回归测试工作的重点就在于测试用例的选择、修改、添加及维护。
回归测试的重要性我们从阿里亚娜5型火箭发射失败例子中就能够看到。
导致其失败的主要原因就是由于复用的代码没有经过充分的回归测试造成的。
本次执行自动化回归测试的用例如表16-7所示
本次测试用例采用原先录制好的测试用例脚，脚本详见本书本书要附赠一张光盘中功能测试脚本。
因执行方式及测试方法用例均为重复功能测试工作，此处不再过多累述。
表16-8为本次回归测试执行的结果。
第16讲完
谢谢！
升级会员 