食之無味，棄之可惜

在企業(yè)級應(yīng)用的“季度或月度發(fā)布”被認(rèn)為是領(lǐng)域最佳實(shí)踐的時(shí)候，在應(yīng)用部署到生產(chǎn)環(huán)境之前維護(hù)一個(gè)完整的環(huán)境來進(jìn)行集成測試是非常必要的。但是，集成測試環(huán)境和集成測試本身有著如下的問題：

• 環(huán)境本身脆弱，而且通常存在手動配置部分，環(huán)境維護(hù)成本很高；
• 環(huán)境因素導(dǎo)致集成測試不穩(wěn)定、不可靠、反饋慢，測試失敗不易定位問題，同時(shí)還會重復(fù)測試隔離組件已經(jīng)測過的功能。

集成測試成為了持續(xù)交付的瓶頸，猶如雞肋。因此，最新一期（2017年第16期）ThoughtWorks技術(shù)雷達(dá)建議企業(yè)暫緩搭建企業(yè)級集成測試環(huán)境，而是采用增量的方式發(fā)布關(guān)鍵組件到生產(chǎn)環(huán)境。增量發(fā)布涉及到一些重要的技術(shù)包括契約測試、將發(fā)布與部署解耦、專注于平均恢復(fù)時(shí)間和生產(chǎn)環(huán)境下的QA。

斷舍離之技術(shù)可行性

下面分別介紹技術(shù)雷達(dá)建議的這四項(xiàng)技術(shù)，以及在沒有集成測試的情況下如何保證應(yīng)用的質(zhì)量、如何幫助企業(yè)做到獨(dú)立增量發(fā)布。

消費(fèi)端驅(qū)動的契約測試

消費(fèi)端驅(qū)動的契約測試是微服務(wù)測試的重要組成部分，主要用來覆蓋兩兩服務(wù)之間的契約關(guān)系，下面舉個(gè)例子來說明什么是契約測試以及契約測試與API測試的區(qū)別。

家里有個(gè)插座，買電器的時(shí)候需要考慮插頭跟插座是能配對的，也就是說插座和插頭之間需要有契約。

這里的契約測試就是插座跟插頭的配套性測試，包括

• 三相/三頭還是兩相/兩頭的；
• 電壓是220V還是110V；
• 插孔的形狀：英式 or 中式？
• 等等

API測試：對于插座本身功能的測試，需要覆蓋

• 插座能夠正常通電；
• 電壓是預(yù)期的220v；
• 接地的插孔真的能夠接地
• 等等

也就是說API測試需要測試API本身功能的各個(gè)方面，而契約測試重點(diǎn)在覆蓋API調(diào)用的格式、參數(shù)數(shù)量、參數(shù)類型等，不一定需要涉及API本身的功能和具體的數(shù)據(jù)。

發(fā)布與部署解耦

部署，就是把組件或者基礎(chǔ)設(shè)施部署到生產(chǎn)環(huán)境，不對用戶可見，不會影響業(yè)務(wù)和用戶的使用。發(fā)布，則是將部署的組件讓用戶可見，對業(yè)務(wù)會產(chǎn)生影響。可以通過采用Feature toggle的方式實(shí)現(xiàn)部署與發(fā)布的解耦，做到持續(xù)部署和可控制的發(fā)布，減少組件改變帶來的風(fēng)險(xiǎn)。這樣，產(chǎn)品經(jīng)理可以根據(jù)業(yè)務(wù)需求靈活控制發(fā)布給最終用戶的功能組件，幫助企業(yè)業(yè)務(wù)價(jià)值最大化。

關(guān)注平均恢復(fù)時(shí)間

先看這樣兩種情況，思考哪種更好：

• 系統(tǒng)宕機(jī)次數(shù)很少，可能每年也就一到兩次，但是恢復(fù)能力很弱，一旦宕機(jī)，得花至少24個(gè)小時(shí)恢復(fù)正常；
• 系統(tǒng)宕機(jī)頻率較高，不過每次宕機(jī)都能快速恢復(fù)，用戶甚至感覺不到。

對于第一種，平均失敗間隔很長，但是一旦失敗對用戶的影響不言而喻；第二種雖然會頻繁的失敗，但是平均恢復(fù)時(shí)間很短，用戶體驗(yàn)不受影響，當(dāng)然是第二種更好。

傳統(tǒng)的Ops團(tuán)隊(duì)比較關(guān)注失敗發(fā)生的頻率，隨著持續(xù)交付和監(jiān)控技術(shù)的發(fā)展，“快速恢復(fù)”成為可能。不用擔(dān)心錯(cuò)誤、失敗的發(fā)生，而是利用對這些錯(cuò)誤和失敗的監(jiān)控和分析，讓系統(tǒng)做到快速恢復(fù)，可以省掉一些復(fù)雜的集成測試，也可以減少無處不在的安全攻擊的影響。

生產(chǎn)環(huán)境下的QA

生產(chǎn)環(huán)境是真實(shí)用戶使用的環(huán)境，通常都不能跟測試環(huán)境一樣可以在上面直接測試產(chǎn)品的功能，不能簡單的把測試環(huán)境所用的QA技術(shù)直接后延到生產(chǎn)環(huán)境，而其中一項(xiàng)在生產(chǎn)環(huán)境使用的技術(shù)就是監(jiān)控。采用監(jiān)控技術(shù)來獲取生產(chǎn)環(huán)境的信息，對其進(jìn)行分析，然后優(yōu)化開發(fā)、測試過程，同時(shí)優(yōu)化企業(yè)業(yè)務(wù)。更多關(guān)于生產(chǎn)環(huán)境下QA的內(nèi)容，請參看文章《產(chǎn)品環(huán)境下的QA》。

對上面四種技術(shù)的解釋，我們可以看到：契約測試是對持續(xù)獨(dú)立部署有幫助的，監(jiān)控技術(shù)則是縮短平均恢復(fù)時(shí)間和做好生產(chǎn)環(huán)境下的QA共同的關(guān)鍵技術(shù)之一。接下來主要分享項(xiàng)目在圍繞契約測試和日志監(jiān)控這兩塊所做的實(shí)踐，一起來看系統(tǒng)級集成測試的斷舍離該如何實(shí)現(xiàn)。

斷舍離之項(xiàng)目實(shí)踐

項(xiàng)目是一個(gè)開發(fā)了七八年的老項(xiàng)目，團(tuán)隊(duì)對集成測試也是進(jìn)行了多次的調(diào)整，經(jīng)歷了“七年之癢”后依然覺得是雞肋：

• Pipeline上執(zhí)行非常不穩(wěn)定，總是“隨機(jī)掛”，不能真實(shí)反映問題；
• 系統(tǒng)復(fù)雜，集成測試自然也不簡單，每次順利執(zhí)行的時(shí)間都需要半個(gè)小時(shí)以上，何況還有很不穩(wěn)定的情況，最嚴(yán)重的時(shí)候?qū)е翾A超過一周拿不到包部署；
• 通過集成測試發(fā)現(xiàn)的應(yīng)用程序的缺陷半年也難得出現(xiàn)一個(gè)；
• 隨著系統(tǒng)逐漸變得復(fù)雜，集成測試維護(hù)的成本也不斷增加。

可以看出，集成測試已經(jīng)嚴(yán)重阻礙了項(xiàng)目持續(xù)交付的進(jìn)行，不得不對其斷舍離了。

（一）測試策略調(diào)整

斷舍離的第一個(gè)部分是從集成測試本身入手，調(diào)整測試策略。步驟如下:

• 不再添加新的功能層面的自動化測試，原有的集成測試部分能用底層的UT、API測試覆蓋的盡量下移；
• UT和API測試不能cover的服務(wù)間的契約關(guān)系通過增加契約測試來保證；
• 從CI上摘掉原來的集成測試，加速pipeline出包，然后添加Smoke測試到QA環(huán)境執(zhí)行；
• 不管是在測試環(huán)境還是生產(chǎn)環(huán)境發(fā)現(xiàn)缺陷，都添加對應(yīng)的測試。

整體策略調(diào)整思路是根據(jù)測試金字塔的結(jié)構(gòu)進(jìn)行調(diào)整，把測試盡量往下層移，但并沒有全部去掉集成測試，只是縮減到非常關(guān)鍵的路徑覆蓋，最終測試結(jié)構(gòu)調(diào)整如下圖所示：

（二）日志監(jiān)控、分析和優(yōu)化

沒有了Pipeline上的集成測試，直接上到QA或者prod環(huán)境，那么加強(qiáng)日志監(jiān)控變得尤其重要。因此，斷舍離的第二個(gè)部分是日志的監(jiān)控、分析和優(yōu)化。

日志數(shù)據(jù)采集

項(xiàng)目使用的日志分析工具是Splunk，使用該工具從下面幾個(gè)方面來著手采集日志數(shù)據(jù)：

• 在Splunk上設(shè)置日志監(jiān)控的Dashboard，主要用來監(jiān)控API的請求失敗、錯(cuò)誤的日志，還有API執(zhí)行時(shí)間等性能相關(guān)內(nèi)容。如下圖所示：

• 設(shè)置預(yù)警郵件提醒：對于一些存在嚴(yán)重性能問題的API請求，通過郵件的方式進(jìn)行預(yù)警提醒，如下圖：

• 主動查找錯(cuò)誤日志：對于一些生產(chǎn)環(huán)境中用戶反饋回來的問題，通過主動查找錯(cuò)誤日志的方式去定位。

• 前面的幾個(gè)機(jī)制同樣應(yīng)用于QA和Staging等測試環(huán)境，以通過日志分析盡量提前發(fā)現(xiàn)問題。

日志數(shù)據(jù)利用

利用前面幾種方式采集到的日志數(shù)據(jù)，從下面幾個(gè)方面進(jìn)行分析和優(yōu)化：

• 發(fā)現(xiàn)和定位系統(tǒng)功能問題，分析系統(tǒng)用戶的行為習(xí)慣，優(yōu)化業(yè)務(wù)；

• 發(fā)現(xiàn)和定位安全、性能等非功能問題，進(jìn)行修復(fù)和優(yōu)化；

• 發(fā)現(xiàn)和分析日志記錄本身的不足，規(guī)范日志記錄，從而進(jìn)一步增強(qiáng)日志給問題診斷帶來的幫助，形成良性循環(huán)。規(guī)范日志記錄主要涉及這些點(diǎn)：統(tǒng)一日志輸出路徑、統(tǒng)一日志記錄格式、清晰定義日志級別，并且把添加必要日志作為story開發(fā)流程的一部分，QA會參與日志評審。下圖是Splunk里看到的項(xiàng)目最新優(yōu)化的日志記錄格式：

項(xiàng)目對集成測試斷舍離才剛剛開始，正在不斷摸索著前進(jìn)，目前能看到的最直接的影響是pipeline出包明顯加快，由以前的好幾天出不來一個(gè)包變成一天能出好幾個(gè)包。最振奮人心的是本周剛剛發(fā)生的事情：前一天下班前報(bào)的bug，第二天上午就已經(jīng)修復(fù)出包可以測試了。

寫在最后

系統(tǒng)級集成測試雖然有各種問題，不一定會因?yàn)榧蓽y試掛掉而發(fā)現(xiàn)很多問題，前面也討論了斷舍離的可行性，分析了項(xiàng)目斷舍離的實(shí)踐，但集成測試并不是用來發(fā)現(xiàn)問題的，而是一道對質(zhì)量把關(guān)的屏障，關(guān)鍵路徑的必要測試是不可替代的。因此，我們提倡減少集成測試的數(shù)量，合理調(diào)整各層測試的比例。

系統(tǒng)級集成測試的斷舍離需要團(tuán)隊(duì)有持續(xù)、遞進(jìn)、穩(wěn)定的交付能力，需要保證用戶不會受此影響，企業(yè)業(yè)務(wù)能夠正常運(yùn)轉(zhuǎn)。系統(tǒng)級集成測試的斷舍離過程不是一蹴而就的，凝結(jié)在集成測試上的心血也不是那么容易放棄的，需要很多的平衡和取舍，并在整個(gè)過程中要不斷的關(guān)注系統(tǒng)的質(zhì)量和風(fēng)險(xiǎn)，及時(shí)作出相應(yīng)的調(diào)整。

文／ThoughtWorks林冰玉