測試人員爲何要深刻到項目實現中去?

（「馬蜂窩技術」公衆號原創內容，ID: mfwtech）

一個項目從需求肯定到最後上線，一般來講流程是這樣的：

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

其實，一個優秀的測試人員應該深刻到項目的每個環節中去發現問題，提出本身的觀點，保證項目質量。那麼要真正深刻到項目實現中，測試應該怎麼作呢？

1、Review 接口定義結構

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

經過接口文檔，能夠幫助測試人員清晰瞭解到前端與後斷是怎麼交互的，每一個頁面哪些操做與後端存在交互，不一樣的接口之間是否存在關聯，清楚這些能夠幫助測試人員在測試過程當中對出現的問題進行精準判斷，肯定致使問題出現的範圍。

在閱讀接口文檔能夠關注如下幾個方面：

• 接口中定義字段是否考慮了擴展性；

• 字段是否必須有明確的說明；若是是代碼實現須要清晰定義 NotNull/NotBlank；

• 字段含義是否存在歧義，字段的含義要有明確的解釋；

• 接口是否覆蓋到了全部業務場景；

• 返回值結構、內容是否正確；一般返回值都有固定格式規範，返回值結構要規範統一，而且接口請求失敗有明確的失敗緣由；

• 字段類型是否正確；

• 入參風格統一；好比日期格式若是是 yyyy-mm-dd 格式，每一個接口最好都統一。

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

2、關注架構設計方案

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

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

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

由於測試環節不該該僅僅發生在提測後，在前期項目設計階段也一樣須要進行測試，只有經過對業務代碼、架構設計、用到的技術有了解，纔可以在設計階段發現缺陷。

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

好比性能測試，若是不清楚整個系統的架構，沒辦法對壓測結果進行分析，甚至設計的壓測方案可能都是存在問題的。還有就是在壓測時候尤爲互聯網的系統架構壓測時常常須要「預熱」，須要預熱的緣由咱們清楚嗎？由於服務端會對數據進行緩衝。

好比在項目架構遷移時如何作到不漏測，拿火車票電子票從 PHP 遷移到 Java 的乘車人模塊爲例，遷移前和遷移後訪問乘車人模塊流程以下圖所示。

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

2）遷移後以下（黃色部分是此次遷移改動部分）

從流程圖中能夠看出，乘車人模塊是搶票和電子票兩個業務的公共模塊，而這次遷移只有電子票的 App 調用 Java 接口訪問乘車人，其餘仍是調用舊接口，因此乘車人模塊重構後要保證電子票和搶票的兩個端（App 和小程序）無論從舊接口仍是重新接口訪問功能都正常，就要弄清楚電子票和搶票這個兩個業務哪部分作了遷移，哪部分沒有遷移，技術方案設計是怎麼樣的，這樣才能保證不漏測。

那測試人員應該怎麼了解一個項目的架構呢？測試人員學習架構或者說了解架構設計應該有測試的獨特視角，一般能作到清楚基本原理、瞭解被測系統部署架構、用到了哪些技術，從測試的角度調用到哪些接口就夠了，固然若是能學習的深刻更好。

首先，無論是已經上線的項目仍是在正在進行中的項目，都有系統架構圖，先從系統架構圖入手，瞭解服務都有哪些，這些服務分佈在哪一層，好比有面向用戶接入層，中間處理不一樣業務的業務層服務，還有從外部服務獲取數據外部接入層服務，還有數據存儲、緩衝，不一樣層之間進行交互的協議、中間件均可以從架構圖中看到，能幫助咱們快速的對整個項目創建一個框架。

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

另外，清楚業務狀態機也很重要。熟悉狀態機能幫助測試人員更加清晰的理解業務，需求文檔是對業務功能的歸納，狀態機是對業務功能不一樣狀況的分解。

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

3、關注數據庫設計

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

1）不一樣表，相同含義的字段命名是否統一；

2）字段類型是否符合要求，好比數據量大的字段類型設計成 int，應該用 bigint 更合理；

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

4）字段是否爲空；接口設計字段能夠空，可是表結構設計字段 NOT NULL，與接口數據結構設計不一致，提交的時候顯然回報錯；

5）是否存在冗餘字段；固然有些狀況爲了效率會容許冗餘字段的存在；

6）是否須要分庫分表。

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

4、閱讀開發的代碼

說到 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.測試人員進行代碼的反講

閱讀完代碼後，測試人員反講對代碼的理解，能夠邀請開發人員一塊兒參加。

固然，咱們在看到代碼會碰到不少問題，能夠向開發同窗請教，瞭解代碼結構，好比哪部分是業務實現代碼，哪些是和數據庫交互設計、哪些配置文件、哪些是接口定義文件，這些均可以幫助咱們快速瞭解項目代碼結構。

5、熟悉項目配置文件

爲了靈活應對一些因爲突發情況或頻繁上線對業務帶來的影響，在項目的實現過程當中研發人員會把一些功能經過配置文件的方式去實現，好比流控配置、對不一樣業務場景的需求配置、爲進行灰度測試的配置等，除此以外還有靜態的環境配置。在配置文件內容的 Review 中應該關注的重點包括：

• 不一樣環境的配置文件不一樣，以防止將測試環境的配置同步到生產環境產生損失

• 功能配置開關，好比限流、降級服務開關、外部依賴如供應商的上下線

• 業務參數配置，業務功能的一些參數須要隨時靈活配置，好比一些活動規則、臨時性的通知信息

• 除了業務相關配置還有中間件的配置也須要關注，好比 tomcat、dubbo、mq 的參數設置很重要，對服務性能的影響很是明顯。

測試人員深刻到一個項目中，須要瞭解熟悉的遠遠不止我在上面提到這幾個方面，還有不少，好比緩衝設計、緩衝失效時間設置，存儲方式等，服務日誌記錄，隨着對業務、系統架構的熟悉，這些都須要去了解，從而在測試中幫助到咱們。

總結

上面是我對測試人員爲何要深刻到一個項目實現中的，以及如何去深刻的一些見解。測試做爲項目最後一個環節，新的測試技術、手段、理念不斷出現，可是保證項目質量的目標沒有變。而深刻到項目中，瞭解項目代碼、瞭解項目設計對於一個優秀測試人員是必須具有的技能。固然，文中的內容也存在一些侷限，歡迎其餘測試小夥伴一塊兒交流。

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

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