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

系统管理员 2024-03-22 14:25 67阅读 0赞

**先抛出我的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等等。

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

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

![f2bacae13af0fefd5f0c2df87bcadf4f.jpeg][]

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

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

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

--------------------

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

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

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

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

--------------------

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

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

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

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

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

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

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

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

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

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

--------------------

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

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

![c3fda4f7f4e9cf345aba92e7bb0a68ae.jpeg][]

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

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

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

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

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

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

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

![d8b561f02617b012dd7b69a1a498d4ed.jpeg][]

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

--------------------

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

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

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

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

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

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

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

**[《10天带你玩转python2021版》][10_python2021]**

### **六、消灭“漏测”相关的学习视频推荐** ###

回看与“漏测”的原因，凡是与测试人员相关的，**我们发现都和测试用例有关。**若测试用例覆盖能跟全面，更细致，执行更到位，则会大大提升消灭“漏测”的概率。

所以推荐几个与测试用例的学习资料给大家。

需要视频学习资料，可以狠狠点击下方链接：

1、**[《实战项目带小白入职7-12k功能测试岗位，仅7小时【史上最快】》][7-12k_7]**

2、**[《功能测试\_6天黑马手工测试2021版》 ][10_python2021]**

3、**[《测试入门\_3天黑马手工测试理论+6天实战完整分享\_适合0基础》 ][3_6_0_]**  
  
4、**[《深入了解软件测试4天视频》 ][4_]**

**5、[《黑盒测试用例设计方法篇》][Link 1]**

6、**[《白盒测试用例设计》][Link 2]**

**7、[《常用抓包工具Charles测试实战》][Charles]**

**8、[《1天软件缺陷与JIRA》 ][1_JIRA_]**

**9、[《1天禅道工具使用》 ][1_]**

[f2bacae13af0fefd5f0c2df87bcadf4f.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/07bf395324444c658936259212d648be.png
[BUG]: https://www.zhihu.com/question/26463640/answer/1571901839
[c3fda4f7f4e9cf345aba92e7bb0a68ae.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/3f3e41c791094c578d693c7b52c0da46.png
[d8b561f02617b012dd7b69a1a498d4ed.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/78691a7b48f74477a5a7fc18283143b7.png
[10_python2021]: https://www.bilibili.com/video/BV1QM4y137xX
[7-12k_7]: https://www.bilibili.com/video/BV1kw411o756
[3_6_0_]: https://www.bilibili.com/video/BV1at4y1Y7AN
[4_]: https://www.bilibili.com/video/BV1Jg4y1675r
[Link 1]: https://www.bilibili.com/video/BV1YT4y137WA
[Link 2]: https://www.bilibili.com/video/BV1cC4y1s7Bx
[Charles]: https://www.bilibili.com/video/BV1gA411q74N
[1_JIRA_]: https://www.bilibili.com/video/BV1DU4y1w7tX
[1_]: https://www.bilibili.com/video/BV1t541147Zk