日常生活中，我們經常會看到不同的平臺使用不同的評分制度來展示用戶對產品或服務的評價。例如，豆瓣和虎撲采用10分制，而淘寶店鋪和美團點評則選擇5分制。那么，為什么同樣是為了反映用戶評價的功能會有不同的分制呢？這背后是否有著特定的考量？

01 一個有意思的現象

最近在人人都是產品經理上看到了一個非常有意思的問題。為什么豆瓣、虎撲等用十分制評分，而淘寶店鋪、美團點評等用五分制？(https://wen.woshipm.com/question/detail/8s2csf.html)。這個問題我從來沒有注意過，去app上一看，果然如此。豆瓣、虎撲都是十分制，淘寶、美團都是五分制。

那么問題來了，為啥同樣都是評價性質的功能，還要搞不同的分制呢？是不是可以統一成五分制或十分制呢？如果不能，背后有什么考量嗎？

02 什么是星級評分

想探究以上的這些問題，就要搞清楚星級評分的一些基本概念。從本質上講，星級評分是評估產品質量或受歡迎程度的一種算法。在一定意義上，星級評分能夠比較真實地反映用戶對產品的評價或情感，是一種相對客觀的方法。

回想一下，每次去吃一家不太熟悉的餐館，場景是不是先看一下大眾點評上的分數咋樣，然后再決定去不去。這就是星級評分的好處，它不需要用戶很繁瑣地看具體評價，可以通過一個分數，直接獲知一個產品或是店鋪的優劣，大大節省了用戶決策的時間成本。另外，這些數據對于一些有良心的企業，也是監控他們的產品是否得到消費者的信賴和支持的良好指標。

星級評分這種收集用戶反饋的方式非常常見。目前主流的評價方式，都是給一個五顆星，然后把所有人的評價通過一個算法轉化成分數，分數有五分制和十分制之分。其他的星級評價方式，諸如三星級，十星級都見過，但是不較五星級少見。

回到文章開頭的五分制和十分制的問題。既然星級評分就是一種算法，那是不是也可以只給兩顆星星讓用戶去評價，或者一個贊的按鈕，一個踩的按鈕來評價呢？我覺得是沒有問題的，因為這也是一種評價，也反映了用戶比較真實的看法和情感。

所以，是什么東西影響使用的評分方式和分制呢？

03 影響星級評分方式和分制的因素

1. 成本因素

從心理測量學角度來說，星級評價可以看做是一種量表。而心理測量學中被廣泛使用的測量方法是李克特量表。這是一種總加量表類型的一種，主要是用來反映填寫者整體的認同程度和主觀評價。一般量表大多采用5級，但是也有7級的，6級的，甚至11級的。

但是從成本角度來說，誤差成本會隨著量表等級的增加逐步降低，回答成本會隨著量表等級的增加而增加。很好理解，回答的星級越多，越能夠真實反應用戶對產品的滿意程度和評價，但是星級越多，讓用戶回答起來就會非常痛苦，最好的就是能夠既讓誤差沒那么大，用戶填寫起來也不太痛苦。這里貼一個網上的圖，圖顯示，星級為5的時候，是最優的。

2. 量表指標因素

既然星級評價是一種量表，那就需要考慮一些量表指標，比如，信效度、區分度等。

最近在開奧運會，我用奧運會的一個項目舉例子說明一下信效度。一個射擊運動員，每次都射擊6環，我們可以說他信度高，所以，信度代表的是量表的可靠程度。還有一個運動員，雖然不是每次都能夠射擊同一環數，但是要不就是10環，要不就是9環。我們可以說這個運動員效度比較高。

所以，效度代表的是量表的準確程度。區分度呢，就是這個量表測量的東西，一定能夠把不同水平的人給區別開。如果靶子設定的特別大，槍法好和槍法差的都能很輕松地打出10環，那這個靶子的區分度就非常差。

搞清楚了這幾個概念，我們就看一下，不同星級評價數量對這幾個指標的影響。

曾經有學者做研究表明，7個等級的星級評價要比5個等級的星級評價能得到更可靠的結果，也就是信度會更高些。但是，信度和等級數量之間并不是線性關系。另外的研究表明，等級數量超過9個時，不同等級的差異就沒有意義了，不會再提供更多的有效信息，反而會讓用戶填寫起來非常累和困惑。

3. 用戶使用習慣問題

通過以上的分析，星級評價的等級數基本錨定在5到9個左右。這和人類短時記憶的容量，7±2個組塊的數量不謀而合。所以，在星級評價數量的選取的時候，也要遵循用戶的使用習慣。

首先用戶是非常不喜歡思考的。對一個事物的評價，最優解就給我一個好還是不好的選項，二極管思維是最受大多數用戶的喜愛了。但是這種評價的區分度又太差。又想評價準，又想有區分度，又想不讓用戶那么累，避免評價數過少，最后分析下來，只有5個等級是最合適的了。

4. 產品調性、對象特征

評價都是為了還原用戶對產品整體的認同程度和主觀評價。那么，準確和恰當是非常重要的。

比如，B站上，用戶對視頻的評價就只有頂或者踩。在B站，用戶對視頻的評價，不是一個譜系，而是一個是或否的關系，要不好看，要不難看，沒有稍微不好看，或者稍微好看，這對于用戶來說，區分好看和稍微好看非常有難度，且沒有必要。這種情況下，就可以犧牲區分度，采用兩星級評價。

但是對于電影來說，需要評價的維度特別多，如果僅僅用頂或者踩，準確性會大大折扣。所以，主流的網站，大多采用5等級星級評價。

04 分數呈現有什么講究

回到開頭我們討論的那個現象，會發現，不管是十分制的豆瓣、虎撲，還是五分制的點評、美團。都采用的是五等級的星級評價。但是分數最終呈現卻不是一樣的。這有什么講究嗎？

要想知道不同分制的區別，我們就要知道分數是咋算出來的。具體的規則細節肯定是獲取不到，我們也不需要知道的那么詳細。

簡單來說，分數主要還是來自于分數平均（可以看一下豆瓣CEO阿北的回答）。我理解，算法主要是處理評價是否可信的問題，比如，阿北提到的，“和影托或者其他非正常個人意見PK”，“時間和打分這自身的情況”。

這些都是在識別，某一個或某一些評價是否是真實的評價，而不是刷的，或者只是因為個人情緒，惡意給的差評。

算法可以理解是一個門檻，這個門檻只讓真實的評價進去，只要你能進去，那算法就簡單了，就是計算平均分，阿北也說了嘛，“接近和還原普通觀眾最原汁原味的平均觀影意見?！?/p>

其他的平臺也應該是這種考慮和算法。

那么，同樣的五等級評分，有的是五分制，為啥有的十分制呢？

兩種分制的不同，可以理解成，分制越大，區分度越大，越能夠將細微的好壞差別體現出來。所以，分制的不同，要回歸用戶。

如果某個平臺上的用戶，對某個事物具體比較高的了解程度和鑒賞水準，那就需要比較高的分制。如果某個平臺上的用戶，對某個事物沒有高的了解程度，那就需要給用戶一個相對來說較為簡單明了的分數，那就需要一個稍微低一點的分制。

所以，這就是為啥同樣的五等級評分，美團用五分制，而豆瓣用十分制。

參考

問卷設計：量表到底是要用5級還是6級？– 人人都是產品經理

評價體系用什么規則好?豆瓣是5星10分制，時光網是10星10分制，淘寶是5星5分制 – 知乎

量表等級，5分、7分、10分哪種更好？等級量表數據應該如何分析？

為什么豆瓣、虎撲等用10分制評分，而淘寶店鋪、美團點評等用5分制?

本文由 @孟老濕 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自pixabay，基于CC0協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。

著美團到家業務的發展，系統復雜度也在持續增長。測試用例數量近兩年增長約一倍，單端數量超過1萬2千條，而研發人員的工作從大部分時間在開發，轉變成一半時間在開發、一半時間在模擬環境和自測。因此，引入自動化測試就顯得十分有必要，本文介紹了美團外賣在自動化測試方向做的一些探索和實踐，希望對從事相關領域工作的同學能夠帶來一些啟發或幫助。

1. 項目背景

美團外賣的業務場景比較多元化，除了外賣自身的業務，還作為平臺承接了閃購、團好貨、醫藥、跑腿等其他業務。除此之外，在全鏈路動態化的大基調下，外賣各個頁面的技術形態也變得越來越復雜，除了Native代碼，還包括Mach（外賣自研動態化框架）、React Native、美團小程序、H5等，不同技術棧的底層技術實現不同，渲染機制不同，進而對測試方式要求也有所不同，這也在無形中增加了測試的難度。下圖匯總了美團多業務、多技術、多App的一些典型場景。

在產品交付上線的過程中，測試的占比也是非常大的，甚至大于總時長的30%。如下圖所示，整個測試包括了冒煙測試、新功能測試、二輪回歸測試、三輪測試。然而，現在需求測試絕大部分還是采用非自動化的方式，這就使得人力成本變得非常之高。

另一方面，相比于2018年，2022年的測試用例數量增長近3倍，已經超過1萬2千條（如下圖所示）。同時，外賣的業務是“三端復用”，除了外賣App，還需要集成到美團App和大眾點評App上，這樣一來，測試工作量就翻了3倍，業務測試壓力之大可想而知。如果按照當前的增長趨勢持續下去，要保障外賣業務的穩定，就必須持續不斷地投入大量的人力成本，所以引入能夠支持外賣“多業務場景”、“多App復用”、“多技術?！?特點的自動化測試工具來提升人效和質量，勢在必行。

2. 項目目標

為了解決外賣面臨的測試困境，我們嘗試去探索一種零學習成本、低維護、高可用的自動化測試方案，能夠支持外賣復雜多變的測試場景，它必須同時滿足下面幾點要求：

• 易用性：工具/平臺的上手難度，使用復雜度應該盡可能的低，因為自動化測試的目的是提效人力，而不是增加人力負擔。
• 平臺支持：移動端至少需要覆蓋iOS和Android雙平臺，同時基于外賣的業務特點，不僅需要對Native支持，也需要支持Mach（自研局部動態化框架）、H5、React Native、美團小程序等技術棧。
• 穩定性：自動化測試用例的執行需要有足夠的穩定性和準確性，測試過程中不應因測試工具本身的不穩定而出現穩定性問題。
• 維護成本：維護成本很大程度上決定了測試工作量的大小，因需求產生變動或架構重構等問題時，用例的維護成本應該盡可能的小。
• 可擴展性：當測試方案不能滿足測試需求時，工具/平臺應具備可擴展的能力。

3. 方案選型

自動化測試工具那么多，自研是重復造輪子嗎？

針對終端的UI自動化測試工具/平臺可謂“屢見不鮮”，市面上也有很多相對成熟的方案，相信大家都有用過，或者至少有所耳聞，但這些方案是否能真的滿足我們提效的訴求呢？以下我們挑選了三類非常具有代表性的自動化測試工具/平臺 - Appium、Airtest Project、SoloPi進行了分析，來幫助大家對自動化測試技術建立一個認知：

• Appium是一個開源工具，用于自動化測試iOS手機、Android手機和Windows桌面平臺上的原生、移動 Web和混合應用。它使用了各系統自帶的自動化框架，無需SDK集成，Appium把這些系統本身提供的框架包裝進一套API——WebDriver API中，可以使用任何語言編寫Client腳本向服務器發送適當的HTTP請求。這讓不同技術棧的人員都能快速上手編寫測試用例，可以選擇自己最為熟悉的語言，但是對于沒有語言開發基礎的人來說，還是有一定學習成本，而且這種方式在多人協作時并沒有太大作用，為了保證自動化用例的可維護性，團隊內部應該需要統一腳本語言。值得一提的是：Appium在iOS、Android和 Windows 測試套件之間可做的一定程度的復用代碼。但是由于不同端界面及元素定位的差異，這往往是不現實的，更無法保證測試的準確性，所以這種所謂的“跨端”就變得毫無意義。
• Airtest Project是由網易游戲推出的一款自動化測試平臺，除了支持通過系統自帶的自動化測試框架，還支持了通過圖像識別的方式，對于非基于原生UI系統的一些游戲引擎提供了SDK的支持。其上手難度稍低，可以一定程度上通過IDE進行相關操作來生成簡單的腳本指令。Airtest雖然基于圖像進行控件識別，為跨端提供了一定的可能性，然而圖像識別并不能達到人眼識別的準確度，除此之外移動端頁面的構成和游戲頁面也存在不小的差別，頁面元素的展示規則和樣式受屏幕分辨率影響較大，單純依靠圖像識別來進行元素查找成功率不高，無法保證測試的準確性。
• SoloPi是一個無線化、非侵入式的自動化測試工具，通過錄制回放的方式進行UI自動化測試，SoloPi雖然只支持Android，但是在錄制回放的這種方式中，還是極具代表性的。傳統的自動化測試工具由于需要編寫測試腳本，所以存在著一定的上手難度（Airtest還是存在代碼編輯的），便產生了SoloPi這種純基于錄制回放的自動化測試方式，將用例的所有操作事件進行錄制，生成一個完整的錄制腳本，通過對腳本的回放來還原所有的操作，從而進行自動化測試。但是，這種方式只能記錄操作，而不能記錄數據，在外賣這種數據驅動展示的場景下無法滿足測試要求。并且外賣的業務要復用到美團App和大眾點評App中，不同App存在部分視圖和邏輯性的差異，SoloPi也無法支持我們“一端錄制多端回放”的測試場景。

可以看出，以上這些自動化測試工具/平臺對于數據記錄，環境模擬、維護成本、跨App復用等方面，都是有所欠缺的。所以無論是哪種方案，在易用性、維護成本、穩定性、可擴展性以及最終的測試效果上，都無法滿足我們對自動化測試的需求。我們并不是為了自動化而自動化，而是要解決實際的提效問題。

那么，怎樣才能確定一個自動化工具/平臺的可用性，并長期落地去使用自動化，帶著上述提到的較高門檻的上手成本、操作繁瑣的環境模擬、差強人意的測試成功率、定位模糊的測試缺陷、難以維護的用例腳本等幾大重要痛點，本文我們將介紹美團外賣自研的測試平臺——AlphaTest，都具備哪些能力以及是如何解決這些問題。

4. 實踐和探索

一個自動化測試工具/平臺能不能用起來，取決于他的上手成本和穩定性，即使工具的測試穩定性做的再好，使用的門檻高也會讓人望而生卻，反之亦然。所以AlphaTest平臺為了上手簡單，降低使用成本，采用了基于錄制回放的方式進行設計，并且彌補了常規錄制回放無法編輯的痛點，同時在手勢操作的基礎上增加了數據錄制。整合美團系App的特性增加了環境模擬、跨App支持、混合技術棧的支持等能力，在使用簡單的同時，也保障了用例的可維護性、測試的準確性等。

4.1 問題和挑戰

注：這里我們將生成的自動化腳本統稱為指令，將平臺生成的用例統稱自動化用例，將錄制回放變成可視化的腳本指令，讓用例變的易懂、易維護。

錄制回放本身是一連串的操作數據的集合，是連續性的、不可拆分，因此幾乎不具備可編輯性，這也就導致了用例維護成本極高。AlphaTest雖然同樣基于錄制回放的方式生成自動化用例，但是我們將每一步的操作都具化成結構化的指令數據，并提供可視化指令編輯器，以支持查看編輯。

這些可視化的指令，完全通過錄制自動生成，也不依賴于任何腳本語言。通過可視化用例指令編輯器，不僅為用例提供了編輯的可能性，同時大大地提高了用例的可閱讀性，每一條測試用例在測試過程中每一步都做了什么、當時的界面是什么樣的、都有哪些斷言校驗點，是顯而易見的，不會存在像傳統圖文描述的測試用例那樣，出現理解偏差。指令生成演示，手機錄制與平臺遠端錄制雙模式支持：

4.2 前置條件準備

一鍵環境模擬，解決操作繁瑣的用例執行前的環境準備。

進行一個用例的測試之前，往往需要做大量的準備工作，比如切換API環境，定位到某個地點，登錄指定賬戶等。這些需要準備的環境條件我們統稱為前置條件。我們知道，前置條件的準備操作通常都不是一兩個步驟就可以完成的，比如賬號登錄/切換：我們需要進入登錄頁，填寫手機號+密碼/驗證碼，點擊登錄等一系列動作來完成這個過程，非常繁瑣，并且每次測試我們都需要準備，重復性高。因此，我們給AlphaTest設計了獨立的前置條件模塊，將用例拆成了兩個部分：前置條件 + 操作步驟。

與其它測試框架不同的是，AlphaTest采用了SDK集成，但對業務無侵入的方式，因此可以通過編寫白盒代碼來實現前置條件的自動配置，只需要在平臺添加需要的指令，下發到SDK后，即可根據相關指令完成前置條件的自動配置，不再需要重復進行相關的操作。并且這些前置條件支持復用，也不需要每次進行用例準備時的重復配置。AlphaTest的前置條件，不僅有著基于美團內部服務及底層Hook的默認實現，也提供了API支持業務方自定義實現，比如實現不同的賬號體系。

4.3 用例錄制與回放的數據一致性

影響用例執行的不僅是代碼，還有數據。

很多時候，自動化用例無法正常執行完成，可能是因為App回放時的本地數據及網絡數據與錄制時的不一致，從而導致用例執行流程的阻塞或App界面展示的不同。這也是大多數自動化測試工具/平臺測試通過率不高的主要因素，因此要保證測試成功率，我們需要控制變量，排除由數據產生的影響。

App運行依賴的數據，有兩部分——本地數據和網絡數據：

• 本地數據是App在運行期間產生的緩存數據或持久化的存儲數據。為了讓用例在錄制回放時都能夠保持一致的本地數據環境，我們在錄制和回放前都對App的本地數據進行了清理操作，這樣用例在錄制和回放的過程中，都可以保持一致的App初始化環境。
• 網絡數據是驅動App交互呈現的基石，各種策略和API升級都會影響網絡數據的響應，因此我們將用例錄制過程中產生的網絡數據也進行了錄制，并將網絡數據和對應的操作指令進行了關聯和綁定，確定了數據產生的事件源。排除數據影響后，我們的自動化測試的成功率就取決于自動化操作的準確性了，這就回到了常見自動化框架范疇。

4.4 用例錄制與回放的操作一致性

目標定位的準確性與手勢定位的精準性。

UI自動化測試的本質就是代替人去自動的做一步步的操作（點擊、長按、輸入、滑動等）。錄制與回放過程的操作能否一致，是否精準，直接影響測試的成功率，決定了工具/平臺的可用性。

• 目標控件定位準確性：

操作行為是否一致首先需要確認操作目標是否一致。與一般測試工具/平臺不同的是AlphaTest采用了ViewPath + 圖像 + 坐標的多重定位方案。得益于SDK集成的方式，我們的ViewPath可以記錄更多的元素視圖特征和執行不同的匹配策略。定位過程中會優先使用ViewPath進行目標控件檢索，當目標控件查找異常時，會結合圖像匹配和坐標匹配的方式進行兜底查找，來確保界面變化程度不大時，也能準確的查找到目標控件。

• 手勢定位的精準性：

有了基于控件的目標定位之后，對于一些常用簡單操作手勢，比如點擊、長按、斷言、甚至輸入都可以做到很好的支持，只需要找到對應的控件，在控件所在位置下發相應的觸摸事件即可。我們知道，App真正接收的觸摸事件是屏幕上一個個精準的觸摸點，在系統處理后，分發給當前App窗口，App在接收事件后再繼續分發，直到找到事件的最佳響應者，后續通過響應者鏈對事件消化處理。那我們要還原一個觸摸事件的坐標點要如何確定呢？由于我們確定的只有控件，所以這個點自然而然就成了控件的中心點了。

大多數情況下，這些都可以很好地進行工作，但是對于一些多響應控件重疊的情況，可能會產生預想不到的操作誤差。為了解決這樣的問題，我們把控件定位與坐標定位進行了結合：基于純坐標的定位是一種定位精準度非常高的定位方式，但是穩定性非常差，只有在屏幕分辨率完全一致且回放頁面控件位置完全一致的情況下，才具備足夠的可靠性，但這往往是不現實的，對測試環境機器量要求過高。

基于控件的定位，又存在著精準度不夠的問題。使用坐標定位，如果定位區域足夠小的話，那么受屏幕尺寸的影響就會越小，只需要確定在小范圍內的相對位置即可。而基于控件目標的定位，恰恰可以把目標區域縮小到一個指定區域，我們剛好可以將二者結合起來，同時解決定位精準度和穩定性的問題。

對于復雜手勢的支持，我們同樣可以采用微分的方式，將一個復雜手勢拆成多個簡單手勢的組成，比如我們可以將一個滑動操作的定位拆成兩個部分：起始位置和終止位置，而這兩個位置的定位，就變成了兩個普通的單點手勢操作定位了，可以通過上面提到的一個目標控件+相對坐標的形式進行定位。核心思想都是將基于屏幕坐標點的定位操作，縮小的目標控件的區域范圍內，以達到不受設備分辨率的影響，實現操作行為一致的效果。

4.5 可溯源的自動化測試

測試全流程記錄，問題溯源一鍵即達。

測試的目的是保證App運行的穩定，測試過程中出現Bug導致測試未通過時，需要溯源問題原因，發生的場景，乃至具體的執行步驟。這也是大多自動化測試工具/平臺所欠缺的，即使發現了問題，排查工作也很困難；這個問題在手工測試的時候，更為嚴重，往往因為很多缺陷無法復現而難以定位。

AlphaTest的自動化用例最小執行單元是操作指令，我們將測試過程的每一條指令的執行狀況和過程中的界面快照進行了記錄，并在指令執行失敗時，對異常原因進行了初步分析。然后將整個用例的執行組合成了一份完整的測試報告，可快速溯源問題步驟。除此之外，我們還增加大量的日志上報，并將整個用例測試過程進行了視頻錄制，來進一步幫助疑難問題的排查。真正做到了用例回放測試可溯源。

4.6 用例的維護

自動化用例需要持續地投入人力來維護么？架構升級，頁面重構，用例需要全部重新錄制么？

因自動化工具/平臺眾多，阻礙長期落地使用的一大問題是用例維護成本高，很多工具/平臺讓我們即便是使用上了自動化，但還需要持續投入人力維護用例的更新，最終的提效收益微乎其微。對于用例更新維護，我們可以梳理劃分成三個場景：

• 需求發生重大變更，整體的業務執行流程及相關的校驗點都需要進行大量的調整。對于這種情況，無論是何種自動化測試工具/平臺，都是需要正常進行用例變更重錄以適應新的需求。
• 需求發生略微變更，業務流程基本一致，需要調整的校驗點、操作以及數據或不影響整體流程的步驟。對于此場景，AlphaTest通過指令編輯器與操作錄制，支持指令增刪改以及數據和場景的還原，幫助用戶快速的進行用例調整，而無需重新錄制用例。例如：修改網絡數據字段、視圖變更路徑、斷言替換目標等。

• 和業務需求不同，我們的技術實現也會發生迭代。隨著App技術架構不斷的演進，經常會面臨著架構升級，頁面重構甚至技術棧變遷等這樣的技術升級。這些變動需要覆蓋大量的測試用例，其中大量的自動化用例又可能會因為變動而導致失效，需要重新錄制。為此，AlphaTest設計一套利用相近分辨率機器進行用例自動修正的功能：利用圖像 + 坐標進行二次識別定位，元素定位成功并校驗通過后，生成新的ViewPath，更新對應的用例指令，對用例進行自動修復，修復后可在任意回放。

4.7 跨App回放用例

同一份代碼運行在不同的App上，是否需要重新編寫多份用例？

美團系的一些業務可能會復用在多個App上。比如外賣有獨立App，但同時也要復用到美團和點評App上，這些功能，幾乎共用一份代碼，而測試人員卻不得不對每個App上的業務功能都進行測試，維護多份用例。由于業務本身實現是一致的，那我們可以通過適配不同App之間的差異，來讓一個業務Case可以橫跨多個App回放，這便可以將成本縮減好幾倍，這些差異主要體現在：

• 前置條件和初始頁面：業務的初始頁面進入路徑不同，例如外賣App打開App就進入到了外賣首頁，但是在美團App中就需要從美團首頁跳轉到外賣頻道。同時由于不同App的樣式風格、設計規范、業務特性等因素，也會造成首頁代碼邏輯和視圖層級的差異。
• AB實驗配置：不同App所配置的實驗可能不同，不同的實驗會導致不同的樣式和代碼邏輯。
• 網路接口映射：不同App中相同業務場景涉及的接口有所不同。
• 頁面Scheme映射：不同App中相同頁面的跳轉Scheme也不相同。

AlphaTest平臺支持App維度各項差異數據配置，當SDK檢測用例回放環境與錄制環境不一致時，會自動進行映射適配，從而讓用例運行到了不同App上。

4.8 埋點的錄制回放

除了功能測試，我們在日常開發和測試的工作中，還會面臨另外一個比較重要的問題就是埋點測試。因此，我們在自動化的基礎上擴展出埋點自動化測試。埋點自動化測試的核心思想是，通過對比錄制時期和回放時期的埋點上報時機和上報參數進行判斷。為了保證埋點自動化測試的穩定性，我們主要采用以下的障機制：

• 字段規則配置：埋點自定義參數千姿百態，甚至有些字段每次代碼執行都不一致，如果進行完全匹配結果注定是失敗的，所以我們在AlphaTest平臺提供了埋點字段規則配置功能，通過人為設置的方式來避免埋點自定義參數校驗失敗。App重啟進入錄制狀態時，用戶就可以操作App，平臺會記錄用戶的操作行為，當產生相應的埋點日志的時候會將日志信息打印在日志區域（如下圖17所示），在該過程中也會對埋點日志進行一定的校驗。重點將操作時機、埋點日志一并保存到服務端。

• 埋點時機校驗：針對時機校驗，程序并不支持埋點曝光的"1px曝光"，"下拉刷新曝光"，"頁面切換曝光"，"切前后臺曝光"這些規則，主要的原因是每一個業務方在對埋點曝光的規則都是不一致的，而且該規則的實現會極大耦合業務代碼。在針對時機校驗我們目前只支持： [1] 點擊埋點上報時機校驗，程序通過事件監聽和埋點類型信息來判斷點擊埋點上報的時機是否是在點擊的操作下產生的，如果不是則報錯。 [2] 埋點重復上報校驗，針對一般情況下用戶一次操作不會產生兩個相同的埋點上報，所以程序會校驗某個事件下發生的所有埋點日志進行一一校驗，檢測是否具有2個或多個埋點日志完全一致，如有發生則會上報錯誤。

• 結果校驗：回放完成后，我們會對比錄制和回放時的埋點數據，根據配置好的字段規則校驗埋點上報是否符合預期。

5. 測試流程

AlphaTest的核心測試流程始終聚焦在用例的錄制與回放環節，整個流程涉及到自動化任務觸發、回放集群調度、斷言服務、消息推送等核心模塊。

以UI自動化和埋點自動化的流程為例，AlphaTest以業務團隊為基本單元，可以和各團隊的測試用例進行關聯，定時同步狀態。同時利用需求評審線上化做為基礎，將自動化用例和研發流程中的PR、集成打包、二輪回歸等節點相結合，定時觸發自動化用例并將結果報告推送給相關負責人。

• 錄制用例： [1] 首先在AlphaTest平臺選擇要錄制的測試用例，打開待測試App進行掃碼即可進入用例待錄制狀態，此時可以設置用例需要的前置條件（賬號信息、Mock數據、定位信息等），之后點擊開始按鈕后，手機便會自動重啟，開始錄制。 [2] 用戶按照測試用例步驟，正常操作手機，AlphaTest會將用戶的操作行為全部記錄下來，并自動生成語義化的描述語言顯示在AlphaTest平臺上，與此同時產生的網絡數據、埋點數據等校驗信息也會一并存儲下來。 [3] 在錄制的過程中可以快捷的打開斷言模式，將頁面上想要校驗的元素進行文本提取/截圖等操作記錄下來，用于后續回放過程中對相同元素進行校驗。 [4] 測試步驟全都執行完畢后，點擊保存按鈕即可生成本條自動化用例。
• 用例回放： [1] 掃描對應自動化用例的二維碼即可進行回放，回放過程中會將用戶錄制的行為、網絡數據進行一比一還原，并且輔助有全過程視頻錄像，用于后續問題排查和溯源。 [2] 回放過程中碰到斷言事件時，會將斷言的元素進行文本提取/截圖，上傳至AlphaTest平臺。回放完成后，會將回放時候的斷言截圖和錄制時的斷言截圖進行圖像對比，作為整個測試結果的一項。 [3] 回放過程中的埋點數據也會一并記錄下來，并和錄制時候的埋點數據和上報時機進行對比，自動提取出其中的差異項。 [4] 回放完成后，會生成完整的測試報告并將結果通過OA推送至相關人員。
• 回放計劃：二輪回歸測試中，回放用例數量多達幾百條，為了做到全流程的自動化，我們提供了回放計劃的概念，可以將多個自動化用例進行編組管理，每一組就是一個回放計劃。觸發一個計劃的回放即可自動觸發計劃內的所有自動化用例。整個計劃都執行完成后，會通知到指定的計劃負責人或群組。

5.1 自動化任務觸發

在整個外賣C端敏捷迭代的流程中，打包平臺主要承接了業務需求發起到需求交付的流程，作為AlphaTest的上游平臺，可以提供打包信息并觸發自動化用例回放任務。以下簡單展示AlphaTest與敏捷協同平臺的交互流程：

5.2 回放集群調度

整個測試過程真正的解放雙手，才能算的上是自動化。因此，我們著手搭建了自己的自動化機器集群，可以 24小時不間斷的執行測試任務。為了保證任務回放能夠順利完成，我們在不同階段增加了相應的?；畈呗?。在極大程度上提高了任務執行完畢的成功率。

• 執行流程：回放任務通過用戶在平臺手動觸發或者二輪自動觸發。新增的回放任務經過任務拆分系統拆分成n個子任務，加入到不同設備的回放任務隊列中。每個子任務經過占用設備->安裝待測App->應用授權->打開scheme->上報結果等步驟完成回放操作。
• 節點?；顧C制：針對回放流程中每一個節點，失敗后進行N（默認為3）次重試操作。減少因網絡波動，接口偶現異常導致的回放失敗數量。
• 子任務?；顧C制：每個回放流程，失敗后進行N（默認為3）次斷點重試。減少因設備異常，SDK心跳上報異常導致的回放失敗數量。
• 父任務?；顧C制：一個父任務會被拆分成N個子任務，當其中的一個子任務S1在節點?；顧C制和子任務保活機制下仍然執行失敗之后，父任務?；顧C制會嘗試將子任務S1中未執行完畢的用例轉移到其他活躍狀態的子任務中。減少因設備異常，設備掉線等問題導致的回放失敗數量。

5.3 斷言服務

用例斷言是整個自動化用例驗證的核心步驟，我們的斷言服務依據用例的實際情形可以分別進行文字與圖像的斷言。其中圖像斷言服務依托于自建的圖像對比算法服務，可以高效進行錄制回放斷言圖像的對比，圖像對比準確率可以達到99%以上。

• 錄制階段： [1] 錄制時增加斷言決策信息的自動采集。 [2] 和正常流程一樣，提取區域的截圖信息。 [3] 如果是文本組件，則提取文本內容，如果是圖片組件，則提取圖片二進制編碼或圖片URL，同時提取區域內的布局信息。
• 回放階段： [1] 回放時，提取和錄制時一致的內容（文本信息、圖片編碼、區域截圖、布局信息）。 [2] 將回放時的斷言信息上傳至AlphaTest平臺。 [3] AlphaTest平臺對斷言結果進行校驗，首先是基于模型的圖像對比，如果判定為一致，則直接標記結果。 [4] 如果判定為不一致、則匹配“斷言失敗數據集”，如果能夠匹配上，則標記結果。如果匹配不上，則需要人工選擇匹配類型。 [5] 匹配類型為“文本校驗”、“根據圖片信息校驗”、“人工校驗”。如果前兩項判定為一致，則直接標記結果。如果“人工校驗”的結果為確實兩張圖不一致，則直接標記結果，結束。 [6] 如果“人工校驗”結果為一致，既上述所有判定都不準確，則需要人工對兩張圖中判定錯誤的原因進行分類（具體類型待定），同時將斷言存儲到失敗數據集。 [7] 模型自動訓練，當數據集超過一定的閾值、通過定時觸發、或者手動觸發的方式，觸發模型自動訓練，訓練完成后自動部署到AlphaTest平臺，不斷迭代。
• 圖像服務：圖像對比模型采用基于度量學習的對比算法，將圖像對的一致性判別轉換為圖像語義的相似度量問題。度量學習（Metric Learning），也稱距離度量學習（Distance Metric Learning，DML）屬于機器學習的一種。其本質就是相似度的學習，也可以認為距離學習。因為在一定條件下，相似度和距離可以相互轉換。比如在空間坐標的兩條向量，既可以用余弦相似度的大小，也可以使用歐式距離的遠近來衡量相似程度。度量學習的網絡采用經典的Siamese結構，使用基于resnext50的主干網絡提取圖像的高級語義特征，后接spplayer完成多尺度特征融合，融合后的特征輸出作為表達圖像語義的特征向量，使用ContrastiveLoss進行度量學習。

[1] 預訓練過程：resnext50網絡是使用ImageNet的預訓練模型。

[2] 數據增強：為增加數據的豐富性、提高網絡的泛化性能，數據增強的方式主要包括：圖像右下部分的隨機剪切和添加黑色蒙層（相應改變圖像對的標簽）。這種數據增強符合控鍵截圖實際情況，不會造成數據分布的改變。

[3] 對比損失：對比損失函數采用ContrastiveLoss，它是一種在歐式空間的pair based loss，其作用是減少一致圖像對距離，保證不一致圖像對的距離大于margin，其中margin=2。

[4] 相似度量：相似度量也是采用計算圖像對特征向量的歐式距離的方法，并歸一化到區間[0, 1]，作為輸出的圖像對相似度。

5.4 消息推送

消息推送作為回放流程的最終環節，我們依賴于美團內部自建的消息隊列服務與OA SDK消息推送能力，可以進行測試報告的實時推送。在此之上，還可以針對不同團隊的推送訴求，做消息模板的定制化。

• 消息定制：消息推送與觸達的核心，是滿足業務訴求；不同業務對自動化測試報告中各項指標的關注點不同，這就需要AlphaTest具備消息推送定制的能力；將消息推送的模板以配置文件的形式提供出來，不同的業務使用不同的業務消息配置文件；再利用OA提供的圖文、多媒體等消息推送能力，可以將自動化測試報告的各項指標自定義拆分；除此之外，消息還需要減少冗余，在這個信息泛濫的時代，我們愿意為無孔不入的消息、通知做減法，只將最重要、最核心的消息推送給最需要的人，既可以推動自動化測試流程的高效流轉，又可以讓各相關業務人員享受到自動化測試能力的便捷性。

• 一鍵觸達：以往的研發人員冒煙測試，主要依賴于測試人員在用例管理平臺建立測試計劃，研發人員根據用例進行手工用例測試結果標記，之后去提測完成后續流程。這中間缺失的主要環節是，難以對研發人員冒煙測試的質量進行把控。而AlphaTest正可以解決此問題，流程轉換為，研發人員在敏捷協同平臺觸發一鍵提測流程，調用AlphaTest的自動化測試能力對冒煙用例進行自動化測試回歸，完成之后將測試生成的測試報告同步提測平臺，作為研發人員冒煙的結論依據，同時在冒煙過程中發生的問題，也可以及時通知到對應的研發人員與測試人員進行改正。既保證了質量，又避免了人力空耗。

6. 落地與實踐

外賣C端主要承擔了用戶在App端點餐、下單、配送的所有核心流程，場景繁多、業務復雜，這也給測試人員的版本測試帶來了諸多挑戰，其中最核心也最耗費人力的便是二輪回歸測試環節。目前，C端采用的雙周敏捷迭代的開發方式，每個迭代周期給測試人員用來進行二輪核心流程回歸的時間為三天，為此C端測試團隊投入了許多人力資源，但即便如此，仍難以覆蓋全部流程；而AlphaTest的設計初衷也正是為解決此問題——UI測試流程全覆蓋及自動化驗證。

6.1 業務共建

用例的轉化與維護

[1] AlphaTest 在外賣C端測試團隊的落地初期，我們采用了共建的模式，也就是業務研發人員與對應測試人員共同來進行用例錄制與維護的工作；推薦這種工作模式的核心原因是，在C端功能迭代流程中的二輪周期的原有工作模式為，研發人員進行二輪冒煙測試，完成測試之后提交二輪包交由測試人員進行二輪回歸測試，所以這本來就是一個雙方都需要參與的環節；而二輪測試作為版本上線前的最重要一個測試流程，保證核心流程的正常也是測試人員與研發人員所關心重點。

[2] 經過多輪的使用與磨合之后，這種模式被證明是行之有效的，在整個C端二輪用例的轉化過程中，測試人員主要負責了用例的錄制與迭代流程，研發人員則主要負責版本回放數據的統計及問題用例的發現與解決。

外賣二輪落地情況

[1] 目前，AlphaTest已經在外賣多個業務落地，支持了大于15個版本的二輪回歸測試，用例覆蓋率達到70%。

[2] 覆蓋了Native、Mach、React Native、美團小程序、H5 技術棧的測試工作，能力上可進行支持：UI自動化測試、埋點自動化測試、動態化加載成功率自動化測試、無障礙適配率自動化測試。

未來，我們會朝著“智能化”和“精準化”兩個方向探索，覆蓋更多測試場景的同時，更進一步提升測試人效。

6.2 實踐效果

7. 參考資料

• [1] https://appium.io
• [2] http://docs.seleniumhq.org/projects/webdriver
• [3] http://airtest.netease.com/index.html
• [4] https://github.com/alipay/SoloPi

| 本文系美團技術團隊出品，著作權歸屬美團。歡迎出于分享和交流等非商業目的轉載或使用本文內容，敬請注明“內容轉載自美團技術團隊”。本文未經許可，不得進行商業性轉載或者使用。任何商用行為，請發送郵件至tech@meituan.com申請授權。

IOps，最初的定義是Algorithm IT Operations，是利用運維算法來實現運維的自動化，最終走向無人化運維。隨著技術成熟，逐步確定為Artificial Intelligence for IT Operations——智能運維，將人工智能應用于運維領域，基于已有的運維數據（日志、監控信息、應用信息等），通過機器學習的方式來進一步解決自動化運維無法解決的問題。

本文系AIOps在美團的探索與實踐的第一部分，如何自動發現故障問題，其中重點介紹了美團時序數據異常檢測系統Horae的架構與設計。

一、背景

早期的運維工作大部分是由運維人員手工完成的，手工運維在互聯網業務快速擴張、人力成本高企的時代，難以維系。于是，自動化運維應運而生，它主要通過可被自動觸發、預定義規則的腳本，來執行常見、重復性的運維工作，從而減少人力成本，提高運維的效率。總的來說，自動化運維可以認為是一種基于行業領域知識和運維場景領域知識的專家系統。隨著整個互聯網業務急劇膨脹，以及服務類型的復雜多樣，“基于人為指定規則”的專家系統逐漸變得力不從心，自動化運維的不足，日益凸顯，當前美團在業務監控和運維層面也面臨著同樣的困境。

DevOps的出現，部分解決了上述問題，它強調從價值交付的全局視角，但DevOps更強調橫向融合及打通，AIOps則是DevOps在運維（技術運營）側的高階實現，兩者并不沖突。AIOps不依賴于人為指定規則，主張由機器學習算法自動地從海量運維數據（包括事件本身以及運維人員的人工處理日志）中不斷地學習，不斷提煉并總結規則。AIOps在自動化運維的基礎上，增加了一個基于機器學習的大腦，指揮監測系統采集大腦決策所需的數據，做出分析、決策，并指揮自動化腳本去執行大腦的決策，從而達到運維系統的整體目標。綜上看，自動化運維水平是AIOps的重要基石，而AIOps將基于自動化運維，將AI和運維很好地結合起來，這個過程需要三方面的知識：

• 行業、業務領域知識，跟業務特點相關的知識經驗積累，熟悉生產實踐中的難題。
• 運維領域知識，如指標監控、異常檢測、故障發現、故障止損、成本優化、容量規劃和性能調優等。
• 算法、機器學習知識，把實際問題轉化為算法問題，常用算法包括如聚類、決策樹、卷積神經網絡等。

美團技術團隊在行業、業務領域知識和運維領域的知識等方面有著長期的積累，已經沉淀出不少工具和產品，實現了自動化運維，同時在AIOps方面也有一些初步的成果。我們希望通過在AIOps上持續投入、迭代和鉆研，將之前積累的行業、業務和運維領域的知識應用到AIOps中，從而能讓AIOps為業務研發、產品和運營團隊賦能，提高整個公司的生產效率。

二、技術路線規劃

2.1 AIOps能力建設

AIOps的建設可以先由無到局部單點探索，在單點探索上得到初步的成果，再對單點能力進行完善，形成解決某個局部問題的運維AI學件，再由多個具有AI能力的單運維能力點組合成一個智能運維流程。行業通用的演進路線如下：

• 開始嘗試應用AI能力，還無較為成熟的單點應用。
• 具備單場景的AI運維能力，可以初步形成供內部使用的學件。
• 有由多個單場景AI運維模塊串聯起來的流程化AI運維能力，可以對外提供可靠的運維AI學件。
• 主要運維場景均已實現流程化免干預AI運維能力，可以對外提供供可靠的AIOps服務。
• 有核心中樞AI，可以在成本、質量、效率間從容調整，達到業務不同生命周期對三個方面不同的指標要求，可實現多目標下的最優或按需最優。

所謂學件，亦稱AI運維組件[1]（南京大學周志華老師提出），類似程序中的API或公共庫，但API及公共庫不含具體業務數據，只是某種算法，而AI運維組件（或稱學件），則是在類似API的基礎上，兼具對某個運維場景智能化解決的“記憶”能力，將處理這個場景的智能規則保存在了這個組件中，學件（Learnware）=模型（Model）+規約（Specification）。