摘要：大交通研發質量體系建設為了幫助用戶更好地完成消費決策閉環，馬蜂窩上線了大交通業務，為用戶提供購買機票火車票等服務。

質量是決定產品能否成功、企業能否持續發展的關鍵因素之一。如何做好質量體系建設，這是個比較大的話題，包含的范圍很廣，也沒有固定的衡量標準。

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

在談到質量管理的時候，很多團隊在開始時會容易進入幾個誤區：

測試環節再關注

在實際項目中，很多時候都在測試階段才發現大量實現類 bug，測試人員每天拉著研發修 bug；要么就是在臨近上線的時候發現了一個重大問題，導致修復驗證時間不夠，但又只能「硬著頭皮」上線。質量保障是要貫穿項目實施從需求提出到研發到測試全階段的，如果到測試環節才來關注，已經晚了。

質量保障是 QA 的事

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

測試人員不需要懂代碼

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

除了手工測試之外，需要根據業務和團隊的需要適時開展接口自動化、UI 自動化、Code Review 等提升效率的工作。兩者有效的結合才是測試質量保證的關鍵。

正常上線就大功告成

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

為了幫助用戶更好地完成消費決策閉環，馬蜂窩上線了大交通業務，為用戶提供購買機票、火車票等服務。為了提升系統的穩定性、更好地支持高并發，大交通將原有 PHP 架構的交通業務重構成支持高并發和更穩定的 Java 集群架構，同時逐漸將各模塊的業務容器化，來提升系統的整體性能并且可維護。

大交通測試團隊主要負責機票、火車票和用車業務的測試。為了避免上面說的四個誤區并結合研發團隊的具體情況，大交通研發質量體系建設主要是從項目流程、業務測試、線上事件和工具建設四個方面來進行的。現階段質量體系建設的目標有 2 點：

縮短線下項目的工期，減少線下 bug 數量

減少線上問題數量

質量體系大盤如下圖所示，其中虛線框中的部分是規劃中或者正在進行中的，實線框中的部分已經完成。

產品的質量不是依靠一個團隊或一個階段就可以保障的，需要在研發的整個流程、每一個階段進行控制和管理。

1.1 分類需求，明確項目周期

大交通業務從無到有，業務功能開發需要具有快速迭代和交付的能力，目前采用的是雙周迭代模式，挑戰性是比較強的。為了在項目快速上線的同時保證質量，我們按照需求的不同類型和等級梳理了交付的核心時間節點。

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

日常?- 開發工期較短，1 個迭代內完成。

項目?- 開發工期 3 天以上，大約 2 個迭代內完成。

線上事件?– 計劃外的突發狀況，通常來說緊急程度高，可能會直接影響線上業務，需要及時響應。

需求包含產品需求和技術需求。為了合理安排開發資源，日常需求和項目需求進行雙周 PK，根據項目價值、優先級、資源情況等確認后續 2 周的需求范圍。日常、項目主要流程如下圖所示：

1.2 項目進度可視化管理

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

1.3 持續集成工作流

Bug 發現的時機越晚，修復 bug 所需的時間就越長，項目工期就越長。為了提升每一個環節的交付質量從而減少線下 bug 和加速項目進度，我們在流程中針對各角色逐步推進了以下機制：

i）針對產品和 UI?，我們約定需求 PK 通過后 3 天內進行需求評審，提升需求的交付速度；開發聯調結束后和提測前參與 Show Case，第一時間驗收產品。

ii)?針對研發，在測試環境 CI/CD 中加入了 Sonar 靜態代碼掃描，只有通過質量閥后才能部署；聯調結束后運行自測用例并將結果標注在用例管理工具中；并組織 Show Case，給產品、運營、測試展示主流程。

iii）針對測試，將測試用例評審時間提前，盡量跟開發技術方案評審時間一致，在提測前 2 天就開始部署隔離的測試環境供開發連調和自測。

（隔離的測試環境是為了多項目并行而使用，會在后續章節中詳細介紹。）

iv）運營同學提出的需求，會在 Show Case 時邀請運營第一時間參與產品驗收。

1.4 培養全員項目管理意識

大交通技術團隊目前沒有專職 PM，所有項目的 PM 均為技術兼職。為了保障所有日常和項目均能如期甚至提前完成、更好的讓項目流程落地以及優化項目流程，由測試團隊負責人等 3 人兼任 PMO，針對項目流程中的問題為研發和產品同學進行分享和培訓，提升研發人員的項目管理能力和產品同學的流程意識。

良好的項目流程制定和優化、項目流程落地、每個環節負責人都高質量地交付給下一個環節的負責人，是保障產品質量的第一步。

業務規模快速發展，業務邏輯越來越復雜，系統級別交互越來越多，都給測試團隊帶來極大挑戰。大交通測試團隊內部主要是從 5 個方面來提升業務測試能力：

2.1 熟悉業務流程和功能

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

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

2.2 閱讀后端代碼

作為系統測試工程師，不需要對開發代碼了如指掌、掌握每一個方法，但是適當的閱讀代碼和代碼的邏輯是有必要的。

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

下圖是機票測試同學閱讀機票接入基礎數據相關代碼時梳理的部分流程圖：

2.3 測試覆蓋率統計

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

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

除了增量代碼測試，每次項目上線前還需要對業務主流程進行回歸測試。

2.4 推進項目自測

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

2.5 數據統計分析

在推進代碼質量時，我們以月為單位需對項目和 Bug 進行數據匯總，并通過對數據進行分析，發現和總結項目過程中的問題及產生原因，針對問題提出項目目優化和質量提升建議并在項目組中推動施行。

月度報告關注的是項目質量往更優發展，而不是統計本身。通過數據展示，大家也可以知道我們的項目質量在持續提高，比如在多個機票大項目并行的情況下，大交通今年 Q1 的線下 bug 總數比去年 Q4 下降了 1/4, 通過數據大家可以感受到項目的整體質量越來越好，也是對團隊很好的鼓舞。

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

3.1 標準化反饋流程

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

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

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

3.2 主動發現問題

除了線上報警外，技術支持也會定期巡檢各業務，預防重大線上問題發生，并通過數據大盤、數據庫異常數據、小時報等異常數據來主動發現線上問題并推動解決。

3.3 質量會議

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

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

只有手工點點點是遠遠不夠的，結合大交通的實際業務場景，測試團隊的工具建設主要圍繞環境支撐、壓力測試、測試平臺、UI 自動化、接口自動化等方面展開。

4.1 環境支撐

無論 Code Review 做得多么完美，最終都需要進行集成測試。良好的測試環境是對測試效率和項目質量的保障，同時測試環境適合與否會對測試結果的真實性和正確性很重要。

大交通的測試環境共有 3 套：Dev 環境、QA 環境、預發環境。之前測試環境出現過一些較明顯的問題，比如：

在搶占開發 Dev 環境的情況下同時最多只能測試兩個 Java 代碼變更項目（QA 和 Dev 各測試一個），嚴重影響效率。

QA 環境上頻繁部署引起測試中斷。

QA 環境上出了真實的票產生了資損。

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

為了解決以上問題，我們進行了測試環境改造及預發環境打通。

4.1.1 測試環境改造

針對以上問題，我們將提升測試環境的穩定性、并行性、隔離性、實時性作為重點指標進行測試環境改造：

相對穩定性：

- QA 有需要時部署?

- Java 代碼：回收開發同學 Jenkins 權限

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

并行性：

- Java：所有微服務均引入測試環境隔離插件，同時支持多項目并行測試

隔離性：

- 測試環境的訂單不能出到線上

- 機票接入：訂單攔截

實時性：

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

良好的測試環境有力的保障了多項目并行開發、連調和測試。提測前 2 天測試同學就開始協助開發部署項目隔離環境，開發在隔離環境中連調和自測，自測通過后測試同學直接在該項目隔離環境進行測試，大大節約了從 Dev 到 QA 的轉換時間。

4.1.2 預發環境打通

大交通測試環境中的數據庫、MQ、Redis 等中間件跟生產環境是分開的，賬戶是虛擬賬戶，出的票是模擬票，因此測試環境跟生產環境還是有很大差距的。過去測試環境結束后直接上線的項目中，有些服務上線后連啟動都是失敗的。

為了能在更加接近生產環境的條件下進行測試，提高一次上線成功率，我們啟動了打通機票、火車票預發環境的技術項目，對預發環境我們的定位是：

上線前預演

真實賬戶、真實交易

代碼與生產隔離

機票火車票的預發環境全部打通后，全部項目在測試環境結束后上預發進行主流程回歸，然后上線。

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

4.2 壓力測試

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

4.3 測試平臺

測試平臺是大交通測試的門戶網站，大交通研發業務線后端使用 Java，前端統一使用 VUE，為了讓大家更快地熟悉大交通研發技術棧，測試平臺采用了跟研發前、后端一致的架構。

測試平臺的最終目標是將團隊開發的工具，如代碼覆蓋率統計、數據工廠、壓測結果展示等整合在一起，后續計劃把接口自動化、UI 自動化等功能逐步加入，逐步完善測試平臺功能，并以界面化的形式開放給團隊內外部人員使用，提升測試效率。

4.4 數據工廠

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

大交通機票測試環境中除了項目隔離環境外，還維護了一套穩定的主干環境，該環境中代碼基本和線上保持一致，數據工廠基于主干測試環境來創建機票訂單。

目前數據工廠一共分為四個模塊：國內/國際機票生單模塊、模擬支付模塊、出票模塊和日志記錄模塊。四個模塊和機票服務端的調用關系如下圖所示：

目前數據工廠實現了生單、模擬支付、出票和操作日志等功能，填寫了參數之后，在前端頁面直接點擊相應按鈕就可以了。

4.5 接口自動化

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

目前覆蓋主流程的回歸測試用例在測試環境定期運行，搜索類接口的自動化在線上定期運行進行監控，有異常時會發郵件報警。除此之外接口自動化還用于數據創建、主流程回歸和遷移類項目測試中。

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

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

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

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

大交通測試團隊成立了不到一年，經過一段時間的摸索和實踐，在研發質量上有了一定的提升，但我們在質量體系建設的道路上才剛剛起步。隨著業務系統越來越復雜，對測試人員和質量體系的要求也會越來越高，也需要全體成員不斷提升質量思維、持續追求質量。未來，我們將不斷積累方法、優化流程和完善工具，保證高質量的持續交付。

本文作者：孫海燕，馬蜂窩大交通業務測試專家、大交通測試團隊負責人。

（題圖來源于網絡）

關注馬蜂窩技術，找到更多你想要的內容