一加Ace2 Pro官宣：普及16G內存 引領24G
一加官方今天繼續為本月發布的新機一加Ace2 Pro帶來預熱，公布了內存方面的信息。“淘汰 8GB ，12GB 起步，16GB 普及，24GB 引領，還有呢？#一加Ace2Pro#，2023 年 8 月，敬請期待。”同時
作者 | 張海云
對于大規模的產品來說，即使采用敏捷的方式來做，也依然避免不了多個服務集成以及和其他產品集成的過程，這一篇就和大家一起討論一下在大規模敏捷測試中如何進行SIT（System Integration Testing）集成測試。
隨著分布式架構的流行，大規模的產品開發更加靈活和便捷，但這同時也為質量保障活動帶來了挑戰。為了更高效地進行測試，我們往往采用測試分層的策略。從關注每個服務的測試，到關注某個模塊的多個服務集成，再包括一個產品內不同模塊間的基礎測試，最后再到整個端到端多個產品間的集成測試。如圖：
迭代內測試主要關注兩個方面的測試：
迭代內的測試如何進行，可以參考上一篇博客：大規模敏捷測試怎么做？——基礎篇
SIT系統集成測試分成了兩個階段：
大規模產品的集成測試一般有兩種組織方式。如圖:
(1) 組織方式
每個Scrum團隊有一個SIT接口人，作為整體SIT測試和各個團隊之間的橋梁。SIT Lead負責SIT整體的組織，協調，策略，規范，機制等。各個Scrum團隊負責SIT的測試執行。
(2) 優勢
這種組織方式相對靈活，SIT接口人可以統籌小組內SIT的任務與團隊內的迭代任務。一般來說SIT任務優先級更高。當SIT任務集中時，可以犧牲迭代內的任務來支持SIT。當SIT相對任務較少時，可以支持更多迭代內的任務。
同時這種組織方式信息更加透明，知識能夠及時共享。接口人可以將SIT發現的問題更快地分享給團隊內，團隊內可以針對問題及時調整迭代。同時迭代內開發新功能的信息可以及時共享為后續SIT測試打下基礎。
(3) 缺點
SIT任務和迭代內容易發生資源沖突，迭代內需要留一定buffer給SIT。人員切換頻繁會導致SIT測試效率低。
(1) 組織方式
獨立的SIT集成測試團隊，團隊成員專門負責系統集成測試執行，與Scrum團隊是弱連接。SIT Lead負責SIT整體的組織，協調，策略，規范，機制等，并負責SIT團隊成員的培養以及與各個Scrum團隊之間的協作和知識傳遞。
(2) 優勢
這種組織方式執行力強，SIT團隊專門負責集成測試，可以快速沉淀集成測試經驗，資源專項專用，工作效率更高。同時還可以隔離對迭代內的影響，迭代內的測試比較容易計劃和控制。
(3) 缺點
這種組織方式協作成本很高。SIT團隊和迭代內團隊是兩個獨立的組織，容易形成筒倉效應。SIT團隊成員需要和每個團隊對接學習業務及架構的知識，并高效及時地與Scrum團隊溝通發現的問題，導致溝通成本增加。而且資源獨占，不夠靈活，對于人員的要求也很高。SIT團隊的成員需要在短時間內對整體的業務理解透徹，不斷地學習新功能，才能更有效的發現集成問題。
(4) 實際項目中的選擇
在實際項目中，根據實際情況可以采用兩種不同的模式來進行SIT測試。對于團隊協作熟練且有足夠帶寬處理臨時任務的團隊，可以采用虛擬SIT測試團隊的方式。這種方式不會對既有的組織結構造成很大的破壞，也不會增加過多的溝通成本和知識傳遞成本。
而對于集成問題影響高，產品尚在初期，對迭代內質量不夠有信心的組織，可以先采用獨立測試團隊來負責SIT測試和問題修復的團隊。這種方式可以屏蔽對迭代內的影響，降低迭代內的管理成本。獨立的SIT團隊成員也應該參加其負責模塊Scrum團隊的關鍵活動，了解迭代內的進度，同步SIT測試情況。在有帶寬的情況下，也隨時支持迭代內的測試工作。
無論哪種方式，都要有統一的原則，測試策略，問題響應機制和測試管理規范，才能有效地協調一致，共同完成集成測試。
在大規模項目中，集成測試的節奏取決于項目的迭代節奏和產品的復雜度。對于較為成熟的產品，建議在每個迭代周期或每個功能發布前進行集成測試。然而，對于從無到有（0-1）的大規模數字化轉型項目，由于業務尚不成熟，頻繁集成可能較為困難。
因此，可以采用滾動式逐步加速的方式進行集成，該方式采用前松后緊的策略。雖然頻繁集成有利于質量保障，但考慮到產品復雜性和初始階段等多種因素，將集成分為四個階段會更加合適。
如圖：
由于業務的復雜性，一個端到端的場景往往涉及到多個模塊，甚至多個產品線，SIT的自測和拉通測試，以及UAT驗收都需要并行滾動進行，每次迭代內工作完成后都要經歷SIT自測，SIT拉通，UAT產品驗收，UAT拉通驗收四個步驟。
經常會遇到第一階段的拉通還沒有完成，就要進行第二階段的SIT自測的情況，所以需要規劃好不同環境的升級計劃，拉出不同的分支，平衡資源等，只有這樣充足的準備才能更高的保障項目的質量。
逐步加速的集成測試節奏能夠幫助我們在前期做好準備，帶領團隊熟悉集成的工作流程，培養團隊對集成測試的認知，形成良好的工作習慣，這樣才能在后續多個并行工作的復雜環境中保持快速集成的節奏。
集成測試一般可以分為三步走，測試計劃與準備，測試執行與監控，測試收尾與總結。每個步驟都有相應的實施活動。
所有的集成中，初次的集成測試最為重要，有三個主要目標：
第一次集成一切都是從0開始，由于每個人對具體的流程、規范、環境、工具，以及人員意識和職責劃分等方面都帶有自己以前的認知。為了達到統一認識和目標，SIT測試啟動會是一個非常必要的環節。
測試用例的設計與編寫是集成測試成功的關鍵，它決定了測試的方向和深入程度。而對于SIT自測和SIT拉通測試，顯然測試用例的設計是不同的。SIT自測更注重本產品內的功能，而SIT拉通測試更注重端到端的場景銜接。
SIT自測有兩個主要目標，一個是為PO驗收迭代內實現的功能，一個是驗證模塊和模塊間的接口集成。所以SIT自測階段的測試用例也分為兩個部分：
SIT拉通測試和SIT自測的側重點不同，它更關注從上游到下游整個貫通的場景。測試用例如何設計也是非常有挑戰的事情。每個產品都在SIT自測時設計了自己的測試用例，如果用笛卡爾集拼接，數量將指數級增長。所以需要按照端到端的業務場景編寫用例，以關鍵性的核心業務展開輻射到各個產品上，保證業務場景測試充分。
一般推薦采用主干開發的策略來管理代碼，這更符合我們敏捷中盡早持續集成的理念。但是如果集成的戰線拉得比較長，集成期間需要保持一定的代碼穩定性，那么集成中發現問題的修復和新功能的開發之間就會產生沖突，這時候就不得不考慮更好的分支策略。
滾動式集成策略使得同時可能最多會有三條線并行。也就是我們除了主干之外，需要有兩個分支。一個分支做SIT拉通集成，另一個分支做SIT自測，主干進行迭代內開發。測試過程中在哪里發現問題，就哪里修復，驗證通過后再統一Cherry Pick到其他分支。
如圖:
(1) 分支策略的優勢
要說這種分支策略的優勢，其實就是滿足了大規模敏捷測試中滾動式并行集成的復雜需求。這樣使得我們可以階段性的盡早地進行集成活動，盡早發現問題，一定程度的測試左移。否則是無法進行這種復雜場景下的集成測試的。然而這種方式也是有成本的。
(2) 分支策略的成本和風險
這種方式的成本是顯而易見的，開發同學必須一個問題進行多個分支的代碼修改或者merge動作，測試同學必須在多個環境上進行驗證。這無疑是帶來了很大的工作量。風險也同樣明顯，如果開發同學忘記merge到主干或者其他分支，這個問題會被遺漏，在將來再次出現，帶來質量風險。
SIT自測時關注的是產品內不同模塊間的接口，一個產品內的團隊聯調機會多，所以接口問題沒有那么突出。但是產品之間都是開發了很多功能后才開始初步進行集成測試的，開發過程中都是各自使用mock的方式屏蔽第三方依賴的，這時候就會導致很多接口變更問題。
如果沒有合適的接口變更處理機制，接口變更會無窮無盡地撲面而來。為了控制變更膨脹，接口變更的流程和機制就呼之欲出。
在開發過程中涉及到和第三方系統交互的接口，在定義清晰后需要留存接口文檔和郵件記錄。這樣在SIT拉通測試的過程中發現問題后就有跡可循，能夠更合理的定義接口變更的合理性。多個產品集成測試需要站在整個產品成功的角度考慮問題，如果集成測試中出現阻塞問題，需要立刻處理，否則會影響整個集成的進度。所以又把問題分為兩種類型：
(1) 阻塞場景：先響應，再更新記錄。
由于拉通測試的特殊性，當存在阻塞場景拉通的問題出現時，不管該問題最終被定義為缺陷還是需求變更，都需要第一優先級進行修復。為了處理這樣的情況，即使是新需求，或者無法達成一致，團隊也會立刻響應處理，隨后再更新相應記錄。
(2) 普通場景：按照一般流程處理。
如果是普通場景，就按照先記錄，判定優先級，再根據迭代安排處理。
大規模的E2E拉通測試很像一場戰爭，需要整個團隊齊心協力，提前做好規劃并快速推動決策調整，任何一環節出現問題都會導致整個阻塞，耽誤的就是幾百號人的時間和精力。
QA在迭代內主要是職責是進行故事卡的測試，有時負責一些Showcase的準備和演示工作。但是在SIT測試中，QA的作用和職責發生了很大的變化。由于參與SIT測試的人員眾多，尤其在后期拉通測試中，需要和其他產品團隊共同合作完成測試。QA的職責從單一的測試執行轉變為一專多能。
首先轉變為一個測試Coach，賦能其他角色，尤其PO來進行測試；其次轉變為一個Agent，問題解決的引擎。對每個問題進行分析，澄清，分發，驅動PO，開發，BA共同協作，快速解決問題；最后還是一個價值守護者，不僅守護著產品的質量，更要守護業務的價值，對拉通中產生的不斷變化業務方案，接口定義，能夠從用戶角度，從ROI角度，據理力爭，并基于問題不斷調整測試策略。
PO第一次參與到測試中來，雖然對場景熟悉，但是對測試理解尚淺。為了幫助PO盡快掌握測試能力，QA需要轉變身份成為一個測試Coach，為PO進行賦能。首先用業務的語言講解系統實現的功能，方便其理解以及要關注的測試點。
其次用技術的手段幫助他們能夠快速上手，將系統需要的配置以及跳過依賴所需要的mock使用方法文檔化，可以及時查閱。
最后作為PO測試的支持者，幫助他們定位問題，確定缺陷嚴重級別，建立與團隊的溝通，將問題盡量描述清晰等等。在后續的各種集成測試， UAT測試中，經過賦能的PO都可以發揮重要的作用。
當PO或者其他產品人員在集成測試中發現問題時，QA首先要進行一個基礎判斷，是否是配置問題，數據問題，環境問題。如果確實是缺陷，則在缺陷上補充自己的分析和判斷，流轉給開發同學及時修復。如果是新的需求或者業務方案問題，則引入BA一起討論澄清。
QA在集成測試中是最關鍵的角色，就像一個引擎，驅動整個團隊來快速解決問題，使得集成測試能夠順利進行。
QA同學也是迭代內交付團隊的一個屏障，將非代碼問題都屏蔽在團隊之外，減輕團隊的工作量，有效地保障迭代內的交付。
QA是質量的守護者，同時也是價值的守護者。在集成測試中，除了代碼的問題，更多時候會有接口的問題，業務方案的問題。在與業務，PO，BA以及其他產品的人員討論中，QA作為信息交匯點，具備業務和技術的結合智慧，提出自己的認知，從用戶的使用角度，從技術的成本角度，統一考慮，以最優的成本守護價值。同時要根據迭代內的測試反饋，不斷地調整測試策略，制定重點的測試場景，對迭代內測試不充分，SIT發現問題較多和風險較高的功能進行回歸測試。
本文鏈接：http://www.www897cc.com/showinfo-26-70415-0.html大規模敏捷測試怎么做（集成篇）
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號