漫談測試人生：軟體測試的墨菲定律、二八定律和木桶定律…

談及人生，我們可能聽過不少具有哲理性且非常受用的定律，那麼談及 測試 ，又有哪些值得我們思考的定律呢？ 加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

墨菲定律

墨菲定律的原話是這樣的：Anything that can go wrong will go wrong。

凡事只要有可能出錯，那就一定會出錯。在測試工作中，我們經常會遇到這樣的場景。

場景一

在需求評審階段，我們憑藉著以往專案的測試經驗預感到這個專案的某些功能點或者某些環節會有潛在問題。

如果這個時候我們沒有及時思考和評估並暴露出風險，等到開發人員完成專案編碼並提交測試時，我們會發現，之前預感到可能發生的bug果然出現了。

場景二

在臨近專案釋出上線，專案依然還有嚴重等級比較高的bug需要修復，在開發人員的不懈努力下終於修復好了一個bug讓我們去驗證。

如果我們只是驗證這個bug並不展開驗證的話，開發人員與測試人員的“互相傷害”也就到此為止了，但是，出於職業意識，我們還是會去驗證下該bug關聯且有被影響風險的模組，結果就是，我們又發現新的bug。

關於墨菲定律，以上兩個場景並不一定是完成成立的，但是在大多工作中，墨菲定律在測試工作得到了印證：當我們憑藉經驗預感到相關的風險時，如果我們沒有及早暴露風險和問題，這些問題最後還是會發生。

二八定律

二八定律在 軟體測試 領域是這樣描述的：80% of all bugs can be found in 20% of program modules。

80%的問題可以在20%的模組中發現，換句話來說，軟體系統中的問題存在群集現象，大部分的問題會集中在少數的模組上。

在軟體專案開展過程中，如果我們沒有對需求和研發方案進行必要且充分的評審，在測試過程中，我們就會發現並 記錄 更多數量的缺陷。

開發類bug的統計結果如圖2-1所示，軟體專案中的bug確實存在群集現象，在少數模組或者功能上，集中了大部分的缺陷，而這部分模組，通常情況下就是軟體系統或者是本次迭代中比較核心的功能模組。 加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

 

圖2-1 二八定律

木桶定律

木桶定律闡述了這樣一個道理：A bucket's capacity is determined by its shortest stave。

一隻水桶能裝多少水取決於它最短的那塊模板。如圖3-1所示，軟體系統的質量正如這個水桶的容量，其質量不是隻取決於測試環節，而是同時取決於測試節點之前以及測試節點之後的所有環節。

如果任何一個環節的質量把控不好，整個軟體系統的質量也會受之影響。

所以為了及早捕獲系統缺陷，我們就要在更早的環節提前介入，儘可能地預防潛在的問題發生，將測試工作從測試環節向左移動。

為了保障系統釋出後線上上正確穩定執行，我們需要持續跟蹤線上系統的執行情況。

 

圖3-1 木桶定律

本文分享的三大定律可能存在一定的片面性，但是想分享的思想是明確的：提高風險控制和質量保障意識，及早地發現和推動問題的解決。

其中：

·墨菲定律告訴我們要有風險意識和風險控制能力。

·二八定律告訴我們要識別工作中的主要內容和次要內容，預防軟體系統中最核心且高風險的部分。

·木桶定律告訴我們軟體系統的質量不僅取決用軟體生命週期的某一個環節的質量，而是依賴軟體生命週期中的每個環節，正如一隻水桶能裝多少水取決於它最短的那塊模板，軟體系統的質量也取決於那個質量最差的環節。

最後，歡迎大家對 文章 糾錯指點，感謝。