回归测试的想法

      回归测试是在测试阶段机动编写执行测试用例的过程。

 

一、回归测试出现在两个时机：

1、在测试阶段，开发修复一版后

针对开发修改的地方，需要做下列内容：

（1）立刻测试已修复的错误

开发可能已经处理了症状，但并未触及根本原因

（2）根据开发修改的逻辑，思考可能影响的地方

错误本身可能得到了修复，但修复也可能造成了其他错误

（3）对性能要求比较高的：跟踪程序内存更改的效果

（4）为每个修复的错误编写一个回归测试

如果回归自动化做的比较好，可以编写到回归自动化的系统内，每次提交版本，可做一次回归测试；

如果没有回归自动化系统，则可记录在bug的备注中，回归bug的时候可以做参考

在最后总结的时候，

2、bug修复完成，封版前的回归测试

封版前需要回归的地方：

（1）之前每次改动的地方是否最终都提交了

需要回归每次提版时编写的回归用例

（2）之前测试用例执行过的地方是否还生效

对主要的功能做回归测试

 

二、关于回归测试用例库

（1）测试库由一系列标准测试案例组成，每次生成程序的新版本时都可以运行这些案例

（2）生成测试案例库所涉及的最困难的方面是确定哪些测试案例

建议：避免花费过多的时间尝试做出决定并在小心谨慎方面犯错

（3）定期查看回归测试库以消除多余的或不必要的测试。每隔两个测试周期查看一次。

（4）关于改动过大的回归测试用例集的选择：

当错误或错误变种的持续时间特别长并且在许多测试周期中都存在时，需要编写大量的测试，并将它们添加到回归测试库；

需要注意的：虽然这些多样的测试对于修复错误是有用的，但是从程序中消除了对错误及其变种的跟踪时，应选择与错误关联的最佳测试，并将其余的测试从库中移除