如何做好回归测试

lsekfe

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

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

新特征\功能	Paging service	Refresh	Multiple selection	Highlight selection
Cascading Data	R	X	R
Search from server		X		X

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

  · 其次，创建一个”影响测试的列表”(Test Impact Checklist)

  这个列表可以有以下部分组成：

  1. 影响范围

  2. 对影响的描述

  3. 影响所影响的特定情节

  4. 代码变化部分，以及所影响的功能

  5. 开发人员所推荐的回归，我想研发过程中，养成dev在改动代码的时候向测试人员提供回归测试推荐的习惯实在是必要的。

  6. 对有依赖关系的特性的影响

  由于要达成某种改动的目的，也许需要其他特性做相应修改。

  策略

  执行回归测试，分为以下三个主要类型，也相应的分为以下三个阶段：

  第一阶段：

  提供被新功能或有依赖关系的改动直接影响的区域。这些区域至少要完成一组小的覆盖全部特性的基本功能的测试用例。

  第二阶段：

  把上个开发阶段(previous release)重复发现的问题列出来 – 这些信息可以从上个阶段的最终测试报告中找到。（也就是说每个阶段的测试报告需要包括重复发现的问题）

  同时，把客户关系和敏感的特性列出来 – 例如付费等。

  第三阶段：

  a. Hot-spot suite 这是基于前两个阶段发现的比较多的问题区域。因为，缺陷往往在比较容易发生缺陷的地方隐藏更多，所以，这样的地方是要增加人手测试的。

  b. 额外增加的测试，这些测试往往是由于晚期check-in代码，或者有依赖关系的特性改动。这个测试范围的定位需要再次使用”影响测试列表Test   Impact Checklist”.

  c. Sanity Test, 这是在产品发布给客户之前做的clean-run测试，类似于monkey test.

z-chad

学习了！！！厉害