背景
品質保障團隊持續推進知乎品質體系的建設，發起和參與了一系列的工作，包括但不限于：
- 産研流程規範
- 專項測試
- 持續內建流水線建設
- 小黑屋和衆測機制
- 内測和灰階
- 線上品質問題監控
- 用戶端品質大賽
其中的每一項工作都産生了大量品質資料，這些資料不僅可以用來衡量 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 團隊的工作效率得到了明顯的提升，品質平台提供的各項資料，也為各事業部和整個知乎的品質文化建設工作提供了有力的支援。
作者:鐘離無糖
出處:https://zhuanlan.zhihu.com/p/68059263