馬蜂窩大交通業務質量體系建設初步實踐

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

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

質量管理的常見誤區

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

測試環節再關注

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

質量保障是 QA 的事

有了良好的質量咱們才能提高用戶體驗和留存率。和第一個問題相相似，不少人會認爲質量只是 QA 的事，和其餘角色沒有太大的關係。而實際上，軟件的質量是在整個研發過程當中逐步造成的，離不開 QA 團隊，但只靠 QA 團隊關注確定是不夠的，業務中的所有角色都須要提高質量意識：開發要加強自測；產品要提早規劃和測試好要上線的內容，當在質量和上線時間發生衝突時應該首選質量；運營同窗對本身配置的運營頁面要通過測試後再上線等等。

測試人員不須要懂代碼

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

除了手工測試以外，須要根據業務和團隊的須要適時開展接口自動化、UI 自動化、Code Review 等提高效率的工做。二者有效的結合纔是測試質量保證的關鍵。

正常上線就大功告成

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

大交通研發質量體系建設

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

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

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

• 減小線上問題數量

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

1. 管控項目流程，提高交付質量

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

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，針對項目流程中的問題爲研發和產品同窗進行分享和培訓，提高研發人員的項目管理能力和產品同窗的流程意識。

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

2. 增強業務測試，實現功能保障

業務規模快速發展，業務邏輯愈來愈複雜，系統級別交互愈來愈多，都給測試團隊帶來極大挑戰。大交通測試團隊內部主要是從 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. 關注線上，造成問題閉環

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

3.1 標準化反饋流程

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

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

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

3.2 主動發現問題

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

3.3 質量會議

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

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

4. 完善工具建設，提高測試效能

只有手工點點點是遠遠不夠的，結合大交通的實際業務場景，測試團隊的工具建設主要圍繞環境支撐、壓力測試、測試平臺、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 上配置運行，後面要對接到測試平臺。

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

遇到的一些困難

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

1. 流程改進中的困難

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

爲了讓 Sonar 自動的發揮它的代碼檢查效能，咱們將 Sonar 引入測試環境 CD 平臺，制定了統一的質量閥，Sonar 掃描不經過質量閥的就沒法部署到測試環境，最初以一個項目爲試點啓用、發現問題和解決問題，如今所有項目在提測前都須要經過 Sonar 代碼掃描並經過質量閥，經過以後才能夠提交測試。

2. 業務測試和工具開發時間衝突

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

總結

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

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

（題圖來源於網絡）

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