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