馬蜂窩大交通業(yè)務(wù)質(zhì)量體系建設初步實(shí)踐

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

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

質(zhì)量管理的常見(jiàn)誤區

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

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

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

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

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

測試人員不需要懂代碼

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

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

正常上線(xiàn)就大功告成

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

大交通研發(fā)質(zhì)量體系建設

1. 管控項目流程，提升交付質(zhì)量

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

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

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

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

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

1.3 持續集成工作流

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

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

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

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

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

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

1.4 培養全員項目管理意識

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

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

2. 加強業(yè)務(wù)測試，實(shí)現功能保障

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

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

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

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

2.2 閱讀后端代碼

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

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

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

2.3 測試覆蓋率統計

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

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

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

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

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

2.5 數據統計分析

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

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

3. 關(guān)注線(xiàn)上，形成問(wèn)題閉環(huán)

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

3.1 標準化反饋流程

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

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

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

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

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

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

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

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

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

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

4.1 環(huán)境支撐

4.2 壓力測試

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

4.3 測試平臺

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

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

4.4 數據工廠(chǎng)

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

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

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

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

4.5 接口自動(dòng)化

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

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

遇到的一些困難

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

1. 流程改進(jìn)中的困難

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

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

2. 業(yè)務(wù)測試和工具開(kāi)發(fā)時(shí)間沖突

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

總結

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

原文轉自：https://mp.weixin.qq.com/s/Enr2It-3jCToej71TcdUQQ