（“馬蜂窩技術”公眾號原創內容，ID: mfwtech）

一個專案從需求確定到最後上線，通常來說流程是這樣的：

「測試」作為一個專案質量保證角色，在上面的整個流程中均有參與。而用例設計、專案測試環節更像測試的主場，PRD 的評審測試人員也會發表很多自己的觀點，對專案的技術評審雖然測試人員也有參與，但也不如前兩個環節的參與程度深。 

其實，一個優秀的測試人員應該深入到專案的每一個環節中去發現問題，提出自己的觀點，保證專案質量。那麼要真正深入到專案實現中，測試應該怎麼做呢？

一、Review 介面定義結構

介面定義文件在測試過程是測試人員接觸比較多的設計文件，尤其是與最外層面向使用者的介面設計相關的部分。在參加介面文件評審、編寫介面用例這些場景下，測試人員都會仔細閱讀介面設計文件。

通過介面文件，可以幫助測試人員清晰瞭解到前端與後斷是怎麼互動的，每個頁面哪些操作與後端存在互動，不同的介面之間是否存在關聯，清楚這些可以幫助測試人員在測試過程中對出現的問題進行精準判斷，確定導致問題出現的範圍。

在閱讀介面文件可以關注以下幾個方面：

• 介面中定義欄位是否考慮了擴充套件性；
• 欄位是否必須有明確的說明；如果是程式碼實現需要清晰定義 NotNull/NotBlank；
• 欄位含義是否存在歧義，欄位的含義要有明確的解釋；
• 介面是否覆蓋到了所有業務場景；
• 返回值結構、內容是否正確；通常返回值都有固定格式規範，返回值結構要規範統一，並且介面請求失敗有明確的失敗原因；
• 欄位型別是否正確；
• 入參風格統一；比如日期格式如果是 yyyy-mm-dd 格式，每個介面最好都統一。

除了上面提到這些，在介面文件還要關注資料庫表結構，確保表結構能滿足介面需求；介面返回資料量要控制在一個合理的範圍，返回資料量太大會有傳輸壓力從而產生效能問題；介面之間要注意低耦

二、關注架構設計方案

對於測試工程師來說學習專案架構或者說系統架構是一個不小挑戰，因為基本上所有的架構知識、開發框架都是基於開發人員進行設計的，而這些內容對於開發人員也是一個不小的挑戰。

那測試人員為什麼還要去了解學習？有測試同行曾經開玩笑說「瞭解專案的架構設計是為了在開會的時候聽懂開發在說什麼」。雖然是一句玩笑話，但也說明測試人員需要了解這方面的內容重要性。瞭解專案的架構設計可以在以下幾方幫助到測試人員：

1. 培養測試人員的架構思維

因為測試環節不應該僅僅發生在提測後，在前期專案設計階段也同樣需要進行測試，只有通過對業務程式碼、架構設計、用到的技術有了解，才能夠在設計階段發現缺陷。

2. 幫助測試更全面、更有針對性地進行

比如效能測試，如果不清楚整個系統的架構，沒辦法對壓測結果進行分析，甚至設計的壓測方案可能都是存在問題的。還有就是在壓測時候尤其網際網路的系統架構壓測時經常需要「預熱」，需要預熱的原因我們清楚嗎？因為服務端會對資料進行緩衝。

比如在專案架構遷移時如何做到不漏測，拿火車票電子票從 PHP 遷移到 Java 的乘車人模組為例，遷移前和遷移後訪問乘車人模組流程如下圖所示。

1）遷移前電子票和搶票訪問乘車人模組方式：

2）遷移後如下（黃色部分是這次遷移改動部分）

從流程圖中可以看出，乘車人模組是搶票和電子票兩個業務的公共模組，而此次遷移只有電子票的 App 呼叫 Java 介面訪問乘車人，其他還是呼叫舊介面，所以乘車人模組重構後要保證電子票和搶票的兩個端（App 和小程式）不管從舊介面還是從新介面訪問功能都正常，就要弄清楚電子票和搶票這個兩個業務哪部分做了遷移，哪部分沒有遷移，技術方案設計是怎麼樣的，這樣才能保證不漏測。

那測試人員應該怎麼了解一個專案的架構呢？測試人員學習架構或者說了解架構設計應該有測試的獨特視角，通常能做到清楚基本原理、瞭解被測系統部署架構、用到了哪些技術，從測試的角度呼叫到哪些介面就夠了，當然如果能學習的深入更好。

首先，不管是已經上線的專案還是在正在進行中的專案，都有系統架構圖，先從系統架構圖入手，瞭解服務都有哪些，這些服務分佈在哪一層，比如有面向使用者接入層，中間處理不同業務的業務層服務，還有從外部服務獲取資料外部接入層服務，還有資料儲存、緩衝，不同層之間進行互動的協議、中介軟體都可以從架構圖中看到，能幫助我們快速的對整個專案建立一個框架。

其次，檢視服務之間的業務互動關係，明確業務資料流轉。通過閱讀流程圖、泳道圖、時序圖都能幫助測試人員理清楚各個微服務之間的互動關係。下圖是根據我自己對馬蜂窩大交通搶票業務的理解，梳理的業務架構圖：

另外，清楚業務狀態機也很重要。熟悉狀態機能幫助測試人員更加清晰的理解業務，需求文件是對業務功能的概括，狀態機是對業務功能不同情況的分解。

最後，瞭解一些架構設計知識，比如為什麼要用訊息佇列，好處是什麼，在專案中不斷積累架構相關的知識，架構相關的知識不斷的豐滿在進行專案設計方案評審時就可從測試角度提出問題，發現問題，對專案質量起到幫助，因為越早發現問題，損失越小。

三、關注資料庫設計

資料庫的重要性不言而喻，任何一條業務線都離不開。資料庫表設計是否合理、是否考慮了業務擴充套件、是否考慮了讀寫分離等，都是需要測試人員在參加資料庫設計評審，甚至在資料庫設計時考慮的。下面分享一些在 Review 資料庫設計表時的參考檢查項：

1）不同表，相同含義的欄位命名是否統一；

2）欄位型別是否符合要求，比如資料量大的欄位型別設計成 int，應該用 bigint 更合理；

3）欄位長度設計是否合理；舉例，曾經測試過一個功能，每 10 分鐘查詢 Redis 中 key 的值存到 MySQL 中，統計值和查詢 key 分兩列儲存，欄位長度設計是 60，實際情況是 key 的長度遠遠大於 60，對 key 進行截斷儲存，導致查詢不到不結果。

4）欄位是否為空；介面設計欄位可以空，但是表結構設計欄位 NOT NULL，與介面資料結構設計不一致，提交的時候顯然回報錯；

5）是否存在冗餘欄位；當然有些情況為了效率會允許冗餘欄位的存在；

6）是否需要分庫分表。

除了以上提到的點，在資料庫設計方面需要 Review 的內容還有很多，比如是否需要考慮讀寫分離、表之間的關聯是否合理等等。建議大家去了解一些與資料庫設計規則相關的知識，來幫助我們在 Review 或者參與資料庫設計時發現更多問題。

四、閱讀開發的程式碼

說到 Code Review 大家並不陌生，上線前分支合併 Master 要進行 Code Review，開發人員相互交叉進行 Review，研發同學常會聽到這樣的對話「飛哥幫我 review 下程式碼」。

Code Review 對於開發人員是很重要的 Check 步驟，對於測試人員也是一樣，一個發現缺陷、理解專案的重要手段。閱讀程式碼可以從以下幾個方面幫助到我們：

1. 檢查測試用例的遺漏點

我們都知道測試做不到窮盡測試，不管是做單元測試還是功能用例都不容易做到全部覆蓋，尤其是有多個條件的情況下越不容易做到，Code Review 可以幫助我們再次檢查是否測試中遺漏功能點。

2. 幫助測試人員更加熟悉系統，深入理解業務

黑盒測試的被測物件是已經成型的系統，不能清楚看到業務功能是在系統架構哪部分上實現的。比如現在流行的微服務架構，一個業務功能可能是多個微服務相互協作完成，通過閱讀程式碼，能夠清晰的知道業務實現的入口在哪裡，呼叫了哪些服務，一個業務場景從開始到結束經過哪些環節都可以清楚地看到。

3. 發現增量功能 Bug 和設計缺陷

業務線的功能是不斷迭代的，因提升體驗而進行的功能優化和增加新功能都在迭代的範圍內。測試人員面對是整個業務線，每次的迭代需要準確判斷本次迭代影響的範圍來確定測試範圍。通過業務程式碼清楚具體的實現細節、實現方式，在業務功能迭代時，測試人員能準確的判斷出程式碼增量是哪部分，關聯受影響的程式碼是哪部分，確定測試範圍，做到精準的測試，在設計評審時反饋可會產生影響的功能給開發人員，與開發形成良好的互動。

說了閱讀程式碼的好處，測試人員如何去 Review 開發人員程式碼？從哪幾個方面入手？

1. 帶著任務看程式碼

帶著任務去看程式碼就是清楚本次迭代有哪些功能，最好在 Review 之前在熟悉一下測試用例，帶著功能實現是否存在問題心態去看，關注業務邏輯實現、介面引數定義部分，一些配置的 config 實現可以不用關注，避免陷入到與功能無關的細節中。

2. 關注程式碼條件判斷

實現業務邏輯各類條件的判斷是必不可少的，也是容易出問題的地方，條件判斷錯誤功能表現可能就是「失之毫釐，差之千里」。條件的判斷需要結合業務實際情況，如：

（1）檢查 if 語句中每個條件表示式是否正確。比如：變數取值 isNotBlank 和 isNotEmpty 就會導致不同結果，涉及與、或、非的表示式尤其要注意；

（2）檢查條件表示式是否涵蓋所有關聯的變數。舉個例子：一個訂單狀態流轉和 a、b 兩個變數的取值有關係，其中 b 變數在某些特情況下影響訂單狀態。如果在條件中只考慮對 a 的判斷而忽略 b，就導致功能不完整。

在進行火車票的改簽測試有這樣一個 bug，同一個乘客成功購票後——>將票改簽到其他日期——>再退票，然後這個乘客在買同樣日期相同車次的票提示行程衝突，預期結果是：使用者已經改簽到其他日期並且退票，可以再次購買。下圖是一個簡化的流程圖，判斷是否行程衝突（黃色部分是導致bug的原因）：

從流程圖可以看出如果乘客有已出票的訂單需要先判斷是否出行或退票，如果否的話說明還是在出票狀態，那需要繼續判斷是否進行了改簽，如果已經改簽允許使用者繼續創單，導致 Bug 的原因就是少判斷了是否改簽這個條件。

（3）檢查對條件不同值給出的處理結果是否正確。舉一個簡單的例子：學生成績不同區間對應 a、b、c 三個不同檔有如下偽碼：

If (s>=90):

Print「a」

Elseif (s>=80 && s<90):

Print「b」

Else:

Print「c」

上面的這段程式碼沒有考慮s取異常值的情況，學生成績取值是大於等於0的，還有就是成績大於100時，在c檔是否合理，也需要考慮實際需求。

3. 關注迴圈語句

所有的迴圈是否都有結束條件即所有的迴圈都能正常的結束；進入迴圈的入口條件是否正確即能進入到迴圈中；迴圈的條件是否存在越界的錯誤等。

4. 檢查程式碼中介面定義與介面文件的定義是否一致

5. 針對增量程式碼進行 Review

通常由於時間有限，沒有足夠的時間閱讀所有的程式碼，可以選擇僅對對增量程式碼進行 Review，檢查是否存在功能遺漏、改動程式碼對是否原有功能產生影響。

6. Review 後知識沉底

前面的幾點都是再說如何去做，在閱讀程式碼的過程中進行知識沉澱也很重要。在 Review 完成後，可以對發現的問題進行整理歸類，在後面的測試過程中可以做為測試用例進行補充。Review 完成可以嘗試畫服務的流程圖，專案架構圖，幫助的自己對專案理解更深入。

7. 測試人員進行程式碼的反講

閱讀完程式碼後，測試人員反講對程式碼的理解，可以邀請開發人員一起參加。

當然，我們在看到程式碼會碰到很多問題，可以向開發同學請教，瞭解程式碼結構，比如哪部分是業務實現程式碼，哪些是和資料庫互動設計、哪些配置檔案、哪些是介面定義檔案，這些都可以幫助我們快速瞭解專案程式碼結構。

五、熟悉專案配置檔案

為了靈活應對一些由於突發狀況或頻繁上線對業務帶來的影響，在專案的實現過程中研發人員會把一些功能通過配置檔案的方式去實現，比如流控配置、對不同業務場景的需求配置、為進行灰度測試的配置等，除此之外還有靜態的環境配置。在配置檔案內容的 Review 中應該關注的重點包括：

• 不同環境的配置檔案不同，以防止將測試環境的配置同步到生產環境產生損失
• 功能配置開關，比如限流、降級服務開關、外部依賴如供應商的上下線
• 業務引數配置，業務功能的一些引數需要隨時靈活配置，比如一些活動規則、臨時性的通知資訊
• 除了業務相關配置還有中介軟體的配置也需要關注，比如 tomcat、dubbo、mq 的引數設定很重要，對服務效能的影響非常明顯。

測試人員深入到一個專案中，需要了解熟悉的遠遠不止我在上面提到這幾個方面，還有很多，比如緩衝設計、緩衝失效時間設定，儲存方式等，服務日誌記錄，隨著對業務、系統架構的熟悉，這些都需要去了解，從而在測試中幫助到我們。

總結

上面是我對測試人員為什麼要深入到一個專案實現中的，以及如何去深入的一些看法。測試作為專案最後一個環節，新的測試技術、手段、理念不斷出現，但是保證專案質量的目標沒有變。而深入到專案中，瞭解專案程式碼、瞭解專案設計對於一個優秀測試人員是必須具備的技能。當然，文中的內容也存在一些侷限，歡迎其他測試小夥伴一起交流。

最後，馬蜂窩大交通團隊也在持續招聘中，測試、前端、Java 開發多個坑位，歡迎有意向的小夥伴來勾搭，簡歷請傳送至郵箱：dongmin@mafengwo.com

本文作者：董敏，大交通研發團隊測試工程師。