背景
質量保障團隊持續推進知乎質量體系的建設，發起和參與了一系列的工作，包括但不限於：
- 產研流程規範
- 專項測試
- 持續集成流水線建設
- 小黑屋和衆測機制
- 內測和灰度
- 線上質量問題監控
- 客戶端質量大賽
其中的每一項工作都產生了大量質量數據，這些數據不僅可以用來衡量 QA 團隊工作的效果，我們還可以通過質量數據的發佈進一步增強其他團隊質量意識，更好的建設全公司的質量文化。
在早期，我們通過寫腳本或人肉統計的方式從各內部系統上拿到需要的信息，在 excel 上以圖表的形式將這些質量數據展示出來。雖然這種方式偶爾會出錯且耗時較長，但成本還可以接受。隨着公司業務的快速發展，QA 團隊人數也迎來了持續快速增長，並按照事業部分成了不同的小組。與此同時，我們還面臨着知乎客戶端的迭代週期從兩週縮短到一週以及 客戶端組件化 的挑戰，質量數據的收集、統計、展示需要投入越來越多的時間和精力，靠人工整理出完整、可靠、可視化的質量數據，幾乎是不可能完成的任務。我們迫切地需要一個能夠自動收集、處理、展示各種類型數據的質量平臺，而結合整個 QA 團隊的實際工作，我們決定最優先實現客戶端每個版本需求和 Bug 情況的自動收集和展示。
總體設計
如前文所述，質量平臺的初步目標包括如下兩點：
- 每個客戶端版本每個事業部的測試報告儘可能自動生成
- 質量數據變化趨勢高度可視化
依照初步目標，質量平臺應該包括如下三大模塊：
- 數據收集：自動從各個系統收集基礎數據
- 數據處理：將基礎數據關聯起來，組合成測試報告，同時支持人工錄入無法自動獲取的部分信息
- 數據展示：以圖表的形式展示各項質量數據隨版本變化的趨勢
數據收集
測試報告的主要內容是該客戶端版本上指定事業部完成的需求和發現的 Bug 統計，那麼我們獲取的基礎數據分爲以下幾類：
版本信息
版本是測試報告的基本維度，對於知乎客戶端來說，一個版本的整個生命週期分爲 開發、測試、灰度、上線 這 4 個階段，測試報告需要記錄每一個階段的代碼提交和 Bug 情況，因此需要明確每個階段的邊界。
目前知乎客戶端發佈流程中，有三項重要的操作：
- 拉分支：知乎客戶端 Gitlab 的項目中存在一個名爲 develop 的分支，所有新功能都只能提交到這個分支上，到達集成測試的時間點時，我們會基於 develop 分支創建一個新的 Release 分支，這個新分支的創建就是版本從開發階段進入測試階段的標誌，而測試中發現的 Bug 都會修復在新分支上
- 發灰度：在測試階段經過完整的迴歸測試和 bugfix 之後，我們會發佈一個灰度版本給我們邀請的內測用戶試用，灰度版的發佈就是測試階段進入灰度階段的標誌
- 提審：經多次灰度驗證版本質量合格後，提交應用市場審覈，提審操作完成後，會收到由應用市場或負責應用市場推廣的同事發出的郵件
綜上所述，每個階段的邊界可以總結爲下表，質量平臺會根據這些條件判斷某個版本所處階段
事業部信息
事業部同樣也是是測試報告的基本維度，但需求和 Bug 信息並沒有直接的與事業部關聯的方法，質量平臺最終通過需求和 Bug 的負責人信息間接找到對應事業部。
對於每一個需求或 Bug ，都有唯一一個明確的開發負責人，拿到這個負責人之後，質量平臺會請求知乎內部的通訊錄，從而獲取負責人所屬事業部信息，該事業部記錄爲需求或 Bug 所屬事業部。
Bug 信息
知乎內部用 JIRA 作爲 Bug 管理工具，當 QA 創建或更新一個 Bug 時，JIRA 會通過我們事先配置的 webhook 將這個 Bug 的全部信息發送給質量平臺，質量平臺會從中提取所需的信息存儲在數據庫中。
QA 組內對 JIRA 上的 Bug 填寫有明確規範，需要準確填寫 Bug 所屬客戶端版本、發佈階段、事業部等信息，這樣質量平臺就可以根據這些規範自動將 Bug 與測試報告對應起來。
需求信息
知乎內部使用 JIRA 作爲需求管理工具，但由於每個事業部需求管理方式差別較大，質量平臺無法像 Bug 信息一樣自動收集和匹配 JIRA 上的需求。
因此我們轉而收集每個版本的代碼提交信息，由於客戶端的每次代碼提交都已經要求關聯對應的 JIRA 上的 issue（包括需求和 Bug），我們可以間接獲取每個版本的需求信息。
代碼提交信息
知乎內部使用 Gitlab 作爲代碼管理工具，由於知乎客戶端正在組件化重構過程中，目前代碼變更的提交有兩種方式：向主倉庫提交 MR 和通過 組件管理平臺 升級組件版本號。
當工程師通過 MR 提交代碼時，我們預先配置的 webhook 會在 MR 合併時給質量平臺發送消息，消息中包含 MR 代碼改動量、負責人、合併時間、目標分支等信息，通過合併時間+目標分支，可以定位到這個 MR 屬於哪個版本的哪個階段，通過 MR 作者信息可以定位到這個 MR 屬於哪個事業部。由於 Gitlab 支持 與 JIRA 的集成，知乎工程師會在 MR 標題中填寫 JIRA 上 issue 的 ID ，我們可以通過這個 ID 將 MR 與 JIRA 上的需求或 Bug 關聯起來。
當工程師通過組件管理平臺提交新的組件版本時，會被要求填寫如下信息，而在測試通過後並升級提測組件時，組件管理平臺會將這些信息加上升級時間等信息發送給質量平臺。質量平臺就可以通過升級時間+主工程分支定位到這次組件升級屬於哪個版本的哪個階段，通過提測操作人信息可以定位到這次組件升級屬於哪個事業部。
數據處理
有了上述的各項基礎數據，我們可以很簡單地將它們組合成指定版本指定事業部的測試報告，報告中某一個版本階段的報告內容如下圖所示，其中 Diff 指組件升級：
同時，將同一個版本的每個階段數據累計，可以得到如下的版本總體數據：
除了這些自動收集的數據，測試報告還支持手動填寫 Bug 。在「Bug 列表」中點擊「添加」按鈕，可以通過填寫jql 在指定的版本階段添加 JIRA 的任意 issue 。
數據展示
爲了快速實現需求並降低維護成本，我們決定使用開源的 BI 系統來實現數據的展示，並對幾款市面上比較優秀的產品進行了調研：
綜合以上優缺點，我們最終選擇了 MetaBase 作爲平臺數據可視化系統。
值得一提的是，爲了配置的靈活性，我們使用 MetaBase 提供的「原生查詢」功能（即通過 sql 獲取報表中的數據）。同時，我們在做數據庫設計時，故意爲每張表增加一些冗餘信息，這樣可以降低 sql 查詢語句的複雜度以及減少 join 操作，從而降低查詢時間。
基於收集到的基礎數據，我們可以在 MetaBase 上做出各維度的質量數據趨勢圖
尾聲
本文介紹了知乎質量平臺的設計思想以及實現方案，解決客戶端版本質量數據收集和展示的問題。知乎質量平臺從 2018 年 9 月投入使用至今，已記錄多於 50 個客戶端版本的質量數據並生成百餘份客戶端版本測試報告。
除此之外，經過不斷的迭代，質量平臺目前還支持了產品質量週報、需求維度測試報告、線上故障報告等多種類型的報告，同時進一步收集了客戶端啓動時間、網絡請求響應時間、包體積等數據，幫助其他技術團隊更準確地制定工作計劃。我們會在後續文章中對這些功能進行詳述。有了質量平臺的支持，QA 團隊的工作效率得到了明顯的提升，質量平臺提供的各項數據，也爲各事業部和整個知乎的質量文化建設工作提供了有力的支持。
最後，知乎質量保障團隊的工具平臺小組持續招聘中，若你對持續集成、持續交付、移動端組件管理、質量平臺等工作有興趣，歡迎點擊 這裏 查看職位詳情，期待你的加入！
本文轉載自知乎。
原文鏈接：