墨菲定律
墨菲定律的原話是這樣的：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 木桶定律
本文分享的三大定律可能存在一定的片面性，但是想分享的思想是明确的：提高風險控制和品質保障意識，及早地發現和推動問題的解決。
其中：
·墨菲定律告訴我們要有風險意識和風險控制能力。
·二八定律告訴我們要識别工作中的主要内容和次要内容，預防軟體系統中最核心且高風險的部分。
·木桶定律告訴我們軟體系統的品質不僅取決用軟體生命周期的某一個環節的品質，而是依賴軟體生命周期中的每個環節，正如一隻水桶能裝多少水取決于它最短的那塊模闆，軟體系統的品質也取決于那個品質最差的環節。