先抛出我的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还是可以看懂的，找到里面的逻辑处理关系，可以明白开发实现某个功能都考虑了哪些场景，再结合用户使用场景就知道哪里会有可能出问题，测试的时候可以着重测试，效率会更高哦。
若想自己成为更懂编程的测试人员，推荐查看下面这个视频教程:
六、消灭“漏测”相关的学习视频推荐
回看与“漏测”的原因，凡是与测试人员相关的，我们发现都和测试用例有关。若测试用例覆盖能跟全面，更细致，执行更到位，则会大大提升消灭“漏测”的概率。
所以推荐几个与测试用例的学习资料给大家。
需要视频学习资料，可以狠狠点击下方链接：
1、《实战项目带小白入职7-12k功能测试岗位，仅7小时【史上最快】》
922
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
