我持續組(zu)織了近3年的(de)(de)，感興趣的(de)(de)可以參(can)與，每周大(da)家一起學習200行左右的(de)(de)源碼，共同(tong)進步。同(tong)時(shi)推薦、。

本文整理自美團技術沙龍第77期《美團億級流量系統的質量風險防控和穩定性治理實踐》。作為一種終端產品生態，小程序在業界產品(pin)中(zhong)占(zhan)有非常重(zhong)要的(de)(de)(de)地位。本文從小(xiao)程序的(de)(de)(de)質量保障需求出(chu)發，分(fen)析小(xiao)程序的(de)(de)(de)測(ce)試(shi)難(nan)點，引出(chu)小(xiao)程序可(ke)測(ce)性的(de)(de)(de)基本概念(nian)，介紹美團到店研發平(ping)臺針對小(xiao)程序可(ke)測(ce)性改進的(de)(de)(de)通用化方案(an)。最后分(fen)享美團門票(piao)業務(wu)小(xiao)程序測(ce)試(shi)工作的(de)(de)(de)實踐經(jing)驗，本文旨在為(wei)讀(du)者在小(xiao)程序質量保障領域提供一(yi)些有價值的(de)(de)(de)見解(jie)和啟(qi)示。

3. 美團門(men)票業務小程序測試實踐

4. 總結與展望

Q&A

1. 引言

測(ce)(ce)試(shi)活(huo)動從本質上可以視為(wei)(wei)被測(ce)(ce)系(xi)統(tong)因(yin)為(wei)(wei)某個激勵(li)(li)產生相應的響(xiang)(xiang)應，并對這些響(xiang)(xiang)應進行全面檢測(ce)(ce)的過程(cheng)。這個過程(cheng)（激勵(li)(li)->響(xiang)(xiang)應->檢查）涉(she)及(ji)(ji)到兩個角色：測(ce)(ce)試(shi)者(zhe)(zhe)以及(ji)(ji)測(ce)(ce)試(shi)對象，測(ce)(ce)試(shi)者(zhe)(zhe)執行激勵(li)(li)與檢查響(xiang)(xiang)應，由機器（程(cheng)序）或者(zhe)(zhe)人來完成；被測(ce)(ce)對象接受激勵(li)(li)，產生響(xiang)(xiang)應。從這個過程(cheng)來看：激勵(li)(li)可控，響(xiang)(xiang)應可觀(guan)，稱之為(wei)(wei)可測(ce)(ce)。以實際業務(wu)測(ce)(ce)試(shi)為(wei)(wei)例，修改(gai)緩存、網絡請求(qiu)MCOK、頁面跳轉(zhuan)、用戶登錄(lu)態設置等都屬于(yu)可測(ce)(ce)性(xing)能力。

在(zai)(zai)未經過任(ren)何可測(ce)性改進的終(zhong)端產品(pin)中(zhong)，測(ce)試(shi)人(ren)員只能通過UI交互，從UI界面(mian)觀(guan)察來完(wan)成(cheng)最基(ji)本的質量(liang)保(bao)障(zhang)。然而應用內部存(cun)在(zai)(zai)各種各樣復雜的邏輯、狀態，要(yao)進行更加深入的測(ce)試(shi)則需(xu)要(yao)對這(zhe)些信(xin)息進行介(jie)入與觀(guan)測(ce)。例如，在(zai)(zai)進行打點(dian)測(ce)試(shi)時，操作頁面(mian)后，需(xu)確認打點(dian)信(xin)息是否被正常上報，這(zhe)一過程通常依賴網絡代理調(diao)試(shi)工具來完(wan)成(cheng)校驗(yan)。同樣，在(zai)(zai)用戶登(deng)錄(lu)測(ce)試(shi)環節中(zhong)，登(deng)錄(lu)完(wan)成(cheng)后，需(xu)要(yao)檢查緩存(cun)是否已正確記錄(lu)登(deng)錄(lu)信(xin)息，這(zhe)要(yao)求(qiu)具備緩存(cun)查看的能力，這(zhe)些體現了實際業(ye)務測(ce)試(shi)場景對可測(ce)性能力的需(xu)求(qiu)。

整體而言，完(wan)備地(di)構造出目標場景進行測(ce)試(shi)涉(she)及到多個復雜的方面，同時觀(guan)測(ce)它是否符合預(yu)期(qi)(qi)也比較困難，如下圖所示(shi)。終(zhong)端測(ce)試(shi)長期(qi)(qi)面臨著挑戰(zhan)。為(wei)應對這些挑戰(zhan)，我們(men)以(yi)增強可(ke)測(ce)性為(wei)基礎，將其貫穿測(ce)試(shi)活(huo)動的始終(zhong)，使得測(ce)試(shi)能更(geng)細(xi)粒度(du)地(di)檢(jian)查系(xi)統，提(ti)高測(ce)試(shi)深度(du)和效率。

作為終(zhong)端(duan)產品的一(yi)(yi)種形(xing)態，小(xiao)程序是運行在宿主(zhu)應(ying)用（如微信(xin)(xin)、快(kuai)手(shou)、百度(du)等(deng)）之上的“輕應(ying)用”，在2017年(nian)由微信(xin)(xin)推出后發(fa)展迅速。由于小(xiao)程序非常依賴于宿主(zhu)應(ying)用環(huan)境，因此在測試過程中，除了(le)面(mian)臨(lin)終(zhong)端(duan)測試固有的難(nan)點外，它還存在一(yi)(yi)些特殊的影響因素(su)。

從運行機制(zhi)的(de)角度來看，小(xiao)程序的(de)代(dai)碼邏(luo)輯運行在宿(su)主(zhu)應用(yong)提供的(de)容器環境內，它無法直(zhi)接(jie)控制(zhi)宿(su)主(zhu)應用(yong)本身和手機系(xi)統，這在一定程度上增(zeng)大了測(ce)試與可測(ce)性(xing)改進(jin)的(de)難度。

在目前的(de)實(shi)踐(jian)中，針(zhen)對小程(cheng)序的(de)測(ce)試主(zhu)要(yao)存在以下幾種工具和(he)策略：

采用如Charles、Fiddler等(deng)網絡代理工(gong)具進行(xing)HTTP/HTTPS請求和響應的(de)代理分(fen)析與校驗(yan)。雖然這類工(gong)具適(shi)合(he)進行(xing)數據包的(de)抓(zhua)取和分(fen)析，但它(ta)們通常無法(fa)深入(ru)小程序的(de)內(nei)部(bu)架構，因此無法(fa)全方位控制或感知應用的(de)內(nei)部(bu)狀態。

運用圖(tu)像處理技(ji)術的(de)自動化測(ce)試(shi)工具(ju)如Airtest進行測(ce)試(shi)，它們主要關(guan)注于界面(mian)層(ceng)面(mian)的(de)操作，未能觸及應用程序(xu)背(bei)后的(de)邏輯處理，因此仍屬于“黑盒測(ce)試(shi)”的(de)范疇。

利用微信(xin)(xin)官方提(ti)供的(de)(de)Minium小(xiao)程(cheng)序(xu)測(ce)(ce)試工具(ju)(ju)來執(zhi)行更(geng)為精細的(de)(de)測(ce)(ce)試操作(zuo)，能夠進(jin)行諸(zhu)如API Mocking等內(nei)部控(kong)制(zhi)。然而，該方法操作(zuo)復雜，并(bing)依(yi)賴于(yu)微信(xin)(xin)開(kai)發者工具(ju)(ju)，而后者與真機環(huan)境(jing)之間存在一定(ding)差異，可(ke)能影(ying)響(xiang)測(ce)(ce)試結果的(de)(de)準確性。

開發專用的(de)自研(yan)調試面板用以驗證程(cheng)序(xu)邏輯和(he)測(ce)試特定場景，但這些工具設計(ji)時(shi)常(chang)(chang)常(chang)(chang)專注(zhu)于特定小程(cheng)序(xu)，不(bu)易遷移(yi)至其(qi)他(ta)應用，而且(qie)它們(men)通常(chang)(chang)不(bu)支持自動化(hua)測(ce)試流程(cheng)。

綜(zong)(zong)上所述，盡管存在多種測(ce)試工具和方法，但目前尚(shang)缺乏(fa)一(yi)套綜(zong)(zong)合性的(de)、易于使用的(de)測(ce)試工具集，能夠全面提(ti)升(sheng)小程序的(de)可(ke)測(ce)性。

2. 小(xiao)程序可測性介紹(shao)

終端可(ke)測性(xing)能力(li)全(quan)景圖

小程(cheng)序(xu)可(ke)(ke)(ke)(ke)測(ce)性(xing)的(de)目(mu)標在于構建一套全方位的(de)通用小程(cheng)序(xu)可(ke)(ke)(ke)(ke)測(ce)性(xing)能(neng)力集合。該體(ti)系(xi)無縫支持真機和模擬器環(huan)境(jing)，兼容多(duo)端(duan)、多(duo)平臺，并(bing)允許(xu)不同應(ying)用以低成本輕松接(jie)入。它能(neng)深入核心，為小程(cheng)序(xu)提(ti)(ti)供(gong)全面(mian)而多(duo)元的(de)可(ke)(ke)(ke)(ke)觀測(ce)性(xing)與(yu)可(ke)(ke)(ke)(ke)控性(xing)，覆蓋應(ying)用界面(mian)、內部狀態、存(cun)儲等關鍵(jian)領域。這一體(ti)系(xi)旨在賦能(neng)測(ce)試(shi)者更(geng)便捷(jie)地應(ying)對復雜測(ce)試(shi)場景，顯著提(ti)(ti)高測(ce)試(shi)的(de)效率與(yu)深入度(du)。

經過了長期的(de)(de)建設積累(lei)，目前我們(men)已(yi)經構建了一(yi)套比較全面的(de)(de)終端可(ke)(ke)(ke)(ke)測(ce)性(xing)(xing)(xing)(xing)能(neng)(neng)力(li)(li)集，包含(han)Android、iOS、小(xiao)程序(xu)、Web等技(ji)術棧(zhan)。其中小(xiao)程序(xu)由于(yu)系(xi)統的(de)(de)結(jie)構特殊性(xing)(xing)(xing)(xing)，可(ke)(ke)(ke)(ke)測(ce)性(xing)(xing)(xing)(xing)能(neng)(neng)力(li)(li)相對其它端會有(you)一(yi)些不同。小(xiao)程序(xu)可(ke)(ke)(ke)(ke)測(ce)性(xing)(xing)(xing)(xing)主要(yao)包括業務邏輯可(ke)(ke)(ke)(ke)測(ce)性(xing)(xing)(xing)(xing)、應用(yong)可(ke)(ke)(ke)(ke)測(ce)性(xing)(xing)(xing)(xing)、系(xi)統&設備可(ke)(ke)(ke)(ke)測(ce)性(xing)(xing)(xing)(xing)三(san)個層級(ji)，在(zai)每個層級(ji)中包含(han)多(duo)個垂(chui)直的(de)(de)細分方向，除了支(zhi)持多(duo)技(ji)術棧(zhan)的(de)(de)公共(gong)可(ke)(ke)(ke)(ke)測(ce)性(xing)(xing)(xing)(xing)能(neng)(neng)力(li)(li)，還提供了如AppData、宿主應用(yong)信息可(ke)(ke)(ke)(ke)觀可(ke)(ke)(ke)(ke)控等特有(you)能(neng)(neng)力(li)(li)。下面以幾個典型能(neng)(neng)力(li)(li)說(shuo)明小(xiao)程序(xu)可(ke)(ke)(ke)(ke)測(ce)性(xing)(xing)(xing)(xing)使用(yong)方式與效果。

| 2.1 使用方式與效果

在(zai)實際(ji)的(de)手(shou)工(gong)以及自動化測(ce)試工(gong)作(zuo)中，小程序可測(ce)性能力能夠很(hen)方便的(de)使用，并在(zai)多個場景下發揮了重要的(de)作(zuo)用。

2.1.1 手工測試

下面(mian)將以緩(huan)存管理(li)、頁面(mian)跳轉功能為例介紹小程(cheng)序在手工測試中(zhong)的使(shi)用方式以及(ji)效果。

在實際的測(ce)(ce)(ce)(ce)試工作中(zhong)，會(hui)結合Lyrebird使(shi)用小程序可(ke)測(ce)(ce)(ce)(ce)性(xing)，Lyrebird是美團到店研發平臺自(zi)研的終(zhong)端(duan)測(ce)(ce)(ce)(ce)試工作臺，包含(han)終(zhong)端(duan)狀(zhuang)態(tai)數據管理、網絡請求代(dai)理與(yu)Mock、缺陷記(ji)錄、自(zi)定義(yi)插件擴(kuo)展等能(neng)力。同時它還提供了(le)圖形化操作界面(mian)，是手工與(yu)自(zi)動化測(ce)(ce)(ce)(ce)試中(zhong)使(shi)用可(ke)測(ce)(ce)(ce)(ce)性(xing)能(neng)力的入口。

在小程序接(jie)(jie)入可(ke)測性能力(li)SDK之后，可(ke)以通過可(ke)測性SDK提供的掃碼功能與Lyrebird建立連接(jie)(jie)，后續就可(ke)以通過Lyrebird在PC端利用可(ke)測性對小程序進(jin)行控制(zhi)以及觀測。

緩存管理

我(wo)們(men)可以通過緩(huan)存(cun)管理(li)功(gong)能(neng)驗證(zheng)依賴緩(huan)存(cun)的業務邏輯正確性(xing)，如(ru)表單信息(xi)\用戶(hu)信息(xi)暫(zan)存(cun)到緩(huan)存(cun)功(gong)能(neng)等(deng)。

頁面跳轉

頁面跳轉(zhuan)是小程序業務測(ce)試(shi)(shi)中(zhong)重(zhong)度(du)使(shi)用的能力，可以(yi)利用該功能跳轉(zhuan)到(dao)如表單(dan)頁，商品詳情頁等中(zhong)間頁面，不(bu)再需要從首(shou)頁一(yi)步一(yi)步操(cao)作(zuo)(zuo)進入(ru)(ru)目標被測(ce)頁面，減少測(ce)試(shi)(shi)前置準備工作(zuo)(zuo)，具(ju)體可以(yi)在該Lyrebird頁面中(zhong)輸(shu)入(ru)(ru)頁面路徑進行跳轉(zhuan)。

2.1.2 自動化測(ce)試(shi)

將可(ke)測(ce)性能力結合Lyrebird應用于自動化測(ce)試。如通過頁(ye)面(mian)跳轉能力直達測(ce)試場景(jing)，然后利(li)用通過可(ke)測(ce)性錄制的(de)頁(ye)面(mian)狀(zhuang)態(tai)數據進(jin)行場景(jing)狀(zhuang)態(tai)還原后進(jin)行頁(ye)面(mian)渲染，獲(huo)取(qu)頁(ye)面(mian)上的(de)數據/布局展示(shi)，最后將實際(ji)運行圖(tu)和(he)預(yu)先設置(zhi)好的(de)頁(ye)面(mian)基準圖(tu)進(jin)行對比(bi)，提(ti)供渲染的(de)差異結果，進(jin)行視覺(jue)DIFF測(ce)試。

這(zhe)類“視覺測(ce)試”以頁面為單位，通過深度鏈接跳轉(zhuan)技(ji)術配(pei)合一系(xi)列(lie)終端(duan)應用本身(shen)的(de)可測(ce)性改造，直達測(ce)試場景，并(bing)通過圖像處理技(ji)術如長圖融合、圖像增量(liang)對(dui)比和文本識別能力進行視覺DIFF測(ce)試。

可測(ce)(ce)(ce)性建設(she)的是對應(ying)用(yong)(yong)內(nei)部狀態的可觀(guan)可控能力，對于任(ren)何測(ce)(ce)(ce)試(shi)方法，只要涉及應(ying)用(yong)(yong)內(nei)部，可測(ce)(ce)(ce)性都能發揮(hui)重要作用(yong)(yong)。比如在健壯性測(ce)(ce)(ce)試(shi)中通過可測(ce)(ce)(ce)性構造破(po)壞性異常場(chang)景(jing)，或(huo)者在功能測(ce)(ce)(ce)試(shi)中模擬小程(cheng)序不(bu)同的進入(ru)方式（如二維(wei)碼、視(shi)頻(pin)號、搜索等(deng)）來測(ce)(ce)(ce)試(shi)所有可能的使用(yong)(yong)場(chang)景(jing)下小程(cheng)序的運(yun)行情況。

| 2.2 接(jie)入方(fang)式

小程(cheng)(cheng)序可測(ce)性能力SDK被封裝為一(yi)個NPM包，在小程(cheng)(cheng)序源代碼(ma)或者編(bian)譯產物項目中引入此NPM包，便可實現可測(ce)性能力的(de)接入，無需(xu)進(jin)行(xing)額外適配工作。

跨平臺運行

除了(le)對微信(xin)(xin)小(xiao)程序(xu)的支持(chi)之外(wai)，小(xiao)程序(xu)可(ke)測性(xing)能(neng)力SDK通過集成一個適配器（Adapter）將能(neng)力擴(kuo)展(zhan)到多宿(su)主應用(yong)，包括美團、支付寶(bao)、快手(shou)、百(bai)度等(deng)平(ping)(ping)臺(tai)的支持(chi)。這些平(ping)(ping)臺(tai)的基礎(chu)庫API與(yu)微信(xin)(xin)類似(si)，適配器會根據不同平(ping)(ping)臺(tai)的特點，對代碼進行相應的調整(zheng)，包括基礎(chu)庫API、前端語法或(huo)文(wen)件類型(xing)等(deng)，以保證在各個平(ping)(ping)臺(tai)上(shang)的兼容(rong)性(xing)和一致(zhi)性(xing)，實現跨平(ping)(ping)臺(tai)運行。

| 2.3 實現原(yuan)理

小(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)可(ke)測(ce)性(xing)(xing)實現的核心思(si)路是(shi)通過JavaScript Hook的方式，在(zai)小(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)JavaScript Runtime中對(dui)如微信小(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)JS基(ji)礎(chu)庫、業務公共基(ji)礎(chu)組(zu)件等目標模塊(kuai)進行透明化介入，實現對(dui)其內部(bu)(bu)的可(ke)觀(guan)可(ke)控。在(zai)此之(zhi)后(hou)，通過可(ke)測(ce)性(xing)(xing)SDK內的中控與外部(bu)(bu)建(jian)立網(wang)絡鏈接，從(cong)而實現在(zai)遠端對(dui)小(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)內部(bu)(bu)狀態(tai)與功能的可(ke)觀(guan)可(ke)控。

JavaScript Hook介紹

JavaScript Hook基(ji)于(yu)JavaScript的動態特性，有(you)以下(xia)方法：

函數Hook：直接覆(fu)蓋或修改(gai)原(yuan)函數：

let?_originAlert?=?alert;??//?保存原函數
alert?=?function?()?{
??console.log('alert執行開始');
??_originAlert.apply(this,?arguments);?//執行原函數
??console.log('alert執行結束');
}

對象屬性Hook：通過Object defineProperty定義(yi)新(xin)的或直接修改某個(ge)對象的屬性，如修改Getter/Setter方(fang)法，控制對某個(ge)對象的獲(huo)取/設置流程。

Object.defineProperty(document,?'cookie',?{
??set:?function(val)?{??//?控制cookie的設置流程
????console.log('獲得cookie:?',?val);
????currentCookie?=?val;
????return?val;
??},
??get:?function()?{??//?控制cookie的獲取流程
????return?null;
??}
});

原(yuan)(yuan)型鏈Hook：修(xiu)改原(yuan)(yuan)型鏈上(shang)的數(shu)據，如(ru)String、Date。

let?_originalGetTime?=?Date.prototype.getTime;??//?保存原型鏈原方法
Date.prototype.getTime?=?function()?{
??console.log('getTime?has?been?called');?
??return?originalGetTime.apply(this,?arguments);?//執行原方法
};

Proxy對象：創(chuang)建代理模式替代原始對象，可以(yi)重新定義獲取、設置和定義屬性等基本對象操作。

//?創建Proxy有兩個參數：
// target：要代理的原始對象
// handler：定義哪些操作將被攔截以及如何重新定義被攔截操作的對象
let?handler?=?{
??get:?function(target,?prop)?{
????console.log(`獲取?${prop}`);
????return?target[prop];
??},
??set:?function(target,?prop,?val)?{
????console.log(`設置?${prop}?值為?${val}`);
????target[prop]?=?val;
????return?true;
??}
};

let?proxy?=?new?Proxy(window,?handler);

proxy.test?=?'test';?????//?輸出:?Setting?test?to?test
console.log(proxy.test);?//?輸出:?Getting?test
?????????????????????????//??????test???
?????????????????????????

靜態Hook：小(xiao)程序構建時在特定文件中直接修(xiu)改其JavaScript源(yuan)代碼。

其他方(fang)式這里就不詳細(xi)展開(kai)了。

可(ke)測性(xing)SDK的大體可(ke)分為四(si)層：

下(xia)面將以網絡請求可觀可控為例介紹小程序可測性的實現原理。

網絡請求代理

當外部(bu)希望(wang)控制小程(cheng)(cheng)序設(she)置(zhi)網絡代理時，整(zheng)體(ti)流程(cheng)(cheng)如(ru)下：

外部（人(ren)/機器(qi)）首先通過(guo)HTTP/WebSocket方式傳(chuan)遞包含設置小程(cheng)序請求代理的(de)指令，如(ru)圖即(ji)攔截(jie)小程(cheng)序發(fa)送(song)的(de)請轉發(fa)到127.0.0.1:1234代理服務(wu)器(qi)；

可(ke)測(ce)性SDK在通信(xin)層接收相應的(de)指(zhi)(zhi)(zhi)(zhi)令(ling)(ling)后(hou)。將其(qi)傳遞給指(zhi)(zhi)(zhi)(zhi)令(ling)(ling)分(fen)發(fa)層。在指(zhi)(zhi)(zhi)(zhi)令(ling)(ling)分(fen)發(fa)層中，收到指(zhi)(zhi)(zhi)(zhi)令(ling)(ling)后(hou)進行(xing)(xing)解析，并(bing)按預定規(gui)則(ze)對指(zhi)(zhi)(zhi)(zhi)令(ling)(ling)執(zhi)行(xing)(xing)進行(xing)(xing)編排(pai)，確定執(zhi)行(xing)(xing)順序(xu)；

指令分(fen)發層按編排(pai)順(shun)序調用功(gong)能層設置網絡(luo)代(dai)理并(bing)傳入開啟狀態和代(dai)理服務器地(di)址(zhi)參數，功(gong)能層通過(guo)修改這(zhe)兩個變量，控制Hook層對請求API的(de)攔截，從而改變請求代(dai)理的(de)狀態；

Hook層攔(lan)截微信基(ji)礎庫里wx對象的request方法，如下圖代碼所示，分為(wei)以下流程

a.保存wx.request原始(shi)方法的(de)引(yin)用（3行(xing)），并通過(guo)Object.defineProperty將wx對象設(she)置為(wei)可寫狀態(tai)（4-8行(xing)）；

b.將(jiang)wx.request修改為Hook的新方法。新方法的入參(can)與(yu)原始wx.request一(yi)致，包(bao)括請求(qiu)頭、請求(qiu)地(di)址(zhi)、響應(ying)體等，因此(ci)可以(yi)對這些參(can)數(shu)進行修改（12行），比(bi)如替換(huan)請求(qiu)域名(ming)、增(zeng)加請求(qiu)頭、修改響應(ying)體數(shu)據(ju)等；

c.最后(hou)用(yong)修改(gai)后(hou)的參(can)數使用(yong)原始方法進(jin)行執行（13行）。

Hook層通過(guo)mockStatus和(he)mockUrl兩個變量控制到小程序是否被代(dai)(dai)理(li)(li)(li)(li)以及(ji)代(dai)(dai)理(li)(li)(li)(li)服務器地址(zhi)（19-22行），當開發(fa)者(zhe)代(dai)(dai)碼中使(shi)用(yong)wx.request發(fa)起請(qing)求(qiu)時，會先經過(guo)Hook指向的新方法。如果被設置代(dai)(dai)理(li)(li)(li)(li)，請(qing)求(qiu)地址(zhi)將會根據代(dai)(dai)理(li)(li)(li)(li)服務器協議進行修改，從而(er)使(shi)得請(qing)求(qiu)被代(dai)(dai)理(li)(li)(li)(li)。

3. 美團(tuan)門(men)票業務小程序測試實踐

在到店(dian)眾多應用了(le)小程序可測性(xing)能力的(de)業務(wu)中，美團(tuan)門票業務(wu)從2021年開始即(ji)參與了(le)小程序可測性(xing)建(jian)設，目前在門票質(zhi)量保障工作中，可測性(xing)相關能力深度(du)應用在新(xin)需(xu)求測試(shi)、回(hui)歸(gui)測試(shi)、線上巡檢等各種(zhong)類型的(de)測試(shi)活動中。

| 3.1 可測性落(luo)地

下(xia)面(mian)通過門票業(ye)務(wu)一個(ge)具體(ti)的新需(xu)求測試例(li)子來(lai)介(jie)紹可測性如何在測試活動中進行落地。

需求背景

用戶從商品詳(xiang)情頁(ye)進(jin)入到填單頁(ye)，在選擇日期、數量或填寫游玩人等信(xin)息(xi)后，為了減(jian)少用戶的(de)操作(zuo)，再次進(jin)入該(gai)填單頁(ye)需要保持之前(qian)填寫的(de)信(xin)息(xi)不變。

操作路徑劃分

該過程需要經過以下步驟：進(jin)入(ru)填(tian)單(dan)(dan)頁 —> 打開(kai)價格日歷彈層，選(xuan)擇相應的(de)日期 —> 添加(jia)數量(liang) —> 填(tian)寫或者選(xuan)擇游玩人(ren) —> 點擊(ji)返回退(tui)出(chu)填(tian)單(dan)(dan)頁 —> 再次進(jin)入(ru)填(tian)單(dan)(dan)頁，查看它(ta)當前的(de)狀態。我們(men)選(xuan)擇對緩存進(jin)行可測性改進(jin)，依靠指令數據(ju)驅動+內部(bu)方法調用來達到(dao)同等UI操作(zuo)的(de)效果，保障此類場景(jing)測試的(de)穩定性并(bing)提高執行效率。

技術實現

整體通(tong)過緩(huan)存(cun)(cun)實現。在進入(ru)填(tian)單(dan)頁(ye)(ye)時(shi)(shi)，首先會讀取小(xiao)程序(xu)上的(de)緩(huan)存(cun)(cun)并渲染；在選擇日期(qi)、數(shu)量(liang)和游(you)玩人時(shi)(shi)，分別對相(xiang)關(guan)信息進行暫存(cun)(cun)；在退(tui)出填(tian)單(dan)頁(ye)(ye)時(shi)(shi)，將這些暫存(cun)(cun)的(de)數(shu)據寫入(ru)緩(huan)存(cun)(cun)。

測試分析

由(you)于進(jin)入填(tian)單(dan)頁(ye)需(xu)要(yao)讀取緩存(cun)(cun)進(jin)行渲染，因(yin)此測試(shi)過程中首先應(ying)從(cong)UI上(shang)進(jin)行驗(yan)證，判斷第二次(ci)(ci)進(jin)入的(de)(de)日(ri)期、數量和游(you)玩人是否與上(shang)一次(ci)(ci)進(jin)入時選(xuan)擇的(de)(de)狀態一致；其次(ci)(ci)還(huan)應(ying)從(cong)數據上(shang)進(jin)行驗(yan)證，即(ji)進(jin)入填(tian)單(dan)頁(ye)有“讀”緩存(cun)(cun)的(de)(de)動(dong)作(zuo)；在退出填(tian)單(dan)頁(ye)時，需(xu)要(yao)將暫存(cun)(cun)的(de)(de)數據寫入緩存(cun)(cun)，因(yin)此測試(shi)過程中應(ying)驗(yan)證數據能正確地寫入緩存(cun)(cun)，而(er)且緩存(cun)(cun)里(li)有正確的(de)(de)值。

可測性能力實踐落地

門票業務(wu)在小程序測試上目前已經落(luo)地多種可(ke)測性能力，如下圖所示(shi)，包括控(kong)制(zhi)(zhi)頁面(mian)跳轉、請(qing)求(qiu)代理、控(kong)制(zhi)(zhi)登(deng)錄(lu)、日志上報、隱私(si)治理、前后端(duan)環境、錄(lu)制(zhi)(zhi)回放、自動化交互控(kong)制(zhi)(zhi)等都在門票測試活動中有相應的(de)落(luo)地，發揮(hui)著非(fei)常重要的(de)作用。

| 3.2 業務實踐總(zong)結

門(men)(men)票(piao)業務(wu)借助可測性(xing)改(gai)進使得測試(shi)(shi)的覆(fu)蓋(gai)更加全面，目(mu)前(qian)30%+的測試(shi)(shi)場景依(yi)賴于可測性(xing)能力(li)進行構(gou)建(jian)。在美團小(xiao)程序和點評(ping)小(xiao)程序的門(men)(men)票(piao)頻道以及(ji)門(men)(men)票(piao)獨(du)立小(xiao)程序上均有(you)上百個自(zi)動(dong)化測試(shi)(shi)用例，頁面覆(fu)蓋(gai)率(lv)已(yi)經達到100%，場景覆(fu)蓋(gai)程度達到80%+。這些測試(shi)(shi)用例在門(men)(men)票(piao)新需(xu)求(qiu)測試(shi)(shi)、回歸(gui)測試(shi)(shi)等各個階段都會觸發自(zi)動(dong)執行，累(lei)計(ji)已(yi)輔助發現上百個有(you)效問題。

4. 總結與展望

美團核心本地商業/到(dao)店研(yan)發(fa)平臺從2021年開始系統(tong)化(hua)建設(she)小(xiao)程(cheng)序可(ke)測(ce)(ce)性(xing)(xing)，到(dao)目前融入到(dao)店終(zhong)端(duan)測(ce)(ce)試(shi)工具鏈以及質量保證體系之中，通過具備(bei)擴展性(xing)(xing)的(de)通用能(neng)力框(kuang)架，融合手工和(he)自動化(hua)測(ce)(ce)試(shi)，貫穿(chuan)測(ce)(ce)試(shi)活動始終(zhong)。未來我們還將持續關注于基礎可(ke)測(ce)(ce)性(xing)(xing)能(neng)力的(de)穩定性(xing)(xing)，聚焦(jiao)具備(bei)更多業務特性(xing)(xing)的(de)可(ke)測(ce)(ce)性(xing)(xing)能(neng)力建設(she)。

Q&A

Q：代理邏輯如果有Bug會不會影響比較(jiao)大

A：代理邏輯(ji)本(ben)身很簡單，出(chu)錯概率不大。進(jin)行Hook時，會有異常監控(kong)能力以及相(xiang)應的(de)兜底策(ce)略，即使(shi)(shi)出(chu)問題(ti)，也盡量降低對(dui)業務實際使(shi)(shi)用的(de)影(ying)響。

Q：可測(ce)性SDK需要對業務代碼進行(xing)改造嗎？

A：不需(xu)要，可測(ce)性SDK對于業務(wu)應用是透明的(de)。

Q：Lyrebird項目和小程序可測性(xing)SDK的關(guan)系是(shi)什么？

A：Lyrebird與(yu)小(xiao)(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)可(ke)(ke)測(ce)(ce)性(xing)(xing)是(shi)兩個獨立(li)的項目。小(xiao)(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)可(ke)(ke)測(ce)(ce)性(xing)(xing)SDK是(shi)以(yi)一個NPM包(bao)(bao)的形式實(shi)現的，在(zai)小(xiao)(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)里安裝NPM包(bao)(bao)，即可(ke)(ke)使小(xiao)(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)具有可(ke)(ke)測(ce)(ce)性(xing)(xing)。Lyrebird可(ke)(ke)以(yi)與(yu)小(xiao)(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)可(ke)(ke)測(ce)(ce)性(xing)(xing)SDK的通信接(jie)口(kou)進行連接(jie)，然后(hou)用戶可(ke)(ke)通過Lyrebird中小(xiao)(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)可(ke)(ke)測(ce)(ce)性(xing)(xing)頁(ye)面使用小(xiao)(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)可(ke)(ke)測(ce)(ce)性(xing)(xing)能力。

Q：針對小程序可測試性能力建(jian)設與實(shi)踐(jian)，我想問下，如果我們要(yao)用你(ni)們的測試工具(ju)，需要(yao)做什么適配嗎？

A：不需(xu)要(yao)進行(xing)額外適配(pei)，最終的呈現會是(shi)NPM包形式，在產物里安裝就可以(yi)接(jie)入我們的可測性能力，可以(yi)對它進行(xing)控制。

Q：生產(chan)環境(jing)會接入可觀測(ce)SDK嗎(ma)？如果接入對(dui)性能有多(duo)大影響？

A：首先是(shi)(shi)對(dui)(dui)它(ta)的(de)(de)(de)性能的(de)(de)(de)影響(xiang)(xiang)，我們實際(ji)上是(shi)(shi)對(dui)(dui)小(xiao)程序(xu)里的(de)(de)(de)基礎庫的(de)(de)(de)API或者一些狀態(tai)數(shu)據進行了攔截，會對(dui)(dui)性能產生一定的(de)(de)(de)影響(xiang)(xiang)，但目前這個影響(xiang)(xiang)范圍對(dui)(dui)業(ye)務來說比較小(xiao)，是(shi)(shi)可接受的(de)(de)(de)。生產環境的(de)(de)(de)不會引入可測性SDK，因此不會對(dui)(dui)線上質量造成影響(xiang)(xiang)。

Q：小程序可測(ce)性有不(bu)適合使用的場景？

小(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)(xu)可(ke)測(ce)性主要針對(dui)(dui)小(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)(xu)前(qian)端手工與自動(dong)化場景(jing)進行能力提升(sheng)，它是(shi)具備(bei)一套通用(yong)(yong)可(ke)擴(kuo)展(zhan)框(kuang)架，可(ke)以按照業務需(xu)(xu)求低成本進行可(ke)測(ce)性能力擴(kuo)展(zhan)，然而，存在特定情況下其適(shi)用(yong)(yong)性受(shou)限(xian)：首(shou)先，由(you)于運行環境的(de)約束，針對(dui)(dui)宿主應用(yong)(yong)如微(wei)信或支付(fu)寶自身的(de)可(ke)測(ce)性需(xu)(xu)求，小(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)(xu)的(de)可(ke)測(ce)性無法支持(chi)。此外，小(xiao)(xiao)(xiao)程(cheng)(cheng)序(xu)(xu)(xu)可(ke)測(ce)性專注于終端測(ce)試，因此對(dui)(dui)于那些需(xu)(xu)求后端服(fu)務鏈路驗(yan)證(zheng)的(de)場景(jing)，并不適(shi)用(yong)(yong)，需(xu)(xu)配合針對(dui)(dui)性工具使用(yong)(yong)。