文章目的
本文是作者在创业公司进行测试过程中，通过对每次迭代测试工作进行总结和改进而提出的一套行之有效的测试分析方法，能通过此方法，在保证可接受的质量前提下，缩小迭代所需的测试范围，提高测试效率。该方法经过几次迭代实践，可操作性强，无难度，能达到事半功倍的效果，特别适合在初创公司（研发流程不规范）实践。
背景
提出此方法的原因是因为我们的软件经过半年迭代后，功能相比初期增加了很多功能模块，功能交互也变得复杂，测试用例从200-300条增长至1000条，在测试人员没有相应增加的情况下，每次回归测试（FFT）无法在2-3天之内完成，已经到了通过加班无法解决的状况，且每次回归测试后我们发现的缺陷不多，但是确实有严重bug和测试的必要性。在不能不做的情况下，我们被迫做出改变，在牺牲一定质量的情况下，提高测试效率，保证产品能按时发布。
回归缺陷产生的原因
在谈如何做回归测试分析前，先分析一下回归缺陷产生的原因，熟悉缺陷产生的原因是测试分析的基础，才能准确的找出缺陷可能产生的地方，从而能准确的找出测试范围。
这里不谈缺陷产生的如下两个原因，因为这类bug主要在新功能提测的期间产生，回归测试不应该出现。
1.需求描述不清楚
2.沟通不畅
我认为，在每次的迭代周期里回归缺陷产生的根本原因只有一个，就是软件代码由于某些原因发生了变化，变化的过程中没有控制好质量引入的。变化的主要原因如下：
1.新需求或者新功能的加入
2. 重构或者缺陷的修改
知道了回归缺陷产生的原因，那么我们做测试分析，确定测试范围就要从这两个变化的主因入手。下面我们就针对这两个主因来一个一个分析。
对新需求或者新功能做测试分析
这个不多说，步骤如下：
需求分析 -> 测试点 ->测试点审查(review) ->测试用例
1. 根据项目经理发的项目计划，确定新功能范围，找到相应需求，对需求进行分析，分析过程中要和产品经理多沟通，多提问
2. 需求分析完之后，提炼测试点，一定要做，通过测试点能清楚的展示测试的思路和脉络
3. 对测试点进行review，一定要得到开发人员的反馈
4. 最后总结成测试用例
对这一部分分析完之后，所得到的测试用例即可加入回归的测试范围。
对重构或者缺陷修改进行测试分析
对重构和缺陷修改进行测试分析从如下两方面入手：
1. 和开发人员，开发负责人多沟通
2. 总结开发人员的提交改动，根据提交信息和修改文件做测试分析
针对以上两点，实践如下：
1. 找到上次发布版本和当前测试版本对应工程的commit号，运行git log —oneline commit1..commit2能拿到该工程的所有修改。其他版本管理工具如svn，diff也能够拿到
2. 拿到修改后，总结成列表，开发人员是不会给我们总结的，自己先做分析，做完分析后，叫上开发一起进行分析。特别是对那些修改变动大的提交要重点分析，这个分析过程是测试一个积累过程，通过3-4次，对软件代码的结构，每个文件代表的模块都会很熟悉，分析的准确率和效率会越来越高。这里可以对开发的提交日志有所要求，比如提交日志包含目的，修改影响范围两部分，这样有助于测试人员进行分析。
3. 做分析的时候要学会引导开发人员，比如要从功能测试，兼容性测试，性能测试，稳定性测试来去引导开发来做确认和分析
这两方面都做好之后，测试分析也会分析的到位，最后测试范围很容易也就出来了，测试范围出来了，测试计划也就出来了。
