如何做好回归测试

在总结回归测试的方法时发现，不管国内国外，这都是个头疼的话题。做是要做，也能做，但是从效率角度说可是千差万别。给我足够多的人或是时间，总是可以保证回归测试进行的彻底，可是那并不是做事情的方法和解决问题的手段。

　　从执行方法的角度看，回归测试大多要通过两种方式去执行：一类借助于工具完成的自动化测试，一类是手动完成。从回归测试的计划和策略上讲，一般有以下两种方法：

　　一、基于风险的

　　这是一个比较简单和常用的方法，顾名思义，就是在分析出改动所带来的风险以后，在易出错的地方进行回归测试以保证原有的功能没有被新的变化影响。这么看，对于新的改动的分析风险能力很重要。如何准确的获得风险列表呢?

　　大家最头疼的地方，也许就是风险所在

　　这可以从以往和dev以及product owner等人的会议及email的讨论中获得。

　　新功能的测试计划

　　在编写测试用例和写测试计划的时候，因为比较系统和全面的了解新功能，所以可以同时把可能的风险列出来，以供日后的回归测试来进行双重保证。

　　商业价值

　　说白了，就是最赚钱的地方，客户最在意的地方。因为这些地方的一点点小错误都可能引来客户的抱怨和不满，所以这些地方就尤其重要。相反，商业价值比较小的地方，有点错误也无伤大雅。那么，测试重点就该有所先后。

　　权重计算
　　影响产品质量的权重参数很多，我们可以估计和预测的有以下方面：
　　1. 项目架构，包括功能之间的依赖关系、功能的复杂度以及需求变更等；
　　2. 大小，多少人开发多少人测试；
　　3. 开发人员的能力，这个常常被忽略的因素往往起到很大的作用。我们可以从开发人员的薄弱环节，或是某个能力稍差的开发人员做的模块下手，找到bug是在情理之中的。