摘要：在冒煙測試執(zhí)行過程中，開發(fā)可以跟測試確定一個合理的冒煙用例數(shù)。另外在中臺測試組每月或每季度會成立專項測試小組專門執(zhí)行對應的專項測試。

?有贊幫助每一位重視產(chǎn)品和服務的商家成功，目前旗下?lián)碛校河匈澪⑸坛恰⒂匈澚闶?、有贊美業(yè)、有贊小程序等SaaS軟件產(chǎn)品，適用全行業(yè)多場景，幫商家網(wǎng)上開店、網(wǎng)上營銷、管理客戶、獲取訂單。

?有贊業(yè)務中臺測試團隊按照職責劃分為六條線：交易組、營銷組、用戶賦能組、商品大數(shù)據(jù)組、基保工具組和穩(wěn)定性組，各組職能如下：

?接下來給大家介紹一下中臺測試團隊的質量保障體系以及我們在測試效率提升上做的事情。

?在定義里面測試是對軟件規(guī)格說明、軟件設計和編碼的最后復審。但軟件質量不是測出來的，而是貫穿整個軟件開發(fā)生命周期，需要各方配合，測試環(huán)節(jié)的目的只是在產(chǎn)品交付之前盡可能多的發(fā)現(xiàn)問題，測試是一個找錯的過程，但無法保證經(jīng)過測試的代碼一定正確，無法證明程序無錯。為了保證盡可能地交付高質量軟件，我們會要求測試人員介入軟件整個生命周期的各個關鍵節(jié)點，如下圖所示：

?做正確的事比正確地做事更重要，問題發(fā)現(xiàn)越晚，修復的成本就越高，在需求階段測試左移，開發(fā)測試產(chǎn)品一起參與需求評審，測試參與技術評審，提前發(fā)現(xiàn)設計問題、可測性問題，當然這會需要開發(fā)和測試有比較強的需求分析能力和測試分析能力。

?我們會提供冒煙測試用例，并要求開發(fā)在提測之前完成執(zhí)行，有兩個目的，一是減少提測的輪數(shù)，提測打回的次數(shù)越多，資源浪費就越多；二是很多開發(fā)不是不想測而是不知道測什么，冒煙測試階段測試會給開發(fā)用例，可以幫助開發(fā)梳理要自測的用例。在冒煙測試執(zhí)行過程中，開發(fā)可以跟測試確定一個合理的冒煙用例數(shù)。另外關于冒煙質量的評價，我們有提測打回的機制，3次打回需求可以不測。
?開發(fā)階段，我們對于核心應用的靜態(tài)代碼掃描以及單測也有一定的要求。

上圖是 Martin Fowler 博客里面截的測試金字塔，越是上層的測試，就會耗費越多的精力、時間和成本。假設我們在驗收階段發(fā)現(xiàn)了問題，這個時候修復代碼會導致之前測過的功能很可能需要重新測試一遍，項目延期的風險很高，而且bugfix有引入新bug的風險。所以我們希望在單測或者靜態(tài)代碼掃描階段可以盡可能發(fā)現(xiàn)問題，降低成本。

?中臺需要提供各種能力到上層，目前我們整體的用例量 10000+，如此龐大的用例量無法通過單純的功能測試進行很好地質量保障，搭建完善的自動化保障體系非常重要。

除了要求各應用的單測覆蓋率和有效性以外，我們會花費較多精力在不同維度的集成測試上，如上圖所示，其中展現(xiàn)層的業(yè)務編排通過集成測試和撥測系統(tǒng)進行保障，這里面還有外部調用的情況，比如電商、零售，所以我們的集成測試還會包含電商零售的P1P2場景。在UI層，業(yè)務穩(wěn)定的線，會做一部分UI自動化，覆蓋核心場景。

?在這個環(huán)節(jié)，部分業(yè)務線會根據(jù)項目情況做專項測試，包括：異常測試、性能測試、安全測試和兼容性測試。另外在中臺測試組每月或每季度會成立專項測試小組專門執(zhí)行對應的專項測試。

?在發(fā)布階段，我們提供了快車發(fā)布流程、SOA合并發(fā)布流程和 iron 公交車發(fā)布流程，各線根據(jù)業(yè)務實際情況會做微調，盡量精簡并適合各自業(yè)務特點的發(fā)布流程把控。這樣做的好處顯而易見，上車的功能會經(jīng)過測試的二次check，跟分開多帶帶發(fā)相比，質量更有保障，原先多次測試介入合并成一次，更能節(jié)約測試資源。

?此外根據(jù)項目情況，可以選擇灰度發(fā)布，灰度發(fā)布會在生產(chǎn)環(huán)境穩(wěn)定集群之外，額外部署一個小規(guī)模的灰度集群，并通過流量控制，引入部分流量到灰度集群，進行正式生產(chǎn)發(fā)布前的灰度驗證。流量控制可支持百分比、店鋪ID等，如果灰度發(fā)布驗證有問題，則流量重新切回穩(wěn)定集群即可。

?針對應用的不同情況，還可以接入流量回放平臺，采集線上請求到預發(fā)環(huán)境執(zhí)行，然后對比線上和預發(fā)響應，如果響應結果不一致則判斷可能是預發(fā)部署的代碼分支有bug，加速回歸速度。

?在這一環(huán)節(jié)，主要通過線上業(yè)務監(jiān)控和撥測系統(tǒng)進行質量防護，線上撥測的用例是場景化的，即使使用量非常少的業(yè)務場景也能發(fā)現(xiàn)問題，但不足的點在于無法發(fā)現(xiàn)一些特殊店鋪才會觸發(fā)的問題以及一些偶現(xiàn)問題，需要業(yè)務監(jiān)控進行補充。針對前端核心場景，也會有部分的UI自動化運行。

?為了提升大家的測試效率，我們開發(fā)了很多工具。部分也在測試博客內做了詳細的介紹，篇幅有限，簡單介紹幾個。

?測試平臺包含數(shù)據(jù)工廠、用例平臺、mock工廠、云測平臺、測試報告等。大家可以點擊到具體的文章查閱詳細設計思路。

?微服務化后，快速迭代的門檻越來越低，但是對復雜系統(tǒng)穩(wěn)定性的考驗卻在成倍增長，在復雜的分布式服務體系中，故障發(fā)生的隨機性和不可預測性都大大增加了。混沌工程可以提高系統(tǒng)彈性，通過設計和執(zhí)行一系列實驗，幫助我們提前發(fā)現(xiàn)系統(tǒng)中潛在的問題，除了常規(guī)故障注入，也可以探究更多其他的非故障類的場景。關于混沌工程的介紹可以看這里

?為了讓項目更有質量地交付，我們深度參與并設計了持續(xù)交付流程，實現(xiàn)底層調度邏輯，將質量保障策略融入整個pipeline，讓產(chǎn)品交付的質量得到更好的保障。

?公交車系統(tǒng)的作用是為了讓整個發(fā)布測試流程更有效率，同時通過將多人變更合并發(fā)布，節(jié)約測試輪次。另外公交車系統(tǒng)與持續(xù)交付系統(tǒng)也做了一些融合，比如開發(fā)自測的需求可以在發(fā)車時及時關注到自動化測試結果。

?在介紹質量保障體系時提到過上線后的節(jié)點，我們主要通過線上業(yè)務監(jiān)控和撥測系統(tǒng)進行質量防護，關于撥測系統(tǒng)的詳細介紹可以見這里。

?性能測試平臺目前分成單接口壓測和全連路壓測兩塊，除了讓壓測過程更加簡單便捷以外，還提供了自動生成壓測結果圖表的功能，方便大家生成壓測報告。

?我們提供了數(shù)據(jù)度量平臺，通過分析項目過程、質量數(shù)據(jù)以及上線以后的各類數(shù)據(jù)表現(xiàn)，判斷出不同緯度的質量情況以及軟件開發(fā)生命周期中出現(xiàn)的問題，方便及時調整優(yōu)化，這部分數(shù)據(jù)比較敏感，暫時不給截圖了。

?我們目前用的覆蓋率工具是 JaCoCo ，在之前的博客里面，也跟大家介紹過我們針對 JaCoCo 做的改造，使它支持計算增量代碼覆蓋率。另外結合調用鏈，我們做了精準測試工具，可以通過代碼改動，精確評估影響范圍。

以上是團隊的大致情況介紹，篇幅有限，很多東西沒有羅列。有贊測試組在持續(xù)招人中，大量崗位空缺，歡迎大家加入，可以一對一詳細講解，有意向換工作的同學歡迎發(fā)簡歷到 winta【@】youzan.com ，當天即可回復。