（“馬蜂窩技術”公衆號原創內容，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 開發多個坑位，歡迎有意向的小夥伴來勾搭，簡歷請發送至郵箱：[email protected]
本文作者：董敏，大交通研發團隊測試工程師。
