回归测试相关概念及经验总结

最近发现随着流程越来越规范，测试的比重变得越来越大。特别是做回归测试的时候，

经常会耗费相当大的人力物力，却不得到理想的结果。所以网上收集了关于回归测试

的一些知识做一下总结。

1、测试用例库的维护

测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面。

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

　　因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。

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

　　随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。

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

　　如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。

　　(4)、增添新的测试用例

　　如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。

　2、回归测试包的选择

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

　　(1)、再测试全部用例

　　选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。

　　(2)、基于风险选择测试

　　可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。

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

　　如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。

　　(4)、再测试修改的部分

　　当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

上述4是比较理论上的做法，实际中很难确定一定的风险标准或者做出划出清晰的影响范围。所以下面

参考下51Testing上面的某人的经验

　　第一，新修改的功能，这个显然是重点；

　　第二，新修改的功能的关联功能，就是有耦合的部分，这个一般最好咨询一下开发人员；

　　第三，程序最有卖点或者说亮点的部分，这个地方一旦有问题，会使程序质量大打折扣；

　　第四，程序中最致命的部分，譬如说安全隐患，数据泄露，加密注册；

　　第五，程序中比较脆弱的部分，这个要咨询开发人员，一般就是他们心中最没底的地方；

　　第六，程序的主干功能；

　　第七，如果以上做完，还有时间的话，最好把用例中级别比较高的用例再执行一遍。

　　以上是回归测试用例的选择优先级。

感觉上述几个优先级还是比较实际的，在下次开发中实践看看