 |
|
|
| 返回 | 主页 |
软件回归测试及其实践 下
[摘要]
如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用
例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，
同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
2、回归测试包的选择
在软件生命周期中，...
如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用
例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，
同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
2、回归测试包的选择
在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回
归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，
时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来
完成回归测试。
回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归
测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果
采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归
测试的意图遭到破坏。
选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：
(1)再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测
试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任
何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增
多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
(2)基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关
键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即
便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要
特征。
(3)基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了
系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优
先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽
早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统
可靠性，但实施起来有一定的难度。
(4)再测试修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分
析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及
一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部
分。
再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新
的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的
回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
3、回归测试的基本过程
有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述基本过程进
行:
(1) 识别出软件中被修改的部分；
(2) 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然
有效的测试用例，其结果是建立一个新的基线测试用例库T0。
(3)依据一定的策略从T0中选择测试用例测试被修改的软件。
(4)如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。
(5)用T1执行修改后的软件。
第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证 修改工
作本身。
三、回归测试实践
在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些
回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需
要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为
了支持多种回归测试策略，自动测试工具应该是通用的和灵活的，以便满足达到不同回归测试
目标的要求。
在测试软件时，应用多种测试技术是常见的。当测试一个修改了的软件时，测试者也可能
希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经
验和判断选择不同的回归测试技术和策略。
回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功能和特征的测
试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要
求。
回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际工
作中可以采用一些策略减轻这些问题。例如，安排新的测试者完成手工回归测试，分配更有经
验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。还
可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化的输入、按键和配
置能够有助于激励测试者又能揭示新的错误。
在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完
成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归
测试发现的问题集中修改，集中回归。
在实际工作中，可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的
测试可以发现兼容性问题，而同时也可以揭示编码在回归方面的错误。
参考文献：
[1] Glenford J.Myers，计算机软件测试技巧，清华大学出版社，1985。
[2] Robert V. Binder，面向对象系统的测试，人民邮电出版社，2001。
[3] Rex Black， 测试流程管理，北京大学出版社，2001。
其它培训参考信息：
软件回归测试及其实践 上
基于PB环境下的软件测试 下
基于PB环境下的软件测试 上
软件开发全过程检测及测试自动化
本地化测试错误分析与测试方法
软件测试的重中之重 下
软件测试的重中之重 上
如何挑选白盒测试工具 下
信息来自互联网，敬请核实，谨慎使用
