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

什么是底層邏輯？
?

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

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

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

......?

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

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

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

1. 對軟件測試的基本認知

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

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

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

• 軟件測試就是發現軟件中存在的缺陷

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

• 軟件測試是系統、完整地評估軟件產品質量，提供質量信息

• 軟件測試是暴露、揭示產品質量風險

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

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

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

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

• 這里提到的“軟件產品”不局限于程序，還包括數據、需求文檔、設計文檔、代碼、用戶手冊、技術手冊等。

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

2. 軟件測試的底層邏輯

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

為什么測？

測什么？

如何測？

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

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

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

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

如何測？就是找到獲取被測對象的質量數據的方式、方法或手段，包括測試方案設計、場景設計、測試用例或測試數據等的設計。

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

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

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

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

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

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

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

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

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

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

3.?測試流程的底層邏輯

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

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

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

概括起來：測試是貫穿整個研發周期，形成閉環，并持續改進。

4.?測試分析的底層邏輯

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

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

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

參考之前寫的文章：

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

• 軟件測試的結構化思維（上）

• 軟件測試的結構化思維（下）

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

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

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

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

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

5.?測試設計的底層邏輯

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

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

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

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

6.?測試自動化的底層邏輯

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

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

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

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

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

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

7.?測試人員的底層邏輯

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

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

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

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

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

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

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

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

• 【軟件測試能力圖譜】升級版

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

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

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

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

結論

軟件測試的底層邏輯是：盡早盡快地獲取必要的質量信息、揭示質量風險。

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

• 貫穿整個研發周期，形成閉環，并持續改進測試流程

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

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

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

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

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

總結

以上是生活随笔為你收集整理的软件测试的底层逻辑是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。