??1. 整體介紹

大家好，我是語雀 QA 會能。

很高興，有機(jī)會跟大家聊一下語雀的質(zhì)量體系和自動化技術(shù)。

下面會分幾個部分給大家介紹，讓大家可以了解到語雀質(zhì)量體系的全貌。

1.1. 語雀產(chǎn)品特點(diǎn)&研發(fā)特點(diǎn)

首先，簡單分析一下語雀，相信很多朋友對語雀都是不陌生的?！刚Z雀」是螞蟻集團(tuán)旗下的文檔與知識庫工具，源自螞蟻集團(tuán)和阿里巴巴內(nèi)部文檔協(xié)同需求，2018 年 1 月 8 日正式對外提供服務(wù)，現(xiàn)已服務(wù)于數(shù)十萬企業(yè)組織和數(shù)百萬個人用戶。

再從研發(fā)角度看，語雀是一個大型?全棧 多端?應(yīng)用，包括了web端、移動端、桌面端。語雀的研發(fā)基于?One CodeBase?模式 （類似google的項(xiàng)目研發(fā)，所有相關(guān)工程都在一個大的git倉庫）。另外還依賴研發(fā)管控、任務(wù)跟蹤、代碼服務(wù)、構(gòu)建流水線等平臺。語雀的迭代發(fā)布比較快，在工程上，技術(shù)團(tuán)隊(duì)對持續(xù)交付的穩(wěn)定性和效率有著很高的要求。

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

1.2. 語雀技術(shù)的：教練模式

我們的解法是“教練模式”。

什么是教練模式? 簡單的說 QA 同學(xué)就相當(dāng)于教練，通過各種質(zhì)量保障機(jī)制規(guī)范和提升開發(fā)同學(xué)的質(zhì)量意識，提供完備的質(zhì)量服務(wù)提升研發(fā)效能，從而提升語雀產(chǎn)品的質(zhì)量。

另外，我們希望通過工程化的方式使質(zhì)量成果可沉淀，可長期持續(xù)，這也是語雀質(zhì)量技術(shù)從起步到發(fā)展的的初衷。

1.3. 質(zhì)量架構(gòu)

再來看看我們的質(zhì)量工程的頂層架構(gòu)，框圖中最底層是我們依賴的基礎(chǔ)平臺(例如研發(fā)管控、任務(wù)跟蹤、代碼服務(wù)、構(gòu)建流水線平臺等) 。

再是質(zhì)量基建，服務(wù)于語雀質(zhì)量的各種能力，包括語雀質(zhì)量的技術(shù)基礎(chǔ) 和 “看不見質(zhì)量”，偏軟性但又極其重要的，質(zhì)量意識和工程文化。

技術(shù)基礎(chǔ)像 skytest 支撐工具、Lark-Reliable 測試報(bào)告和覆蓋率持久化查看、Macaca 套件提供了 UIA 技術(shù)支持，在后面的會有詳細(xì)的介紹。

質(zhì)量能力，就是語雀實(shí)際解決的問題和質(zhì)量成果了，相關(guān)領(lǐng)域包括持續(xù)集成、缺陷收斂、線上巡檢、UI 自動化建設(shè)，長效機(jī)制建設(shè)和研發(fā)提效，后面也會詳細(xì)介紹。

??2. 質(zhì)量支撐工具

每個質(zhì)量團(tuán)隊(duì)或多或少都會有質(zhì)量支撐工具或服務(wù)，以解決團(tuán)隊(duì)內(nèi)的質(zhì)量問題，接下來介紹 SkyTest 和 Reliable。

2.1. SkyTest

大多質(zhì)量團(tuán)隊(duì)都會有一些核心的測試支撐工具，我見過比較多的是 web 服務(wù)的形式提供的，比如 xx 測試服務(wù)，xx 測試平臺，這就要求團(tuán)隊(duì)內(nèi)需要有全棧開發(fā)的同學(xué)，并且對這樣服務(wù)的開發(fā)維護(hù)投入還是比較大的。

SkyTest 就是語雀的主要質(zhì)量支撐工具，它承載了語雀質(zhì)量技術(shù)沉淀，就好比 QA 同學(xué)的 “百寶箱”，里面有各式各樣趁手的測試工具，為語雀質(zhì)量能力建設(shè)奠定了技術(shù)基礎(chǔ)。

SkyTest 以 npm 工具模塊的形式存在，可以直接通過 cli 的方式使用，或者以 node 模塊集成，集成便捷，比較輕量，適合 QA 工具的研發(fā)。維護(hù)成本相對 web 應(yīng)用要輕量很多。

2.2. Reliable

LarkReliable 作為質(zhì)量數(shù)據(jù)持久化&洞察服務(wù)，和 SkyTest 搭配，能夠滿足大部分測試能力的實(shí)現(xiàn)。目前在語雀除了集團(tuán)內(nèi)其他平臺提供的專項(xiàng)能力外，團(tuán)隊(duì)內(nèi)的質(zhì)量能力實(shí)現(xiàn)都是能夠 Hold 住的。

基于開源的 Macaca Reliable 套件實(shí)現(xiàn)，如果所在團(tuán)隊(duì)正好缺少類似的工具服務(wù)，完全可以基于開源的Relibale套件，快速實(shí)現(xiàn)團(tuán)隊(duì)內(nèi)的測試報(bào)告持久化和數(shù)據(jù)洞察的服務(wù)能力。

• 測試、覆蓋率報(bào)告查看

• 覆蓋率洞察

??3. 建立機(jī)制

通過建立機(jī)制 形成長效收斂的質(zhì)量閉環(huán)，其實(shí)我們最初的想法很簡單就是想辦法通過自動化 QA 同學(xué)的工作流，讓質(zhì)量同學(xué)能空出手來做更有長期作用的質(zhì)量工程建設(shè)。過程中逐漸沉淀了一個個機(jī)制，通過高度自動化，提升效能。

在質(zhì)量體系建設(shè)初期做好機(jī)制閉環(huán)，帶來的長期收益是非常可觀的，推薦優(yōu)先切入建設(shè)。

3.1. 周迭代值班

迭代有序化，有點(diǎn)像項(xiàng)目經(jīng)理，在語雀日常迭代管理、發(fā)布執(zhí)行都?xì)w QA 同學(xué)。兩個 QA 同學(xué)輪流按周迭代值班，保障發(fā)布質(zhì)量，做好 UIA 回歸卡點(diǎn)、發(fā)布執(zhí)行和 hotfix 復(fù)盤。

最初我們的發(fā)布節(jié)奏是 一周兩次，頻繁的發(fā)布使得發(fā)布質(zhì)量不可控，產(chǎn)生較多 hotfix，所以在保證足夠敏捷的同時，我們將服務(wù)端發(fā)布節(jié)奏控制在一周一發(fā)?？赡軐芏鄻I(yè)務(wù)團(tuán)隊(duì)來說，一周一發(fā)也是很高的頻率了，大部分產(chǎn)品的迭代周期一般都是半個月或一個月發(fā)布。

但是，如何在高頻發(fā)布下保障交付質(zhì)量？關(guān)鍵還是需要持續(xù)集成能力和自動化能力，相信通過后續(xù)的介紹，會有答案。

3.2. 缺陷收斂

線下缺陷播報(bào)

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

其實(shí)通知類的功能不難實(shí)現(xiàn)，語雀做的其實(shí)相當(dāng)于做好“快遞的最后1公里”，將缺陷管理平臺中的缺陷統(tǒng)計(jì)分析后自動化播報(bào)到研發(fā)群中（其實(shí)是對缺陷管理平臺能力的擴(kuò)展）。

我們建立了日報(bào) / 周報(bào) 機(jī)制，有效促進(jìn)收斂，清理缺陷歷史債， 最終保持人均一個。慢慢形成了團(tuán)隊(duì)內(nèi)的習(xí)慣和心智: “缺陷進(jìn)池，一定會被解決?！?做到有始有終，從惡性循環(huán)變成良性循環(huán)。

線上日志缺陷治理

缺陷的另一個重要來源: 線上異常和缺陷?

針對這部分缺陷，我們通過不間斷獲取、分析線上日志的方式，及時發(fā)現(xiàn)線上發(fā)生的缺陷，并自動化錄入到對應(yīng)的缺陷管理項(xiàng)目中，我們對日志內(nèi)容進(jìn)行規(guī)則自動分析并按照主站、移動端、桌面端歸一分類指派給對應(yīng)的負(fù)責(zé)人修復(fù)，整體效率和信息及時性在潛移默化中得到很大提升。

3.3. 覆蓋率治理

增量覆蓋率 PR 合并卡點(diǎn)

增量覆蓋率卡點(diǎn)的意義，相信不用多說。當(dāng)新代碼無單測合入就會導(dǎo)致整體覆蓋率越來越低，會加劇代碼腐化。因此，我們在 PR 環(huán)節(jié)加入了增量代碼檢測能力，為評審人和開發(fā)同學(xué)提供直觀的覆蓋率報(bào)告，同時也希望能激勵大家能夠及時補(bǔ)充單測用例；（也是擴(kuò)展了代碼管理平臺的能力）

實(shí)現(xiàn)分析: 每次單元測試執(zhí)行后生成的覆蓋率信息和 PR 的 diff 信息通過計(jì)算獲取增量的覆蓋率信息，最后通過macaca-istanbul工具 生成覆蓋率報(bào)告 （支持顏色渲染和縮略圖）。

全量覆蓋率-項(xiàng)目覆蓋率治理

語雀團(tuán)隊(duì)很注重測試覆蓋率，一直以來保持在比較高的覆蓋率水平，項(xiàng)目覆蓋率的跟蹤這塊原來也都有，但是年久失修一些項(xiàng)目的覆蓋率數(shù)據(jù)沒有及時更新和維護(hù)。

我們通過搜集、合并分散在各 CI 任務(wù)中的項(xiàng)目覆蓋率數(shù)據(jù)，然后每周通過釘釘進(jìn)行覆蓋率播報(bào)，有效恢復(fù)了各項(xiàng)目的覆蓋率跟蹤，實(shí)現(xiàn)了覆蓋率的長期統(tǒng)計(jì)跟蹤機(jī)制。

實(shí)現(xiàn)分析: 收集 CI 中運(yùn)行的單測任務(wù)覆蓋率信息 -> 測試結(jié)束時合并相應(yīng)的覆蓋率數(shù)據(jù)上傳到 Reliable，并按周進(jìn)行覆蓋率數(shù)據(jù)的播報(bào)。

3.4. 線上不可用治理

先說說為什么做這個事，過去，語雀會有遇到因?yàn)榈桶姹净虿恢С值臑g覽器造成的線上不可用問題，經(jīng)常也會收到用戶類似的反饋，很影響用戶體驗(yàn)。web 應(yīng)用其實(shí)都會有類似的問題，從根本上杜絕是我們的目標(biāo)。

我們針對低版本內(nèi)核不兼容、白屏的死角問題，進(jìn)行監(jiān)控和不支持引導(dǎo)。同時建設(shè)了瀏覽器版本分布情況的準(zhǔn)確的感知能力。我們的目標(biāo)是做到三個一定：

1. 一定沒有不明確的瀏覽器版本

2. 明確的瀏覽器版本一定可用

3. 主流的瀏覽器一定支持自動化回歸

3.5. CI 問題跟蹤

語雀日常 CI 任務(wù)經(jīng)常因?yàn)橐恍﹩栴}不通過，非常影響研發(fā)效率。其中有工具的問題、有用例本身設(shè)計(jì)不穩(wěn)定（比如缺少 mock、時序調(diào)用錯亂、斷言粒度不合理等）。

為了促進(jìn)大家日常及時解決不穩(wěn)定問題，及時通知反饋問題的指派人，我們實(shí)現(xiàn)了 CI 問題的自動化跟蹤機(jī)制。

• 自動化發(fā)現(xiàn)問題（日志、缺陷池、覆蓋率數(shù)據(jù)、CI報(bào)錯等等）

• 自動化指派跟蹤（項(xiàng)目缺陷管理平臺）

• 及時消息通知（釘釘機(jī)器人）

通過高度的自動化，使收斂變得自然，研發(fā)變得高效。

??4. 持續(xù)交付

沒有持續(xù)集成的時候是怎樣的:?

開發(fā)合并了 PR 之后，需要人工及時部署更新，然后反饋給開發(fā)同學(xué)，讓開發(fā)同學(xué)去驗(yàn)證，雖然只是些點(diǎn)擊和通知操作，但環(huán)節(jié)之間都是割裂的需要人工執(zhí)行，打斷工作節(jié)奏不說，費(fèi)心費(fèi)力。并且自動化的功能性集成測試也是缺失的。

為了解決這些問題，我們重點(diǎn)建設(shè)了穩(wěn)健的 CICD，從代碼合并開始，到后面的部署、自動化測試回歸一氣呵成，敏捷理念中的持續(xù)集成是實(shí)際在做的，讓持續(xù)測試成為了我們的基本規(guī)約。

4.1. 主站點(diǎn)

通過日常迭代分支的 PR 合并，觸發(fā)對應(yīng)的 CI 流水線任務(wù)，完成持續(xù)部署和持續(xù)測試。

會有詳盡的通知，比如直接給到迭代驗(yàn)證地址鏈接，直接能看到已部署的 PR 信息，看到持續(xù)測試的報(bào)告鏈接等等，盡可能為研發(fā)同學(xué)帶來便利，提升研發(fā)體驗(yàn)和效率。

4.2. 桌面端 CICD

不僅僅是主站，我們桌面端和移動端的開發(fā)同學(xué)也能享受到尊貴的 CICD 服務(wù)。

桌面端實(shí)際上是一款桌面應(yīng)用客戶端軟件，桌面端的持續(xù)測試和持續(xù)部署是通過辦公網(wǎng)的一臺 macmini 實(shí)現(xiàn)測試回歸環(huán)境，在構(gòu)建平臺觸發(fā)構(gòu)建后會異步通知 macmini 進(jìn)行自動化集成測試和報(bào)告的發(fā)送。

• 桌面端

4.3. 移動端CICD

移動端的持續(xù)集成通過構(gòu)建平臺打包后 使用 螞蟻云測平臺（提供移動端真機(jī)測試服務(wù)） 觸發(fā)執(zhí)行UI自動化測試任務(wù)，在執(zhí)行完畢之后也會發(fā)送相關(guān)報(bào)告到釘釘群中。

4.4. CI 提效

CI 慢、不穩(wěn)定的問題一直以來是語雀團(tuán)隊(duì)的痛點(diǎn)問題，極其影響研發(fā)效率。我們從各個細(xì)節(jié)優(yōu)化了整體ci的效率和穩(wěn)定性。

• 通過 Docker 技術(shù)做鏡像級別的緩存，解決clone環(huán)節(jié)慢，git拉取不穩(wěn)定的問題。

• 通過 自研 job_keeper 工具實(shí)現(xiàn)不穩(wěn)定任務(wù)自動重試。

• 通過 shell 腳本異常捕獲和處理，提升腳本穩(wěn)定性。

• 通過 拆分 CI 任務(wù)，降低整體耗時峰值。

從各個細(xì)節(jié)優(yōu)化，使 CI 縮短了執(zhí)行時間，提高了成功率, ?減少了人工重試負(fù)擔(dān)。

優(yōu)化后，正常 15 分鐘以內(nèi)可以完成一輪全量回歸。

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

??5. UI 自動化技術(shù)

測試金字塔: 相信有同學(xué)見過，這種下寬上窄的三角形結(jié)構(gòu)，代表在各層自動化的建議投入分配比例。

語雀的單測是開發(fā)同學(xué)們自己負(fù)責(zé)的，QA 同學(xué)負(fù)責(zé) UI 自動化測試部分的測試。在我加入語雀之前，語雀在 UIA 領(lǐng)域就有比較多的實(shí)踐，UI 自動化是我們一直堅(jiān)持的質(zhì)量保障手段。

相信也有很多質(zhì)量團(tuán)隊(duì)嘗試過 UI 自動化，但很少能有堅(jiān)持持續(xù)做的，原因有很多，比如下面的一些因素:

• UIA 的實(shí)踐曲線很陡，技術(shù)門檻比較高，在技術(shù)選型和工程化實(shí)踐階段就放棄了。

• 需要有一定的用例量和成熟的工程實(shí)踐，才能發(fā)揮效果，短期 ROI 很低，團(tuán)隊(duì)沒有持續(xù)投入的動力。

• 用例的維護(hù)成本高，UI 一旦發(fā)生較大變化，就需要更新用例，如果實(shí)踐經(jīng)驗(yàn)不足會導(dǎo)致不可持續(xù)。

其實(shí)語雀質(zhì)量作為“過來人”，也是遇到過同樣的困難，語雀的 UIA 成功和團(tuán)隊(duì)前期摸索的持續(xù)投入有很大的關(guān)系。

• 自動化發(fā)現(xiàn)的問題

目前進(jìn)入了收益期，通過 UIA 目前已發(fā)現(xiàn)的關(guān)鍵問題已達(dá)到 70+，相當(dāng)于避免了多次 hotfix，有效避免了大量線上缺陷的發(fā)生。

UIA 的一些優(yōu)勢:

• 自動化測試可以代替大量的手工機(jī)械重復(fù)性操作，可以省下大量時間專注于設(shè)計(jì)測試用例。

• 研發(fā)提效自動化測試可以大幅度提升回歸測試的效率，非常適合敏捷開發(fā)。

• 支撐穩(wěn)定性測試和巡檢 使得 7*24 小時核心功能穩(wěn)定性測試、自動巡檢成為可能。

5.1. Macaca 套件

Macaca 是一套面向用戶端軟件的測試解決方案，提供了自動化驅(qū)動，環(huán)境配套，周邊工具，集成方案，旨在解決終端上的測試、自動化、性能等方面的問題。

我們的自動化能力就是基于 Macaca 擴(kuò)展實(shí)現(xiàn)的。

Macaca 是設(shè)計(jì)典型的 C/S 架構(gòu)，提供了標(biāo)準(zhǔn)化的驅(qū)動層，消除了各技術(shù)平臺測試技術(shù)棧的差異。用戶側(cè)的 API 設(shè)計(jì)只需要遵從 W3C webdriver 標(biāo)準(zhǔn) 就可以輕松實(shí)現(xiàn)多技術(shù)棧接入，驅(qū)動各類瀏覽器/設(shè)備的自動化測試執(zhí)行。

5.2. 多瀏覽器

我們的 UIA 覆蓋了 Web 端 Chrome/Firefox/Safari/Edge 多種主流瀏覽器，全量 UIA 回歸任務(wù)基本能夠在 30 分鐘內(nèi)完成?

積累用例總數(shù) 2k+ ?500 余條用例涵蓋了已有業(yè)務(wù)核心鏈路和功能，自動化率達(dá)到了 51%?

多端回歸我們是通過封裝?macaca-playwright?驅(qū)動實(shí)現(xiàn)的，playwright ?是微軟開源的驅(qū)動框架，提供了比較全面、強(qiáng)大的 web UI 測試能力。

樣例報(bào)告，過程中提供視頻回放，每個細(xì)節(jié)都可以回溯:

5.3. 桌面端 UIA

通過研究和實(shí)踐系統(tǒng)自動化能力，將系統(tǒng)操作能力封裝為?macaca-macos?驅(qū)動。

使我們的自動化技術(shù)從基于瀏覽器跨度到基于操作系統(tǒng)層面，實(shí)現(xiàn)了桌面端 UIA 技術(shù)框架升級。

結(jié)合自研的?AppTester?桌面端應(yīng)用測試框架，支撐了語雀桌面端的 UI 自動化測試。

桌面端 UIA

5.4. 移動端 UIA

移動端的 UIA，我們采用了 內(nèi)部云測平臺(提供真機(jī)測試服務(wù)) 的方案，搭配我們自研的 macaca app inspector （元素拾取工具）、 Macaca Reporter 測試報(bào)告 和 Reliable 報(bào)告持久化服務(wù)，實(shí)現(xiàn)了完整的移動端自動化測試方案。

樣例報(bào)告:

5.5. UIA 白屏巡檢

UI 自動化的另一個應(yīng)用場景就是巡檢。監(jiān)測線上出現(xiàn)導(dǎo)致不可用的穩(wěn)定性故障，及早發(fā)現(xiàn)，及時告警、止損 當(dāng)然我們運(yùn)維同學(xué)也是配了很多監(jiān)控報(bào)警的，線上的白屏巡檢是一種補(bǔ)充保障手段。

實(shí)現(xiàn)原理:?

通過對線上靜態(tài)頁面和預(yù)期頁面進(jìn)行像素級對比，發(fā)現(xiàn)線上頁面有較大出入時，及時告警。

目前每 10 分鐘會不間斷執(zhí)行一次，實(shí)現(xiàn) 10 分鐘內(nèi)的白屏發(fā)現(xiàn)和告警。

• web端巡

• 移動端的巡檢

移動端也有完備的巡檢:?

我們通過云測平臺設(shè)置定時計(jì)劃實(shí)現(xiàn)，目前日常巡檢是 iOS 和 Android 端每間隔 4 小時輪換執(zhí)行一次，每次執(zhí)行時隨機(jī)選取一臺空閑設(shè)備來執(zhí)行全量的測試用例

5.6. 錄制器

隨著 UIA 用例數(shù)量的增加，用例維護(hù)成本成為不可忽略的負(fù)擔(dān)。我們嘗試通過 UI 錄制器減輕維護(hù)工作。

團(tuán)隊(duì)自研的 macaca-recorder 工具基于插件化設(shè)計(jì)，通過錄制的方式生成測試腳本。一個關(guān)鍵特點(diǎn)是支持模板開發(fā)，可以定制化錄制所需的 UIA 腳本，這樣無論封裝或者使用什么樣的測試框架，都可以靈活支持。

github地址：https://github.com/macacajs/macaca-recorder

• 支持 語雀 Web 端 UI 腳本錄制

6. 總結(jié)

6.1. 質(zhì)量 3.0

通過這樣的一個個方案的切實(shí)落地，實(shí)踐之前提到的"教練模式"。實(shí)現(xiàn)了業(yè)務(wù)質(zhì)量和質(zhì)量工程齊頭并進(jìn)，讓語雀的質(zhì)量邁入了一個新的臺階, ? 這里可以用一個工業(yè)革命的比喻讓大家更好地理解。

從刀耕火種的農(nóng)耕社會 -> 初步探索工業(yè)化 -> 全面工業(yè)化（質(zhì)量 3.0）

6.2. 結(jié)語

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

確知：https://www.yuque.com/jodeee

會能：https://www.yuque.com/huineng

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