我们做软件测试的，最关键的任务是在产品上线之前将bug尽可能地发现，在产品上线之后出现bug，即时准确定位bug，让开发尽早修改bug，无论是哪种情况或者任务，我们都希望将bug杀死在萌芽中，所以如何将研发质量保证前置，我们能做什么?

摘要

在实际项目中，抛开产品需求的质量不说，但就研发质量保证而言，测试人员在测试阶段发现大量的实现类bug,每天拉着开发人员修bug;要么在临近上线的时候，发现了一个重大问题，导致修复验证时间不够，但又只能“硬着头皮”上线。解决这些问题的方法或许多种多样，但这里来聊聊如何使用研发质量保证前置来尽可能避开这些问题。

背景

在实际项目中，抛开产品需求的质量不说，但在研发质量保证上面，测试人员往往需要时不时的面对不少头痛的情况：

开发团队来了一个新人，本来需求量不大，但测试人员在测试时发现连主流程都跑不通，无法走下去;

这次有一个从零起步的大项目，涉及多个模块的交互，但QA在测试时发现，实现与需求不一致，不得不重新拉产品同学、开发同学重新对需求;

需要要重构一个核心需求，结果由于排期紧张，导致提测后不仅改坏了很多老功能，新功能也各种不通;

改动了一个各种交互场景十分复杂的业务，由于开发耗时，测试周期本来就被压缩了，外加上大部分场景模拟、测试很耗时，临到上线勉勉强强测完，虽然不是很有信心，但由于项目紧急只能硬着头皮上线了;

要改一个与第三方业务交互十分复杂的业务，由于需要第三方配合才能100%覆盖场景，但由于环境问题、第三方人员时间问题导致测试被block住很久;

无论这些问题你是都遇到过，还是遇到过其中的几个，这些问题可能都给上线质量带来了或多或少的影响，甚至直接带来了线上故障。这些问题都有一个共同的特征：大部分问题的暴露都集中到了测试阶段。这里抛开需求方面问题，就自己的项目经验，聊聊与实现相关的研发质量保证前置方面的心得与体会。

什么是研发质量保证前置

质量保证想必大家都不陌生了，就是通过各种手段保证产品保质保量上线，说白了就是线上尽量少出故障，最好不出故障。研发质量保证是指代码实现层面的质量了，研发质量对应的bug是实现类bug，换句话说是实现与需求不符合导致的bug了。而研发质量保证前置是指将实现类bug的暴露时间点提前。

实现类bug的暴露阶段通常为：技术设计、技术评审、代码实现、提测时的冒烟测试、测试阶段、线上。研发质量保证前置就是让实现类bug的暴露更加提前，最好在技术设计阶段就发现。

研发质量保证前置的几种手段

前面说过实现类bug暴露有不同的阶段，但就其中的技术设计而言，目前还是开发人员为绝对主导的阶段，而且极其依赖开发人员的经验，就目前接触的众多实际项目而言，测试人员直接参与技术设计的阶段的机会还比较少，因而技术设计质量这里暂时不做过多讨论了。下面就其余的几个阶段聊聊自己的一些经验，欢迎大家补充。

一、在技术评审中确认各种场景的实现

这里的技术评审推荐开发人员主导，测试人员参加的评审会。站在测试人员的角度，虽然评审会的具体形式不限，但应该达到如下的目的：

业务需求中的各种场景都覆盖了

涉及的原有业务都覆盖了

各种异常场景处理符合需求或产品公共处理

当然了，技术评审本身需要测试人员对产品业务、技术实现都非常熟悉，否则即使参与评审，恐怕效果也微乎其微了。这里为了让开发人员积极配合技术评审，可以考虑以下实践：

将技术评审加入到项目流程中，具体形式可以依据项目大小而定;

为了鼓励大家参与的积极性，不妨想些针对性的鼓励方法;

每次评审，可以总结优化点、修改点 ，并做周知，让团队成员认可评审的价值所在;

二、在代码实现阶段鼓励微服务测试

众所周知，单元测试主要是为了从底层代码更快发现问题，尽量避免直接测试一个大的模块，这样排查问题会比较耗时。不记得有多少次，开发人员为了排查一个问题不得不打个断点，debug几次才能真正定位到问题代码了。出现此问题除了log日志不太全外，就是组装成模块的更小模块、方法缺少必要的关键单测了。当然了，实际项目大家对单元测试的态度往往是：尽管爱，但很难真正行动。就自己接触的众多项目而言，开发人员可能通过日志自检，或者就针对某一些方法简单跑下测试，把单元测试当成工作的团队还真没有接触过。于是乎，在实际项目中，通过和开发人员达成共识，在代码实现阶段，针对某个独立服务测试自检。

适合微服务测试的业务大致有以下几个特点：

业务除了API接口外，更底层实现是通过若干微服务搭建起来的

涉及的微服务逻辑复杂，集成测试很难100%覆盖

涉及的微服务频繁业务修改，并且需要独立上线

微服务测试实现最好使用自动化。自己在实际的业务中，已经将微服务的测试完全通过自动化的手段实现，测试用例的维护由测试人员维护，在需要测试时，开发人员只需要点击一键执行，几分钟后就可以直接查看结果了。当然了，除了自动化手段外，如果某个服务不易100%自动化，可以结合自己的业务特点考虑有无辅助方案。

三、在提测时做好冒烟测试

想必无论是开发人员，还是测试人员，在针对同一个测试用例执行结果时，往往都会有类似的体会：开发人员认真执行了没有发现问题，但测试人员随便试用两下却发现问题了。当然这排除掉开发人员，测试人员执行测试时的视角不同外，恐怕就是对同一个测试用例的执行步骤理解不一致了。

这里有几个自己的一些实践经验：

QA将核心主流程用例，指派给具体的开发人员执行;

QA人员提供类似一键自测的自动化工具，供开发人员执行;

复杂的需要创造场景的用例，QA辅助开发人员一起执行

具体哪种方式，依据各自业务特点、需要而定，但要切记：不可把冒烟测试当做一种流程对待，执行是只是走个过场。

四、在测试时快速发现问题

快速发现问题是问题的暴露尽可能在测试周期前半段时间，避开诸如在测试周期快结束的1天突然发现了很多问题，导致bug修复、回归验证的时间都不够了。因而，快速发现问题最核心的目标是尽可能早的暴露问题。

要想让问题提前暴露，当然除了测试方案的完备性、人员经验等因素外，还可以从测试效率提升入手做些事情：

(1)自动化覆盖。这是效率提升常用的一种技术手段，只要自动化用例覆盖全面，外加上一键执行，问题几分钟可以暴露出来。

(2)提前准备好测试需要的“一切”。这里的“一切”，不仅仅包括测试数据、测试设备，还包括当存在与第三方交互时，需要对方做的一些事情，需要提前打好招呼，约定时间等等。力求达到不会因为前期准备不足而耽误测试执行。

(3)尽可能让更多人参与测试。看到这里，你可能会说: 测试除了测试人员外，还有其他人需要参与，更何况其他人也不想参与啊。对，确实有这方面的问题。但这里是说，质量保证涉及方方面面的事情，不是测试人员一个人的事情;而且测试人员也有经验、视角的局限性，很可能很明显的问题恰恰漏掉了。因而测试人员不妨引导团队其他人员 参与测试，比如让产品人员/开发人员参与主功能的验收，设计人员参与UI/UE校对等等。在自己实际的项目中，感受最深的一点是，团队人员的参与，可以以“小白用户”心态来看待产品，因而更能发现一些体验方面的问题，而这恰恰因为测试人员接触产品过多而容易漏掉的。

写在最后

研发质量的保证需要开发人员、测试人员齐心协力、共同努力，需要二者对质量保证都谨慎对待。有时在想，如果开发人员写的代码没有实现问题，那么测试人员的工作就可以大大减少了，少了问题排查、修复、验证的耗时，验证几遍就可以上线发布了。但这种显然在实际项目中不太可能实现了：越来越复杂的产品设计，产品迭代速度越来越快，产品需求量有增无减...

认清了研发质量保证的各种阻碍之后，不妨摆正心态，认真做些事情，来把研发质量保证前置，以求尽可能减少产品发布风险吧!

感谢您的阅读，以上就是达内软件测试培训为您分享的如何将研发质量保证前置的相关内容，你学会了吗?更多软件测试的相关知识尽在达内软件测试培训机构官网，敬请关注!

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。