軟體測驗的底層邏輯是什么？

原創 Test Ninja 軟體質量報道 2021-12-08 07:55

什么是底層邏輯？

按照劉潤老師的解釋就是：

“事物間的共同點，就是底層邏輯，

只有不同之中的相同之處、變化背后不變的東西，才是底層邏輯，

......

底層邏輯+環境變數 = 方法論”

他還說：“只有底層邏輯，才是有生命力的，”

所以我們要來探討一下：軟體測驗的底層邏輯是什么？

1. 對軟體測驗的基本認知

對軟體測驗的基本認知，使我們達成共識，從而基于這個共識，更容易去討論軟體測驗的底層邏輯，對軟體測驗的基本認知，需要精簡到一句話來描述，即抓住軟體測驗的本質，以簡潔的方式描述正確的軟體測驗價值觀，但不是某個人的軟體測驗價值觀，而是能被大多數人接受的軟體測驗價值觀，

在我寫的《全程軟體測驗（第3版）》第1章中，深度討論了對軟體測驗的認知，

• 軟體測驗是驗證軟體功能特性是否滿足需求；

• 軟體測驗就是發現軟體中存在的缺陷

• 軟體測驗包含了靜態測驗——需求、設計、代碼的評審活動

• 軟體測驗是系統、完整地評估軟體產品質量，提供質量資訊

• 軟體測驗是暴露、揭示產品質量風險

• 軟體測驗不僅是技術性活動，而且是社會性、心理等多方面的綜合性活動，

• 軟體測驗是通過投入質量保障性成本來極大地減少劣質成本

根據這些對軟體測驗的認知，用一句話來說明軟體測驗的基本認知，那就是：基于對用戶真實需求的理解，通過各種手段獲得軟體產品真實的、全方位的質量資訊，無論是驗證軟體功能特性是否滿足需求、評估產品的質量還是揭示產品的質量風險，都是基于獲得的有關產品的真實的質量資訊做出判斷的，而缺陷可以看做是這個活動程序中的副產品，

• 這里強調對用戶真實需求的理解，一方面體現“沒有用戶就沒有質量，質量相對用戶而存在”，我們必須從用戶角度出發來完成測驗，另方面是用戶的真實需求，而不是虛假的、錯誤的需求，業務的需求最終要分解成用戶角色的需求，而系統的功能/非功能性需求也是為了滿足用戶的需求，

• 這里提到的“軟體產品”不局限于程式，還包括資料、需求檔案、設計檔案、代碼、用戶手冊、技術手冊等，

了解了“什么是軟體測驗”之后，下面就可以討論軟體測驗的底層邏輯，

2. 軟體測驗的底層邏輯

軟體測驗的底層邏輯可以概括為三個問題的回答：

1. 為什么測？

2. 測什么？

3. 如何測？

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

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

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

2. 測什么？取決于交付的質量目標，即從質量目標出發，進行目標分解，然后針對每一個特地的子目標來確定要獲得的有關被測物件的質量資料，從而確定其測驗范圍或測驗項，如果再進一步，我們根據用戶對質量特性、功能特性的感受不同來決定測驗項的優先級，這部分屬于測驗分析的作業，并涉及測驗風險和測驗策略，

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

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

之前也寫過一篇文章：軟體測驗靈魂三問，如何懟回去？ 對文中“靈魂三問”的回答，是不是也體現了軟體測驗的底層邏輯？

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

第 2 問：測驗怎么測得？到底會不會測？

第 3 問：測驗快點啊！為什么總是測驗拖后腿，最后才報 Bug？

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

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

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

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

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

3. 測驗流程的底層邏輯

測驗流程符合一般工程專案流程，經過分析、計劃、設計、實施和評估的程序，任何一個環節不可缺失，每一個環節都重要，但前面的環節會影響后面的環節，所以越在前面的環節越重要，測驗分析是基礎，依次是設計、實施和評估，構成一個金字塔模型，

測驗流程的另一個底層邏輯：形成倍訓，如果經過評估，發現測驗程序有問題，需要重新分析、修改計劃、修改設計......再經過一個完整的程序，構成一個新的倍訓，從測驗流程改進來看，也需要構成PDCA那樣的倍訓，從今天DevOps的角度看，測驗是為了讓用戶更滿意，但同時要進行用戶調查，收集用戶反饋，構成倍訓，如我16年前所畫的倍訓，

從缺陷帶來的成本來看，測驗進行的越早越好，因為劣質成本是指數級增長，

概括起來：測驗是貫穿整個研發周期，形成倍訓，并持續改進，

4. 測驗分析的底層邏輯

測驗分析的底層邏輯是基于系統思維、結構化思維去思考，需要從專案背景、產品結構、質量要求等各個方面進行系統地思考，不容忽視一些蛛絲馬跡，順藤摸瓜，完整地呈現測驗范圍，識別出各種測驗風險，最終明確測驗項及其優先級，

系統思維可以讓我們看清楚被測物件的輸入/輸出、前置條件和后置條件、周圍環境和面臨的各種場景，

結構化思維幫助我們制定更有效的測驗方案和測驗策略，如分層測驗、面向介面的測驗等，同時，測驗總是有風險的，所以測驗分析時一定要采用基于風險的測驗策略，并應用80/20原則，確定20%最嚴重的風險集中在什么地方、哪些功能是用戶最常用的20%功能、哪些測驗項是屬于重點測驗的20%等，

參考之前寫的文章：

• 測無定法，測必有法：測驗策略運用之道

• 軟體測驗的結構化思維（上）

• 軟體測驗的結構化思維（下）

• 看家本領之一：軟體測驗的系統性思維

• 看家本領之二：軟體測驗的分析性思維

測驗分析的底層邏輯之一：測驗分析是層層剝離、逐步深入的系統分析程序，從業務需求、用戶行為、系統功能、應用場景等不同維度對被測物件進行系統的分析，最終確定測什么，

測驗分析的底層邏輯之二：測驗分析也是一個博弈、選擇直至平衡的程序，需要定力和洞察力，做出取舍，如運用80/20原則，抓主要風險，有時需要舍棄一些次要風險，

測驗分析的底層邏輯之三：以終為始，從測驗目標出發最侄訓到測驗目標，如從考慮如何衡量測驗充分性的要求出發，最終分析的結果——各測驗項完成是能夠滿足測驗充分性的要求的，

5. 測驗設計的底層邏輯

測驗設計是基于測驗分析的結果，運用合適的方法完成測驗資料、測驗場景或測驗用例的設計，按照工程思維的方式，解決方案不只一個，要設計多個方案，從中選出更優或最優的方案，

測驗設計的本質是以更有效的方式覆寫測驗需求，從場景覆寫、邏輯覆寫、路徑覆寫和資料覆寫等不同覆寫策略中選擇一種或幾種，測驗設計也是一個循序漸進的程序，不斷完善的程序，

測驗設計是辯證統一的思維程序，既有嚴密的邏輯思維，也有跳躍式、發散性的創造性思維；既是黑盒測驗方法和白盒測驗方法的對立統一、靜態測驗和動態測驗的融合，也是主動測驗和被動測驗的融合......只有這樣才能更徹底地滿足設計要求，更快地完成測驗以實作測驗目標，

測驗設計的底層邏輯：測驗設計是藝術，更要創新、融合，

6. 測驗自動化的底層邏輯

測驗自動化就是要充分發揮工具的作用或價值，例如工具能百分之百地執行命令、任勞任怨，所以自動化測驗適合機械、單調的測驗作業，如回歸測驗、性能負載測驗、壓力測驗、兼容性測驗、BVT（版本構建驗證測驗）等，

測驗自動化的腳本開發和執行是建立在測驗分析和設計之上，如果測驗分析和設計存在問題，依靠工具是無法解決這類問題的，有更好的測驗分析和設計，才有更好的自動化測驗，所以我們清楚測驗分析/設計與自動化測驗的關系顯得非常重要，

工具的開發和使用、腳本的開發和使用都是由人完成的，所以人還是第一位的，工具是第二位的，測驗自動化還受到文化、流程的影響，測驗自動化能否成功不是一個技術問題，今天來看，技術上已經沒有障礙了，障礙往往出現在企業的文化、研發流程和開發質量（如軟體實作的規范性、可測驗性等）等方面，

測驗自動化的底層邏輯之一：工具重要，但人才是決定的因素；

測驗自動化的底層邏輯之二：自動化測驗是建立在測驗分析與設計的基礎之上；

測驗自動化的底層邏輯之三：一切適合自動化的測驗作業都盡可能地被自動化，同時要創造有利于自動化測驗的環境，

7. 測驗人員的底層邏輯

最后談談測驗人員的底層邏輯，測驗人員是否有價值，不取決于他/她目前的作業態度、知識與技能，而是取決于態度、知識與技能的進步速度，因為我們無法改變過去，但可以改變未來，只要持續學習、持續反思，就能快速完成自己的進化，快速成長起來，就沒有人能擋得住你的壯麗前程，

之前寫過幾篇文章，討論測驗人員如何學習、如何反思和如何成長：

• 從對人負責的角度，重新理解軟體測驗

• 拋磚引玉，討論如何更好地為測驗而學

• 看家本領之三：軟體測驗的批判性思維

• 讀了這篇文章，受益終身：敏捷測驗思維模式

• 我見過最大的世面，是2013年負債1萬去上海聽了一場雅尼的音樂會

• 只要堅信自己，任何目標都是能實作的

• 【軟體測驗能力圖譜】升級版

• 軟體測驗人員迷茫之中如何找到職業發展的方向？

• 永遠無法改變別人、只能改變自己：持續學習是最好的途徑

如果我們掌握了軟體測驗的底層邏輯，只有探尋到萬變中的不變，才能動態地、持續地看清軟體測驗的本質，看清軟體測驗的底牌，我們就能始終如魚得水，

測驗人員的底層邏輯：只要你持續地學習與反思，沒有人能夠擋得住你成長為測驗專家，

結論

軟體測驗的底層邏輯是：盡早盡快地獲取必要的質量資訊、揭示質量風險，

為此，延伸出來的軟體測驗底層邏輯有：

• 貫穿整個研發周期，形成倍訓，并持續改進測驗流程

• 基于風險的測驗策略是必不可少的

• 以終為始、系統地分析測驗需求，在資源和測驗目標之間尋求平衡

• 測驗設計是藝術，更要創新、融合

• 在分析和設計的基礎上，盡可能地實作自動化測驗

• 講好測驗故事，和各方一致、協同作業