有贊業務中臺測試團隊介紹

1、團隊概況

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

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

 接下來給你們介紹一下中臺測試團隊的質量保障體系以及咱們在測試效率提高上作的事情。

2、中臺質量保障體系

 在定義裏面測試是對軟件規格說明、軟件設計和編碼的最後複審。但軟件質量不是測出來的，而是貫穿整個軟件開發生命週期，須要各方配合，測試環節的目的只是在產品交付以前儘量多的發現問題，測試是一個找錯的過程，但沒法保證通過測試的代碼必定正確，沒法證實程序無錯。爲了保證儘量地交付高質量軟件，咱們會要求測試人員介入軟件整個生命週期的各個關鍵節點，以下圖所示：

2.1 需求階段

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

2.2 開發階段

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

上圖是 Martin Fowler 博客裏面截的測試金字塔，越是上層的測試，就會耗費越多的精力、時間和成本。假設咱們在驗收階段發現了問題，這個時候修復代碼會致使以前測過的功能極可能須要從新測試一遍，項目延期的風險很高，並且bugfix有引入新bug的風險。因此咱們但願在單測或者靜態代碼掃描階段能夠儘量發現問題，下降成本。

2.3 測試階段

 中臺須要提供各類能力到上層，目前咱們總體的用例量 10000+，如此龐大的用例量沒法經過單純的功能測試進行很好地質量保障，搭建完善的自動化保障體系很是重要。

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

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

2.4 發佈階段

 在發佈階段，咱們提供了快車發佈流程、SOA合併發佈流程和 iron 公交車發佈流程，各線根據業務實際狀況會作微調，儘可能精簡併適合各自業務特色的發佈流程把控。這樣作的好處顯而易見，上車的功能會通過測試的二次check，跟分開單獨發相比，質量更有保障，原先屢次測試介入合併成一次，更能節約測試資源。

 此外根據項目狀況，能夠選擇灰度發佈，灰度發佈會在生產環境穩定集羣以外，額外部署一個小規模的灰度集羣，並經過流量控制，引入部分流量到灰度集羣，進行正式生產發佈前的灰度驗證。流量控制可支持百分比、店鋪ID等，若是灰度發佈驗證有問題，則流量從新切回穩定集羣便可。

 針對應用的不一樣狀況，還能夠接入流量回放平臺，採集線上請求到預發環境執行，而後對比線上和預發響應，若是響應結果不一致則判斷多是預發部署的代碼分支有bug，加速回歸速度。

2.5 上線階段

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

3、中臺測試效率提高

 爲了提高你們的測試效率，咱們開發了不少工具。部分也在測試博客內作了詳細的介紹，篇幅有限，簡單介紹幾個。

3.1 測試平臺

 測試平臺包含數據工廠、用例平臺、mock工廠、雲測平臺、測試報告等。你們能夠點擊到具體的文章查閱詳細設計思路。

3.2 混沌工程

 微服務化後，快速迭代的門檻愈來愈低，可是對複雜系統穩定性的考驗卻在成倍增加，在複雜的分佈式服務體系中，故障發生的隨機性和不可預測性都大大增長了。混沌工程能夠提升系統彈性，經過設計和執行一系列實驗，幫助咱們提早發現系統中潛在的問題，除了常規故障注入，也能夠探究更多其餘的非故障類的場景。關於混沌工程的介紹能夠看這裏

3.3 持續交付

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

3.4 公交車系統

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

3.5 線上撥測系統

 在介紹質量保障體系時提到過上線後的節點，咱們主要經過線上業務監控和撥測系統進行質量防禦，關於撥測系統的詳細介紹能夠見這裏。

3.6 性能測試平臺

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

3.7 度量平臺

 咱們提供了數據度量平臺，經過分析項目過程、質量數據以及上線之後的各種數據表現，判斷出不一樣緯度的質量狀況以及軟件開發生命週期中出現的問題，方便及時調整優化，這部分數據比較敏感，暫時不給截圖了。

3.8 覆蓋率與精準

 咱們目前用的覆蓋率工具是 JaCoCo ，在以前的博客裏面，也跟你們介紹過咱們針對 JaCoCo 作的改造，使它支持計算增量代碼覆蓋率。另外結合調用鏈，咱們作了精準測試工具，能夠經過代碼改動，精確評估影響範圍。

以上是團隊的大體狀況介紹，篇幅有限，不少東西沒有羅列。有贊測試組在持續招人中，大量崗位空缺，歡迎你們加入，能夠一對一詳細講解，有意向換工做的同窗歡迎發簡歷到 winta【@】youzan.com ，當天便可回覆。