摘要：在实际项目中，抛开产品需求的质量不说，但就研发质量保证而言，测试人员在测试阶段发现大量的实现类bug,每天拉着开发人员修bug；要么在临近上线的时候，发现了一个重大问题，导致修复验证时间不够，但又只能“硬着头皮”上线。解决这些问题的方法或许多种多样，但这里来聊聊如何使用研发质量保证前置来尽可能避开这些问题。
　　关键词：研发质量，质量保证前置，尽早暴露问题，上线风险
　　背景
　　在实际项目中，抛开产品需求的质量不说，但在研发质量保证上面，测试人员往往需要时不时的面对不少头痛的情况：
　　开发团队来了一个新人，本来需求量不大，但测试人员在测试时发现连主流程都跑不通，无法走下去；
　　这次有一个从零起步的大项目，涉及多个模块的交互，但QA在测试时发现，实现与需求不一致，不得不重新拉产品同学、开发同学重新对需求；
　　需要要重构一个核心需求，结果由于排期紧张，导致提测后不仅改坏了很多老功能，新功能也各种不通；
　　改动了一个各种交互场景十分复杂的业务，由于开发耗时，测试周期本来就被压缩了，外加上大部分场景模拟、测试很耗时，临到上线勉勉强强测完，虽然不是很有信心，但由于项目紧急只能硬着头皮上线了；
　　要改一个与第三方业务交互十分复杂的业务，由于需要第三方配合才能100%覆盖场景，但由于环境问题、第三方人员时间问题导致测试被block住很久；
　　无论这些问题你是都遇到过，还是遇到过其中的几个，这些问题可能都给上线质量带来了或多或少的影响，甚至直接带来了线上故障。这些问题都有一个共同的特征：大部分问题的暴露都集中到了测试阶段。这里抛开需求方面问题，就自己的项目经验，聊聊与实现相关的研发质量保证前置方面的心得与体会。
　　什么是研发质量保证前置
　　质量保证想必大家都不陌生了，就是通过各种手段保证产品保质保量上线，说白了就是线上尽量少出故障，最好不出故障。研发质量保证是指代码实现层面的质量了，研发质量对应的bug是实现类bug，换句话说是实现与需求不符合导致的bug了。而研发质量保证前置是指将实现类bug的暴露时间点提前。
　　实现类bug的暴露阶段通常为：技术设计、技术评审、代码实现、提测时的冒烟测试、测试阶段、线上。研发质量保证前置就是让实现类bug的暴露更加提前，最好在技术设计阶段就发现。
　　研发质量保证前置的几种手段
　　前面说过实现类bug暴露有不同的阶段，但就其中的技术设计而言，目前还是开发人员为绝对主导的阶段，而且极其依赖开发人员的经验，就目前接触的众多实际项目而言，测试人员直接参与技术设计的阶段的机会还比较少，因而技术设计质量这里暂时不做过多讨论了。下面就其余的几个阶段聊聊自己的一些经验，欢迎大家补充。
　　一、在技术评审中确认各种场景的实现
　　这里的技术评审推荐开发人员主导，测试人员参加的评审会。站在测试人员的角度，虽然评审会的具体形式不限，但应该达到如下的目的：
　　业务需求中的各种场景都覆盖了
　　涉及的原有业务都覆盖了
　　各种异常场景处理符合需求或产品公共处理
　　当然了，技术评审本身需要测试人员对产品业务、技术实现都非常熟悉，否则即使参与评审，恐怕效果也微乎其微了。这里为了让开发人员积极配合技术评审，可以考虑以下实践：
　　将技术评审加入到项目流程中，具体形式可以依据项目大小而定；
　　为了鼓励大家参与的积极性，不妨想些针对性的鼓励方法；
　　每次评审，可以总结优化点、修改点 ，并做周知，让团队成员认可评审的价值所在；
　　二、在代码实现阶段鼓励微服务测试
　　众所周知，单元测试主要是为了从底层代码更快发现问题，尽量避免直接测试一个大的模块，这样排查问题会比较耗时。不记得有多少次，开发人员为了排查一个问题不得不打个断点，debug几次才能真正定位到问题代码了。出现此问题除了log日志不太全外，就是组装成模块的更小模块、方法缺少必要的关键单测了。当然了，实际项目大家对单元测试的态度往往是：尽管爱，但很难真正行动。就自己接触的众多项目而言，开发人员可能通过日志自检，或者就针对某一些方法简单跑下测试，把单元测试当成工作的团队还真没有接触过。于是乎，在实际项目中，通过和开发人员达成共识，在代码实现阶段，针对某个独立服务测试自检。
　　适合微服务测试的业务大致有以下几个特点：
　　业务除了API接口外，更底层实现是通过若干微服务搭建起来的
　　涉及的微服务逻辑复杂，集成测试很难100%覆盖
　　涉及的微服务频繁业务修改，并且需要独立上线
　　微服务测试实现最好使用自动化。自己在实际的业务中，已经将微服务的测试完全通过自动化的手段实现，测试用例的维护由测试人员维护，在需要测试时，开发人员只需要点击一键执行，几分钟后就可以直接查看结果了。当然了，除了自动化手段外，如果某个服务不易100%自动化，可以结合自己的业务特点考虑有无辅助方案。
　　三、在提测时做好冒烟测试
　　想必无论是开发人员，还是测试人员，在针对同一个测试用例执行结果时，往往都会有类似的体会：开发人员认真执行了没有发现问题，但测试人员随便试用两下却发现问题了。当然这排除掉开发人员，测试人员执行测试时的视角不同外，恐怕就是对同一个测试用例的执行步骤理解不一致了。
　　这里有几个自己的一些实践经验：
　　QA将核心主流程用例，指派给具体的开发人员执行；
　　QA人员提供类似一键自测的自动化工具，供开发人员执行；
　　复杂的需要创造场景的用例，QA辅助开发人员一起执行
　　具体哪种方式，依据各自业务特点、需要而定，但要切记：不可把冒烟测试当做一种流程对待，执行是只是走个过场。
　　四、在测试时快速发现问题
　　快速发现问题是问题的暴露尽可能在测试周期前半段时间，避开诸如在测试周期快结束的1天突然发现了很多问题，导致bug  修复、回归验证的时间都不够了。因而，快速发现问题最核心的目标是尽可能早的暴露问题。
　　要想让问题提前暴露，当然除了测试方案的完备性、人员经验等因素外，还可以从测试效率提升入手做些事情：
　　自动化覆盖。这是效率提升常用的一种技术手段，只要自动化用例覆盖全面，外加上一键执行，问题几分钟可以暴露出来。
　　提前准备好测试需要的“一切”。这里的“一切”，不仅仅包括测试数据、测试设备，还包括当存在与第三方交互时，需要对方做的一些事情，需要提前打好招呼，约定时间等等。力求达到不会因为前期准备不足而耽误测试执行。
　　尽可能让更多人参与测试。看到这里，你可能会说: 测试除了测试人员外，还有其他人需要参与，更何况其他人也不想参与啊。对，确实有这方面的问题。但这里是说，质量保证涉及方方面面的事情，不是测试人员一个人的事情；而且测试人员也有经验、视角的局限性，很可能很明显的问题恰恰漏掉了。因而测试人员不妨引导团队其他人员 参与测试，比如让产品人员/开发人员参与主功能的验收，设计人员参与UI/UE校对等等。在自己实际的项目中，感受最深的一点是，团队人员的参与，可以以“小白用户”心态来看待产品，因而更能发现一些体验方面的问题，而这恰恰因为测试人员接触产品过多而容易漏掉的。
　　写在最后
　　研发质量的保证需要开发人员、测试人员齐心协力、共同努力，需要二者对质量保证都谨慎对待。有时在想，如果开发人员写的代码没有实现问题，那么测试人员的工作就可以大大减少了，少了问题排查、修复、验证的耗时，验证几遍就可以上线发布了。但这种显然在实际项目中不太可能实现了：越来越复杂的产品设计，产品迭代速度越来越快，产品需求量有增无减...
　　认清了研发质量保证的各种阻碍之后，不妨摆正心态，认真做些事情，来把研发质量保证前置，以求尽可能减少产品发布风险吧！