如何開展大規模整合測試

在《質量保障體系從 1 到 N 的思考》中，落地實踐了迭代內的質量保障體系構建，但是在日常的工作中，個人還涉及到了端到端的大規模整合測試，這個活動主要是在專案的前兩個版本需要集中做，那麼如何開展這類測試活動呢？筆者結合自己在多個大型專案中的實踐，做了整理。

1. 什麼是端到端整合測試

端到端整合測試，又叫 SIT 拉通測試，主要關注不同產品間的介面整合。端到端的場景可能會涉及多個產品，多個組織，以及龐雜的參與人員都會增加拉通測試的難度。就像搭樂高，迭代測試，就像各個小零件間的配合，更多的是關注上下游依賴的系統，而端到端整合測試，就是把所有零件按照圖紙（場景），組合成一個完整的玩具（實際上完整的業務流程）的過程。

整合測試有如下特點：

規模大：端到端整合測試涉及業務的全鏈路流程，需要配合的系統一般比較多，規模大；

系統多：實際的業務場景相對複雜，需要多系統配合，不論哪個環節出問題，對業務而言，就是失敗的；

涉及人員多：由於前面兩個原因，涉及到人員就會很多，需要做好溝通和協調，對組織的軟技能要求高；

關注資料的流向而不是單系統的異常：到了端到端整合測試，測試人員需要關注的是完整的業務場景是否能走通，異常業務流是否能回退或者有解決方案，而不需要過於關注某個節點系統內部的異常；

2. 團隊組織形態

基於端到端整合測試的基本要求，又需要經常開展類似的活動（在專案上線前期，如果需要多系統協同上線，就需要做一次完整的拉通測試）。為了滿足這種活動需要，我們選擇瞭如下圖所示的組織架構：

端到端整合測試的人員，需要從各系統團隊中抽取出來（角色包含測試和產品，必須有產品加入），這些人即參與日常的迭代測試，瞭解當前迭代系統的業務需求，同時在開展端到端測試的時候，抽出來負責端到端測試，由各團隊負責人統籌安排，一般來說 SIT 任務優先順序更高。當 SIT 任務集中時，可以犧牲迭代內的任務來支援 SIT。當 SIT 相對任務較少時，可以支援更多迭代內的任務。

同時這種組織方式資訊更加透明，知識能夠及時共享。介面人可以將 SIT 發現的問題更快地分享給團隊內，團隊內可以針對問題及時調整迭代。同時迭代內開發新功能的資訊可以及時共享為後續 SIT 測試打下基礎。但缺點也比較明顯，端到端整合測試任務和迭代內容易發生資源衝突，迭代內需要留一定 buffer 給端到端整合測試。

3. 開展端到端整合測試的前期準備

因為涉及人員多，規模大，為了更好地開展端到端整合測試，需要做好充分的事先準備，才能更好地開展活動，應對變化。所以，在開展端到端測試之前，需要梳理好准入條件，以便評估風險。一般會包含如下准入條件：

迭代需求研發完成度：由於平時大家關注的點都在各自的迭代中，對於哪些需求是否研發完成，未完成的 Story 對整體的業務影響是什麼並不清晰，所以需要在端到端整合測試前，明確迭代任務是否都已開發完成，如果有未完成的，需要在這裡明確出來，讓團隊知道並評估影響。

迭代測試報告：各子專案需要出具各自迭代的測試報告，以便團隊整體評估風險；

端到端測試人員名單：方便後續做溝通和協調，也有利於整體產能和人力資源的評估。

端到端測試用例：在開展端到端測試之前，需要完成對應端到端測試用例的評審（具體的形式下文再闡述）。

環境對齊：由於涉及的系統多，各系統又有各自的環境，所以需要在開展端到端整合測試前，確認各系統對接的環境是正確的（這裡可以另開一個文件來記錄，明確各系統對應的 IP、埠、中介軟體地址等，也方便後續排查問題能夠快速對應的伺服器）

基礎資料準備：根據業務場景和測試用例，需要各團隊準備好對應的基礎測試資料，避免在測試過程中因為缺少基礎資料而導致測試阻塞（根據經驗，這裡是最容易出問題的地方，需要認真對待）

4. 測試用例輸出與評審

首先，需要和產品、業務一起確認端到端整合測試的業務場景。與迭代測試用例不同，端到端測試的用例更關注從上游到下游整個貫通的場景。測試用例如何設計也是非常有挑戰的事情。每個產品都在 SIT 自測時設計了自己的測試用例，如果用笛卡爾集拼接，數量將指數級增長。所以需要按照端到端的業務場景編寫用例，以關鍵性的核心業務展開輻射到各個產品上，保證業務場景測試充分。

根據上圖的場景路線圖，輸出測試用例。對於測試用例的組織形式，也與迭代測試不同，因為閱讀和執行測試人員的物件不同（在迭代測試中，測試用例的閱讀物件是測試人員，所以不需要很細緻，甚至只需要功能點就可以了。但是在端到端測試中，測試用例的閱讀物件是產品或者業務，還有可能是一線業務人員，所以需要把測試用例寫得更明確些）。我們採用的測試用例模板如下圖所示：

5. 端到端測試過程實踐

在端到端測試開展的期間，需要關注以下內容：

人員集中辦公：由於這個活動涉及的人員較多，所以需要一個集中辦公，降低溝通成員，讓相關人員更專注地開展測試活動，也更有利於問題的推動解決。

明確每日的執行目標：沒有目標就無法跟進度。一般開展端到端測試的時間會比較長（多輪次，多場景，至少 1 星期的時間），所以需要明確每天的測試進展，大家往同一個目標去努力。

視覺化：在這麼多人場景下，如果無法做到視覺化，那問題的跟進就會非常麻煩，所以需要一個大看板來隨時反饋進度和阻塞點，我們利用 Excel 的強大函式功能，做了如下實時看板：

同時，對測試過程中發現的問題進行實時的跟蹤記錄，確保發現的問題都被記錄在冊，以便後期做覆盤時，提供有效的資料支撐。

在整個端到端整合測試的執行過程中，需要測試負責人實時推進和解決隨時發現的問題，除了程式碼的問題，更多時候會有介面的問題，業務方案的問題。在與業務，PO，BA 以及其他產品的人員討論中，測試人員作為資訊交匯點，需要具備業務和技術的結合智慧，提出自己的認知，從使用者的使用角度，從技術的成本角度，統一考慮，以最優的成本守護價值。同時要根據迭代內的測試反饋，不斷地調整測試策略，制定重點的測試場景，對迭代內測試不充分，對於端到商發現問題較多和風險較高的功能進行迴歸測試

6. 測試問題覆盤

因為整體的測試執行過程場景複雜，人員多，遇到的問題也會比較多，所以需要在每日完成測試執行任務後，做及時的覆盤，發現並解決過程問題，並根據當天實際的執行情況，對第二天的任務做出針對性的調整，提高測試執行效率。

具體問題具體分析，這裡就不放相關的案例了。

7. 測試人員的思維轉換

在整體的端到端測試過程中，不管是總體的負責人，還是各業務系統的測試人員，都面臨著與迭代測試完全不同角色。在迭代測試中，測試人員更關注的是區域性功能的業務驗證和風險識別，但是在端到端測試中，測試人員需要做出至少以下幾點的思維轉換：

a. 作為團隊引擎驅動問題的解決：

當 PO 或者其他產品人員在整合測試中發現問題時，測試人員首先要進行一個基礎判斷，是否是配置問題，資料問題，環境問題。如果確實是缺陷，則在缺陷上補充自己的分析和判斷，流轉給開發同學及時修復。如果是新的需求或者業務方案問題，則引入 BA 一起討論澄清。

測試人員在整合測試中是最關鍵的角色，就像一個引擎，驅動整個團隊來快速解決問題，使得整合測試能夠順利進行。測試人員也是迭代內交付團隊的一個屏障，將非程式碼問題都遮蔽在團隊之外，減輕團隊的工作量，有效地保障迭代內的交付。

b. 作為價值守護者

測試人員是質量的守護者，同時也是價值的守護者。在整合測試中，除了程式碼的問題，更多時候會有介面的問題，業務方案的問題。在與業務，PO，BA 以及其他產品的人員討論中，測試人員作為資訊交匯點，具備業務和技術的結合智慧，提出自己的認知，從使用者的使用角度，從技術的成本角度，統一考慮，以最優的成本守護價值。同時要根據迭代內的測試反饋，不斷地調整測試策略，制定重點的測試場景，對迭代內測試不充分，SIT 發現問題較多和風險較高的功能進行迴歸測試。

8. 挑戰點

在主持過多場次不同業務的端到端場景後，個人感覺對於這類測試活動，對負責人最大的挑戰不在於對業務的熟悉程度（當然需要對整體的業務有相對完整的瞭解，也做不到對各系統都相當瞭解），而在於出現問題時，如何高效地溝通並推動問題的解決。所以在開展端到端測試之前，負責人需要對每個系統的對接人要有相當的熟悉，出現問題時，需要快速找到對應的人員，組織小團隊討論解決方案，並推動問題的解決，這就需要有非常好的溝通和協調能力，並要有高度的責任心，才能把這件事做好。

9. 小結

文章篇幅較長，基本上完整的介紹了大規模整合測試的實踐，腦圖整理如下：

注：在編寫本文的過程中，關於理論的部分，參考了張海雲老師在 TW 公眾號上發表的文章：大規模敏捷測試怎麼做（整合篇）。