測試的底層邏輯

作者：京東零售 張強

寫這篇文章，是希望把我的一些我認為是非常有價值的經驗總結出來，能夠幫助剛做測試不久的新同事，或者是測試經驗豐富的老同事以共享。希望我們可愛的新同事，準備要在測試領域耕耘的夥伴，能夠通過我的文章瞭解到測試的底層邏輯，也就是我們測試工作中可能看不到隱藏較深的點，而不只是日常所見的寫用例、提bug、開發自動化、做平臺；俗話說外行看熱鬧，內行看門道。

我認為測試人員不應該成為PRD的搬運工，高階測試工程師也不應該只是測試工具得開發者；

測試人員，最基本的測試基礎理論一定要掌握，當然研發編碼技術也必不可少；如果這兩樣缺少一樣，都無法成為一個優秀的測試人員；之前有很多測試人員都是不喜歡寫程式碼，然後做了測試；但在未來或者現在，一個不懂程式碼的測試人員，很難成為一個優秀的測試人員；但只懂程式碼，不瞭解測試理論基礎的人（不懂得測試分析、用例設計、測試策略的人，或者即使瞭解一些 ，但實際工作中不怎麼使用的人），一定也不是一個合格的測試人員。

下面帶大家瞭解一些測試的底層邏輯，測試的門道。

一、優秀測試人員應該具備的核心能力

根據Testerhome《2021年度測試行業問卷調查報告》-【優秀測試人員應具備的技術/能力】分析，

1、“程式設計/指令碼/自動化、溝通表達、測試基礎理論” 被認為是優秀測試人員的三大核心能力，繼續領先其他項；

2、資料庫、效能測試、安全測試、大資料演算法等技術要求，從2020年開始大幅增長；

三大核心能力基本是大家公認的，也是穩定不變的；但新的技術要求近幾年開始都有了大量需求；從分析資料可以看到，市場對測試人員的要求會隨著新技術的出現而不斷變化；但三大核心能力是測試人員的必修課，變化不會太大，會一直佔據核心位置。

自從10幾年前的QTP開始，自動化測試就是測試人員追求的目標；直至今日，各種自動化技術、框架已經琳琅滿目；市場對測試人員的要求也越來越高，測試人員不僅要會寫自動化用例，還需要具備開發維護自動化框架平臺的能力；純黑盒的測試人員要麼已經完成了能力升級，要麼在升級的路上；完全依賴黑盒測試完成工作的已經越來越少，如果不會編寫自動化用例或不瞭解程式語言，估計找工作簡歷都很難通過。

但往往物極必反，測試人員的程式碼能力越來越強，測試基礎能力卻被忽視，測試領域的專業能力逐步被淡化；正如逆水行周，不進則退；三大核心能力應該是齊頭並進，不應該顧此失彼。

這些年參與了部門很多的招聘面試，我的感受就是很多測試人員雖然工作多年，但對測試用例的設計方法、策略等掌握並不好；至少有60%的人在用例設計中不會用什麼用例設計方法，也不會思考怎麼進行測試分析和設計，他們大部分只是功能測試的執行者，測試設計方面思考很少，測試計劃更是很少有人寫，測試用例也只是PRD的拆分；總之，測試人員一不小心就會成為PRD的搬運工。

作為一個測試老人，還是希望測試行業能夠健康發展，在新技能提升的情況下，測試的專業性也能與時俱進，畢竟質量保障是測試人員的根本。

二、黑盒測試的底層邏輯

什麼是黑盒測試？

它是把程式看作一個黑盒子，在不考慮程式內部結構的情況下，檢查程式功能是否按照PRD的規定正常使用，程式是否能適當地接收輸入資料，產生正確的輸出。

這，其實就是黑盒測試的定義，也是黑盒測試的底層邏輯；一般人不會重視定義，但往往就是定義會告訴你真理。

工作中有很多人在習慣了一種型別的系統測試，然後換一個新的業務型別，忽然就不知如何下手了；也許是新的總要有一個適應的時間；其實萬變不離其宗，只要掌握了黑盒測試的底層邏輯，就能夠讓你很快上手不再需要適應調整；

我們大部分做的都是黑盒測試，所以無論什麼型別的系統，我們的測試方案都是“ 檢查程式功能是否按照PRD的規定正常使用，程式是否能適當地接收輸入資料，產生正確的輸出。” 。

我們的測試依據是PRD，首先必須對PRD瞭如執掌，然後分析他的輸入有哪些，輸出有哪些；這些都覆蓋到了，你基本就可以做到80分了，也就是你拿下這個專案已不成問題。

最後，我還是想再囉嗦強調一下， 就怕我講的大家還是沒有看懂，因為上面講的大家都懂，第一天瞭解測試，就知道什麼時候黑盒測試，什麼輸入輸出了；但是往往真理就藏在平凡之間，記住他的定義！！！

當你遇到專案不知如何下手測試時，把定義拿出來認真讀三遍，一定會找到答案！！！

強調： 實際當中純黑盒的其實並不多，除了瞭解輸入、輸出，中間的處理邏輯也一定要清楚，這樣對測試更有幫助；另外更重要的就是：必須熟讀PRD，必須對PRD裡的內容分析透徹，不放過任何一段文字，一個詞。其實PRD裡和設計文件裡也會有很多的漏洞等你挖掘。

三、黑盒測試底層邏輯詳解：【輸入輸出測試模型】

【輸入】： 這裡的輸入，並不是簡單的介面輸入框才算是輸入；任何只要能夠觸發系統執行的都是輸入。按照程式碼架構分層，輸入也可以做到如下分類：

1、介面操作的輸入：

正向操作：

1）單一操作：

•正常的操作：輸入框、按鈕、單選複選框、按鈕、下拉框等的規定操作異常的操作：輸入框的異常值、超長輸入等、按鈕的多次點選、快速連續點選（很容易就會發現資料重複提交，或者系統反應緩慢等各種問題，說不定系統就此而奔潰）

2）複雜操作：

•組合操作：一般系統的功能都是各種操作的組合；另外一種跟業務場景相關，也就是各種業務場景同時組合進行操作。

•並行操作：多人對同一功能點的併發操作；或者多人對同一個資料進行的操作，比如兩個人同時對一條單價進行修改、刪除等操作。

逆向操作：

3）逆向操作：

•回退操作：通過瀏覽器或APP進行的回退操作取消操作：正常操作突然取消，例如使用者填寫很多表格內容，突然操作了取消，是否需要儲存或提示呢？刪除操作：通過系統提供的功能對資料進行刪除

下面的輸入是最容易被忽略的：

2、服務層的輸入：

•介面服務：對外提供的介面，對於系統來說也是很常見的一種輸入，這種輸入也是最容易出問題的；

•檔案上傳：有些系統功能是通過獲取ftp伺服器上的excel、xml等檔案來觸發系統執行的，所以這時候的輸入就變成了檔案。

•MQ訊息：也是京東最常見的一種輸入形式，MQ裡也可能會包含檔案地址等，這種輸入就更加靈活了。

強調：

•對於介面上游的輸入，無論何種形式，都要分析上游資料的每一個欄位，瞭解上游各種輸入的可能。

•有些欄位還必須從業務【源頭】瞭解這個欄位的含義，可能的列舉值，可能的結果等；

•另外由於歷史原因，源頭的資料就可能存在各種想像不到的資料；

•對於輸入的分析非常重要，這時候你就可以使用【等價類】方法進行分析。

3、資料層的輸入：

•資料的變化：有很多後臺處理的任務就是監控是否有新資料的插入或刪除等資料欄位的變化：後臺處理任務監控資料狀態的變化，或組合欄位的變化等快取資料的變化：除了資料庫的變化，有的是快取資料的變化時間的變化：定時任務除了資料是輸入，時間也是他的輸入。

【輸出】：輸出分為可見輸出和不可見輸出

看的見的輸出： 就是我們常見的系統操作反饋，使用者能直接看到的變化；比如彈框、提示、跳轉、資料的新增、修改、刪除後的變化，圖片、視訊等操作後的變化等等。

看不見的輸出： 看不見的輸出是最容易忽略也是最容易出問題的；【看不見的輸出】包括：資料庫的變化、快取的變化、系統檔案的變化、傳送給下游介面的資料等

【看的見的輸出】雖然能夠幫我們驗證基本90%以上的功能，通過介面展示的資料也能驗證我們新增或修改的資料，是否新增成功了或正確的被修改了；但是我們看到的只是一部分；還有很多欄位是沒有被展示的，有的可能只是給下游或其他系統使用的，也有可能是留給未來使用的；這些不可見的部分，經常就會引起系統的異常，也是隱藏在系統中最大的坑；

所以測試，除了站在使用者的角度去測試系統，還要站在設計者的角度去測試，更應該站在整個產品的角度去思考。

---

四、測試分析與設計的底層邏輯

說到測試分析與設計，我認為這個是測試人員最核心的能力；上面講到的黑盒測試、輸入輸出模型，只是針對功能測試的方法，雖然一般的系統測試中功能測試佔到80%-90%左右，但並不是全部。而且也只是測試中的一個階段一個型別，要想做好測試，測試分析和設計是必不可少的。

大家可以思考一個問題：拿到一個專案，你如何來測試？如何保障質量？

面試中很多人給我的答案是：分析需求，編寫用例，然後執行測試，發報告；這個只是測試的流程，只是告訴了我們測試的先後順序，但並不能指導一個測試人員如何去測試，如何去做測試分析，更無法保障系統的質量。

拿到一個專案，你如何來測試？

可以借用5W2H方法來分析，其實作為測試架構師，不需要5W也不需要3W，2W+1H 就夠了！

因為這2W+1H 是最重要的，也是最容易被經驗代替然後就忽略的；日常的測試工作由於產品的形態及系統的架構基本固定，所以測試方案思路也基本固定，這樣就導致拿到類似的專案就不再有思考，基本很快就按照經驗開始幹了；一旦遇到不同型別的系統，或者遇到新的業務就不知如何下手，這時候2W1H分析法就可以幫助我們解決這個問題。

測試架構師只需要思考三個問題（2W+1H） 就夠了：

1、Why？ 為什麼做這個專案？專案的背景是什麼？——只有知道為什麼，才知道使用者想要什麼。

2、What？ 這個專案我們需要測什麼？我們的測試範圍有哪些？——只有範圍明確，測試才不會遺漏。

3、How? 這個專案我們怎麼測？我們應該使用哪些測試策略、測試方法？——這裡告訴我們測試應當有策略有方法

測試負責人（也可能是測試架構師）還需確定的兩個問題：

4、When? 專案期望的完成時間？

5、Who? 可以呼叫的資源有哪些？

專案經理需要考慮的另外兩個問題：（測試負責人也需要思考的2個問題）

6、Where？是否需要集中封閉，是否需要研發測試坐到一起？

測試人員還可以思考需要在什麼環境下測試？測試環境？預發環境？線上環境？windows環境？Linux環境？ios環境？Android？什麼瀏覽器？什麼版本等等

7、How Much？ 這個專案成本是多少？需要多少人日？需要多少伺服器資源？

測試分析和設計的底層邏輯就是如何回答好2W1H這三個問題；Why和What可以指導我們進行測試分析，瞭解專案的【背景】，確認測試的【範圍】；How可以指導我們去進行測試設計，根據專案背景及測試範圍確定測試的【策略】。

不過目前講的還是方法論，具體的操作步驟還沒有講；由於這一部分內容比較多，可以通過一篇文章具體來講；大家也可以自己去了解學習一下，就是HTSM啟發式測試策略模型，這個模型正好與2W+1H是相對應的。

---

五、測試人員的內功修煉

作為測試人員，“溝通表達等軟技能”被認為是優秀測試人員的三大核心能力一，根據上面的統計資料，90%以上的人都是認可的。下面把我之前的一些總結分享一下：

1、主動溝通

在電商領域，特點就是快速和變化；有些需求或專案，經常要求快速上線，由於時間短，PRD裡有些邏輯就可能會存在漏洞或者根本沒有考慮到，面對這樣的情況，我們測試該怎麼辦呢？這時就需要溝通，與產品隨時溝通需求，與開發隨時溝通設計，與其他系統隨時溝通聯調，沒有溝通，專案裡的坑很容易就會被遺漏。溝通還必需得是主動出擊，找產品、找研發、找其他條線的測試，把自己當成老闆，這個專案的質量基本就有保障了；把自己當成老闆的員工，一定是最讓老闆放心的員工。

2、要有自己的標準

系統測試最基本的依據就是需求規格說明書；作為測試人員，我們是最後一道保障；測試必須有自己的分析，不能輕易就跟著研發的思路走，因為他告訴你的已經是經過他們思考加工過的，與原始需求可能已經存在了偏差；這也正是測試的價值所在。即使他們說的99%都是對的，但是也只能作為我們分析的一個材料；我們必須自己通過需求去分析。

3、對一切都要有懷疑的態度

需求是測試的依據，但是依據也有錯的時候；所以對PRD也要有懷疑的態度。測試就是要懷疑一切； 每一個流程每一個細節；我看需求的時候第一遍基本預設他是對的，等對整體有了一定的理解，我就開始懷疑，流程是否完整? 是否存在漏洞? 模組功能是否能滿足使用者的要求? 非正常操作是否會出現問題? 使用者是否會用？這個功能是否真的為客戶解決了問題？等等，這些問題可以通過我們的一些質量標準、測試策略以及測試經驗去懷疑，去思考。總之，測試每一個功能都要“三思”。

4、站在公司和使用者的角度思考

公司越大，部門越多，系統就會越複雜；相互依賴越多，出問題的機率也會越大；因為邊界多了，溝通成本也就高了；需要溝通的點多了，只要有些細節沒有溝通到位，或者都沒有考慮到，或者都認為是對方負責，那坑就出現了；當然這樣的坑大部分會在聯調測試階段發現，但對於測試進度影響非常大，經常會造成反工、延期等風險；

要想這些坑能夠在測試階段發現，這時候就需要有一個主測試了；但我覺得主測試不應該是一個人，所有測試人員都應該是“主測試”；作為測試人員，軟體質量的最後把關者，不能只看到自己負責的這一塊，不能侷限於自己的部門、團隊，只要對整個系統有疑問，我們都有責任提出來，去找人解決。測試不能只看區域性，要看全域性；要站在公司的位置和使用者的角度去思考，去測試。

上面主要是總結了我得一些經驗，測試中的一些道，有不足之處或不夠全面的也希望大家多多補充；後續還會繼續分享我認為很重要的 HTSM模型，以及我認為非常重要的等價類劃分，場景測試、基因測試、探索式測試的一些好的方法等。總之，我想把我的一些有價值的經驗都分享出來以共享。