一

其实，这篇文章最开始的标题是《如何用一个抹布一次清理完一个落满灰尘的工位》，读来读去觉得有点绕，写到最后也发现，哇，这个抹布好惨呀，就把标题改为《一块抹布引发的惨案》，又感觉有标题党的嫌疑，最终就确定了目前这个标题。

言归正传，不知道读到这的同学里面有没有杠精，做测试的话，我相信肯定有，不管怎样，我先解释一下，本次主要是讨论测试策略的话题，比如如何尽早发现严重程度比较高的 Bug，有人会说，这和抹布有什么关系？别着急，继续看。

二

我一直觉得，测试不只是单纯的技术输出型工种，有时候发挥好软技能，会起到事半功倍的效果。

就本次「如何用一个抹布一次清理完一个落满灰尘的工位」这个问题，我们可以想象下，落满灰尘的工位，肯定比较脏，除了桌面，还有电脑显示器、主机、柜子等需要清理。

如果一块抹布，我们拿来就上手，会发现桌子还没擦完，抹布就得洗洗啦，那么要想一次清理完，我们需要这个抹布可以多擦几次，那我们要如何才能让一个抹布可以尽量多擦几次呢？

经常做家务的(男)同学，这时候就比较有经验了，我可以正面擦一次，反面再擦一次呀！

对，所以前提是，不能拿来抹布随手就开始擦，而是先要平展开，规则的使用单面，这样至少可以用两次啦，但是两次也不一定够呀，怎么办？如何让只有两面的抹布出来多个有规则的面？

可能已经有人想到了，把抹布对折一下呗。

你看，折一次之后就是四个面，折两次就是八个面啦，一个抹布擦八次和擦一次，这反差效果还是挺大的吧。

咳咳，又有杠精来了：「理论上可以八次，实际上已经很脏了，越到后面效果越差呀。」

嗯，这是当然，所以除了折叠，我们还需要规划好擦拭的优先顺序，比如显示器这种不好擦又贵重的物品，可以优先擦，桌面就留到最后啦，这样虽然后面效果会差，但也是可以接受的啦。

好了，一个抹布我们说了这么多，感觉到惨了没？其实我主要想表达的还是，合理调整测试策略，可以让测试执行事半功倍。

三

看，抹布终于和测试扯上关系了哈，不过我们还是举个测试的例子再详细说明下吧。

比如有个项目，写了 100 条用例，现在大家要帮忙做第一轮覆盖的测试执行，常规来说只需要把用例从上到下、从前到后执行就行啦，但是呢，有可能出现跑到第 80 条用例时，突然发现一个 P1 的 Bug，然后一通捣鼓和定位，发现是技术架构的问题，如果修改，前面的所有付出全部白费，囧吧。

那基于前面抹布的惨案，我们可以想象一下，如果执行人员中有一个对测试策略有一定了解的人，那么他拿来用例的第一反应并不是立刻执行，而是先看看需求涉及的关键修改点，然后看看用例和需求的对应关系，并按照需求关键点的顺序把所有 P1 + P0 的用例重新做个排序，并按照这个顺序优先执行 P1 + P0 的重点用例，这样，或许就能第一时间发现这个潜在的 P1 级别 Bug 了。

当然这样的话，对执行人员的要求就比较高了，那我们再想象一下，如果主导该项目的项目负责人，在分配任务的时候，告知了哪部分功能的重要程度比较高，并且把所有用例按优先级顺序标注好，具体执行时也明确要求先执行优先级高的用例，只要执行人员能听明白，也同样可以尽早发现这个 P1 的 Bug。

那有同学说了，P1 级的用例，我们肯定都是优先执行的，这个例子不恰当呀，好吧，那 P2 的也可以这么来呀，当然，P2 的用例一般都比较多，那么策略还可以继续优化下，比如两个人执行的话，一个从上往下执行，一个从下往上执行，如果多个人的话，每个人可以划分出自己优先执行的范围，自己负责部分执行完了再去覆盖其他的部分。

总的原则就是，重要性高的用例优先覆盖，尽可能早的完成第一次的完整覆盖。

四

好了，这就是我早上清理工位时突然想到的，哈哈，脑洞是不是有点大？你觉得有道理不？欢迎留言讨论。