1.1.3 當(dāng)前軟件測試工程化的困局與解法

可能你已經(jīng)發(fā)現(xiàn)前述的測試左移是完全基于瀑布模型的，但是現(xiàn)在，敏捷開發(fā)和持續(xù)交付等研發(fā)模式被廣泛采用，再加上軟件架構(gòu)的持續(xù)復(fù)雜化，前述的測試左移只能在局部范圍內(nèi)發(fā)揮作用，我們需要探索并實踐適應(yīng)新時代軟件研發(fā)模式的測試左移。為此，我們有必要先系統(tǒng)地探討一下當(dāng)前軟件測試工程化的困局，理解困局將有助于我們對測試進(jìn)行優(yōu)化。

總體來看，當(dāng)前軟件測試工程化的困局主要表現(xiàn)在以下3個維度：

● 技術(shù)實現(xiàn)上，軟件架構(gòu)的復(fù)雜度越來越高；

● 團(tuán)隊管理上，開發(fā)團(tuán)隊和測試團(tuán)隊的協(xié)作成本因為“筒倉效應(yīng)”變得越來越高；

● 研發(fā)模式上，敏捷開發(fā)、持續(xù)交付、DevOps等的實踐對測試活動提出了全新的要求。

接下來，我們依次展開討論。

1. 技術(shù)實現(xiàn)維度上的困局與解法

從技術(shù)實現(xiàn)維度來看，軟件架構(gòu)的復(fù)雜度越來越高，軟件本身的規(guī)模越來越大，傳統(tǒng)的測試模式越來越“力有不逮”。

早期的軟件基本采用單體架構(gòu)，通過后期基于黑盒功能的系統(tǒng)測試基本能夠保證軟件質(zhì)量。但是如今的軟件架構(gòu)普遍具有冰山模型（如圖1-6所示）的特征，基于黑盒功能的系統(tǒng)測試往往只能對水面上的一少部分GUI（Graphical User Interface，圖形用戶界面）進(jìn)行驗證，大量的業(yè)務(wù)邏輯實現(xiàn)其實都在水面以下的微服務(wù)中，想通過水面上的GUI部分覆蓋水面下的所有業(yè)務(wù)邏輯幾乎是不可能完成的任務(wù)，因為你可能都不知道水面下有什么。試問，在傳統(tǒng)黑盒測試模式下，又有多少測試工程師能夠?qū)Ρ粶y軟件的架構(gòu)設(shè)計、調(diào)用鏈路、數(shù)據(jù)流狀態(tài)等有清晰的理解呢？

圖1-6 冰山模型

現(xiàn)在互聯(lián)網(wǎng)產(chǎn)品的后端往往非常龐大和復(fù)雜，一般由幾十到幾千個微服務(wù)相互協(xié)作共同完成前端業(yè)務(wù)請求，這時候如果把測試寄希望于面向終端用戶的系統(tǒng)測試，那么你能夠發(fā)現(xiàn)的缺陷就會非常有限，而且發(fā)現(xiàn)缺陷之后，在調(diào)用鏈路中定位到出問題的微服務(wù)的成本也會很高。

在這種情況下，最優(yōu)的測試策略就是先保證后端每個微服務(wù)的質(zhì)量，這樣集成場景下沒有問題的概率就能大幅度提高。這就要求測試工作必須前置到微服務(wù)的接口開發(fā)層面，把大量的組合邏輯驗證交由接口測試來覆蓋，在GUI層只做基本的業(yè)務(wù)邏輯覆蓋即可。

由上面的分析可以看出，軟件架構(gòu)后端的復(fù)雜化對測試的介入時機(jī)提出了新的要求，隨著微服務(wù)架構(gòu)的發(fā)展，測試重點必須從GUI端逐漸左移到API端，此時測試工程師的能力也必須隨之?dāng)U展，其已經(jīng)不能完全基于黑盒功能來設(shè)計測試用例，而必須知道更多架構(gòu)和接口設(shè)計上的細(xì)節(jié)才能有效開展測試用例的設(shè)計，這些都要求測試介入的時機(jī)必須提前，即左移到架構(gòu)設(shè)計。

2. 團(tuán)隊管理維度上的困局與解法

從團(tuán)隊管理維度來看，開發(fā)團(tuán)隊和測試團(tuán)隊的協(xié)作成本因為筒倉效應(yīng)變得越來越高，繼續(xù)采用獨立測試團(tuán)隊和開發(fā)團(tuán)隊的做法越來越行不通，我們可以通過實際工作中常見的真實例子來感受一下這個困局。

在開發(fā)和測試采用獨立團(tuán)隊的情況下，當(dāng)測試工程師發(fā)現(xiàn)一個缺陷時，他要做的第一件事就是把缺陷的詳細(xì)情況了解清楚并且完整記錄在缺陷報告中。他需要找到最簡單的可穩(wěn)定重現(xiàn)缺陷的操作步驟，并且需要提供相關(guān)的測試數(shù)據(jù)，還需要對出現(xiàn)缺陷時的軟件版本號、環(huán)境細(xì)節(jié)、配置細(xì)節(jié)等都做詳盡的記錄。更進(jìn)一步地，為了便于開發(fā)工程師重現(xiàn)缺陷，他最好把出問題時的日志以及相關(guān)截圖都保留好，一同記錄至缺陷報告。這樣一份高質(zhì)量的缺陷報告往往需要花費測試工程師不少的時間。

但是當(dāng)這份缺陷報告被提交后，如果缺陷不是來自生產(chǎn)環(huán)境，那么開發(fā)工程師往往并不會立馬處理缺陷，因為開發(fā)工程師一般會選擇確保能夠連續(xù)完成當(dāng)前負(fù)責(zé)的工作，盡量避免被打斷。一般過了大半天或一兩天，等開發(fā)工程師負(fù)責(zé)的工作告一段落后，他才會開始處理這個缺陷。此時他要做的第一件事就是重現(xiàn)缺陷，在重現(xiàn)缺陷之前，他必須按缺陷報告提供的詳細(xì)信息重建測試環(huán)境，其中包括環(huán)境安裝、測試數(shù)據(jù)構(gòu)建等一系列步驟，所以往往也要花費不少時間。

如果問題能夠重現(xiàn)，則可以進(jìn)一步定位問題；如果問題不能重現(xiàn)，則可能這個缺陷在流程上就要被打回去加以復(fù)現(xiàn)。假定現(xiàn)在問題能夠重現(xiàn)了，你會發(fā)現(xiàn)修復(fù)缺陷的過程往往是很快的，因為這個坑就是開發(fā)工程師自己挖的。

修復(fù)缺陷以后，開發(fā)工程師提交代碼，集成流水線會生成對應(yīng)的待測版本并通知之前的測試工程師進(jìn)行驗證。但是此時測試工程師大概率在處理其他測試工作，測試工程師同樣不希望被打斷，所以不會為了驗證這個缺陷立馬搭建環(huán)境。從效率角度出發(fā)，測試工程師一般會選擇將多個缺陷集中在一個版本上一起驗證，這樣就能省掉很多環(huán)境搭建的時間。所以從缺陷修復(fù)完成到測試工程師驗證這個缺陷，往往需要等好幾天。

從上面的過程描述中我們可以發(fā)現(xiàn)，從缺陷被發(fā)現(xiàn)到缺陷最終被驗證的整個過程中，真正有效的工作時間占比很小，大量的時間都被流程上的等待和環(huán)境安裝等耗費掉了。整個過程中，開發(fā)工程師沒有偷懶，測試工程師也沒有偷懶，他們各自都選擇了效率最高的方式開展工作，但是從全局視角來看，效率仍十分低下。據(jù)一些企業(yè)內(nèi)部的不完全統(tǒng)計，每個缺陷全生命周期中一般會有超過80%的時間被跨團(tuán)隊的過程流轉(zhuǎn)浪費掉。

除了上述時間上的浪費，還有以下原因使得測試團(tuán)隊與開發(fā)團(tuán)隊各自獨立的組織設(shè)置越來越寸步難行。

（1）獨立的測試團(tuán)隊往往在開發(fā)后期才介入，很難有效保證測試的覆蓋率和質(zhì)量。

（2）開發(fā)測試比持續(xù)增長，測試人力投入越來越大，實際收益卻很低，測試團(tuán)隊進(jìn)行的測試活動并不能顯著降低現(xiàn)網(wǎng)問題數(shù)。

（3）需求本身會不斷變化，需求的實現(xiàn)也會隨之變化，開發(fā)團(tuán)隊和測試團(tuán)隊之間的需求傳遞效率往往十分低下，這在增加漏測隱患的同時，也增加了交接成本。

（4）如果開發(fā)團(tuán)隊要快速迭代軟件版本，這就要求測試團(tuán)隊具有很高的效率和很短的反饋周期，獨立的測試團(tuán)隊很難跟上快速迭代的版本需要。

（5）獨立的測試團(tuán)隊有點像“保姆”，這直接導(dǎo)致開發(fā)團(tuán)隊的自測意識不夠，心理上依賴測試團(tuán)隊，使得質(zhì)量內(nèi)建形同虛設(shè)。

（6）由于開發(fā)團(tuán)隊不負(fù)責(zé)測試活動，可能未積極考慮如何降低測試的難度，可測試性設(shè)計甚至不會被納入開發(fā)工程師的考慮范圍。

所以，試想一下，如果測試工程師和開發(fā)工程師是同一批人，過程流轉(zhuǎn)造成的大量時間浪費是不是就不會發(fā)生？測試活動是不是就能提前介入？需求變化的傳遞是不是就會更加順暢？測試的反饋周期是不是也會進(jìn)一步縮短？開發(fā)團(tuán)隊的質(zhì)量意識是不是也會增強？可測試性問題是不是自然會被納入開發(fā)工程師的考慮范圍？這也就是現(xiàn)在先進(jìn)的軟件組織廣泛推崇開發(fā)者自測的原因，而開發(fā)者自測可以說是測試左移的一種有效落地途徑，能夠最大程度滿足質(zhì)量內(nèi)建的各種要求。

3. 研發(fā)模式維度上的困局與解法

從研發(fā)模式維度來看，敏捷開發(fā)、持續(xù)交付和DevOps等研發(fā)模式愈發(fā)流行，產(chǎn)品的研發(fā)節(jié)奏越來越快，傳統(tǒng)的“開發(fā)提測之后進(jìn)行測試，然后上線發(fā)布”的測試模式面臨很大的挑戰(zhàn)。在當(dāng)前新的研發(fā)模式下，研發(fā)生命周期中的各個階段（比如設(shè)計、開發(fā)和測試階段）都被弱化，或者說邊界變得非常模糊，一個迭代通常就包含設(shè)計、開發(fā)、測試和發(fā)布的全流程，已經(jīng)很難有大把的時間專門用來集中開展測試活動，工程師的能力邊界正在變得模糊，普遍需要全棧工程師。

在這種背景下，必須把測試實踐全程融入研發(fā)的各個階段，把控各個階段的質(zhì)量，而不能依賴于最后的系統(tǒng)測試。我們需要轉(zhuǎn)變觀念，傳統(tǒng)研發(fā)模式下的系統(tǒng)測試以發(fā)現(xiàn)問題為主要目標(biāo)，而現(xiàn)在的系統(tǒng)測試應(yīng)該以“成果展示”和“獲取信心”為主要目標(biāo)。