软件测试灵魂三问，如何回怼？

Posted 2021-12-18 程序员二黑

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试灵魂三问，如何回怼？相关的知识，希望对你有一定的参考价值。

灵魂三问：

第 1 问：为什么这个 Bug 测不出来？
第 2 问：测试怎么测得？到底会不会测？
第 3 问：测试快点啊！为什么总是测试拖后腿，最后才报 Bug？

有朋友说：

对测试新人则是“惊魂三问”！

如果老板也这么问，更惊魂！

如果是开发人员问测试人员，则是“甩锅三问”

如果是测试人员自问，倒是反思，不是坏事！

也有朋友说，问了几万遍，就是没有答案图片

要么先看看网友如何怼回去的？

网友A：

如果是研发问，直接怼回去：

1.这么简单功能也出错？

2.研发怎么开发的，会不会开发？

3.研发能不能快点，为什么最后才给我们打包？

如果是领导问，马上认错：

对不起！对不起！对不起！

（注：似乎怼得不错，但开发一定会再怼回来，1. 功能不简单啊，如果功能不出错，还要你们测试干什么？2.你来开发、写给我看看？…可能会引来一场格斗）

网友B：

具体问题具体分析吧：

1.复盘下为什么没有测出来？是开发单元测试覆盖度不够，用例覆盖度不够，还是事实上就是难以覆盖到，之后改进。

2.把测试流程分享出来，邀请业务方、研发、测试等等相关人员，一起完善。

3.从流程下手，需求开发测试都要排期，测试排期要有“底线”.实在不行，只能用老办法，要么砍掉不核心的需求，要么延期；另一方面，做测试提效，自动化测试、提测质量准入、测试左移右移那一套都用上。

（注：这样的态度很好，善于反思，从流程、技术、人等找根因，力求立行立改、息事宁人，但不怼回去，长期下去，地位会不会越来越低？）

网友C：

分析缺陷产生原因、复现条件：测试环境能否复现？线上环境为什么没有复现？没有复现影响多大？—— 如果是漏测，那就得认；

摆事实：讲清测试方案、设计、方法，确认这个方案当时有没有获得一致评审通过？如果当时已经通过了，那就是大家的锅；如果这些没做，那测试当然就负主要责任；

看看是不是测试阶段总在做一些验收性的测试？如果是，验收性测试本身就比较耗时间，测试时间不足，测试的深度自然也不足；如果本身不是做一些验收性的测试，测试能够提前介入，一般不会“最后才报
Bug”，这里只需要列举“提前”报的 Bug。

（注：和第二个差不多，首先从自身找原因，进行根因分析，case by case，摆事实、讲道理，解决问题是硬道理）

网友D：

看情况吧。如果是自己问自己，那么就好好分析下。

如果是开发要甩锅，那么就按 @混子兄弟说的怼回去。

如果是领导问到了，那就是时间紧、技术债多、开发不自测、基础设施差、沉淀差、产品瞎B改，再道个歉，许诺个美好的未来。

最后说要用 TDD，需要一波 Money
或者其它激励，来偿还技术债，比如让开发自测需要推动，基础设施需要组织人做，都需要钱💰和资源。嗯，这么看，好像还是个增收途径。图片

（注：到后面跑题了）

网友E：

1、这个问题一定很隐蔽吧？不然怎么会单元测试没发现，自测没发现，集成测试也没发现，要不要一起分析问题的原因以便日后改进
2、这部分我上下文不足，可以和你pair一起测吗？
3、如果你自己的代码有足够的信心，不给测试留时间也可以，相信你可以控制好自己的代码质量

（注：第一个问题怼得挺好。第3个回答，显得测试是多余的？）

网友F：

1、目前看到的，我比较赞同评论是：就在大家相互扯皮的时候，鹅厂又发钱了！微信支付团队拿到2019年公司创始人奖，奖金2个亿，这还不包括年终奖（年终奖10个月起）。腾讯云完成100亿营收，团队每人阳光普照，一人一部iPhone11 Pro。
2、我们认真思考一下，快节奏的今天，还拿出这些东西聊个昏天暗地，从本质上其实就在浪费时间，可以说这些都不是问题，是结果。
3、原因太多了，大家都知道，但提出这些话题的意义是什么呢？如果一个测试团队还在这些东西上面浪费时间，那么对不起，我们已经输了，对手的唯一目标是推掉我方水晶！我们的目标在谁来背锅。如果这么几句嘲讽话语就逼疯测试，那么我们真的应该反省一下，自己有多脆弱不堪，测试也好开发也罢，共同目标是赢这一局，不是故步自封撇清自己！

最后一个同学，是不是说得很好？我把这段话从我的朋友圈搬到这里，对我写这篇文章不利啊，因为她已经批评我们“还拿出这些东西聊个昏天暗地，从本质上其实就在浪费时间”，那为什么还搬过来了？因为有道理。

我们再回头看那“灵魂三问”：

第 1 问：为什么这个 Bug 测不出来？
第 2 问：测试怎么测得？到底会不会测？
第 3 问：测试快点啊！为什么总是测试拖后腿，最后才报Bug？

第1问，不管是开发问还是老板问，不管是为了甩锅还是追究责任而来，都是需要回答的问题——产品上线后有遗漏的Bug，就需要问“为什么”？而且不只一个“为什么？”，按照根因分析方法，最多会问五个“为什么？”，“为什么这个 Bug 测不出来？” 这是第一问，答案可能是：

没有测试用例，会继续问：为什么没有测试用例（案例）？
有测试用例，没有执行或环境不对，会继续问：为什么没有执行（或环境为什么不对）？

只有这样不断深挖下去，才有可能找到根本原因在流程、在开发身上。不问为什么，是没办法让开发和领导知道他们自身存在的问题。虽然我们知道：

测试不能穷尽的
一般软件测试只是样本试验不是数学证明
开发写出的Bug越多，测试漏掉的Bug越多

这些只是道理，怼起来，力量不够。用具体的case或事实来说明问题更好、更有力。如果上面五个“为什么”追究下去，追到测试自身问题，那也说明测试自己没做好，需要改善。

第2问，的确说明问者带有情绪了，是第一问经常被问住了？还是产品上线后问题比较多？如果是前者，回到“第1问”；如果是后者，这时可以用“开发写出的Bug越多，测试漏掉的Bug也越多”来怼，最好用数据来说明，例如：

开发写出1000个缺陷，测试发现Bug的能力是98%，那么漏掉20个Bug
开发写出100个缺陷，测试发现Bug的能力还是98%，那么只漏掉2个Bug

这种带着情绪的问，如上面王同学说，也可以置之不理。如果对自身能力比较自信的，可以怼过去：

开发有没有做单元测试？有没有code review？
咱们看看哪些缺陷是可以通过单元测试、code review能发现的？
要不要我们一个一个bug过，看看这些bug究竟怎样逃过一关又一关的？
你们怎么写出这么多缺陷？怎么写的代码？
这么多缺陷，不都是开发写出来的？
难道不知道 “质量是构建出来的、不是测试测出来的” 吗？
咱们换一个位置，你来测，我来写代码，如何？

有实力，才能怼😄

第3问，这个问题要一分为二，如果之前前期发现的缺陷少，后期发现的缺陷多，测试的确要反思，没有很好地采用“基于风险的测试策略”。如果前期也报了比较多问题，但最后也报了几个缺陷，这比较正常。因为从目前现实情况看，测试常常是瓶颈，这是现实，因为测试人员少，开发：测试比常常是4:1、5:1或更高。其实，测试工作量没这么少，测试人员不仅要做新改动的测试，还要做回归测试，更何况许多开发没做好单元测试和code review，如果再加上缺乏代码规范、代码质量不高，只能是恶性循环，没有“银弹”能解决这样的问题。

这时候，如果一定要怼，就自然是：