在总结回归测试的方法时发现，不管国内国外，这都是个头疼的话题。做是要做，也能做，但是从效率角度说可是千差万别。给我足够多的人或是时间，总是可以保证回归测试进行的彻底，可是那并不是做事情的方法和解决问题的手段。我觉得google的James Whittaker说的好“事实上，有些测试组坚持要保持一个规模相对比较大的团队主要是因为他们的假设前提就是有些事情做错了。这也意味着编码和测试之间的工作失衡。添加更多的测试人员并不能解决任何问题。”“In fact， teams that insist on having a large testing presence are generally assumed to be doing something wrong. Having too large a test team is a very strong sign that the code/test mix is out of balance. Adding more testers is not going to solve anything.”当然，google把quality交给developer去own才能将测试人员的工作真正做到是质量环节的最后确保。而不是去检查developer犯的错误。

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

　　一、基于风险的

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

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

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

　　● 新功能的测试计划

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

　　● 商业价值

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

　　● 权重计算

　　影响产品质量的权重参数很多，我们可以估计和预测的有以下方面：

　　1. 项目架构，包括功能之间的依赖关系、功能的复杂度以及需求变更等

　　2. 大小，多少人开发多少人测试

　　3. 开发人员的能力，这个常常被忽略的因素往往起到很大的作用。我们可以从开发人员的薄弱环节，或是某个能力稍差的开发人员做的模块下手，找到bug是在情理之中的。

　　二、矩阵法

　　这种方法虽然麻烦，但是却最高效，也是目前看来最佳的办法。但是这个方法的执行需要QA manager有很强的执行能力以及一个沟通比较通畅的团队。以下为这种方法执行的具体步骤：

　　● 首先，创建一个影响回归的功能\特性矩阵（regression impact matrix）

　　列出所有的特征和功能，例如

　　“X” 表示新特性将对已有功能造成直接影响；”R” 表示 新特性对已有功能存在间接影响。