怎么看待QA（软件测试）漏测bug？

先抛出我的2个观点：

1、漏测不一定是测试的锅。但当问题发生时，测试第一时间不要去拒绝推卸责任，而是要先去解决漏测问题。

2、漏测问题的及时处理很重要，但是避免再次漏测更重要。

为了将此问题阐述的更清楚，我将通过下面几个方面来论述：

1、“漏测”的原因分析
2、如何第一时间去解决“漏测”问题
3、如何避免自己无辜背锅“漏测”
4、如何避免再次“漏测”的建议（重点）
5、如何在消灭“漏测”的基础上还能保证测试效率
6、消灭“漏测”相关的学习视频推荐

一、“漏测”原因分析

近几年，发生了好几起互联网圈的“漏测”事件：

2011年淘宝一元门事件，单个商家预计损失在几百到上百万之间；

2014年刀塔传奇母亲节事件，2万金币变钻石（价值2000元人民币），该福利全服推送；

2015年携程瘫痪门事件，致使携程盘前股价暴跌11.67%；

2017年初阴阳师“业原火”事件，无敌体力无限制刷副本，还能刷到顶级材料，多少大R的噩梦；

2018年王者荣耀test邮件事件，安卓QQ区喜获“天美史上最强福利”，英雄沈梦溪、棒球奇才、英雄李信和灼热之刃四个永久道具随便用；

2019年拼多多优惠券事件，传言该BUG使拼多多一夜损失200亿。

.....

那么，漏测了一定是测试的锅吗？其实不然，导致漏测的原因有很多，随便举例，就会有这么些情况：

①　需求规格不明确，导致测试用例编写过于粗犷。产品和测试的责任。

②　需求规格变更但未通知测试，导致测试用例未及时更新，产品责任。

③　测试用例覆盖不全面，场景出现遗漏，测试主责，产品、研发负责（参与用例评审）。

④　测试过程中未严格按照测试用例执行，测试责任。

⑤　时间不充足，经项目组达成一致后仅执行了部分优先级较高的模块测试，导致一些功能点在测试过程中被忽略，那么项目、研发、产品、测试都有责任。

⑥　测试环境受限，导致缺陷漏测。

⑦　开发人员解决bug时引入的新BUG等等。

可以看出以上情况都会导致系统在上线之后出现异常，而且并不都是测试的责任。产品、研发、项目、测试环境都可能要担责。

所以再仔细的测试，都无法避免漏测，简直是防不胜防。

所以"漏测"这口锅全部扣测试身上，明显是不能接受的，关键在于测试人员需要找出足够的证据来保护自己。

但出现bug后，也不要直接甩锅，这样让人感觉在逃避问题。第一要紧事情是处理bug，尽量减少对用户的影响；只要用户影响不大，即便有责任后果也不会太严重。

如何第一时间处理好bug呢？

二、如何第一时间去解决“漏测”问题

相比“漏测”的归责，我们更应该关注的是如何去解决漏测问题。如何处理呢？一般分为下面2步：

①问题发生时，拒绝推卸责任，第一时间解决用户使用问题。当问题出现后测试应该立即记录，确认影响范围，并尽快找到恢复方法。优先保证用户使用恢复正常。

②缩短问题修复时间，尽快推送修复后的版本给用户。确认问题复现步骤，并紧急协调研发人员进行修复。

三、如何避免自己无辜背锅“漏测”

“漏测"问题解决了，但“漏测"这口锅就会全部扣测试身上呢，这样明显也是不能接受的，测试人员需要找出足够的证据来保护自己。

所以，我们一定要对测试后出现的bug做好总结，事后组织反思会，进针对本次事故问题原因进行追溯，通过回溯确定问题的产生原因，问题的责任认定基本就清楚了。

问题回溯一般从bug的引入阶段，bug的产生原因，bug的遗漏原因等几个方面去分析。例如：

1）Bug如果是需求阶段引入的，需求本身有遗漏/描述不清楚，那么主要是产品人员的责任，但是设计、开发、测试人员没有评审出问题，同样也有责任

2） Bug 如果是开发阶段引入的，测试人员设计用例的时候没有考虑到，那么主要是测试人员的责任，但是测试用例同样是要经过开发、产品的评审才会使用的

3）bug同样是开发阶段引入的，如果bug是由于开发修改bug的时候引入了新的bug，恰好那个用例之前测试过，不会再重新测试了，这样的遗漏主要责任就在开发，修改bug控制影响范围是开发必须做到的，但是测试人员可以没有做到代码看护的事情

4）再或者产品人员变更需求后，只是告诉开发要改，但是没有同步给测试，造成测试漏测，这就是项目研发流程有问题了，项目经理要负主要责任。

通过上面几个例子也可以看出，bug的产生有很多种可能的原因，一般情况下，在项目组中不会刻意的强调谁要负主要责任。为了团队的团结，大部分情况下都是产品、开发、测试共同承担责任。

小贴士：本章节内容转载自：软件测试完后，还有BUG，是测试人员的问题吗？

四、如何避免再次“漏测”的建议（重点）

一坑绝不二踩，一个坑绝不摔两次跤。如何避免漏测？送你下面6条建议：

①规范工作流程，制定标准。可以主动推动项目团队就项目工作流程认知达成一致，明确项目排期，严格按照项目计划时间进行，需求lackdown后禁止再改动需求或者增加新需求。避免打出现信息同步不及时或者不同步问题。若必须改动则必须通过项目会议全员通过后才可。

②规范测试计划，做好Plan B。计划要明确测试范围、测试方法，以及准入准出标准；同时要考虑项目过程中的可能风险问题，做好Plan B。

③统一用例编写规范，选好回归用例。可以统一团队用例编写标准，明确优先级并得到项目团队的认可。P0优先级的用例可用于回归测试，确保功能可用（一般影响功能正常使用的均为P0）。

④严格执行用例、拒绝模糊验收。可以将用例上传至同一平台进行管理，执行时直接在平台做好记录，避免执行过程中遗漏或者测试人员“偷懒”导致执行不完全。而且执行失败的用例可跟bug关联起来，最终输出报告。此时验收标准可具体化到用例执行无遗漏，缺陷无遗留或者解决率达到XX%，甚至可以按照优先级、严重程度再具体到每个级别的解决率。例如：严重程度S0、S1级别解决率100%、S2级别解决率98%等等。

⑤拒接口头需求，拒提口头Bug。所有工作对接需要有文字形式的记录，包括提测、提bug、上线通知。不要觉得大家关系很好，有的东西说一声即可。当事故来临时你可以再看看关系好还有没有用。做好文字形式的记录既是保护自己也是约束各方，为自己的一言一行负责。

此外，测试还可以推动一下项目上线策略的制定，例如：可推动灰度发布策略，明确灰度范围，可选一些容忍度较好的客户群加入灰度名单，上线前先进行灰度试用，若规定时间内有异常，随时回滚修复；若规定时间无异常问题上报，即可全量推送。

若是为了避免“漏测”事故，就一味降低测试效率，这当然也是不允许的。
判断一个测试团队强不强，会至少两个维度：是不是快（效率），是不是好（没有漏测）。
强悍的测试团队应该是又快又好。

所以也给广大测试同学一些工作建议，提升测试质量（消灭“漏测”）的同时，如何提升团队质量和效率。

五、如何在消灭“漏测”的基础上还能保证测试效率

（1）善用平台统一管理（用例、Bug）：可以借助一些好用的平台，推动项目团队使用。公共平台数据清晰透明，方便团队各方随时查看测试进度、bug解决进度。

（2）善用工具完善测试：可以借助一些测试工具的使用，来弥补人为做不到的监控，比如可以在测试途中开着抓包工具，对于所有的请求和响应均做好监控，以防发生不明确复现手段导致bug滞留问题，也能给研发提供一个初步的定位，帮助研发缩短问题排查流程，从而提高bug解决效率。

（3）规范用例编写标准，团队达成统一。这里要明确到标题格式、前置条件、操作步骤、预期结果，最重要的是要明确用例优先级。

（4）引入自动化，让测试更高效。众所周知，自动化测试可以很好的提升效率，那么我们的回归用例明确后，这部分回归工作可以通过自动化来实现，找个“工具人”24小时不眠不休干活，岂不是可以在有效时间内更充分的测试。

（5）多看代码，理解研发所想。工作之余建议大家多看看研发的代码，看不懂可以让研发讲解大致思路，但是我相信最简单if else还是可以看懂的，找到里面的逻辑处理关系，可以明白开发实现某个功能都考虑了哪些场景，再结合用户使用场景就知道哪里会有可能出问题，测试的时候可以着重测试，效率会更高哦。

若想自己成为更懂编程的测试人员，推荐查看下面这个视频教程:

《10天带你玩转python2021版》