軟體測試的底層邏輯

軟體測試的底層邏輯可以概括為三個問題的回答：為什麼測？？測什麼？？如何測？？

哪怕是微小的努力，也要讓我們每天的生活，變得明快、愉悅，把這件事看得高於一切，才是真正的【有品】

 

而且在回答這三個問題的過程中，要能適應不同的測試物件（如 Windows/MacOS native 應用、 web 軟體、移動 app 、嵌入式軟體 ）、不同的測試型別（如功能測試、效能測試、安全性測試、相容性測試等）、不同的測試層次（如單元測試、整合測試、系統測試等）、不同的團隊和不同的產品等，成為放之四海而皆準的答案。雖然上下文不同，會有不同的測試方法、技術和實踐，但我們能抽象出它們的共同點。

 

基於這樣的考慮，那下面就來回答這三個基本問題：

 

 

01 為什麼測？

只要是人做的工作，就不能保證萬無一失，會存在問題。如果軟體帶著問題出去，就很有可能給客戶帶來損失或讓客戶不滿意，最終導致企業的利益受損。過去無數的質量事故，也證明了這一點，在交付給客戶之前，軟體需要得到充分的測試，否則後果嚴重。

 

 

02

測什麼？

取決於交付的質量目標，即從質量目標出發，進行目標分解，然後針對每一個特地的子目標來確定要獲得的有關被測物件的質量資料，從而確定其測試範圍或測試項。如果再進一步，我們根據使用者對質量特性、功能特性的感受不同來決定測試項的優先順序。這部分屬於測試分析的工作，並涉及測試風險和測試策略。

 

03

如何測？

就是找到獲取被測物件的質量資料的方式、方法或手段，包括測試方案設計、場景設計、測試用例或測試資料等的設計。

 

也就是 For Quality, from Quality objectives and by getting Quality data ( 為了質量而測，從質量目標出發、想方設法獲取質量資訊）。

 

 

 

 

軟體測試靈魂三問，如何懟回去？

 

第 1 問：為什麼這個 Bug 測不出來？

 

第 2 問：測試怎麼測得？到底會不會測？

 

第 3 問：測試快點啊！為什麼總是測試拖後腿，最後才報 Bug ？

 

其實也體現了 “軟體測試”的另一層邏輯，即：

 

第 1 問的答案所呈現的底層邏輯：測試是不能窮盡的，測試總是有風險的，而且開發寫出的 Bug 越多，測試漏掉的 Bug 越多；測試只能證明已發現的缺陷是缺陷，不能證明軟體沒有缺陷，因為測試是一個樣本實驗。

 

第 2 問的答案所呈現的底層邏輯：對所做的測試工作（包括測試目標的制定、測試分析的過程以及對應的測試設計方法）能解釋清楚，而且測試不是孤立的工作，受需求（如需求模糊）、系統設計（如耦合性、複雜性）、程式設計（如偷偷修改程式碼）等影響，測試要與產品、開發等緊密合作。

 

第 3 問的答案所呈現的底層邏輯：我們可以在開發寫完程式碼之前完成測試分析、測試計劃和測試設計，但系統層次的測試執行需要等待開發完成版本構建，測試執行是後期工作，測試時間容易被開發前期工作擠掉一部分，專案的延期容易造成錯覺——測試拖後腿。

 

測試的底層邏輯（機率思維）：測試是一個樣本實驗，需要精心分析和設計，努力以最小的代價並儘早地去揭示質量風險。既然是一個樣本實驗，缺陷的分佈是正態分佈的，質量可以從 3sigma 提升到 6sigma ，但永遠達不到 100% 。