摘要：大交通研發(fā)質(zhì)量體系建設(shè)為了幫助用戶(hù)更好地完成消費(fèi)決策閉環(huán)，馬蜂窩上線了大交通業(yè)務(wù)，為用戶(hù)提供購(gòu)買(mǎi)機(jī)票火車(chē)票等服務(wù)。

質(zhì)量是決定產(chǎn)品能否成功、企業(yè)能否持續(xù)發(fā)展的關(guān)鍵因素之一。如何做好質(zhì)量體系建設(shè)，這是個(gè)比較大的話題，包含的范圍很廣，也沒(méi)有固定的衡量標(biāo)準(zhǔn)。

打開(kāi)一個(gè)互聯(lián)網(wǎng)公司招聘網(wǎng)站，搜索「測(cè)試工程師」崗位時(shí)，你會(huì)發(fā)現(xiàn)幾乎全部 JD 都包含一條要求「建設(shè)或者參與建設(shè)所負(fù)責(zé)業(yè)務(wù)的質(zhì)量體系」。那么，是不是談到質(zhì)量保障就只是測(cè)試團(tuán)隊(duì)的職責(zé)？測(cè)試團(tuán)隊(duì)在這個(gè)過(guò)程中如何發(fā)揮價(jià)值？本文將結(jié)合馬蜂窩大交通測(cè)試團(tuán)隊(duì)在質(zhì)量體系從無(wú)到有搭建過(guò)程中的實(shí)踐，來(lái)談一下對(duì)質(zhì)量體系建設(shè)的看法和理解。

在談到質(zhì)量管理的時(shí)候，很多團(tuán)隊(duì)在開(kāi)始時(shí)會(huì)容易進(jìn)入幾個(gè)誤區(qū)：

測(cè)試環(huán)節(jié)再關(guān)注

在實(shí)際項(xiàng)目中，很多時(shí)候都在測(cè)試階段才發(fā)現(xiàn)大量實(shí)現(xiàn)類(lèi) bug，測(cè)試人員每天拉著研發(fā)修 bug；要么就是在臨近上線的時(shí)候發(fā)現(xiàn)了一個(gè)重大問(wèn)題，導(dǎo)致修復(fù)驗(yàn)證時(shí)間不夠，但又只能「硬著頭皮」上線。質(zhì)量保障是要貫穿項(xiàng)目實(shí)施從需求提出到研發(fā)到測(cè)試全階段的，如果到測(cè)試環(huán)節(jié)才來(lái)關(guān)注，已經(jīng)晚了。

質(zhì)量保障是 QA 的事

有了良好的質(zhì)量我們才能提升用戶(hù)體驗(yàn)和留存率。和第一個(gè)問(wèn)題相類(lèi)似，很多人會(huì)認(rèn)為質(zhì)量只是 QA 的事，和其他角色沒(méi)有太大的關(guān)系。而實(shí)際上，軟件的質(zhì)量是在整個(gè)研發(fā)過(guò)程中逐步形成的，離不開(kāi) QA 團(tuán)隊(duì)，但只靠 QA 團(tuán)隊(duì)關(guān)注肯定是不夠的，業(yè)務(wù)中的全部角色都需要提升質(zhì)量意識(shí)：開(kāi)發(fā)要增強(qiáng)自測(cè)；產(chǎn)品要提前規(guī)劃和測(cè)試好要上線的內(nèi)容，當(dāng)在質(zhì)量和上線時(shí)間發(fā)生沖突時(shí)應(yīng)該首選質(zhì)量；運(yùn)營(yíng)同學(xué)對(duì)自己配置的運(yùn)營(yíng)頁(yè)面要經(jīng)過(guò)測(cè)試后再上線等等。

測(cè)試人員不需要懂代碼

在開(kāi)發(fā)快速迭代的環(huán)境下，對(duì)測(cè)試工作的技能要求越來(lái)越高，測(cè)試和開(kāi)發(fā)之間的合作更加快速緊密。全手工測(cè)試的方式主要有兩個(gè)問(wèn)題，一是時(shí)間成本高，無(wú)法滿足當(dāng)前快速迭代的需求，而且容易出錯(cuò)；二是測(cè)試人員自身的技術(shù)水平得不到提升，成長(zhǎng)性受限。

除了手工測(cè)試之外，需要根據(jù)業(yè)務(wù)和團(tuán)隊(duì)的需要適時(shí)開(kāi)展接口自動(dòng)化、UI 自動(dòng)化、Code Review 等提升效率的工作。兩者有效的結(jié)合才是測(cè)試質(zhì)量保證的關(guān)鍵。

正常上線就大功告成

一個(gè)項(xiàng)目從需求提出、開(kāi)發(fā)、測(cè)試、發(fā)布只是走完了線下流程，雖然系統(tǒng)經(jīng)過(guò)了嚴(yán)格的測(cè)試，但是畢竟線上的情況和場(chǎng)景會(huì)更加復(fù)雜多變，上線后才是真正經(jīng)受線上用戶(hù)考驗(yàn)的時(shí)候，我們必須關(guān)注線上日志、用戶(hù)反饋、線上報(bào)警等，及時(shí)修復(fù)線上問(wèn)題，并將用戶(hù)提出的合理化建議轉(zhuǎn)為產(chǎn)品優(yōu)化或產(chǎn)品需求并實(shí)現(xiàn)，形成整個(gè)閉環(huán)。

為了幫助用戶(hù)更好地完成消費(fèi)決策閉環(huán)，馬蜂窩上線了大交通業(yè)務(wù)，為用戶(hù)提供購(gòu)買(mǎi)機(jī)票、火車(chē)票等服務(wù)。為了提升系統(tǒng)的穩(wěn)定性、更好地支持高并發(fā)，大交通將原有 PHP 架構(gòu)的交通業(yè)務(wù)重構(gòu)成支持高并發(fā)和更穩(wěn)定的 Java 集群架構(gòu)，同時(shí)逐漸將各模塊的業(yè)務(wù)容器化，來(lái)提升系統(tǒng)的整體性能并且可維護(hù)。

大交通測(cè)試團(tuán)隊(duì)主要負(fù)責(zé)機(jī)票、火車(chē)票和用車(chē)業(yè)務(wù)的測(cè)試。為了避免上面說(shuō)的四個(gè)誤區(qū)并結(jié)合研發(fā)團(tuán)隊(duì)的具體情況，大交通研發(fā)質(zhì)量體系建設(shè)主要是從項(xiàng)目流程、業(yè)務(wù)測(cè)試、線上事件和工具建設(shè)四個(gè)方面來(lái)進(jìn)行的?，F(xiàn)階段質(zhì)量體系建設(shè)的目標(biāo)有 2 點(diǎn)：

縮短線下項(xiàng)目的工期，減少線下 bug 數(shù)量

減少線上問(wèn)題數(shù)量

質(zhì)量體系大盤(pán)如下圖所示，其中虛線框中的部分是規(guī)劃中或者正在進(jìn)行中的，實(shí)線框中的部分已經(jīng)完成。

產(chǎn)品的質(zhì)量不是依靠一個(gè)團(tuán)隊(duì)或一個(gè)階段就可以保障的，需要在研發(fā)的整個(gè)流程、每一個(gè)階段進(jìn)行控制和管理。

1.1 分類(lèi)需求，明確項(xiàng)目周期

大交通業(yè)務(wù)從無(wú)到有，業(yè)務(wù)功能開(kāi)發(fā)需要具有快速迭代和交付的能力，目前采用的是雙周迭代模式，挑戰(zhàn)性是比較強(qiáng)的。為了在項(xiàng)目快速上線的同時(shí)保證質(zhì)量，我們按照需求的不同類(lèi)型和等級(jí)梳理了交付的核心時(shí)間節(jié)點(diǎn)。

目前大交通客戶(hù)端頁(yè)面較少，大多為 H5 前端頁(yè)面。以雙周迭代為前提，需求一共分為 3 類(lèi)：

日常?- 開(kāi)發(fā)工期較短，1 個(gè)迭代內(nèi)完成。

項(xiàng)目?- 開(kāi)發(fā)工期 3 天以上，大約 2 個(gè)迭代內(nèi)完成。

線上事件?– 計(jì)劃外的突發(fā)狀況，通常來(lái)說(shuō)緊急程度高，可能會(huì)直接影響線上業(yè)務(wù)，需要及時(shí)響應(yīng)。

需求包含產(chǎn)品需求和技術(shù)需求。為了合理安排開(kāi)發(fā)資源，日常需求和項(xiàng)目需求進(jìn)行雙周 PK，根據(jù)項(xiàng)目?jī)r(jià)值、優(yōu)先級(jí)、資源情況等確認(rèn)后續(xù) 2 周的需求范圍。日常、項(xiàng)目主要流程如下圖所示：

1.2 項(xiàng)目進(jìn)度可視化管理

要縮短交付周期，如何讓團(tuán)隊(duì)更好的協(xié)作，敏捷的推進(jìn)產(chǎn)品研發(fā)是需要考慮的問(wèn)題。整體思路采用 SCRUM 敏捷的方法論來(lái)推進(jìn)，此類(lèi)落地工具有很多，我們選擇的是 TAPD 來(lái)管理整個(gè)研發(fā)生命周期。比如用故事墻對(duì)大型項(xiàng)目的迭代規(guī)劃狀態(tài)進(jìn)行可視化管理；對(duì)于專(zhuān)項(xiàng)任務(wù)使用看板進(jìn)行階段性同步等，透明團(tuán)隊(duì)工作，讓每個(gè)角色都能對(duì)進(jìn)度直接負(fù)責(zé)，提升協(xié)作效率。

1.3 持續(xù)集成工作流

Bug 發(fā)現(xiàn)的時(shí)機(jī)越晚，修復(fù) bug 所需的時(shí)間就越長(zhǎng)，項(xiàng)目工期就越長(zhǎng)。為了提升每一個(gè)環(huán)節(jié)的交付質(zhì)量從而減少線下 bug 和加速項(xiàng)目進(jìn)度，我們?cè)诹鞒讨嗅槍?duì)各角色逐步推進(jìn)了以下機(jī)制：

i）針對(duì)產(chǎn)品和 UI?，我們約定需求 PK 通過(guò)后 3 天內(nèi)進(jìn)行需求評(píng)審，提升需求的交付速度；開(kāi)發(fā)聯(lián)調(diào)結(jié)束后和提測(cè)前參與 Show Case，第一時(shí)間驗(yàn)收產(chǎn)品。

ii)?針對(duì)研發(fā)，在測(cè)試環(huán)境 CI/CD 中加入了 Sonar 靜態(tài)代碼掃描，只有通過(guò)質(zhì)量閥后才能部署；聯(lián)調(diào)結(jié)束后運(yùn)行自測(cè)用例并將結(jié)果標(biāo)注在用例管理工具中；并組織 Show Case，給產(chǎn)品、運(yùn)營(yíng)、測(cè)試展示主流程。

iii）針對(duì)測(cè)試，將測(cè)試用例評(píng)審時(shí)間提前，盡量跟開(kāi)發(fā)技術(shù)方案評(píng)審時(shí)間一致，在提測(cè)前 2 天就開(kāi)始部署隔離的測(cè)試環(huán)境供開(kāi)發(fā)連調(diào)和自測(cè)。

（隔離的測(cè)試環(huán)境是為了多項(xiàng)目并行而使用，會(huì)在后續(xù)章節(jié)中詳細(xì)介紹。）

iv）運(yùn)營(yíng)同學(xué)提出的需求，會(huì)在 Show Case 時(shí)邀請(qǐng)運(yùn)營(yíng)第一時(shí)間參與產(chǎn)品驗(yàn)收。

1.4 培養(yǎng)全員項(xiàng)目管理意識(shí)

大交通技術(shù)團(tuán)隊(duì)目前沒(méi)有專(zhuān)職 PM，所有項(xiàng)目的 PM 均為技術(shù)兼職。為了保障所有日常和項(xiàng)目均能如期甚至提前完成、更好的讓項(xiàng)目流程落地以及優(yōu)化項(xiàng)目流程，由測(cè)試團(tuán)隊(duì)負(fù)責(zé)人等 3 人兼任 PMO，針對(duì)項(xiàng)目流程中的問(wèn)題為研發(fā)和產(chǎn)品同學(xué)進(jìn)行分享和培訓(xùn)，提升研發(fā)人員的項(xiàng)目管理能力和產(chǎn)品同學(xué)的流程意識(shí)。

良好的項(xiàng)目流程制定和優(yōu)化、項(xiàng)目流程落地、每個(gè)環(huán)節(jié)負(fù)責(zé)人都高質(zhì)量地交付給下一個(gè)環(huán)節(jié)的負(fù)責(zé)人，是保障產(chǎn)品質(zhì)量的第一步。

業(yè)務(wù)規(guī)?？焖侔l(fā)展，業(yè)務(wù)邏輯越來(lái)越復(fù)雜，系統(tǒng)級(jí)別交互越來(lái)越多，都給測(cè)試團(tuán)隊(duì)帶來(lái)極大挑戰(zhàn)。大交通測(cè)試團(tuán)隊(duì)內(nèi)部主要是從 5 個(gè)方面來(lái)提升業(yè)務(wù)測(cè)試能力：

2.1 熟悉業(yè)務(wù)流程和功能

對(duì)于測(cè)試人員來(lái)說(shuō)，熟悉業(yè)務(wù)流程、功能等需求，才能打開(kāi)思維，在測(cè)試過(guò)程中做到有的放矢。比如大交通的機(jī)票業(yè)務(wù)對(duì)基礎(chǔ)數(shù)據(jù)準(zhǔn)確性要求很高，還有虛倉(cāng)、改簽、航變、運(yùn)價(jià)、值機(jī)等特有的功能，這些都需要測(cè)試人員去深入了解。我們會(huì)非定期邀請(qǐng)產(chǎn)品、運(yùn)營(yíng)同學(xué)進(jìn)行機(jī)票業(yè)務(wù)的培訓(xùn)，同時(shí)測(cè)試也會(huì)給開(kāi)發(fā)同學(xué)反講和培訓(xùn)一些業(yè)務(wù)。

隨著團(tuán)隊(duì)新人的加入和系統(tǒng)越來(lái)越多以及越來(lái)越復(fù)雜，為了避免漏測(cè)，我們啟動(dòng)了梳理各業(yè)務(wù)功能、功能入口矩陣圖的工作。舉個(gè)例子，機(jī)票保險(xiǎn)除了 C 端用戶(hù)頁(yè)面，運(yùn)營(yíng)后臺(tái)和供應(yīng)商后臺(tái)也有相應(yīng)功能，那么機(jī)票保險(xiǎn)相關(guān)的業(yè)務(wù)我們需要把全部入口都考慮到。矩陣圖給技術(shù)方案評(píng)審、測(cè)試計(jì)劃和測(cè)試方案制定提供了指導(dǎo)性意義。

2.2 閱讀后端代碼

作為系統(tǒng)測(cè)試工程師，不需要對(duì)開(kāi)發(fā)代碼了如指掌、掌握每一個(gè)方法，但是適當(dāng)?shù)拈喿x代碼和代碼的邏輯是有必要的。

大交通研發(fā)后端代碼以 Java 為主，在熟悉業(yè)務(wù)的前提下，有 Java 代碼基礎(chǔ)的測(cè)試人員每個(gè)季度都會(huì)設(shè)定閱讀后端微服務(wù)代碼的績(jī)效目標(biāo)，閱讀代碼、搞清微服務(wù)、數(shù)據(jù)庫(kù)或緩存、定時(shí)任務(wù)之間的調(diào)用關(guān)系、沉淀成文檔、并反講給編寫(xiě)該微服務(wù)的開(kāi)發(fā)，由開(kāi)發(fā)來(lái)判斷閱讀效果。讀完部分甚至全部代碼之后，后續(xù)的新項(xiàng)目中可以更加自如地從頭把控產(chǎn)品質(zhì)量，如技術(shù)方案是否合理、對(duì)增量代碼進(jìn)行 Code Review 提前發(fā)現(xiàn) bug、協(xié)助開(kāi)發(fā)定位問(wèn)題原因，并推動(dòng)開(kāi)發(fā)在編碼前進(jìn)行技術(shù)方案、接口協(xié)議、數(shù)據(jù)庫(kù)評(píng)審。

下圖是機(jī)票測(cè)試同學(xué)閱讀機(jī)票接入基礎(chǔ)數(shù)據(jù)相關(guān)代碼時(shí)梳理的部分流程圖：

2.3 測(cè)試覆蓋率統(tǒng)計(jì)

覆蓋率是度量測(cè)試完整性和有效性的一個(gè)常用手段。在大交通業(yè)務(wù)體系中，有些項(xiàng)目的邏輯分支非常復(fù)雜，為了評(píng)估手工、接口自動(dòng)化、UI 自動(dòng)化等黑盒測(cè)試手段是否能覆蓋全部代碼邏輯分支。近期我們啟動(dòng)了增量代碼覆蓋率統(tǒng)計(jì)項(xiàng)目，目前在小型項(xiàng)目中試用，一輪測(cè)試完成后查看覆蓋率統(tǒng)計(jì)數(shù)據(jù)，在二輪測(cè)試中則重點(diǎn)覆蓋第一輪中未涉及的部分。

有時(shí)候某些邏輯分支構(gòu)造測(cè)試場(chǎng)景非常困難，這時(shí)需要引入 Code Review 等手段來(lái)進(jìn)行覆蓋。需要注意的是，即使把增量代碼百分百覆蓋掉，也不代表就萬(wàn)事大吉了，有時(shí)候開(kāi)發(fā)會(huì)漏開(kāi)發(fā)某部分代碼，這種情況下最好的情況是在技術(shù)方案評(píng)審和結(jié)合功能矩陣圖來(lái)設(shè)計(jì)測(cè)試用例時(shí)發(fā)現(xiàn)，但我們建議在測(cè)試后期仍要再來(lái)審視一次是否有遺漏開(kāi)發(fā)的情況。

除了增量代碼測(cè)試，每次項(xiàng)目上線前還需要對(duì)業(yè)務(wù)主流程進(jìn)行回歸測(cè)試。

2.4 推進(jìn)項(xiàng)目自測(cè)

大交通有些較為簡(jiǎn)單的日常和項(xiàng)目測(cè)試沒(méi)有介入，采用開(kāi)發(fā)自測(cè)+產(chǎn)品驗(yàn)收后直接上線的模式。測(cè)試同學(xué)不定期會(huì)給開(kāi)發(fā)和產(chǎn)品同學(xué)培訓(xùn)測(cè)試基礎(chǔ)知識(shí)，比如：部署隔離的 Java 測(cè)試環(huán)境、部署 PHP 代碼，前端微服務(wù)切換、Mock 平臺(tái)使用等，有些項(xiàng)目測(cè)試也會(huì)提供測(cè)試用例由產(chǎn)品來(lái)執(zhí)行，通過(guò)培訓(xùn)使沒(méi)有測(cè)試介入的項(xiàng)目也能夠保證質(zhì)量。

2.5 數(shù)據(jù)統(tǒng)計(jì)分析

在推進(jìn)代碼質(zhì)量時(shí)，我們以月為單位需對(duì)項(xiàng)目和 Bug 進(jìn)行數(shù)據(jù)匯總，并通過(guò)對(duì)數(shù)據(jù)進(jìn)行分析，發(fā)現(xiàn)和總結(jié)項(xiàng)目過(guò)程中的問(wèn)題及產(chǎn)生原因，針對(duì)問(wèn)題提出項(xiàng)目目?jī)?yōu)化和質(zhì)量提升建議并在項(xiàng)目組中推動(dòng)施行。

月度報(bào)告關(guān)注的是項(xiàng)目質(zhì)量往更優(yōu)發(fā)展，而不是統(tǒng)計(jì)本身。通過(guò)數(shù)據(jù)展示，大家也可以知道我們的項(xiàng)目質(zhì)量在持續(xù)提高，比如在多個(gè)機(jī)票大項(xiàng)目并行的情況下，大交通今年 Q1 的線下 bug 總數(shù)比去年 Q4 下降了 1/4, 通過(guò)數(shù)據(jù)大家可以感受到項(xiàng)目的整體質(zhì)量越來(lái)越好，也是對(duì)團(tuán)隊(duì)很好的鼓舞。

在文章最初部分我們講過(guò)只關(guān)注線下是不夠的，必須要關(guān)注線上，將線下和線上結(jié)合在一起形成閉環(huán)。大交通在線上問(wèn)題的發(fā)現(xiàn)、處理、匯總上主要做了以下幾個(gè)方面的工作：

3.1 標(biāo)準(zhǔn)化反饋流程

測(cè)試團(tuán)隊(duì)制定了一套完整的線上問(wèn)題處理和反饋機(jī)制，明確工作流，并借助工具（TAPD）落地。

內(nèi)部用戶(hù)和外部客服人員反饋問(wèn)題后，由運(yùn)營(yíng)、產(chǎn)品統(tǒng)一記錄到 TAPD 中，由技術(shù)支持人員過(guò)濾問(wèn)題，復(fù)現(xiàn)并確認(rèn)問(wèn)題是否有效，如果有效則判斷問(wèn)題類(lèi)型：如是咨詢(xún)類(lèi)問(wèn)題，則技術(shù)支持直接回復(fù)；如是 bug（即線上故障），則轉(zhuǎn)交開(kāi)發(fā)解決；如是產(chǎn)品改進(jìn)，則轉(zhuǎn)交產(chǎn)品記錄。遇重大問(wèn)題開(kāi)發(fā)則通知 Team Leader 關(guān)注。無(wú)論何種類(lèi)型的問(wèn)題，都會(huì)在 TAPD 流轉(zhuǎn)，直至問(wèn)題問(wèn)題報(bào)告人驗(yàn)證并關(guān)閉。最終，處理結(jié)果將反饋至內(nèi)外部用戶(hù)。

高優(yōu)先級(jí)問(wèn)題會(huì)被優(yōu)先處理，處理完畢后也會(huì)盡快組織故障 Review。

3.2 主動(dòng)發(fā)現(xiàn)問(wèn)題

除了線上報(bào)警外，技術(shù)支持也會(huì)定期巡檢各業(yè)務(wù)，預(yù)防重大線上問(wèn)題發(fā)生，并通過(guò)數(shù)據(jù)大盤(pán)、數(shù)據(jù)庫(kù)異常數(shù)據(jù)、小時(shí)報(bào)等異常數(shù)據(jù)來(lái)主動(dòng)發(fā)現(xiàn)線上問(wèn)題并推動(dòng)解決。

3.3 質(zhì)量會(huì)議

每周固定召開(kāi)質(zhì)量會(huì)議，由技術(shù)支持發(fā)起，開(kāi)發(fā)、測(cè)試、產(chǎn)品、運(yùn)營(yíng)參加，對(duì)上周的線上問(wèn)題逐個(gè)進(jìn)行 Review，故障類(lèi)問(wèn)題分析原因、以點(diǎn)帶面將類(lèi)似問(wèn)題全部解決；咨詢(xún)類(lèi)問(wèn)題轉(zhuǎn)需求和運(yùn)營(yíng)工具、釋放人力；產(chǎn)品缺陷類(lèi)轉(zhuǎn)為產(chǎn)品需求。每月初的質(zhì)量會(huì)議也會(huì)對(duì)上月的線上問(wèn)題進(jìn)行整體 Review，針對(duì)問(wèn)題提出質(zhì)量建議并推動(dòng)落地。

目前大交通的線上故障月度數(shù)據(jù)呈下降趨勢(shì)，與線下項(xiàng)目質(zhì)量提升、每周的質(zhì)量會(huì)議和全員質(zhì)量意識(shí)培養(yǎng)密不可分，并且隨著產(chǎn)品改進(jìn)類(lèi)需求上線，用戶(hù)體驗(yàn)也越來(lái)越好。

只有手工點(diǎn)點(diǎn)點(diǎn)是遠(yuǎn)遠(yuǎn)不夠的，結(jié)合大交通的實(shí)際業(yè)務(wù)場(chǎng)景，測(cè)試團(tuán)隊(duì)的工具建設(shè)主要圍繞環(huán)境支撐、壓力測(cè)試、測(cè)試平臺(tái)、UI 自動(dòng)化、接口自動(dòng)化等方面展開(kāi)。

4.1 環(huán)境支撐

無(wú)論 Code Review 做得多么完美，最終都需要進(jìn)行集成測(cè)試。良好的測(cè)試環(huán)境是對(duì)測(cè)試效率和項(xiàng)目質(zhì)量的保障，同時(shí)測(cè)試環(huán)境適合與否會(huì)對(duì)測(cè)試結(jié)果的真實(shí)性和正確性很重要。

大交通的測(cè)試環(huán)境共有 3 套：Dev 環(huán)境、QA 環(huán)境、預(yù)發(fā)環(huán)境。之前測(cè)試環(huán)境出現(xiàn)過(guò)一些較明顯的問(wèn)題，比如：

在搶占開(kāi)發(fā) Dev 環(huán)境的情況下同時(shí)最多只能測(cè)試兩個(gè) Java 代碼變更項(xiàng)目（QA 和 Dev 各測(cè)試一個(gè)），嚴(yán)重影響效率。

QA 環(huán)境上頻繁部署引起測(cè)試中斷。

QA 環(huán)境上出了真實(shí)的票產(chǎn)生了資損。

Dev 環(huán)境上開(kāi)發(fā)自測(cè)的很完美，但提測(cè)后部署到 QA 環(huán)境之后連主流程都不工作。

為了解決以上問(wèn)題，我們進(jìn)行了測(cè)試環(huán)境改造及預(yù)發(fā)環(huán)境打通。

4.1.1 測(cè)試環(huán)境改造

針對(duì)以上問(wèn)題，我們將提升測(cè)試環(huán)境的穩(wěn)定性、并行性、隔離性、實(shí)時(shí)性作為重點(diǎn)指標(biāo)進(jìn)行測(cè)試環(huán)境改造：

相對(duì)穩(wěn)定性：

- QA 有需要時(shí)部署?

- Java 代碼：回收開(kāi)發(fā)同學(xué) Jenkins 權(quán)限

- PHP 代碼：推動(dòng)公司 PHP 部署平臺(tái)（AOS）進(jìn)行改造，只有 owner 和分享的人才能部署

并行性：

- Java：所有微服務(wù)均引入測(cè)試環(huán)境隔離插件，同時(shí)支持多項(xiàng)目并行測(cè)試

隔離性：

- 測(cè)試環(huán)境的訂單不能出到線上

- 機(jī)票接入：訂單攔截

實(shí)時(shí)性：

- 除被測(cè)代碼外，其他代碼也要實(shí)時(shí)更新。

良好的測(cè)試環(huán)境有力的保障了多項(xiàng)目并行開(kāi)發(fā)、連調(diào)和測(cè)試。提測(cè)前 2 天測(cè)試同學(xué)就開(kāi)始協(xié)助開(kāi)發(fā)部署項(xiàng)目隔離環(huán)境，開(kāi)發(fā)在隔離環(huán)境中連調(diào)和自測(cè)，自測(cè)通過(guò)后測(cè)試同學(xué)直接在該項(xiàng)目隔離環(huán)境進(jìn)行測(cè)試，大大節(jié)約了從 Dev 到 QA 的轉(zhuǎn)換時(shí)間。

4.1.2 預(yù)發(fā)環(huán)境打通

大交通測(cè)試環(huán)境中的數(shù)據(jù)庫(kù)、MQ、Redis 等中間件跟生產(chǎn)環(huán)境是分開(kāi)的，賬戶(hù)是虛擬賬戶(hù)，出的票是模擬票，因此測(cè)試環(huán)境跟生產(chǎn)環(huán)境還是有很大差距的。過(guò)去測(cè)試環(huán)境結(jié)束后直接上線的項(xiàng)目中，有些服務(wù)上線后連啟動(dòng)都是失敗的。

為了能在更加接近生產(chǎn)環(huán)境的條件下進(jìn)行測(cè)試，提高一次上線成功率，我們啟動(dòng)了打通機(jī)票、火車(chē)票預(yù)發(fā)環(huán)境的技術(shù)項(xiàng)目，對(duì)預(yù)發(fā)環(huán)境我們的定位是：

上線前預(yù)演

真實(shí)賬戶(hù)、真實(shí)交易

代碼與生產(chǎn)隔離

機(jī)票火車(chē)票的預(yù)發(fā)環(huán)境全部打通后，全部項(xiàng)目在測(cè)試環(huán)境結(jié)束后上預(yù)發(fā)進(jìn)行主流程回歸，然后上線。

目前采用的測(cè)試流程如下：

4.2 壓力測(cè)試

在高并發(fā)的場(chǎng)景的搜索類(lèi)項(xiàng)目和活動(dòng)類(lèi)項(xiàng)目中，我們進(jìn)行壓力測(cè)試。壓測(cè)流程如下圖所示。這里可以參考之前馬蜂窩技術(shù)公眾號(hào)發(fā)布過(guò)的一篇關(guān)于壓力測(cè)試的文章，在此不過(guò)多展開(kāi)。

4.3 測(cè)試平臺(tái)

測(cè)試平臺(tái)是大交通測(cè)試的門(mén)戶(hù)網(wǎng)站，大交通研發(fā)業(yè)務(wù)線后端使用 Java，前端統(tǒng)一使用 VUE，為了讓大家更快地熟悉大交通研發(fā)技術(shù)棧，測(cè)試平臺(tái)采用了跟研發(fā)前、后端一致的架構(gòu)。

測(cè)試平臺(tái)的最終目標(biāo)是將團(tuán)隊(duì)開(kāi)發(fā)的工具，如代碼覆蓋率統(tǒng)計(jì)、數(shù)據(jù)工廠、壓測(cè)結(jié)果展示等整合在一起，后續(xù)計(jì)劃把接口自動(dòng)化、UI 自動(dòng)化等功能逐步加入，逐步完善測(cè)試平臺(tái)功能，并以界面化的形式開(kāi)放給團(tuán)隊(duì)內(nèi)外部人員使用，提升測(cè)試效率。

4.4 數(shù)據(jù)工廠

數(shù)據(jù)工廠基于大交通測(cè)試平臺(tái)開(kāi)發(fā)。在一些逆向交易的需求測(cè)試中，需要先創(chuàng)建不同類(lèi)型的訂單作為測(cè)試前提，如果從前端下機(jī)票訂單的話，一共需要操作5步：首頁(yè)->列表頁(yè)->報(bào)價(jià)頁(yè)->訂單填寫(xiě)頁(yè)->乘機(jī)人選擇頁(yè)。為了簡(jiǎn)化創(chuàng)建訂單的步驟和方便產(chǎn)品驗(yàn)收以及外部團(tuán)隊(duì)回歸使用，我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了機(jī)票數(shù)據(jù)工廠，希望可以實(shí)現(xiàn)國(guó)內(nèi)國(guó)際機(jī)票測(cè)試一鍵生單，向研發(fā)、測(cè)試快速提供訂單數(shù)據(jù)，為測(cè)試環(huán)境回歸提供數(shù)據(jù)。

大交通機(jī)票測(cè)試環(huán)境中除了項(xiàng)目隔離環(huán)境外，還維護(hù)了一套穩(wěn)定的主干環(huán)境，該環(huán)境中代碼基本和線上保持一致，數(shù)據(jù)工廠基于主干測(cè)試環(huán)境來(lái)創(chuàng)建機(jī)票訂單。

目前數(shù)據(jù)工廠一共分為四個(gè)模塊：國(guó)內(nèi)/國(guó)際機(jī)票生單模塊、模擬支付模塊、出票模塊和日志記錄模塊。四個(gè)模塊和機(jī)票服務(wù)端的調(diào)用關(guān)系如下圖所示：

目前數(shù)據(jù)工廠實(shí)現(xiàn)了生單、模擬支付、出票和操作日志等功能，填寫(xiě)了參數(shù)之后，在前端頁(yè)面直接點(diǎn)擊相應(yīng)按鈕就可以了。

4.5 接口自動(dòng)化

接口自動(dòng)化的好處不言而喻，我們采用的是比較通用的接口自動(dòng)化框架 TestNG+Rest-assured+Maven，目前在 Jenkins 上配置運(yùn)行，后面要對(duì)接到測(cè)試平臺(tái)。

目前覆蓋主流程的回歸測(cè)試用例在測(cè)試環(huán)境定期運(yùn)行，搜索類(lèi)接口的自動(dòng)化在線上定期運(yùn)行進(jìn)行監(jiān)控，有異常時(shí)會(huì)發(fā)郵件報(bào)警。除此之外接口自動(dòng)化還用于數(shù)據(jù)創(chuàng)建、主流程回歸和遷移類(lèi)項(xiàng)目測(cè)試中。

在搭建質(zhì)量體系的過(guò)程中，我們也遇到了一些困難：

比如 Sonar 靜態(tài)代碼掃描的引入。之前 Sonar 只是放在了 CI 平臺(tái)并沒(méi)有跟 CD 綁定在一起也沒(méi)有引入質(zhì)量閥，需要專(zhuān)職人員來(lái)督促開(kāi)發(fā)進(jìn)行掃描和檢查掃描結(jié)果，引入靜態(tài)代碼掃描的效果并不是很好。

為了讓 Sonar 自動(dòng)的發(fā)揮它的代碼檢查效能，我們將 Sonar 引入測(cè)試環(huán)境 CD 平臺(tái)，制定了統(tǒng)一的質(zhì)量閥，Sonar 掃描不通過(guò)質(zhì)量閥的就無(wú)法部署到測(cè)試環(huán)境，最初以一個(gè)項(xiàng)目為試點(diǎn)啟用、發(fā)現(xiàn)問(wèn)題和解決問(wèn)題，現(xiàn)在全部項(xiàng)目在提測(cè)前都需要通過(guò) Sonar 代碼掃描并通過(guò)質(zhì)量閥，通過(guò)之后才可以提交測(cè)試。

大交通沒(méi)有專(zhuān)職的測(cè)試開(kāi)發(fā)崗位，發(fā)生沖突的情況下優(yōu)先保障業(yè)務(wù)測(cè)試，業(yè)務(wù)測(cè)試間隙期來(lái)做工具開(kāi)發(fā)工作，在這樣的情況下有一些跟業(yè)務(wù)測(cè)試結(jié)合比較緊密的自動(dòng)化工作開(kāi)展的比較緩慢，目前我們的接口自動(dòng)化只覆蓋了核心回歸用例，后面需要把接口自動(dòng)化和大多數(shù)項(xiàng)目測(cè)試結(jié)合在一起，真正把接口自動(dòng)化應(yīng)用于項(xiàng)目測(cè)試中。

大交通測(cè)試團(tuán)隊(duì)成立了不到一年，經(jīng)過(guò)一段時(shí)間的摸索和實(shí)踐，在研發(fā)質(zhì)量上有了一定的提升，但我們?cè)谫|(zhì)量體系建設(shè)的道路上才剛剛起步。隨著業(yè)務(wù)系統(tǒng)越來(lái)越復(fù)雜，對(duì)測(cè)試人員和質(zhì)量體系的要求也會(huì)越來(lái)越高，也需要全體成員不斷提升質(zhì)量思維、持續(xù)追求質(zhì)量。未來(lái)，我們將不斷積累方法、優(yōu)化流程和完善工具，保證高質(zhì)量的持續(xù)交付。

本文作者：孫海燕，馬蜂窩大交通業(yè)務(wù)測(cè)試專(zhuān)家、大交通測(cè)試團(tuán)隊(duì)負(fù)責(zé)人。

（題圖來(lái)源于網(wǎng)絡(luò)）

關(guān)注馬蜂窩技術(shù)，找到更多你想要的內(nèi)容