其實，這篇文章最開始的標題是《如何用一個抹布一次清理完一個落滿灰塵的工位》，讀來讀去覺得有點繞，寫到最後也發現，哇，這個抹布好慘呀，就把標題改為《一塊抹布引發的慘案》，又感覺有標題黨的嫌疑，最終就確定了目前這個標題。

言歸正傳，不知道讀到這的同學裏面有沒有杠精，做測試的話，我相信肯定有，不管怎樣，我先解釋一下，本次主要是討論測試策略的話題，比如如何盡早發現嚴重程度比較高的 Bug，有人會說，這和抹布有什麽關系？別著急，繼續看。

二

我一直覺得，測試不只是單純的技術輸出型工種，有時候發揮好軟技能，會起到事半功倍的效果。

就本次「如何用一個抹布一次清理完一個落滿灰塵的工位」這個問題，我們可以想象下，落滿灰塵的工位，肯定比較臟，除了桌面，還有電腦顯示器、主機、櫃子等需要清理。

如果一塊抹布，我們拿來就上手，會發現桌子還沒擦完，抹布就得洗洗啦，那麽要想一次清理完，我們需要這個抹布可以多擦幾次，那我們要如何才能讓一個抹布可以盡量多擦幾次呢？

經常做家務的(男)同學，這時候就比較有經驗了，我可以正面擦一次，反面再擦一次呀！

對，所以前提是，不能拿來抹布隨手就開始擦，而是先要平展開，規則的使用單面，這樣至少可以用兩次啦，但是兩次也不一定夠呀，怎麽辦？如何讓只有兩面的抹布出來多個有規則的面？

可能已經有人想到了，把抹布對折一下唄。

你看，折一次之後就是四個面，折兩次就是八個面啦，一個抹布擦八次和擦一次，這反差效果還是挺大的吧。

咳咳，又有杠精來了：「理論上可以八次，實際上已經很臟了，越到後面效果越差呀。」

嗯，這是當然，所以除了折疊，我們還需要規劃好擦拭的優先順序，比如顯示器這種不好擦又貴重的物品，可以優先擦，桌面就留到最後啦，這樣雖然後面效果會差，但也是可以接受的啦。

好了，一個抹布我們說了這麽多，感覺到慘了沒？其實我主要想表達的還是，合理調整測試策略，可以讓測試執行事半功倍。

三

看，抹布終於和測試扯上關系了哈，不過我們還是舉個測試的例子再詳細說明下吧。

比如有個項目，寫了 100 條用例，現在大家要幫忙做第一輪覆蓋的測試執行，常規來說只需要把用例從上到下、從前到後執行就行啦，但是呢，有可能出現跑到第 80 條用例時，突然發現一個 P1 的 Bug，然後一通搗鼓和定位，發現是技術架構的問題，如果修改，前面的所有付出全部白費，囧吧。

那基於前面抹布的慘案，我們可以想象一下，如果執行人員中有一個對測試策略有一定了解的人，那麽他拿來用例的第一反應並不是立刻執行，而是先看看需求涉及的關鍵修改點，然後看看用例和需求的對應關系，並按照需求關鍵點的順序把所有 P1 + P0 的用例重新做個排序，並按照這個順序優先執行 P1 + P0 的重點用例，這樣，或許就能第一時間發現這個潛在的 P1 級別 Bug 了。

當然這樣的話，對執行人員的要求就比較高了，那我們再想象一下，如果主導該項目的項目負責人，在分配任務的時候，告知了哪部分功能的重要程度比較高，並且把所有用例按優先級順序標註好，具體執行時也明確要求先執行優先級高的用例，只要執行人員能聽明白，也同樣可以盡早發現這個 P1 的 Bug。

那有同學說了，P1 級的用例，我們肯定都是優先執行的，這個例子不恰當呀，好吧，那 P2 的也可以這麽來呀，當然，P2 的用例一般都比較多，那麽策略還可以繼續優化下，比如兩個人執行的話，一個從上往下執行，一個從下往上執行，如果多個人的話，每個人可以劃分出自己優先執行的範圍，自己負責部分執行完了再去覆蓋其他的部分。

總的原則就是，重要性高的用例優先覆蓋，盡可能早的完成第一次的完整覆蓋。

四

好了，這就是我早上清理工位時突然想到的，哈哈，腦洞是不是有點大？你覺得有道理不？歡迎留言討論。

一塊抹布引發的關於測試策略的思考