優先進行測試的 6 條原則

• 2020 年 3 月 13 日
• 筆記

進入正題前，我先說過小故事。

我們家老大留了個馬尾辮，所以晚上洗完頭髮都要吹乾才行，這種體力活當然是我來做了。

有一次洗完之後，我看到蓬蓬亂亂的，就想著給梳順了再吹，誰知道這梳子一下去怎麼也梳不動，稍微使勁又拽著頭髮痛，我就犯嘀咕了，這不是剛洗完的頭髮應該絲滑般順柔的么？

既然梳不動，那就不管了，先吹乾再說吧，數完 600 個數後（我家的習慣，老大嫌吹頭髮時間長，我就告訴她數完 600 個數准好，效果特別好），終於完事了，這時候才發現，都不用梳就已經是絲滑般柔順了，拿起梳子一梳，簡直順暢的不得了。

我突然恍然大悟，有些事情的順序是不能顛倒的，倒行逆施事倍功半，順勢而為事半功倍。

好了，故事講完了，你可能要疑惑了，這和今天的主題有什麼關係呢？

那我再講過故事好了。

團隊新接了個項目，這個項目有兩個文件，一個文件負責 UI 實現，另一個文件負責功能實現，功能實現文件提供介面給 UI 文件來同步功能的開關狀態，二麻子主要負責項目中 UI 部分的測試，三胖子負責功能介面文件的測試。

前期開發已經同步了介面的設計規格，所以項目實施過程中，兩條線就按各自的進度進行推進了。

開發提測後，二麻子很忙，每天都能提十來個 UI 的 Bug，不過有一些是開發還沒來得及實現，有一些是產品還沒給定明確的需求。

測試進行到第三天，終於可以做介面的聯調測試了，才發現好像哪兒不對勁，開關明明關閉了，為啥功能還生效著呢？原來功能開關是實時變化的，但是功能實際的開啟和關閉則必須等系統重啟後才生效。

現在怎麼辦？要麼接受現在的方案，畢竟進度已經推進的差不多了，要麼推翻現在的方案，畢竟目前的結果並不是用戶需要的。

如果是有如果的話，優先確認需求合理性是不是能發現這個問題？優先推進實際場景測試是不是可以提前發現這個問題？

這個例子稍微有點極端，因為過程中的漏洞太多了，但是不排除實際沒有這樣的事情發生。

為了更準確的說明，我就再講個故事好了。

二麻子今天的工作目標是在一個主流平台上完成一個項目的用例執行，大概 100 條測試用例，看起來時間緊任務重，二麻子一刻也不敢放鬆。

麻溜的搭建完測試環境，二麻子就開始馬不停蹄的進行用例執行了，半天時間跑了 40 條，看起來再努力一把，下班前完成任務是沒啥問題的。

可是二麻子並沒有按照用例優先順序的順序跑，因為想著反正今天都要跑完嘛，從上到下比較好計算進度，免得跳來跳去的。

結果還真就出問題了，因為這個項目是有驅動文件的，最後幾條用例寫的是要加驅動校驗。

一方面，功能測試要帶上校驗器來執行，也就是說，今天的用例可能白跑了，另一方面，二麻子加上校驗器之後發現系統藍屏了……屏了……了……

你說二麻子冤不冤，累死累活的忙活了一天，最後系統卻用一個藍屏來回報他，當然了，也怪二麻子自己沒有搞清楚用例執行的優先順序，才會導致前功盡棄。

好了，上面幾個例子都在說優先順序的重要性，那既然這麼重要，有沒有啥明確遵守的規則呢？

我大概總結了這麼幾條原則，僅供參考：

1、優先完成用戶實際場景的測試，其他再按需各種測； 2、優先保證需求的合理性，再驗證實現的正確性； 3、優先驗證實現方案的合理性，再驗證實現的正確性； 4、優先測試容易出現問題的地方（哪些地方容易出問題？看之前的回饋和問題單），再做常規測試； 5、優先功能驗證，再做 UI 驗證； 6、儘早聯調、儘早聯調、儘早聯調；

以上，我通過三個小故事說明了優先順序在做事（測試）過程中的重要性，同時提供了幾個優先測試的原則，不知道你是否有類似的經歷？