墨菲定律
墨菲定律的原話是這樣的：Anything that can go wrong will go wrong。
凡事只要有可能出錯，那就一定會出錯。在測試工作中，我們經常會遇到這樣的場景。
關注我，每天分享軟件測試技術乾貨、面試經驗，想進《Python自動化測試學習交流羣》可以直接加V：atstudy-js
場景一
在需求評審階段，我們憑藉着以往項目的測試經驗預感到這個項目的某些功能點或者某些環節會有潛在問題。
如果這個時候我們沒有及時思考和評估並暴露出風險，等到開發人員完成項目編碼並提交測試時，我們會發現，之前預感到可能發生的bug果然出現了。
場景二
在臨近項目發佈上線，項目依然還有嚴重等級比較高的bug需要修復，在開發人員的不懈努力下終於修復好了一個bug讓我們去驗證。
如果我們只是驗證這個bug並不展開驗證的話，開發人員與測試人員的“互相傷害”也就到此爲止了，但是，出於職業意識，我們還是會去驗證下該bug關聯且有被影響風險的模塊，結果就是，我們又發現新的bug。
關於墨菲定律，以上兩個場景並不一定是完成成立的，但是在大多工作中，墨菲定律在測試工作得到了印證：當我們憑藉經驗預感到相關的風險時，如果我們沒有及早暴露風險和問題，這些問題最後還是會發生。
二八定律
二八定律在軟件測試領域是這樣描述的：80% of all bugs can be found in 20% of program modules。
80%的問題可以在20%的模塊中發現，換句話來說，軟件系統中的問題存在羣集現象，大部分的問題會集中在少數的模塊上。
在軟件項目開展過程中，如果我們沒有對需求和研發方案進行必要且充分的評審，在測試過程中，我們就會發現並記錄更多數量的缺陷。
開發類bug的統計結果如圖2-1所示，軟件項目中的bug確實存在羣集現象，在少數模塊或者功能上，集中了大部分的缺陷，而這部分模塊，通常情況下就是軟件系統或者是本次迭代中比較核心的功能模塊。
圖2-1 二八定律
木桶定律
木桶定律闡述了這樣一個道理：A bucket's capacity is determined by its shortest stave。
一隻水桶能裝多少水取決於它最短的那塊模板。如圖3-1所示，軟件系統的質量正如這個水桶的容量，其質量不是隻取決於測試環節，而是同時取決於測試節點之前以及測試節點之後的所有環節。
如果任何一個環節的質量把控不好，整個軟件系統的質量也會受之影響。
所以爲了及早捕獲系統缺陷，我們就要在更早的環節提前介入，儘可能地預防潛在的問題發生，將測試工作從測試環節向左移動。
爲了保障系統發佈後在線上正確穩定運行，我們需要持續跟蹤線上系統的運行情況。
圖3-1 木桶定律
本文分享的三大定律可能存在一定的片面性，但是想分享的思想是明確的：提高風險控制和質量保障意識，及早地發現和推動問題的解決。
其中：
·墨菲定律告訴我們要有風險意識和風險控制能力。
·二八定律告訴我們要識別工作中的主要內容和次要內容，預防軟件系統中最核心且高風險的部分。
·木桶定律告訴我們軟件系統的質量不僅取決用軟件生命週期的某一個環節的質量，而是依賴軟件生命週期中的每個環節，正如一隻水桶能裝多少水取決於它最短的那塊模板，軟件系統的質量也取決於那個質量最差的環節。