功能模块提测前注意这几件事，再也不怕被测试diss了！
概述
在项目管理流程中，有几个关键阶段：
需求阶段、开发阶段、测试阶段、上线阶段
其中的需求阶段和开发阶段是最为重要的，一个是设计，定义这个功能如何运作，一个是执行与实现，这两个阶段把控好了，往下走就会顺利很多。下面重点讲一下开发阶段中的提测步骤，在提测前应该准备什么东西，以保证提测的质量。
首先关于提测这个动作，我自己是这么理解的：
提测了，就说明开发人员认为功能就长这样了，已经完全按照产品PRD完整的实现了，是个严谨、负责、认真的动作。
理论上，研发人员一旦提测，就可以开始处理其他需求任务了的。
为啥要注重提测质量
在刚才提到几个项目管理阶段中，越早认真越好，早发现问题早解决，如果到了测试阶段，还出现各种各样的问题，基本都是要付出惨痛的代价的。
你有没有遇到过，功能提测后，还出现如下情况：
功能跟产品PRD里的不一样，走偏了；
前端BUG几百个；
严重阻塞性BUG几十个；
测试环境极度不稳定，测试人员一直来让开发人员定位。
这些问题都会造成极大的沟通成本、执行成本，也会占用很多资源，直接影响了整个部门对需求处理的吞吐量，而这些本身是可以尽量避免的。解决的办法就是狠抓提测这个步骤。下面列一下我自己实战过且发挥了作用的一些手法。
注意：这里着重强调的是，提测这个动作执行前，要做的事情，关注的是，测试人员接手后，是否能顺利走下去，像架构方案、技术设计、压测、回滚方案呀，这些是另外的动作，是必做的，不会在文章里强调。
提测前要做的事情(不分先后)
完成端到端联调
自己负责的部分再完美也是没用的，端到端一联调，可能就出问题。
端到端联调的重要性再怎么强调都不为过，它可以整体性的验证功能模块是否符合产品预期。像UI问题、体验问题、后端接口数据问题、兼容性问题等，都可以在这个阶段发现。
另外有两个小技巧可以用上：
如果开发环境不太稳定或者数据不全，建议直接在测试环境里做开发联调，把环境调顺了，完成后，测试人员可以在同一个测试环境里做功能测试，可以避免提测后，一大堆环境问题，而测试人员又不知道如何处理，只能找开发定位，造成的资源浪费。当然如果测试人员有能力独立维护测试环境的话，就不建议这么干哈。 根据测试人员提供的冒烟用例，有目标的进行开发联调，提高联调效率。如果开发人员很有耐性，能按照产品 PRD里提的点，逐个验证，那当然更好了。
执行冒烟用例
xxx功能冒烟不通过，打回的邮件发出来)，因此开发人员需要认真的执行冒烟用例。列出改动点
准备好上回归环境的清单
MQ配置，这些在提测前，都需要准备好，要不然就可能出现功能模块在测试环境或者回归环境无法顺利运行的情况，缺胳膊少腿的，像大一些的模块，涉及到的服务很多，每个服务都有自己变更，不及时记录起来，很容易忘记。这样会极大的降低功能测试的效率。必要时，产品经理提前验收
几百个前端体验或者UI问题，单单是测试人员写BUG描述，就花费了很长时间，然后还需要让开发流转BUG，这些都需要时间。坑测试人员了。因此宁愿按住它，不开始。另外这也是保护测试人员的一种方式，毕竟队列就这么长，别随便给测试扔一些不靠谱的功能。提测质量，如果功能模块都上线了，但是出问题了，那么老板第一个找的就是测试人员，因为功能是否能上线，是测试人员决定的，相当于跟老板说：功能经过严格的测试了，可以交付了。
提测质量，冒烟不过的，打回，再冒烟不过，严肃警告，还是冒烟不过，那就狠一点，可以直接不测试某些开发组提测过来的模块，因为一提测过来，进入到测试环节后，就又开始各种不顺利，各种浪费。有道无术，术可成；有术无道，止于术
欢迎大家关注Java之道公众号
好文章，我在看❤️
评论