软件回归测试及其实践(2)

　　测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行

　　维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其

　　中的问题，有必要追加新的测试用例来测试这些新的功能或特征。因此，测试用例库的维护工

　　作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例

　　无法覆盖的软件功能或特征。

　　测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要

　　内容包括下述几个方面。

　　(1)删除过时的测试用例

　　因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就

　　会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测

　　试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。

　　(2)改进不受控制的测试用例

　　随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状

　　态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要

　　进行改进，使其达到可重复和可控制的要求。

　　(3)删除冗余的测试用例

　　如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用

　　例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，

　　并将冗余的用例删除掉。

　　(4)增添新的测试用例

　　如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用

　　例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。

　　通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，

　　同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。

　　2、回归测试包的选择

　　在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回

　　归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，

　　时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来

　　完成回归测试。

　　回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归

　　测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果

　　采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归

　　测试的意图遭到破坏。

　　选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：

　　(1)再测试全部用例

　　选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测

　　试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任

　　何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增

　　多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。

　　(2)基于风险选择测试

　　可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关

　　键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即

　　便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要

　　特征。

　　(3)基于操作剖面选择测试

　　如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了

　　系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优

　　先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽

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