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

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

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

?接下來給大家介紹一下中臺(tái)測試團(tuán)隊(duì)的質(zhì)量保障體系以及我們在測試效率提升上做的事情。

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

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

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

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

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

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

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

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

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

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

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

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

?測試平臺(tái)包含數(shù)據(jù)工廠、用例平臺(tái)、mock工廠、云測平臺(tái)、測試報(bào)告等。大家可以點(diǎn)擊到具體的文章查閱詳細(xì)設(shè)計(jì)思路。

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

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

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

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

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

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

?我們目前用的覆蓋率工具是 JaCoCo ，在之前的博客里面，也跟大家介紹過我們針對(duì) JaCoCo 做的改造，使它支持計(jì)算增量代碼覆蓋率。另外結(jié)合調(diào)用鏈，我們做了精準(zhǔn)測試工具，可以通過代碼改動(dòng)，精確評(píng)估影響范圍。

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