質量是決定產品能否成功、企業能否持續發展的關鍵因素之一。如何做好質量體系建設，這是個比較大的話題，包含的範圍很廣，也沒有固定的衡量標準。
開啟一個網際網路公司招聘網站，搜尋「測試工程師」崗位時，你會發現幾乎全部 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. 業務測試和工具開發時間衝突
大交通沒有專職的測試開發崗位，發生衝突的情況下優先保障業務測試，業務測試間隙期來做工具開發工作，在這樣的情況下有一些跟業務測試結合比較緊密的自動化工作開展的比較緩慢，目前我們的介面自動化只覆蓋了核心迴歸用例，後面需要把介面自動化和大多數專案測試結合在一起，真正把介面自動化應用於專案測試中。
總結
大交通測試團隊成立了不到一年，經過一段時間的摸索和實踐，在研發質量上有了一定的提升，但我們在質量體系建設的道路上才剛剛起步。隨著業務系統越來越複雜，對測試人員和質量體系的要求也會越來越高，也需要全體成員不斷提升質量思維、持續追求質量。未來，我們將不斷積累方法、優化流程和完善工具，保證高質量的持續交付。
本文作者：孫海燕，馬蜂窩大交通業務測試專家、大交通測試團隊負責人。
（題圖來源於網路）
關注馬蜂窩技術，找到更多你想要的內容