需求频繁变更，测试怎么办？

参考极客时间董建琴老师讲解的《怎么有效解决3个测试痛点》

---

前言

现在的公司，需求是由各个业务部门提出的，需求常常有一些或大或小的改动，而改动后的产品就意味着要进行回归测试，回归测试的测试范围大家都知道：①修改的功能②修改的功能影响的其他范围。

因此，在这种情况下，怎么精确的把握修改的功能以及影响的范围，这个问题就时常困扰着我们…

---

一、需求变更后的测试痛点

1. 不能精准确认开发改动的影响面

每次变更的需求产品都会罗列出来需求修改的功能或新增的功能，但更深层次的影响，比如，是否影响数据库的表结构？是否新加接口？是否修改接口？是否还有需求中未提及的逻辑控制？
这些修改的内容往往都是需要开发提供给我们，所以我们需要精确的确认开发改动的影响面，才能对症下药。

比如，需求需要控制一个操作只能由一个角色的固定人员才能进行，开发说这估计要新增一个标识，传给前端进行判断。
那么，我们最好就要知道要加一个什么标识？标识加在哪张表？其他流程上会不会涉及到这个标识？这样我们才能设计出覆盖更全面的测试用例。

2. 需求变更影响测试环节

对于需求变更比较频繁的情况，测试环节的影响也是比较大的。可能上一个迭代才测试通过的需求，下一个迭代又要增加一些内容或者做一些优化，甚至于影响整个流程。这就意味着我们需要增加用例、修改用例，甚至于重新分析流程再编写用例。这无疑是很占用本次迭代中的测试时间的。

因此，如何降低需求变更对测试环节的影响就是测试很头痛的问题了。

3.确定测试优先级

不知道诸君有没有这样的困扰，在测试的范围确定下来后，测试的重点却迟迟确定不下来。觉得这个测试点是本次迭代的修改内容，是重点关注对象；或者那个测试点对流程有影响，也是重点关注对象；或者这个测试点影响了重要逻辑的判断，还是重点关注对象…呃，这么一算下来工作量又很多呀，岂不是要天天加班了！！！

所以，如何确定测试的优先级也是很重要的…

二、如何解决？

1.如何精准确认开发改动的影响面？

上图是董建琴老师的课程中列出的确认开发改动影响面的解决方案。

第一条在于规范提测流程，让开发提供完善的提测清单，我们再根据提测单提取改动点和影响范围，这一条我们可以 try 一 try~
第二条需要测试人员读代码、分析代码，提取影响的业务和接口，这需要测试人员具备一定的代码能力，这对于现在的我来说性价比不高…
第三条是通过工具进行监控，Skywaking我查询了一下：“Skywalking是一个国产的开源框架。它是一款优秀的分布式系统应用程序性能监视工具工具，包括了分布式追踪，性能指标分析和服务依赖分析等”。对于框架需要一定的学习成本，后期可以慢慢学习，但不是马上能应用到我们项目中的方案。

所以，重点讲一下第一条：通过规范化的提测流程来辅助测试确定开发的代码变动影响的范围。

我们现在的流程是开发完成任务后，会先对自己负责的模块进行演示，相当于是和测试一起对主要流程进行冒烟，演示通过后，测试人员就开始执行用例了。在我们现在的流程体现出的一些问题有：

1. 测试范围与开发范围不能对接。对本次迭代的具体任务只能通过测试的前期设计来确定，提测的功能可能会有遗漏；
2. 开发的测试建议不能明确。个别开发可能会从实现的角度提醒测试验证一些可能存在的问题，但是大多数开发现在还没有这个意识；
3. 提测和未提测功能不能确定。一次迭代中可能会存在分批次提测的情况，但是在现在的流程中，测试不能明确哪些功能是已提测的。

通过上面的分析，我觉得在我们现在的流程中引入提测单，对整个项目还是比较有益的。下面就是我参考一些大佬后编辑的一份提测单模板：

2.如何降低需求变更对测试环节的影响？

• 需求变更的原因
  我们现在的流程中有时候会发生某个需求到测试环节还没最终确定的情况，分析了一下导致这种情况的原因：
  1）需求的设计不够周全；（一个操作后的数据处理、一个功能在其他入口的处理等）
  2）需求的变更没有及时更新；（后期变更的需求没有及时更新到禅道上）
  3）需求的评审不规范；（需求中不能实现或没考虑到的地方不能提前发现）
  4）业务部门提需求的流程不规范；

• 降低需求变更对测试环节影响的方法
  1）提高测试在需求评审中的参与度。需求评审应提前至少两天告知测试，测试在期间应对需求进行分析拆分测试点，并对有疑问的需求进行记录；
  2）规范需求变更流程。需求变更后测试应考虑测试的实施以及具体的工作量；
  3）规范bug。bug中需要关联需求，开发解决方案中因写明bug产生原因，通过后期的数据统计来反向推进产品将需求设计的更详细周全；

3.如何确定测试优先级？

• 测试前做预估
  1）比较重要的功能，比如下单、支付这种涉及金额计算的；
  2）逻辑比较复杂的功能，比如自动派单功能；
  3）影响面比较大的功能，比如影响主流程的功能；
• 测试后做分析
  通过禅道等工具对线上环境或测试环境产生的bug的各个维度生成报表。比如可以通过对各个模块bug数量的统计，分析出下次的测试重点；

总结

用一张董建琴老师的课程中的脑图做总结。