“事物間的***同點，就是底層邏輯。
只有不同之中的相同之處、變化背後不變的東西，才是底層邏輯。
......
底層邏輯+環境變量 = 方法論”
所以我們要來探討壹下：軟件測試的底層邏輯是什麽？
1. 對軟件測試的基本認知
對軟件測試的基本認知，使我們達成***識，從而基於這個***識，更容易去討論軟件測試的底層邏輯。對軟件測試的基本認知，需要精簡到壹句話來描述，即抓住軟件測試的本質，以簡潔的方式描述正確的軟件測試價值觀，但不是某個人的軟件測試價值觀，而是能被大多數人接受的軟件測試價值觀。
軟件測試是驗證軟件功能特性是否滿足需求；
軟件測試就是發現軟件中存在的缺陷
軟件測試包含了靜態測試——需求、設計、代碼的評審活動
軟件測試是系統、完整地評估軟件產品質量，提供質量信息
軟件測試是暴露、揭示產品質量風險
軟件測試不僅是技術性活動，而且是 社會 性、心理等多方面的綜合性活動。
軟件測試是通過投入質量保障性成本來極大地減少劣質成本
根據這些對軟件測試的認知，用壹句話來說明軟件測試的基本認知，那就是：基於對用戶真實需求的理解，通過各種手段獲得軟件產品真實的、全方位的質量信息。無論是驗證軟件功能特性是否滿足需求、評估產品的質量還是揭示產品的質量風險，都是基於獲得的有關產品的真實的質量信息做出判斷的，而缺陷可以看做是這個活動過程中的副產品。
這裏強調對用戶真實需求的理解，壹方面體現“沒有用戶就沒有質量，質量相對用戶而存在”，我們必須從用戶角度出發來完成測試，另方面是用戶的真實需求，而不是虛假的、錯誤的需求，業務的需求最終要分解成用戶角色的需求，而系統的功能/非功能性需求也是為了滿足用戶的需求。
這裏提到的“軟件產品”不局限於程序，還包括數據、需求文檔、設計文檔、代碼、用戶手冊、技術手冊等。
了解了“什麽是軟件測試”之後，下面就可以討論軟件測試的底層邏輯。
2. 軟件測試的底層邏輯
軟件測試的底層邏輯可以概括為三個問題的回答：
為什麽測？
測什麽？
如何測？
而且在回答這三個問題的過程中，要能適應不同的測試對象（如Windows/MacOS native應用、 web軟件、移動app、嵌入式軟件 ）、不同的測試類型（如功能測試、性能測試、安全性測試、兼容性測試等）、不同的測試層次（如單元測試、集成測試、系統測試等）、不同的團隊和不同的產品等，成為放之四海而皆準的答案。雖然上下文不同，會有不同的測試方法、技術和實踐，但我們能抽象出它們的***同點。
基於這樣的考慮，那下面就來回答這三個基本問題：
為什麽測？只要是人做的工作，就不能保證萬無壹失，會存在問題。如果軟件帶著問題出去，就很有可能給客戶帶來損失或讓客戶不滿意，最終導致企業的利益受損。過去無數的質量事故，也證明了這壹點，在交付給客戶之前，軟件需要得到充分的測試，否則後果嚴重。
測什麽？取決於交付的質量目標，即從質量目標出發，進行目標分解，然後針對每壹個特定的子目標來確定要獲得的有關被測對象的質量數據，從而確定其測試範圍或測試項。如果再進壹步，我們根據用戶對質量特性、功能特性的感受不同來決定測試項的優先級。這部分屬於測試分析的工作，並涉及測試風險和測試策略。
如何測？就是找到獲取被測對象的質量數據的方式、方法或手段，包括測試方案設計、場景設計、測試用例或測試數據等的設計。
軟件測試靈魂三問，如何懟回去？
第 1 問：為什麽這個 Bug 測不出來？
第 2 問：測試怎麽測得？到底會不會測？
第 3 問：測試快點啊！為什麽總是測試拖後腿，最後才報 Bug？
其實也體現了“軟件測試”的另壹層邏輯，即：
第1問的答案所呈現的底層邏輯：測試是不能窮盡的，測試總是有風險的，而且開發寫出的Bug越多，測試漏掉的Bug越多；測試只能證明已發現的缺陷是缺陷，不能證明軟件沒有缺陷，因為測試是壹個樣本實驗。
第2問的答案所呈現的底層邏輯：對所做的測試工作（包括測試目標的制定、測試分析的過程以及對應的測試設計方法）能解釋清楚，而且測試不是孤立的工作，受需求（如需求模糊）、系統設計（如耦合性、復雜性）、編程（如偷偷修改代碼）等影響，測試要與產品、開發等緊密合作。
第3問的答案所呈現的底層邏輯：我們可以在開發寫完代碼之前完成測試分析、測試計劃和測試設計，但系統層次的測試執行需要等待開發完成版本構建，測試執行是後期工作，測試時間容易被開發前期工作擠掉壹部分，項目的延期容易造成錯覺——測試拖後腿。
測試的底層邏輯（概率思維）：測試是壹個樣本實驗，需要精心分析和設計，努力以最小的代價並盡早地去揭示質量風險。
3. 測試流程的底層邏輯
測試流程符合壹般工程項目流程，經過分析、計劃、設計、實施和評估的過程，任何壹個環節不可缺失，每壹個環節都重要，但前面的環節會影響後面的環節，所以越在前面的環節越重要。測試分析是基礎，依次是設計、實施和評估，構成壹個金字塔模型。
測試流程的另壹個底層邏輯：形成閉環。如果經過評估，發現測試過程有問題，需要重新分析、修改計劃、修改設計......再經過壹個完整的過程，構成壹個新的閉環。
4. 測試分析的底層邏輯
測試分析的底層邏輯是基於系統思維、結構化思維去思考，需要從項目背景、產品結構、質量要求等各個方面進行系統地思考，不容忽視壹些蛛絲馬跡，順藤摸瓜，完整地呈現測試範圍，識別出各種測試風險，最終明確測試項及其優先級。
測試分析的底層邏輯之壹：測試分析是層層剝離、逐步深入的系統分析過程。從業務需求、用戶行為、系統功能、應用場景等不同維度對被測對象進行系統的分析，最終確定測什麽。
測試分析的底層邏輯之二：測試分析也是壹個博弈、選擇直至平衡的過程，需要定力和洞察力，做出取舍，如運用80/20原則，抓主要風險，有時需要舍棄壹些次要風險。
測試分析的底層邏輯之三：以終為始，從測試目標出發最終回到測試目標，如從考慮如何衡量測試充分性地要求出發，最終分析的結果——各測試項完成是能夠滿足測試充分性的要求的。
5.測試人員的底層邏輯
最後談談測試人員的底層邏輯。測試人員是否有價值，不取決於他/她目前的工作態度、知識與技能，而是取決於工作態度、知識與技能的進步速度，因為我們無法改變過去，但可以改變未來。只要持續學習、持續反思，就能快速完成自己的進化，快速成長起來，就沒有人能擋得住妳的壯麗前程。