从年前开始做一个产品新build的regression 测试，因为是第一次接触产品，之前没有时间去了解功能，着实花了很多时间，连续加班半个月，还是有点累人的。在这里总结一下这大半个月的工作，从中学到知识得到成长。

　　结合实践，我希望对regression有更加透彻的理解，以帮助日后的工作：

　　查了一些资料，先从原理来理解。

　　Regress 的英语定义是： return to a worse or lessdeveloped state

　　而Regression test 的意义在于：在新版本上运行所有已通过测试的case，从而验证新版本的稳定性。

　　在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。

　　在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准（Baseline）。

　　如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因）引起的，那么测试用例的基准就要修改，以便和新的功能保持一致。

　　针对一个Bug Fix，我们也要作Regression Test。

　　（1）验证新的代码的确把缺陷改正了。

　　（2）同时要验证新的代码没有把模块的现有功能破坏，没有Regression。

　　回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。

　　结合上面的原理，我总结有以下几点：

　　1. Regression测试主要目的是验证模块和功能是否出现倒退，以前修过的bug是否重新复发；

　　2. Regression测试除了围绕上面两个工作展开，还需要进行测试用例baseline的维护工作：

　　a) 模块功能的正常变化所引起的不符合，需要及时更正case；

　　b) 把上一个版本所出现并且修复的缺陷及时的引入到case库里面；

　　c) 把功能的变更和名称的改动及时地反映到case里面；

　　3. Regression测试中也会遇到以前版本里面本来就存在但没有被发现的缺陷，但这些缺陷不应该作为重点验证的部分，因为regression测试的主要目的是发现因为修改而出现的倒退现象；

　　4. 为了节省时间和精力，节约成本，regression测试应该重点侧重于分析因为上一版本所改动部分可能引起的问题并重点验证，而不要过多的集中于一些边缘测试和性能测试等；

　　这就是我这次项目所学到的东西，帮助我对下一次regression测试的效率和重点有所调整。也希望对你有所帮助！

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。

本文出自rose62yl的51Testing软件测试博客：http://www.51testing.com/?109108