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

?有贊幫助每一位重視產品和服務的商家成功，目前旗下擁有：有贊微商城、有贊零售、有贊美業、有贊小程序等SaaS軟件產品，適用全行業多場景，幫商家網上開店、網上營銷、管理客戶、獲取訂單。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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