語雀質量體系與自動化

1. 整體介紹

大家好，我是語雀 QA 會能。
很高興，有機會跟大家聊一下語雀的質量體系和自動化技術。
下面會分幾個部分給大家介紹，讓大家可以瞭解到語雀質量體系的全貌。

1.1. 語雀產品特點&研發特點

首先，簡單分析一下語雀，相信很多朋友對語雀都是不陌生的。
「語雀」是螞蟻集團旗下的文件與知識庫工具，源自螞蟻集團和阿里巴巴內部文件協同需求，2018年1月8日正式對外提供服務，現已服務於數十萬企業組織和數百萬個人使用者。

再從研發角度看，語雀是一個大型 全棧 多端 應用，包括了 web 端、移動端、桌面端。
語雀的研發基於 One CodeBase ** 模式（類似 google 的專案研發，所有相關工程都在一個大的 git 倉庫）。
另外還依賴研發管控、任務跟蹤、程式碼服務、構建流水線等平臺。
語雀的迭代釋出比較快，在工程上，技術團隊對持續交付的穩定性和效率有著很高的要求 **。

然而我們的 QA 就只有我和另外一個同學確知，測試開發比接近（1:20)，在這樣的情況下如何做好質量保障工作就成了一個大問題, 下面來說說我們的解法。

1.2. 語雀技術的：教練模式

我們的解法是 “教練模式”。
什麼是教練模式? 簡單的說 QA 同學就相當於教練，透過各種質量保障機制規範和提升開發同學的質量意識，提供完備的質量服務提升研發效能，從而提升語雀產品的質量。
另外，我們希望透過工程化的方式使質量成果可沉澱，可長期持續，這也是語雀質量技術從起步到發展的的初衷。

1.3. 質量架構

再來看看我們的質量工程的頂層架構，框圖中最底層是我們依賴的基礎平臺 (例如研發管控、任務跟蹤、程式碼服務、構建流水線平臺等) 。
再是質量基建，服務於語雀質量的各種能力，包括語雀質量的技術基礎 和 “看不見質量”，偏軟性但又極其重要的，質量意識和工程文化。
技術基礎像 skytest 支撐工具、Lark-Reliable 測試報告和覆蓋率持久化檢視、Macaca 套件提供了 UIA 技術支援，在後面的會有詳細的介紹。
質量能力，就是語雀實際解決的問題和質量成果了，相關領域包括持續整合、缺陷收斂、線上巡檢、UI 自動化建設，長效機制建設和研發提效，後面也會詳細介紹。

2. 質量支撐工具

每個質量團隊或多或少都會有質量支撐工具或服務，以解決團隊內的質量問題，接下來介紹 SkeyTest 和 Reliable。

2.1. SkyTest

大多質量團隊都會有一些核心的測試支撐工具，我見過比較多的是 web 服務的形式提供的，比如 xx 測試服務，xx 測試平臺，這就要求團隊內需要有全棧開發的同學，並且對這樣服務的開發維護投入還是比較大的。

SkyTest 就是語雀的主要質量支撐工具，它承載了語雀質量技術沉澱，就好比 QA 同學的 “百寶箱”，裡面有各式各樣趁手的測試工具，為語雀質量能力建設奠定了技術基礎。

SkyTest 以 npm 工具模組的形式存在，可以直接透過 cli 的方式使用，或者以 node 模組整合，整合便捷，比較輕量，適合 QA 工具的研發。維護成本相對 web 應用要輕量很多。

2.2. Reliable

LarkReliable 作為質量資料持久化&洞察服務，和 SkyTest 搭配，能夠滿足大部分測試能力的實現。目前在語雀除了集團內其他平臺提供的專項能力外，團隊內的質量能力實現都是能夠 Hold 住的。

基於開源的 Macaca Reliable 套件實現，如果所在團隊正好缺少類似的工具服務，完全可以基於開源的 Relibale 套件，快速實現團隊內的測試報告持久化和資料洞察的服務能力。

• 測試、覆蓋率報告檢視
• 覆蓋率洞察

3. 建立機制

透過建立機制 形成長效收斂的質量閉環，其實我們最初的想法很簡單就是想辦法透過自動化 QA 同學的工作流，讓質量同學能空出手來做更有長期作用的質量工程建設。過程中逐漸沉澱了一個個機制，透過高度自動化，提升效能。
在質量體系建設初期做好機制閉環，帶來的長期收益是非常可觀的，推薦優先切入建設。

3.1. 周迭代值班

迭代有序化，有點像專案經理，在語雀日常迭代管理、釋出執行都歸 QA 同學。
兩個 QA 同學輪流按周迭代值班，保障釋出質量，做好 UIA 迴歸卡點、釋出執行和 hotfix 覆盤。

最初我們的釋出節奏是 一週兩次，頻繁的釋出使得釋出質量不可控，產生較多 hotfix，所以在保證足夠敏捷的同時，我們將服務端釋出節奏控制在一週一發。可能對很多業務團隊來說，一週一發也是很高的頻率了，大部分產品的迭代週期一般都是半個月或一個月釋出。

但是，如何在高頻釋出下保障交付質量？關鍵還是需要持續整合能力和自動化能力，相信透過後續的介紹，會有答案。

3.2. 缺陷收斂

線下缺陷播報

相信大家都有看到過，在缺陷池裡擺爛的缺陷吧，（大多是一些重要不緊急的缺陷，推不動解決）是不是很揪心，有強迫症的同學們可能會受不了。

其實通知類的功能不難實現，語雀做的其實相當於做好 “快遞的最後 1 公里”，將缺陷管理平臺中的缺陷統計分析後自動化播報到研發群中（其實是對缺陷管理平臺能力的擴充套件）。

我們建立了日報 / 週報 機制，有效促進收斂，清理缺陷歷史債， 最終保持人均一個。慢慢形成了團隊內的習慣和心智: “缺陷進池，一定會被解決。” 做到有始有終，從惡性迴圈變成良性迴圈。

線上日誌缺陷治理

缺陷的另一個重要來源: 線上異常和缺陷
針對這部分缺陷，我們透過不間斷獲取、分析線上日誌的方式，及時發現線上發生的缺陷，並自動化錄入到對應的缺陷管理專案中，我們對日誌內容進行規則自動分析並按照主站、移動端、桌面端歸一分類指派給對應的負責人修復，整體效率和資訊及時性在潛移默化中得到很大提升。

3.3. 覆蓋率治理

增量覆蓋率 PR 合併卡點

增量覆蓋率卡點的意義，相信不用多說。當新程式碼無單測合入就會導致整體覆蓋率越來越低，會加劇程式碼腐化。
因此，我們在 PR 環節加入了增量程式碼檢測能力，為評審人和開發同學提供直觀的覆蓋率報告，同時也希望能激勵大家能夠及時補充單測用例；（也是擴充套件了程式碼管理平臺的能力）

實現分析: 每次單元測試執行後生成的覆蓋率資訊和 PR 的 diff 資訊透過計算獲取增量的覆蓋率資訊，最後透過macaca-istanbul工具 生成覆蓋率報告（支援顏色渲染和縮圖）。

全量覆蓋率 - 專案覆蓋率治理

語雀團隊很注重測試覆蓋率，一直以來保持在比較高的覆蓋率水平，專案覆蓋率的跟蹤這塊原來也都有，但是年久失修一些專案的覆蓋率資料沒有及時更新和維護。
我們透過蒐集、合併分散在各 CI 任務中的專案覆蓋率資料，然後每週透過釘釘進行覆蓋率播報，有效恢復了各專案的覆蓋率跟蹤，實現了覆蓋率的長期統計跟蹤機制。

實現分析: 收集 CI 中執行的單測任務覆蓋率資訊 -> 測試結束時合併相應的覆蓋率資料上傳到 Reliable，並按周進行覆蓋率資料的播報。

3.4. 線上不可用治理

先說說為什麼做這個事，過去，語雀會有遇到因為低版本或不支援的瀏覽器造成的線上不可用問題，經常也會收到使用者類似的反饋，很影響使用者體驗。web 應用其實都會有類似的問題，從根本上杜絕是我們的目標。

我們針對低版本核心不相容、白屏的死角問題，進行監控和不支援引導。同時建設了瀏覽器版本分佈情況的準確的感知能力。我們的目標是做到三個一定：

1. 一定沒有不明確的瀏覽器版本
2. 明確的瀏覽器版本一定可用
3. 主流的瀏覽器一定支援自動化迴歸

3.5. CI 問題跟蹤

語雀日常 CI 任務經常因為一些問題不透過，非常影響研發效率。其中有工具的問題、有用例本身設計不穩定（比如缺少 mock、時序呼叫錯亂、斷言粒度不合理等）。
為了促進大家日常及時解決不穩定問題，及時通知反饋問題的指派人，我們實現了 CI 問題的自動化跟蹤機制。

• 自動化發現問題（日誌、缺陷池、覆蓋率資料、CI 報錯等等）
• 自動化指派跟蹤 （專案缺陷管理平臺）
• 及時訊息通知（釘釘機器人）

透過高度的自動化，使收斂變得自然，研發變得高效。

4. 持續交付

沒有持續整合的時候是怎樣的:
開發合併了 PR 之後，需要人工及時部署更新，然後反饋給開發同學，讓開發同學去驗證，雖然只是些點選和通知操作，但環節之間都是割裂的需要人工執行，打斷工作節奏不說，費心費力。並且自動化的功能性整合測試也是缺失的。

為了解決這些問題，我們重點建設了穩健的 CICD，從程式碼合併開始，到後面的部署、自動化測試迴歸一氣呵成，敏捷理念中的持續整合是實際在做的，讓持續測試成為了我們的基本規約。

4.1. 主站點

透過日常迭代分支的 PR 合併，觸發對應的 CI 流水線任務，完成持續部署和持續測試。
會有詳盡的通知，比如直接給到迭代驗證地址連結，直接能看到已部署的 PR 資訊，看到持續測試的報告連結等等，儘可能為研發同學帶來便利，提升研發體驗和效率。

4.2. 桌面端 CICD

不僅僅是主站，我們桌面端和移動端的開發同學也能享受到尊貴的 CICD 服務。
桌面端實際上是一款桌面應用客戶端軟體，桌面端的持續測試和持續部署是透過辦公網的一臺 macmini 實現測試迴歸環境，在構建平臺觸發構建後會非同步通知 macmini 進行自動化整合測試和報告的傳送。

• 桌面端

4.3. 移動端 CICD

移動端的持續整合透過構建平臺打包後 使用 螞蟻雲測平臺（提供移動端真機測試服務）觸發執行 UI 自動化測試任務，在執行完畢之後也會傳送相關報告到釘釘群中。

4.4. CI 提效

CI 慢、不穩定的問題一直以來是語雀團隊的痛點問題，極其影響研發效率。
我們從各個細節最佳化了整體 ci 的效率和穩定性。

• 透過 Docker 技術做映象級別的快取，解決 clone 環節慢，git 拉取不穩定的問題。
• 透過 自研 job_keeper 工具實現不穩定任務自動重試。
• 透過 shell 指令碼異常捕獲和處理，提升指令碼穩定性。
• 透過 拆分 CI 任務，降低整體耗時峰值。

從各個細節最佳化，使 CI 縮短了執行時間，提高了成功率, 減少了人工重試負擔。
最佳化後，正常 15 分鐘以內可以完成一輪全量回歸。

完善的 CICD 能力，使得在語雀做研發是一件很幸福的事。極大提升了研發同學們的工作體驗和效率。

5. UI 自動化技術

測試金字塔: 相信有同學見過，這種下寬上窄的三角形結構，代表在各層自動化的建議投入分配比例。
語雀的單測是開發同學們自己負責的，QA 同學負責 UI 自動化測試部分的測試。在我加入語雀之前，語雀在 UIA 領域就有比較多的實踐，UI 自動化是我們一直堅持的質量保障手段。

相信也有很多質量團隊嘗試過 UI 自動化，但很少能有堅持持續做的，原因有很多，比如下面的一些因素:

• UIA 的實踐曲線很陡，技術門檻比較高，在技術選型和工程化實踐階段就放棄了。
• 需要有一定的用例量和成熟的工程實踐，才能發揮效果，短期 ROI 很低，團隊沒有持續投入的動力。
• 用例的維護成本高，UI 一旦發生較大變化，就需要更新用例，如果實踐經驗不足會導致不可持續。

其實語雀質量作為 “過來人”，也是遇到過同樣的困難，語雀的 UIA 成功和團隊前期摸索的持續投入有很大的關係。

• 自動化發現的問題

目前進入了收益期，透過 UIA 目前已發現的關鍵問題已達到 70+，相當於避免了多次 hotfix，有效避免了大量線上缺陷的發生。
UIA 的一些優勢:

• 自動化測試可以代替大量的手工機械重複性操作，可以省下大量時間專注於設計測試用例。
• 研發提效自動化測試可以大幅度提升迴歸測試的效率，非常適合敏捷開發。
• 支撐穩定性測試和巡檢 使得 7*24 小時核心功能穩定性測試、自動巡檢成為可能。

5.1. Macaca 套件

Macaca 是一套面向使用者端軟體的測試解決方案，提供了自動化驅動，環境配套，周邊工具，整合方案，旨在解決終端上的測試、自動化、效能等方面的問題。
我們的自動化能力就是基於 Macaca 擴充套件實現的。

Macaca 是設計典型的 C/S 架構，提供了標準化的驅動層，消除了各技術平臺測試技術棧的差異。使用者側的 API 設計只需要遵從 W3C webdriver 標準 就可以輕鬆實現多技術棧接入，驅動各類瀏覽器/裝置的自動化測試執行。

5.2. 多瀏覽器

我們的 UIA 覆蓋了 Web 端 Chrome/Firefox/Safari/Edge 多種主流瀏覽器，全量 UIA 迴歸任務基本能夠在 30 分鐘內完成
積累用例總數 2k+ 500 餘條用例涵蓋了已有業務核心鏈路和功能，自動化率達到了 51%
多端迴歸我們是透過封裝 macaca-playwright 驅動實現的，playwright 是微軟開源的驅動框架，提供了比較全面、強大的 web UI 測試能力。

樣例報告，過程中提供影片回放，每個細節都可以回溯:

5.3. 桌面端 UIA

透過研究和實踐系統自動化能力，將系統操作能力封裝為 macaca-macos 驅動。
使我們的自動化技術從基於瀏覽器跨度到基於作業系統層面，實現了桌面端 UIA 技術框架升級。
結合自研的 AppTester 桌面端應用測試框架，支撐了語雀桌面端的 UI 自動化測試。

桌面端

5.4. 移動端 UIA

移動端的 UIA，我們採用了 內部雲測平臺 (提供真機測試服務) 的方案，搭配我們自研的 macaca app inspector（元素拾取工具）、 Macaca Reporter 測試報告 和 Reliable 報告持久化服務，實現了完整的移動端自動化測試方案。



樣例報告:

5.5. UIA 白屏巡檢

UI 自動化的另一個應用場景就是巡檢。監測線上出現導致不可用的穩定性故障，及早發現，及時告警、止損
當然我們運維同學也是配了很多監控報警的，線上的白屏巡檢是一種補充保障手段。
實現原理:
透過對線上靜態頁面和預期頁面進行畫素級對比，發現線上頁面有較大出入時，及時告警。
目前每 10 分鐘會不間斷執行一次，實現 10 分鐘內的白屏發現和告警。

• web 端巡檢

• 移動端的巡檢 > 移動端也有完備的巡檢: > 我們透過雲測平臺設定定時計劃實現，目前日常巡檢是 iOS 和 Android 端每間隔 4 小時輪換執行一次，每次執行時隨機選取一臺空閒裝置來執行全量的測試用例

5.6. 錄製器

隨著 UIA 用例數量的增加，用例維護成本成為不可忽略的負擔。我們嘗試透過 UI 錄製器減輕維護工作。
團隊自研的 macaca-recorder 工具基於外掛化設計，透過錄制的方式生成測試指令碼。一個關鍵特點是支援模板開發，可以定製化錄製所需的 UIA 指令碼，這樣無論封裝或者使用什麼樣的測試框架，都可以靈活支援。

• 支援 語雀 Web 端 UI 指令碼錄製

6. 總結

6.1. 質量 3.0

透過這樣的一個個方案的切實落地，實踐之前提到的"教練模式"。實現了業務質量和質量工程齊頭並進，讓語雀的質量邁入了一個新的臺階, 這裡可以用一個工業革命的比喻讓大家更好地理解。
從刀耕火種的農耕社會 -> 初步探索工業化 -> 全面工業化（質量 3.0）

6.2. 結語

至此語雀的質量體系和自動化能力介紹完了。這是兩位 QA 同學會能和確知的語雀數字花園，歡迎一起交流，互相學習。

確知：https://www.yuque.com/jodeee
會能：https://www.yuque.com/huineng

還沒有使用過語雀的朋友，也歡迎嘗試使用我們的產品。

轉發自原文連結：https://www.yuque.com/antfe/featured/ogh09airm80p1igb