概述

       在项目管理流程中，有几个关键阶段：

需求阶段、开发阶段、测试阶段、上线阶段

       其中的需求阶段和开发阶段是最为重要的，一个是设计，定义这个功能如何运作，一个是执行与实现，这两个阶段把控好了，往下走就会顺利很多。下面重点讲一下开发阶段中的提测步骤，在提测前应该准备什么东西，以保证提测的质量。

       首先关于提测这个动作，我自己是这么理解的：

提测了，就说明开发人员认为功能就长这样了，已经完全按照产品PRD完整的实现了，是个严谨、负责、认真的动作。

       理论上，研发人员一旦提测，就可以开始处理其他需求任务了的。

       为啥要注重提测质量

       在刚才提到几个项目管理阶段中，越早认真越好，早发现问题早解决，如果到了测试阶段，还出现各种各样的问题，基本都是要付出惨痛的代价的。

       你有没有遇到过，功能提测后，还出现如下情况：

功能跟产品PRD里的不一样，走偏了；
前端BUG几百个；
严重阻塞性BUG几十个；
测试环境极度不稳定，测试人员一直来让开发人员定位。

       这些问题都会造成极大的沟通成本、执行成本，也会占用很多资源，直接影响了整个部门对需求处理的吞吐量，而这些本身是可以尽量避免的。解决的办法就是狠抓提测这个步骤。下面列一下我自己实战过且发挥了作用的一些手法。

注意：这里着重强调的是，提测这个动作执行前，要做的事情，关注的是，测试人员接手后，是否能顺利走下去，
像架构方案、技术设计、压测、回滚方案呀，这些是另外的动作，是必做的，不会在文章里强调。

       提测前要做的事情(不分先后)

       完成端到端联调

自己负责的部分再完美也是没用的，端到端一联调，可能就出问题。

       端到端联调的重要性再怎么强调都不为过，它可以整体性的验证功能模块是否符合产品预期。像UI问题、体验问题、后端接口数据问题、兼容性问题等，都可以在这个阶段发现。

       另外有两个小技巧可以用上：

• 如果开发环境不太稳定或者数据不全，建议直接在测试环境里做开发联调，把环境调顺了，完成后，测试人员可以在同一个测试环境里做功能测试，可以避免提测后，一大堆环境问题，而测试人员又不知道如何处理，只能找开发定位，造成的资源浪费。当然如果测试人员有能力独立维护测试环境的话，就不建议这么干哈。

• 根据测试人员提供的冒烟用例，有目标的进行开发联调，提高联调效率。如果开发人员很有耐性，能按照产品PRD里提的点，逐个验证，那当然更好了。

       执行冒烟用例

       测试人员在需求评审完后，就需要开始进行测试用例设计了，其中的冒烟用例是一个子集，是基础的用例，这些用例如果无法通过，测试人员就可以将提测的模块打回(会有一封大大的同时又抄送老板的主题为xxx功能冒烟不通过，打回的邮件发出来)，因此开发人员需要认真的执行冒烟用例。

       另外测试人员提供的冒烟用例必须要有质量，能准确覆盖基础的重要的功能点。

       列出改动点

       这里的改动点，说的是，你当前开发的模块，改动了哪些已有的且在线上稳定运行的模块。你需要列出来，让测试人员更有目的性更有效率的去做回归测试。

       准备好上回归环境的清单

       像配置文件变更、数据库变更，MQ配置，这些在提测前，都需要准备好，要不然就可能出现功能模块在测试环境或者回归环境无法顺利运行的情况，缺胳膊少腿的，像大一些的模块，涉及到的服务很多，每个服务都有自己变更，不及时记录起来，很容易忘记。这样会极大的降低功能测试的效率。

       我之前遇到过好几次，一个功能模块周一晚上提测，隔天测试人员开始介入，但是直到隔天下午功能模块才顺利的在测试环境里运行，这是多么的不应该，浪费开发人员和测试人员的时间，严重一些的，还可能导致项目延期。

       必要时，产品经理提前验收

       像大一些的功能模块，涉及到的点非常多，这个时候，如果产品经理有时间的话，可以让其在功能提测前验收一把，这样可以及早发现功能模块是否走偏了，也可以发现很多的前端体验问题，及时让开发人员解决掉。

       我是遇到过，一个项目，提测后，测试人员提了几百个前端体验或者UI问题，单单是测试人员写BUG描述，就花费了很长时间，然后还需要让开发流转BUG，这些都需要时间。

       想对测试人员说的

       如果开发提测前，上文提到的那些动作没有准备好，测试人员是可以不进行测试的，因为提交给测试人员的，是一个极度不稳定的东西，一旦进入测试环节，就开始坑测试人员了。因此宁愿按住它，不开始。另外这也是保护测试人员的一种方式，毕竟队列就这么长，别随便给测试扔一些不靠谱的功能。

       另外，测试人员可以理直气壮挑战开发人员的，其实只有一处，就是提测质量，如果功能模块都上线了，但是出问题了，那么老板第一个找的就是测试人员，因为功能是否能上线，是测试人员决定的，相当于跟老板说：

功能经过严格的测试了，可以交付了。

       而事实上，上线后却是一堆问题。因此测试人员一定要死磕开发人员的提测质量，冒烟不过的，打回，再冒烟不过，严肃警告，还是冒烟不过，那就狠一点，可以直接不测试某些开发组提测过来的模块，因为一提测过来，进入到测试环节后，就又开始各种不顺利，各种浪费。

       小结

       流程有了，就要开始考验执行力了，这是个难题，一开始的话，比较建议的方式是，项目指定一个懂项目管理流程的技术负责人，授予他/她临时权力，由它全程统筹，到处督战，谁不配合，可以直接指出。按照这种方式，实施几个项目后，大家就会开始慢慢适应。

作者：Sam哥哥

原文链接：https://blog.csdn.net/linsongbin1/article/details/107736541#comments_13179026