相信做过测试的人对回归测试都深有感触吧......特别是在进入Alpha， Beta之后，如果不幸发现产品的Bug不断、持续、稳定的出现，那么恭喜了，卖糕的知道需要做多少次回归测试。

　　真实项目中，即使是相当顺利地开发过程，通常也许要多轮的回归测试。只要是个正常人，在一轮轮的回归测试轰炸下，相信都有发狂的趋势。很多人把回归测试当作枯燥、无趣、低端的工作，认为这种测试没有什么价值，对自己也没有任何的提高。我猜存在这类想法的人主要有以下几个原因：

　　1、回归测试次数过多。当QM无法正确的评估代码改动对程序带来的风险时，通常最简单、最粗暴的方法就是“我们来一轮回归测试”！当然，还有更粗暴的：来一轮Full Cycle！

　　2、每轮回归测试中使用的相同的测试用例。虽然说回归测试的主要目的是验证代码的改动没有影响到程序原来的正常功能，但是这不是说就应该用相同的测试用例去做测试。使用完全相同的测试用例，一方面会造成测试疲劳，另一方面测试的效果也不会很好。

　　3、如何评估回归测试的效果。是不是说回归测试没有发现新的问题就说明产品没有问题，这次回归测试的目标已经达到？其实回归测试的本质目标是原来的产品代码没有引入新问题。回归测试的用例仅仅说明这些测试用例没有发现问题，而不是说新的代码没有对产品造成问题。所以如何评估回归测试的效果是整个环节中最后，也是很重要的一点。

　　上面说了这么多，我想大家也该明白要想真正的做好回归测试，也不是一件容易的事情了吧。

　　无论做什么，首先要明确目标！

　　回归测试的主要目标通常可以划分为：

　　1、确保系统的稳定性

　　2、对软件的质量建立足够的信心。

　　根据这两类目标，回归测试用例可以大致分为：

　　1、针对修改的测试用例。这类测试用例的目标是确保修改的正确性。

　　2、确保系统质量的测试用例。根据测试覆盖率和风险选择或者创建测试用例，用来保证系统质量“足够好”

　　第一种类型的测试用例通常的原则是：

　　1、发现Bug的case重新run，确保结果正确。

　　2、分析Bug Fix对系统直接相关的其他部分有没有影响。选择一些cases来验证。

　　这类测试的选择一般都比较直接。相对较复杂的是如何选择第二类测试用例，即如何保证系统整体的质量。

　　目前还没有什么通用的方法可以直接、方便、高效的选择回归测试用例。通常都是根据经验法则去作相应的选取。