浅谈如何分析回归测试的范围

近期和小伙伴们讨论自己公司关于保证不断迭代过程中，准确分析测试范围，在有限的人力和时间资源条件下，又快有准的对即将发布的版本进行测试。

测试范围分析的几个阶段：

一、没有正规的流程

      这种一般发生在文档不完善，甚至连测试用例都没有的公司。

      测试人员根据经验独自分析回归测试范围。比如修改A模块，回归测试就只覆盖A模块，有经验的，知道A模块与B模块有关联，回归A模块和B模块。

      这种方式会存在很大可能性，遗漏一些重要的回归项，很导致发布的版本不满足要求。对测试人员的工作积极性也是一个很大的打击。

      也可能由于测试发布的内容比较简单，每次都全量测试。

      全量测试这种方式，无疑对测试人员来说是一个极大的考验，每次的发版，做着重复的事情，很难说，

      测试人员在往后的测试中，还能真正意义上的执行全量测试。

      没有正规流程，最终系统的质量决定于测试人员的专业精神、责任心和对系统的熟悉程度。

二、经济常用的手段

     测试人员和开发、需求等其他相关人员，一起讨论分析覆盖的范围。 再执行这些范围内涉及的测试用例。

     同时也可能加上一些每个版本必须验证的用例，但这部分用例占比不会很大，主要保证系统主流程功能。

     这是目前大部分公司使用的手段。有了开发人员、需求人员分析的加持，这种方式比没有正规分析流程的方式可信度会提升一大截。

     这种方式的效果，取决于参会人员的专业程度和参与的深度。

三、有一定技术含量方法

     1、建立需求、用例对应的矩阵

     2、在用例中标识与之关联的其他用例，每次回归的时候，此用例回归，则与之关联的用例也需要回归

     3、建立代码块和用例对应的矩阵，根据修改的代码块，找到需要回归的用例

     这些方法的难度在于矩阵的建立和维护。但是可以从理论层面上得到一个有数据支撑的范围分析结果。

     目前公司的管理工具，对这块没有好的支持，如果有好的类似的工具，欢迎大家留言交流。