作者 |  張海云

對于大規模的產品來說，即使采用敏捷的方式來做，也依然避免不了多個服務集成以及和其他產品集成的過程，這一篇就和大家一起討論一下在大規模敏捷測試中如何進行SIT（System Integration Testing）集成測試。

一、大規模敏捷測試的分層策略

隨著分布式架構的流行，大規模的產品開發更加靈活和便捷，但這同時也為質量保障活動帶來了挑戰。為了更高效地進行測試，我們往往采用測試分層的策略。從關注每個服務的測試，到關注某個模塊的多個服務集成，再包括一個產品內不同模塊間的基礎測試，最后再到整個端到端多個產品間的集成測試。如圖：

1.迭代內測試

迭代內測試主要關注兩個方面的測試：

• 服務的功能測試
• 模塊內的服務集成

迭代內的測試如何進行，可以參考上一篇博客：大規模敏捷測試怎么做？——基礎篇

2.SIT集成測試

SIT系統集成測試分成了兩個階段：

• 第一個階段是SIT產品內的集成測試，又叫SIT產品自測，主要關注產品內不同服務間的集成，不考慮第三方產品的影響，此時是產品的初步集成，使用mock server屏蔽掉第三方系統的依賴并保證測試充分很重要。
• 第二個階段是SIT產品間的集成測試，又叫SIT拉通測試，主要關注不同產品間的接口集成。端到端的場景可能會涉及多個產品，多個組織，以及龐雜的參與人員都會增加拉通測試的難度。所以如何更好地組織和實施集成測試是大規模敏捷測試成功的關鍵。

二、兩種集成測試的組織方式

大規模產品的集成測試一般有兩種組織方式。如圖:

1.虛擬的SIT測試團隊

(1) 組織方式

每個Scrum團隊有一個SIT接口人，作為整體SIT測試和各個團隊之間的橋梁。SIT Lead負責SIT整體的組織，協調，策略，規范，機制等。各個Scrum團隊負責SIT的測試執行。

(2) 優勢

這種組織方式相對靈活，SIT接口人可以統籌小組內SIT的任務與團隊內的迭代任務。一般來說SIT任務優先級更高。當SIT任務集中時，可以犧牲迭代內的任務來支持SIT。當SIT相對任務較少時，可以支持更多迭代內的任務。

同時這種組織方式信息更加透明，知識能夠及時共享。接口人可以將SIT發現的問題更快地分享給團隊內，團隊內可以針對問題及時調整迭代。同時迭代內開發新功能的信息可以及時共享為后續SIT測試打下基礎。

(3) 缺點

SIT任務和迭代內容易發生資源沖突，迭代內需要留一定buffer給SIT。人員切換頻繁會導致SIT測試效率低。

2.獨立的SIT測試團隊

(1) 組織方式

獨立的SIT集成測試團隊，團隊成員專門負責系統集成測試執行，與Scrum團隊是弱連接。SIT Lead負責SIT整體的組織，協調，策略，規范，機制等，并負責SIT團隊成員的培養以及與各個Scrum團隊之間的協作和知識傳遞。

(2) 優勢

這種組織方式執行力強，SIT團隊專門負責集成測試，可以快速沉淀集成測試經驗，資源專項專用，工作效率更高。同時還可以隔離對迭代內的影響，迭代內的測試比較容易計劃和控制。

(3) 缺點

這種組織方式協作成本很高。SIT團隊和迭代內團隊是兩個獨立的組織，容易形成筒倉效應。SIT團隊成員需要和每個團隊對接學習業務及架構的知識，并高效及時地與Scrum團隊溝通發現的問題，導致溝通成本增加。而且資源獨占，不夠靈活，對于人員的要求也很高。SIT團隊的成員需要在短時間內對整體的業務理解透徹，不斷地學習新功能，才能更有效的發現集成問題。

(4) 實際項目中的選擇

在實際項目中，根據實際情況可以采用兩種不同的模式來進行SIT測試。對于團隊協作熟練且有足夠帶寬處理臨時任務的團隊，可以采用虛擬SIT測試團隊的方式。這種方式不會對既有的組織結構造成很大的破壞，也不會增加過多的溝通成本和知識傳遞成本。

而對于集成問題影響高，產品尚在初期，對迭代內質量不夠有信心的組織，可以先采用獨立測試團隊來負責SIT測試和問題修復的團隊。這種方式可以屏蔽對迭代內的影響，降低迭代內的管理成本。獨立的SIT團隊成員也應該參加其負責模塊Scrum團隊的關鍵活動，了解迭代內的進度，同步SIT測試情況。在有帶寬的情況下，也隨時支持迭代內的測試工作。

無論哪種方式，都要有統一的原則，測試策略，問題響應機制和測試管理規范，才能有效地協調一致，共同完成集成測試。

三、SIT集成測試節奏

在大規模項目中，集成測試的節奏取決于項目的迭代節奏和產品的復雜度。對于較為成熟的產品，建議在每個迭代周期或每個功能發布前進行集成測試。然而，對于從無到有（0-1）的大規模數字化轉型項目，由于業務尚不成熟，頻繁集成可能較為困難。

因此，可以采用滾動式逐步加速的方式進行集成，該方式采用前松后緊的策略。雖然頻繁集成有利于質量保障，但考慮到產品復雜性和初始階段等多種因素，將集成分為四個階段會更加合適。

• 階段一：MVP集成。第一次集成測試基于項目的MVP，即核心功能進行，經過初期調研、產品設計、架構設計和多次迭代開發，產品核心雛形已基本完成。除了輕量級集成，第一次正式的系統集成測試是在完成最高優先級P0級別需求（MVP）后進行的。
• 階段二：大需求集成。第二次集成測試在完成次優先級P1級別需求后進行。由于P1中仍存在一些難以拆分的大需求，因此需要等需求功能完整后再進行集成測試。
• 階段三：按迭代集成。后續需求相對較小，可以更容易拆分，因此可以按照每個迭代的頻率進行集成測試。
• 階段四：按需集成。在集成測試過程中，可能會陸續發現一些新的小需求。為了及時進行集成測試和測試拉通，可以按需進行集成。

如圖： 

由于業務的復雜性，一個端到端的場景往往涉及到多個模塊，甚至多個產品線，SIT的自測和拉通測試，以及UAT驗收都需要并行滾動進行，每次迭代內工作完成后都要經歷SIT自測，SIT拉通，UAT產品驗收，UAT拉通驗收四個步驟。

經常會遇到第一階段的拉通還沒有完成，就要進行第二階段的SIT自測的情況，所以需要規劃好不同環境的升級計劃，拉出不同的分支，平衡資源等，只有這樣充足的準備才能更高的保障項目的質量。

逐步加速的集成測試節奏能夠幫助我們在前期做好準備，帶領團隊熟悉集成的工作流程，培養團隊對集成測試的認知，形成良好的工作習慣，這樣才能在后續多個并行工作的復雜環境中保持快速集成的節奏。

四、SIT集成測試規劃

集成測試一般可以分為三步走，測試計劃與準備，測試執行與監控，測試收尾與總結。每個步驟都有相應的實施活動。

所有的集成中，初次的集成測試最為重要，有三個主要目標：

• PO（Product Owner）完成對于迭代內工作的驗收：他們會參與集成測試，并集中在場景的測試上。
• 完成各模塊間的集成測試：驗證各模塊之間的接口是否工作正常，滿足需求。QA需要關注除了PO負責測試場景外的邊界和異常場景的測試。
• 培養團隊習慣：還有一個更為重要的目標是培養團隊習慣，讓所有相關的團隊成員能夠熟悉集成測試概念，目標，原則，策略，流程規范等，并不斷地持續改進，為后續的快節奏集成打下堅實的基礎。

第一次集成一切都是從0開始，由于每個人對具體的流程、規范、環境、工具，以及人員意識和職責劃分等方面都帶有自己以前的認知。為了達到統一認識和目標，SIT測試啟動會是一個非常必要的環節。

五、集成測試用例的設計

測試用例的設計與編寫是集成測試成功的關鍵，它決定了測試的方向和深入程度。而對于SIT自測和SIT拉通測試，顯然測試用例的設計是不同的。SIT自測更注重本產品內的功能，而SIT拉通測試更注重端到端的場景銜接。

1.SIT自測的用例編寫

SIT自測有兩個主要目標，一個是為PO驗收迭代內實現的功能，一個是驗證模塊和模塊間的接口集成。所以SIT自測階段的測試用例也分為兩個部分：

• 一是由系統的終端用戶從用戶視角進行編寫，由QA和PO審核修改完成的，這樣編寫出來的用例場景更能貼近實際的業務，同時在編寫用例的過程中可以讓用戶更加了解系統邏輯，是一個交流對齊的過程。
• 二是QA基于接口進行一些邊界及異常場景的測試。

2.SIT拉通的用例編寫

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

六、分支策略及SIT問題修復機制

一般推薦采用主干開發的策略來管理代碼，這更符合我們敏捷中盡早持續集成的理念。但是如果集成的戰線拉得比較長，集成期間需要保持一定的代碼穩定性，那么集成中發現問題的修復和新功能的開發之間就會產生沖突，這時候就不得不考慮更好的分支策略。

滾動式集成策略使得同時可能最多會有三條線并行。也就是我們除了主干之外，需要有兩個分支。一個分支做SIT拉通集成，另一個分支做SIT自測，主干進行迭代內開發。測試過程中在哪里發現問題，就哪里修復，驗證通過后再統一Cherry Pick到其他分支。

如圖: 

(1) 分支策略的優勢

要說這種分支策略的優勢，其實就是滿足了大規模敏捷測試中滾動式并行集成的復雜需求。這樣使得我們可以階段性的盡早地進行集成活動，盡早發現問題，一定程度的測試左移。否則是無法進行這種復雜場景下的集成測試的。然而這種方式也是有成本的。

(2) 分支策略的成本和風險

這種方式的成本是顯而易見的，開發同學必須一個問題進行多個分支的代碼修改或者merge動作，測試同學必須在多個環境上進行驗證。這無疑是帶來了很大的工作量。風險也同樣明顯，如果開發同學忘記merge到主干或者其他分支，這個問題會被遺漏，在將來再次出現，帶來質量風險。

七、集成測試中接口變更之殤

SIT自測時關注的是產品內不同模塊間的接口，一個產品內的團隊聯調機會多，所以接口問題沒有那么突出。但是產品之間都是開發了很多功能后才開始初步進行集成測試的，開發過程中都是各自使用mock的方式屏蔽第三方依賴的，這時候就會導致很多接口變更問題。

如果沒有合適的接口變更處理機制，接口變更會無窮無盡地撲面而來。為了控制變更膨脹，接口變更的流程和機制就呼之欲出。

接口變更機制

在開發過程中涉及到和第三方系統交互的接口，在定義清晰后需要留存接口文檔和郵件記錄。這樣在SIT拉通測試的過程中發現問題后就有跡可循，能夠更合理的定義接口變更的合理性。多個產品集成測試需要站在整個產品成功的角度考慮問題，如果集成測試中出現阻塞問題，需要立刻處理，否則會影響整個集成的進度。所以又把問題分為兩種類型：

(1) 阻塞場景：先響應，再更新記錄。

由于拉通測試的特殊性，當存在阻塞場景拉通的問題出現時，不管該問題最終被定義為缺陷還是需求變更，都需要第一優先級進行修復。為了處理這樣的情況，即使是新需求，或者無法達成一致，團隊也會立刻響應處理，隨后再更新相應記錄。

(2) 普通場景：按照一般流程處理。

如果是普通場景，就按照先記錄，判定優先級，再根據迭代安排處理。 

大規模的E2E拉通測試很像一場戰爭，需要整個團隊齊心協力，提前做好規劃并快速推動決策調整，任何一環節出現問題都會導致整個阻塞，耽誤的就是幾百號人的時間和精力。

八、QA測試人員在集成測試中職責的轉變

QA在迭代內主要是職責是進行故事卡的測試，有時負責一些Showcase的準備和演示工作。但是在SIT測試中，QA的作用和職責發生了很大的變化。由于參與SIT測試的人員眾多，尤其在后期拉通測試中，需要和其他產品團隊共同合作完成測試。QA的職責從單一的測試執行轉變為一專多能。

首先轉變為一個測試Coach，賦能其他角色，尤其PO來進行測試；其次轉變為一個Agent，問題解決的引擎。對每個問題進行分析，澄清，分發，驅動PO，開發，BA共同協作，快速解決問題；最后還是一個價值守護者，不僅守護著產品的質量，更要守護業務的價值，對拉通中產生的不斷變化業務方案，接口定義，能夠從用戶角度，從ROI角度，據理力爭，并基于問題不斷調整測試策略。

1.作為測試Coach對PO賦能

PO第一次參與到測試中來，雖然對場景熟悉，但是對測試理解尚淺。為了幫助PO盡快掌握測試能力，QA需要轉變身份成為一個測試Coach，為PO進行賦能。首先用業務的語言講解系統實現的功能，方便其理解以及要關注的測試點。

其次用技術的手段幫助他們能夠快速上手，將系統需要的配置以及跳過依賴所需要的mock使用方法文檔化，可以及時查閱。

最后作為PO測試的支持者，幫助他們定位問題，確定缺陷嚴重級別，建立與團隊的溝通，將問題盡量描述清晰等等。在后續的各種集成測試， UAT測試中，經過賦能的PO都可以發揮重要的作用。

2.作為團隊引擎驅動問題解決

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

QA在集成測試中是最關鍵的角色，就像一個引擎，驅動整個團隊來快速解決問題，使得集成測試能夠順利進行。

QA同學也是迭代內交付團隊的一個屏障，將非代碼問題都屏蔽在團隊之外，減輕團隊的工作量，有效地保障迭代內的交付。

3.作為價值守護者

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