前言

最近一年多一直在做前端的一些測試策治，從小程序到店鋪裝修，基本都是純前端的工作颤殴，剛開始從后端測試轉(zhuǎn)為前端測試的時(shí)候，對前端東西茫然無感鼻忠，而且團(tuán)隊(duì)內(nèi)沒有人做過純前端的測試工作涵但，只能一邊踩坑一邊總結(jié)經(jīng)驗(yàn)，然后將容易出現(xiàn)問題的點(diǎn)形成體系帖蔓、不斷總結(jié)摸索矮瘟，最終形成了目前的一套前端測試解決方案。在此塑娇，將有贊的前端質(zhì)量保障體系進(jìn)行總結(jié)澈侠，希望和大家一起交流。

先來全局看下有贊前端的技術(shù)架構(gòu)和針對每個(gè)不同的層次埋酬，主要做了哪些保障質(zhì)量的事情：

有贊的 Node 技術(shù)架構(gòu)分為業(yè)務(wù)層哨啃、基礎(chǔ)框架層烧栋、通用組件和基礎(chǔ)服務(wù)層，我們?nèi)粘１容^關(guān)注的是基礎(chǔ)框架拳球、通用組件和業(yè)務(wù)層代碼审姓。Node 業(yè)務(wù)層做了兩件事情，一是提供頁面渲染的 client 層祝峻，用于和 C 端用戶交互魔吐，包括樣式、行為 js 等莱找；二是提供數(shù)據(jù)服務(wù)的 server 層酬姆，用于組裝后臺提供的各種接口，完成面向 C 端的接口封裝宋距。

對于每個(gè)不同的層轴踱，我們都做了一些事情來保障質(zhì)量，包括：

• 針對整個(gè)業(yè)務(wù)層的 UI 自動化谚赎、核心接口|頁面撥測淫僻；
• 針對 client 層的 sentry 報(bào)警；
• 針對 server 層的接口測試壶唤、業(yè)務(wù)報(bào)警雳灵；
• 針對基礎(chǔ)框架和通用組件的單元測試；
• 針對通用組件變更的版本變更報(bào)警闸盔；
• 針對線上發(fā)布的流程規(guī)范悯辙、用例維護(hù)等。

下面就來分別講一下這幾個(gè)維度的質(zhì)量保障工作迎吵。

一躲撰、UI自動化

很多人會認(rèn)為，UI 自動化維護(hù)成本高击费、性價(jià)比低拢蛋，但是為什么在有贊的前端質(zhì)量保證體系中放在了最前面呢？

前端重用戶交互蔫巩，單純的接口測試谆棱、單元測試不能真實(shí)反映用戶的操作路徑，并且從以往的經(jīng)驗(yàn)中總結(jié)得出圆仔，因?yàn)楦鞣N不可控因素導(dǎo)致的發(fā)布 A 功能而 B 功能無法使用垃瞧，特別是核心簡單場景的不可用時(shí)有出現(xiàn)，所以每次發(fā)布一個(gè)應(yīng)用前坪郭，都會將此應(yīng)用提供的核心功能執(zhí)行一遍个从，那隨著業(yè)務(wù)的不斷積累，需要回歸的測試場景也越來越多歪沃，導(dǎo)致回歸的工作量巨大嗦锐。為了降低人力成本鸵隧，我們亟需通過自動化手段釋放勞動力，所以將核心流程回歸的 UI 自動化提到了最核心地位意推。

當(dāng)然，UI 自動化的最大痛點(diǎn)確實(shí)是維護(hù)成本珊蟀，為降低維護(hù)成本菊值，我們將頁面分為組件維度、頁面維度育灸，并提供統(tǒng)一的包來處理公用組件腻窒、特殊頁面的通用邏輯，封裝通用方法等磅崭，例如初始化瀏覽器信息儿子、環(huán)境選擇、登錄俺抽、多網(wǎng)點(diǎn)切換群叶、點(diǎn)擊壁肋、輸入、獲取元素內(nèi)容等等愉适，業(yè)務(wù)回歸用例只需要關(guān)注自己的用例操作步驟即可。

1.框架選擇

-- puppeteer^[1]癣漆，它是由 Chrome 維護(hù)的 Node 庫维咸，基于 DevTools 協(xié)議來驅(qū)動 chrome 或者 chromium 瀏覽器運(yùn)行，支持 headless 和 non-headless 兩種方式惠爽。官網(wǎng)提供了非常豐富的文檔癌蓖，簡單易學(xué)。

UI 自動化框架有很多種婚肆，包括 selenium租副、phantom；對比后發(fā)現(xiàn) puppeteer 比較輕量旬痹，只需要增加一個(gè) npm 包即可使用附井；它是基于事件驅(qū)動的方式，比 selenium 的等待輪詢更穩(wěn)當(dāng)两残、性能更佳永毅；另外，它是 chrome 原生支持人弓，能提供所有 chrome 支持的 api沼死，同時(shí)我們的業(yè)務(wù)場景只需要覆蓋 chrome，所以它是最好的選擇崔赌。

-- mocha^[2] + mochawesome^[3]意蛀，mocha 是比較主流的測試框架耸别，支持 beforeEach、before县钥、afterEach秀姐、after 等鉤子函數(shù)，assert 斷言若贮，測試套件省有，用例編排等。
mochawesome 是 mocha 測試框架的第三方插件谴麦，支持生成漂亮的 html/css 報(bào)告蠢沿。

js 測試框架同樣有很多可以選擇，mocha匾效、ava舷蟀、Jtest 等等，選擇 mocha 是因?yàn)樗`活面哼，很多配置可以結(jié)合第三方庫野宜，比如 report 就是結(jié)合了 mochawesome 來生成好看的 html 報(bào)告；斷言可以用 powser-assert 替代魔策。

2.腳本編寫

• 封裝基礎(chǔ)庫
  • 封裝 pc 端速缨、h5 端瀏覽器的初始化過程
  • 封裝 pc 端、h5 端登錄統(tǒng)一處理
  • 封裝頁面模型和組件模型
  • 封裝上傳組件代乃、日期組件旬牲、select 組件等的統(tǒng)一操作方法
  • 封裝 input、click搁吓、hover原茅、tap、scrollTo堕仔、hover擂橘、isElementShow、isElementExist摩骨、getElementVariable 等方法
  • 提供根據(jù) “html 標(biāo)簽>>頁面文字” 形式獲取頁面元素及操作方法的統(tǒng)一支持
  • 封裝 baseTest通贞，增加用例開始、結(jié)束后的統(tǒng)一操作
  • 封裝 assert恼五，增加斷言日志記錄
• 業(yè)務(wù)用例
  • 安裝基礎(chǔ)庫
  • 編排業(yè)務(wù)用例

3.執(zhí)行邏輯

• 分環(huán)境執(zhí)行
  • 增加預(yù)上線環(huán)境代碼變更觸發(fā)昌罩、線上環(huán)境自動執(zhí)行
• 監(jiān)控源碼變更
  • 增加 gitlab webhook，監(jiān)控開發(fā)源碼合并 master 時(shí)自動在預(yù)上線環(huán)境執(zhí)行
  • 增加 gitlab webhook灾馒，監(jiān)控測試用例變更時(shí)自動在生產(chǎn)環(huán)境執(zhí)行
• 每日定時(shí)執(zhí)行
  • 增加 crontab茎用，每日定時(shí)執(zhí)行線上環(huán)境

二、接口測試

接口測試主要針對于 Node 的 server 層，根據(jù)我們的開發(fā)規(guī)范轨功，Node 不做復(fù)雜的業(yè)務(wù)邏輯旭斥，但是需要將服務(wù)化應(yīng)用提供 dubbo 接口進(jìn)行一次轉(zhuǎn)換，或?qū)⒍鄠€(gè) dubbo 接口組合起來古涧，提供一個(gè)可供 h5/小程序渲染數(shù)據(jù)的 http 接口垂券，轉(zhuǎn)化過程就帶來了各種數(shù)據(jù)的獲取、組合羡滑、轉(zhuǎn)換圆米，形成了新的端到端接口。這個(gè)時(shí)候單單靠服務(wù)化接口的自動化已經(jīng)不能保障對上層接口的全覆蓋啄栓，所以我們針對 Node 接口也進(jìn)行自動化測試。為了使用測試內(nèi)部統(tǒng)一的測試框架也祠，我們通過 java 去請求 Node 提供的 http 接口昙楚，那么當(dāng)用例都寫好之后，該如何評判接口測試的質(zhì)量诈嘿？是否完全覆蓋了全部業(yè)務(wù)邏輯呢堪旧？此時(shí)就需要一個(gè)行之有效的方法來獲取到測試的覆蓋情況，以檢查有哪些場景是接口測試中未覆蓋的奖亚，做到更好的查漏補(bǔ)缺淳梦。

istanbul^[4] 是業(yè)界比較易用的 js 覆蓋率工具，它利用模塊加載的鉤子計(jì)算語句昔字、行爆袍、方法和分支覆蓋率，以便在執(zhí)行測試用例時(shí)透明的增加覆蓋率作郭。它支持所有類型的 js 覆蓋率陨囊，包括單元測試、服務(wù)端功能測試以及瀏覽器測試夹攒。

但是蜘醋，我們的接口用例寫在 Java 代碼中，通過 Http 請求的方式到達(dá) Node 服務(wù)器咏尝，非 js 單測压语，也非瀏覽器功能測試，如何才能獲取到 Node 接口的覆蓋率呢编检？

解決辦法是增加 cover 參數(shù)：--handle-sigint胎食，通過增加 --handle-sigint 參數(shù)啟動服務(wù)，當(dāng)服務(wù)接收到一個(gè) SIGINT 信號（linux 中 SIGINT 關(guān)聯(lián)了 Ctrl+C）允懂，會通知 istanbul 生成覆蓋率斥季。這個(gè)命令非常適合我們，并且因此形成了我們接口覆蓋率的一個(gè)模型：

1. istanbule --handle-sigint 啟動服務(wù)
2. 執(zhí)行測試用例
3. 發(fā)送 SIGINT結(jié)束istanbule，得到覆蓋率

最終酣倾，解決了我們的 Node 接口覆蓋率問題舵揭，并通過 jenkins 持續(xù)集成來自動構(gòu)建

當(dāng)然，在獲取覆蓋率的時(shí)候有需求文件是不需要統(tǒng)計(jì)的躁锡，可以通過在根路徑下增加 .istanbule.yml 文件的方式午绳，來排除或者指定需要統(tǒng)計(jì)覆蓋率的文件

verbose: false
instrumentation:
    root: .
    extensions:
        - .js
    default-excludes: true
    excludes:['**/common/**','**/app/constants/**','**/lib/**']
    embed-source: false
    variable: __coverage__
    compact: true
    preserve-comments: false
    complete-copy: false
    save-baseline: false
    baseline-file: ./coverage/coverage-baseline.json
    include-all-sources: false
    include-pid: false
    es-modules: false
reporting:
    print: summary
    reports:
        - lcov
    dir: ./coverage
    watermarks:
        statements: [50, 80]
        lines: [50, 80]
        functions: [50, 80]
        branches: [50, 80]
    report-config:
        clover: {file: clover.xml}
        cobertura: {file: cobertura-coverage.xml}
        json: {file: coverage-final.json}
        json-summary: {file: coverage-summary.json}
        lcovonly: {file: lcov.info}
        teamcity: {file: null, blockName: Code Coverage Summary}
        text: {file: null, maxCols: 0}
        text-lcov: {file: lcov.info}
        text-summary: {file: null}
hooks:
    hook-run-in-context: false
    post-require-hook: null
    handle-sigint: false
check:
    global:
        statements: 0
        lines: 0
        branches: 0
        functions: 0
        excludes: []
    each:
        statements: 0
        lines: 0
        branches: 0
        functions: 0
        excludes: []

三、單元測試

單元測試在測試分層中處于金字塔最底層的位置映之，單元測試做的比較到位的情況下拦焚，能過濾掉大部分的問題，并且提早發(fā)現(xiàn) bug杠输，也可以降低 bug 成本赎败。推行一段時(shí)間的單測后發(fā)現(xiàn)，在有贊的 Node 框架中蠢甲，業(yè)務(wù)層的 server 端只做接口組裝僵刮，client 端面向?yàn)g覽器，都不太適合做單元測試鹦牛，所以我們只針對基礎(chǔ)框架和通用組件進(jìn)行單測搞糕，保障基礎(chǔ)服務(wù)可以通過單測排除大部分的問題。比如基礎(chǔ)框架中店鋪通用信息服務(wù)曼追，單測檢查店鋪信息獲惹涎觥；比如頁面級商品組件礼殊，單測檢查商品組件渲染的 html 是否和原來一致驹吮。

單測方案試行了兩個(gè)框架：

• Jest^[5]
• ava^[6]

比較推薦的是 Jest 方案，它支持 Matchers 方式斷言晶伦；支持 Snapshot Testing钥屈，可測試組件類代碼渲染的 html 是否正確；支持多種 mock坝辫，包括 mock 方法實(shí)現(xiàn)篷就、mock 定時(shí)器、mock 依賴的 module 等近忙；支持 istanbule竭业，可以方便的獲取覆蓋率。

總之及舍，前端的單測方案也越來越成熟未辆，需要前端開發(fā)人員更加關(guān)注 js 單測，將 bug 扼殺在搖籃中锯玛。

四咐柜、基礎(chǔ)庫變更報(bào)警

上面我們已經(jīng)對基礎(chǔ)服務(wù)和基礎(chǔ)組件進(jìn)行了單元測試兼蜈，但是單測也不能完全保證基礎(chǔ)庫的變更完全沒有問題，伴隨著業(yè)務(wù)層引入新版本的基礎(chǔ)庫拙友，bug 會進(jìn)一步帶入到業(yè)務(wù)層为狸，最終影響 C 端用戶的正常使用。那如何保障每次業(yè)務(wù)層引入新版本的基礎(chǔ)庫之后能做到全面的回歸遗契？如何讓業(yè)務(wù)測試同學(xué)對基礎(chǔ)庫變更更加敏感呢辐棒？針對這種情況，我們著手做了一個(gè)基礎(chǔ)庫版本變更的小工具牍蜂。實(shí)現(xiàn)思路如下：

1. 對比一次 master 代碼的提交或 merge 請求漾根，判斷 package.json 中是否有特定基礎(chǔ)庫版本變更
2. 將對應(yīng)基礎(chǔ)庫的前后兩個(gè)版本的代碼對比發(fā)送到測試負(fù)責(zé)人
3. 根據(jù) changelog 判斷此次回歸的用例范圍
4. 增加 gitlab webhook，只有合并到合并發(fā)布分支或者 master 分支的代碼才觸發(fā)檢查

這個(gè)小工具的引入能及時(shí)通知測試人員針對什么需求改動了基礎(chǔ)組件鲫竞，以及這次基礎(chǔ)組件的升級主要影響了哪些方面辐怕，這樣能避免相對黑盒的測試。

第一版實(shí)現(xiàn)了最簡功能从绘，后續(xù)再深挖需求寄疏，可以做到前端代碼變更的精準(zhǔn)測試。

五顶考、sentry報(bào)警

在剛接觸前端測試的時(shí)候，js 的報(bào)錯(cuò)沒有任何追蹤妖泄，對于排查問題和定位問題有很大困擾驹沿。因此我們著手引入了 sentry 報(bào)警監(jiān)控，用于監(jiān)控線上環(huán)境 js 的運(yùn)行情況蹈胡。

sentry^[7] 是一款開源的錯(cuò)誤追蹤工具渊季，它可以幫助開發(fā)者實(shí)時(shí)監(jiān)控和修復(fù)崩潰。

開始我們接入的方式比較簡單粗暴罚渐，直接全局接入却汉，帶來的問題是報(bào)警信息非常龐大，全局上報(bào)后 info荷并、warn 信息都會打出來合砂。

更改后，使用 sentry 的姿勢是：

• sentry 的全局信息上報(bào)源织，并進(jìn)行篩選
  • 錯(cuò)誤類型: TypeError 或者 ReferenceError
  • 錯(cuò)誤出現(xiàn)用戶 > 1k
  • 錯(cuò)誤出現(xiàn)在 js 文件中
  • 出現(xiàn)錯(cuò)誤的店鋪 > 2家
• 增加核心業(yè)務(wù)異常流程的主動上報(bào)

最終將篩選后的錯(cuò)誤信息通過郵件的形式發(fā)送給告警接收人翩伪，在固定的時(shí)間集中修復(fù)。

六谈息、業(yè)務(wù)報(bào)警

除了 sentry 監(jiān)控報(bào)警缘屹，Node 接口層的業(yè)務(wù)報(bào)警同樣是必不可少的一部分，它能及時(shí)發(fā)現(xiàn) Node 提供的接口中存在的業(yè)務(wù)異常侠仇。這部分是開發(fā)和運(yùn)維同學(xué)做的轻姿，包括在 Node 框架底層接入日志系統(tǒng)犁珠；在業(yè)務(wù)層正確的上報(bào)錯(cuò)誤級別、錯(cuò)誤內(nèi)容互亮、錯(cuò)誤堆棧信息犁享；在日志系統(tǒng)增加合理的告警策略，超過閾值之后短信胳挎、電話告警饼疙，以便于及時(shí)發(fā)現(xiàn)問題、排查問題慕爬。

業(yè)務(wù)告警是最能快速反應(yīng)生產(chǎn)環(huán)境問題的一環(huán)窑眯，如果某次發(fā)布之后發(fā)生告警，我們第一時(shí)間選擇回滾医窿，以保證線上的穩(wěn)定性磅甩。

七、約定規(guī)范

除了上述的一些測試和告警手段之外姥卢，我們也做了一些流程規(guī)范卷要、用例維護(hù)等基礎(chǔ)建設(shè)，包括：

• 發(fā)布規(guī)范
  • 多個(gè)日常分支合并發(fā)布
  • 限制發(fā)布時(shí)間
  • 規(guī)范發(fā)布流程
  • 整理自測核心檢查要點(diǎn)
• 基線用例庫
  • 不同業(yè)務(wù) P0 核心用例定期更新
  • 項(xiàng)目用例定期更新到業(yè)務(wù)回歸用例庫
  • 線上問題場景及時(shí)更新到回歸用例庫

目前有贊的前端測試套路基本就是這樣独榴，當(dāng)然有些平時(shí)的努力沒有完全展開僧叉，例如接口測試中增加返回值結(jié)構(gòu)體對比；增加線上接口或頁面的撥測^[8]棺榔；給開發(fā)進(jìn)行自測用例設(shè)計(jì)培訓(xùn)等等瓶堕。也還有很多新功能探索中，如接入流量對比引擎症歇，將線上流量導(dǎo)到預(yù)上線環(huán)境郎笆，在代碼上線前進(jìn)行對比測試；增加UI自動化的截圖對比忘晤；探索小程序的UI自動化等等宛蚓。

參考鏈接：

• [1] https://github.com/GoogleChrome/puppeteer
• [2] https://www.npmjs.com/package/mocha
• [3] https://www.npmjs.com/package/mochawesome
• [4] https://github.com/gotwarlost/istanbul
• [5] https://github.com/facebook/jest
• [6] https://github.com/avajs/ava
• [7] https://docs.sentry.io
• [8] https://tech.youzan.com/youzan-online-active-testing/