今天想要和大家聊聊一些回归测试中遇到的问题，痛点以及实际项目中总结的一些优化方案。

曾经经历过一个项目在项目团队不断壮大之后面临的一个新问题：回归缺陷增多。当时心里无数次在思考为什么我们的产品会是这样的一个现状，为什么测试人员们已经那么努力，却还是会有那么多的回归缺陷？你无法想象，作为一个测试人员，当她们看到自己测试过的缺陷再次出现时心情，尤其当这种现象周而复始的发生时，脸上是多么的羞愧，心里是多么的着急，这让我不得不又开始分析我们整个测试活动。

由于在此之前一直在做微软的产品测试，众所周知，微软的测试在软件行业是成熟且先进的，他们有成熟的自动化测试框架和工具，可以自动分配，安装，释放测试虚拟机，测试环境，大量的回归测试用例，测试用例的分类，优先级，编写者， 历史记录，自动分析失败的测试用例，失败测试用例和缺陷的自动连接，报告自动生成以及分发，这简直给测试人员带来了极大的方便，他们真的可以集中精力在产品质量上，全身心的投入在价值较高的测试活动中，不会沉浸在无休止低效的非测试工作，比如，“环境部署，安装测试环境，分析一次又一次的同样原因失败的测试用例，找对应缺陷，一些反复的低效的沟通等等“。

由于刚毕业一直在做这样的项目，完全处于一个美好而单纯的测试环境，没有看到过外面世界的纷纷扰扰，直到进入新的项目组，以前现成的成熟的工具和框架消失了，才对那些平时用起来顺手到不会思考的东西开始思考了。

那个项目组也有一套现有的BDD自动化测试框架，这里面包括我们的冒烟测试以及回归测试， 先来讲讲这里面的一些痛点：

冒烟测试

1. 冒烟测试的投入远远超过产出。 由于80%失败的测试用例都是产品一些小的前端布局或者功能上的改变，又或者是第三方服务不稳定引起的，所以测试人员在修复这些失败的测试用例时，缺乏成就感，总觉得是一些低级的错误引起测试用例挂掉，在其花费的成本远远高于它所带来的价值，这里的价值主要指的是监控和确保开发人员的的每一次提交都没有影响产品主要流程。

2. 冒烟测试在责任划分上不明确，大多数情况下都是测试人员在修复。当冒烟测试失败后，没有第一时间快速去修复，因此，阻塞了开发人员提交代码，在这么一个庞大的项目组，一旦冒烟测试失败，被阻塞的那可就不是某个人的代码提交，可能是几十个开发。久而久之，开发人员感受不到冒烟测试带来的价值，反而感受到更多的是累赘，效率低等等代名词。

回归测试

1. 测试用例冗余，由于团队人员一直在更新，导致会有一部分测试点相同的测试用例。

2. 没有优先级划分，在运行时没有任何偏向性和设计性，需要的时候全跑一次，然后逐个排查失败的测试用例。

3. 在自动执行时，没有策略，比如，在pipeline上设置的是每天晚上跑一次，这样高频率的跑回归测试导致pipeline长时间处于失败状态，并且测试人员第二天就要花时间去调查，修复。想想测试人员每天除了当下迭代中繁重的测试任务，还要天天去修复回归测试，这会给他们带来多大负担。

4. 测试用例责任划分不明确， 在很多测试用例失败的情况下，没有明确的Owner， 或者没有根据项目和工作量大小合理调节Owner 

5. 回归测试覆盖率不够，发布前的回归测试给测试人员带来的帮助不大，几乎还要靠测试人员手动去测试一遍。

以上种种再加上项目组其他因素影响导致产品线上问题数量增多，这种现象长期下去，客户和团队对测试团队信任度减少，因此可能会提出更多的额外要求，恶性循环间接导致测试人员工作量增大，但是产生出来的有价值的东西却不多。

下面是笔者想到的一些优化回归测试的方法：

1. 保证覆盖率到80%的回归测试

要想做好回归测试，首先最重要的当然是过关的覆盖率，没有足够多的测试用例，其他理论，方法论都是空中楼阁。当然实际项目中，也要结合项目人员配备等等其他因素的影响，期望的最大覆盖率也可能会相应变化，总之，适合自己团队的，才是最好的。我们只是希望它尽可能的高，当回归测试覆盖率达到80%-90%的时候，是能很大程度解放测试人员双手的，尤其在一个业务复杂，人员体系庞大的项目组中，没有一套安全可靠的回归测试安全网来把关，在产品发布后，是很难让项目成员对产品质量有信心的，更甚者，会在发布前让团队成员诚惶诚恐。在这一点上，测试人员有责任为团队编织这样一条坚实的安全防护网，帮助团队建立质量监控，可视化的数据可以清晰的把产品质量展现给团队。

 2. 测试用例划分优先级

 站在测试的角度，个人很喜欢把每一次发布想象成一场博弈。每一条测试用例都是一枚棋子，而测试人员就是这里的博弈人，产品是项目组的“帅”，缺陷则是对方的“将”。为了赢得本次对弈，我们要很好的利用每一枚棋子，了解它们的特征，什么时候出“车”，什么时候出“士”，什么时候再出“兵”，我们为了杜绝对方的攻陷，又要相应摆什么阵做到无懈可击，有的放矢，收放自如。

在测试用例足够多的时候，怎么管理好你这些棋子就至关重要了。那么在管理测试用例前，首先要了解测试用例，并未它们加上标签，标志它们不同的特征，这里我们想要提出的是最显著的特征：优先级

浏览一下我们的测试用例，很大一部分是站在测试的角度去设计测试用例，没有很精确的划分优先级，设计出合理的测试用例等级纬度。参考众所周知的二八法则，我们往往最重要的功能只占整个产品的20%，其余的80%可能都没那么重要。在此基础上，结合我们项目中的用户数据分析统计，可以确定用户实际使用较为频繁的功能是和我们期望或者假想的功能是否一致，并且及时做出调整。基于这里所定的划分原则，在设计测试用例，映射出每条测试用例和功能模块的优先级。

 3. 测试用例责任划分制

可以看到冒烟测试和回归测试中出现问题后，我们都缺乏一个很快的机制，让它快速找到解决者，因此这里提出测试用例责任划分制。由于每次CI挂掉后，上面显示的提交代码人名字和实际真正捣蛋的提交代码人名字不一致，大家总会在想是否是自己的代码有问题，或者存在侥幸心理，或者过分担忧，总之不会有个明确的责任划分，那也就不会第一时间去修复。对于冒烟测试和回归测试，我们可能不同的责任划分制，比如冒烟测试，会分两种情况，一种是某个开发人员的代码导致CI挂掉，那么他就是责任人；另一种是测试用例失败由非该开发人员代码原因引起的。这里的责任划分制主要指的是我们需要确保每一条测试用例在后期是有人去维护的，在CI挂掉后，或者测试用例失败后第一时间有人去修复，不要阻塞其他人员工作。

这种责任划分制还会发生在一旦出现产品需求改变，或者测试用例有问题时，又或者是测试用例失败的情况下，可以很明确的知道这条测试用例对应到项目组的哪位成员，他有义务去更新或者分析这条测试用例。

另外需要提到的一点是，在测试用例失败之后，最好可以自动触发出一条提示信息，这条提示信息包括这条测试用例的编写者，失败日志，失败时间等等.

4. 迭代回归测试和发布回归测试

结合敏捷原则“尽早发现问题”和一般项目发布前的回归测试，我们衍生出来“迭代回归测试”。

迭代回归测试：在迭代结束后期，项目应识别出本次迭代所涉及的功能，以及开发本迭代功能可能会影响到的功能，对这些功能做一次有针对性的回归测试。在实际项目中，结合功能模块相互间的依赖性和完整性，这个周期可以做适当调整，比如两个迭代做一次，只要确保本阶段开发的产品代码质量就可以了。

迭代回归测试的好处是既可以保证在本次迭代结束后，下一个迭代开始前，回归测试代码能够尽可能的跟上功能开发进度，及早发现和解决本次迭代产生的技术债务，又能够在宏观上可视化本次迭代的产品质量。有了迭代回归测试，我们不再需要每天去跑繁重的发布回归测试，不再每天花费测试人员额外去关注回归测试，可以全心全意工作在日常真正的测试中；不再看到一个长时间失败状态的回归测试 ，让项目组成员噫唏嘘。

 发布回归测试：在发布前，为了保证我们本次发布中不会有我们遗漏掉的缺陷，并且整个产品所有能够涉及到功能都没有问题，我们需要针对将要发布功能，范围， 优先级，用户，对回归测试制定测试策略

做一次全覆盖性的回归测试，把所有回归测试运行一次，或者多次。

当然，这里的方法论看上去很简单，但是在实际项目中似乎没那么简单，它需要和开发团队，测试团队无缝的沟通合作，借用他们专业的技术能力和业务能力，确保最终的功能划分是正确并且合理的，在这里推荐在迭代开始前创建一个idea board, 在本次迭代中，不管是需求分析师，开发人员，测试人员，在识别到当前代码或者功能模块可能会影响到某个功能时，及时记录下来，最后确定出来优先级，在迭代回归测试和发布回归测试中参考。

5. 最后，工欲善其事，必先利其器

一个好的测试用例管理工具会给测试工作者带来很大便利，它最好可以帮助我们在优先级，测试用例责任人，测试用例所属功能模块，测试用例运行次数，缺陷连接等等，满足过滤分类功能，建立测试资产的可跟踪性，创建测试用例集，测试报告分发与分析。这里推荐VS TFS，Zephyr，它们都是很不错的测试用例管理工具。