首先，還是要強(qiáng)調(diào)：

• 前端是一種特殊的GUI軟件
• API測試方法論在測試GUI時并不能解決所有問題。

與很多前端工程師討論過前端測試，大家更多的還是盯著API測試方法論。誠然，前端有那么一小部分代碼是可以用API測試保證質(zhì)量的，但前端項目中的絕大多數(shù)代碼是GUI界面，前端測試應(yīng)該向傳統(tǒng)GUI測試方法論需求解決方案：GUI軟件測試_百度百科 ，這個百科詞條介紹的很不錯，大家可以感受一下GUI測試相關(guān)概念和方法。它的測試用例、覆蓋率統(tǒng)計、測試方法等等都與API測試有著很大的不同。

統(tǒng)一了這個認(rèn)知之后，我們來討論一下前端GUI測試的特殊性。根據(jù)百科詞條上的那些介紹，相信大家都能感覺到GUI測試的成本非常高，而前端這種特殊的GUI軟件，具有天生的快速迭代特征，這使得case維護(hù)成本也變得非常高，經(jīng)常跟不上迭代速度。

一個標(biāo)準(zhǔn)的互聯(lián)網(wǎng)應(yīng)用產(chǎn)品的前端部分，我粗略估計大概有20%的業(yè)務(wù)基礎(chǔ)代碼比較穩(wěn)定，比如通用組件、通用算法和數(shù)據(jù)模塊等，可以針對這些建立復(fù)雜一些的API和GUI測試用例來保證質(zhì)量。剩下80%的部分不是很穩(wěn)定，每天都在迭代，針對他們維護(hù)case的成本非常高。目前業(yè)界中號稱做了自動化測試的項目，也大多是在做那穩(wěn)定的20%。

面對這種現(xiàn)狀，我其實也沒想到過什么好的方法，基本原則就是：以最低的成本建立和維護(hù)自動化測試用例。到目前為止，就想到過兩個方案（都不是測試方案，只是回歸測試輔助）：

1. 不太靠譜的“超級工位”大法。
這個方案可以說根本不是什么技術(shù)方案，而是一個辦公設(shè)施，就是我們準(zhǔn)備一個工位，擺上所有我們需要測試的主流設(shè)備，然后設(shè)備通過某種方式與一臺電腦相連接，測試人員坐在工位上，在電腦中輸入某個url，就能同步到所有設(shè)備中，然后開始逐個的人肉測試。

超級工位大法示意圖（應(yīng)該很多設(shè)備的，這里就是隨便展示一下而已。。。）
相比現(xiàn)在的前端GUI測試，超級工位已經(jīng)算是從0到1的飛躍了，雖然沒解決什么技術(shù)問題，但為測試前的準(zhǔn)備工作做好了鋪墊。如果把前端測試比作吃屎，超級工位就是為這餐準(zhǔn)備了一個好一點的餐桌。。。
        2. 靠譜一些的“頁面差異監(jiān)控”
12年的時候還在百度，當(dāng)時有同事去美國參加velocity，twitter分享了一下他們的開發(fā)流程，其中有一個環(huán)節(jié)就是頁面對比監(jiān)控，利用了一個叫pdiff的工具，每次提交代碼，會自動對比頁面之間的差異然后提醒測試人員注意回歸。這也是一個典型的GUI測試零成本維護(hù)用例的案例。不過pdiff這個工具是基于像素對比的，誤報率比較高，所以去年我做了一個這個項目：fouber/page-monitor · GitHub 基于DOM樹的diff，這樣就能很大程度上自主控制要監(jiān)控的元素，可以設(shè)置監(jiān)控樣式、文本的變化，比起像素diff智能了一些。
其工作原理就是利用phantom或其他headless瀏覽器訪問頁面，然后截圖，然后執(zhí)行一段js，遍歷整個dom樹，獲取元素計算樣式和元素內(nèi)文本內(nèi)容，構(gòu)造出一個JSON結(jié)構(gòu)，然后每次diff這個json來判斷頁面差異，并標(biāo)記在截圖上展示。dom樹的diff過程有點類似react的虛擬dom樹diff。

react的dom樹diff算法示意圖:

react的dom樹diff算法示意圖:

DOM樹diff我們可以分辨出元素樣式修改/內(nèi)容修改/新增元素/刪除元素四種不同的頁面差異，我們可以配置選擇器來忽略元素。四種頁面差異的效果圖：

基于這樣的頁面差異對比監(jiān)控，我們可以建立一個任務(wù)系統(tǒng)，把應(yīng)用的所有頁面url監(jiān)控起來，這樣每次版本迭代提交代碼后，系統(tǒng)就能自動告訴我們，哪些頁面的元素展現(xiàn)發(fā)生了改變，用于確定回歸范圍。

用監(jiān)控的方式確定測試回歸范圍，是一種“少吃屎”的手段，符合工程化要求，能比較大范圍的應(yīng)用，雖然不能完美解決GUI中的交互問題，但能保證GUI的展現(xiàn)問題已經(jīng)是不小的進(jìn)步了。