软件回归测试及其实践(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。

原文转自：http://www.uml.org.cn/Test/200463028.htm