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

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

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

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

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

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

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

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

測試人員不需要懂代碼

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

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

正常上線就大功告成

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

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

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

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

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

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

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

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

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

目前大交通客戶端頁面較少，大多為 H5 前端頁面。以雙周迭代為前提，需求一共分為 3 類：

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

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

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

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

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

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

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

Bug 發(fā)現(xiàn)的時機(jī)越晚，修復(fù) bug 所需的時間就越長，項(xiàng)目工期就越長。為了提升每一個環(huán)節(jié)的交付質(zhì)量從而減少線下 bug 和加速項(xiàng)目進(jìn)度，我們在流程中針對各角色逐步推進(jìn)了以下機(jī)制：

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

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

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

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

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

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

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

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

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

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

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

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

2.2 閱讀后端代碼

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

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

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

2.3 測試覆蓋率統(tǒng)計

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 主動發(fā)現(xiàn)問題

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

3.3 質(zhì)量會議

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

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

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

4.1 環(huán)境支撐

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

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

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

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

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

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

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

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

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

相對穩(wěn)定性：

- QA 有需要時部署?

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

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

并行性：

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

隔離性：

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

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

實(shí)時性：

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

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

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

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

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

上線前預(yù)演

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

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

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

目前采用的測試流程如下：

4.2 壓力測試

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

4.3 測試平臺

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

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

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

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

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

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

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

4.5 接口自動化

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

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

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

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

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

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

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

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

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

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