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

1. 引言

測(ce)(ce)試活動(dong)從本(ben)質(zhi)上(shang)可(ke)以(yi)視為被測(ce)(ce)系(xi)統因為某個(ge)激(ji)(ji)勵產(chan)(chan)生相應(ying)的(de)(de)響(xiang)(xiang)應(ying)，并對這些響(xiang)(xiang)應(ying)進行(xing)全面檢(jian)測(ce)(ce)的(de)(de)過程(cheng)(cheng)。這個(ge)過程(cheng)(cheng)（激(ji)(ji)勵->響(xiang)(xiang)應(ying)->檢(jian)查(cha)）涉及(ji)到兩(liang)個(ge)角(jiao)色：測(ce)(ce)試者(zhe)以(yi)及(ji)測(ce)(ce)試對象，測(ce)(ce)試者(zhe)執行(xing)激(ji)(ji)勵與檢(jian)查(cha)響(xiang)(xiang)應(ying)，由機器（程(cheng)(cheng)序）或(huo)者(zhe)人來(lai)完(wan)成(cheng)；被測(ce)(ce)對象接受(shou)激(ji)(ji)勵，產(chan)(chan)生響(xiang)(xiang)應(ying)。從這個(ge)過程(cheng)(cheng)來(lai)看：激(ji)(ji)勵可(ke)控，響(xiang)(xiang)應(ying)可(ke)觀(guan)，稱之為可(ke)測(ce)(ce)。以(yi)實際(ji)業務測(ce)(ce)試為例，修(xiu)改緩(huan)存、網絡請求MCOK、頁面跳轉、用(yong)戶(hu)登錄態設置(zhi)等(deng)都屬于可(ke)測(ce)(ce)性能力。

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

整體而言，完備地構造出目標場景(jing)進行測(ce)試(shi)涉及到多個復雜的(de)方面(mian)，同(tong)時觀測(ce)它是否符合預期也比(bi)較(jiao)困難，如下圖所示。終(zhong)(zhong)端測(ce)試(shi)長期面(mian)臨著(zhu)挑(tiao)戰。為(wei)應對這些挑(tiao)戰，我們以增(zeng)強可測(ce)性為(wei)基礎，將其貫穿(chuan)測(ce)試(shi)活動的(de)始終(zhong)(zhong)，使得測(ce)試(shi)能(neng)更細粒度地(di)檢查(cha)系統，提高測(ce)試(shi)深度和(he)效率。

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

從(cong)運(yun)行機制的(de)角度來看，小程序的(de)代碼邏輯運(yun)行在(zai)宿主(zhu)應用(yong)提供的(de)容器環境(jing)內，它無法直接控制宿主(zhu)應用(yong)本(ben)身和(he)手機系統，這(zhe)在(zai)一定程度上(shang)增大了測試(shi)與可測性(xing)改進的(de)難度。

在目前的實(shi)踐中，針對小(xiao)程序的測試主(zhu)要存(cun)在以下(xia)幾(ji)種工具和策略(lve)：

采(cai)用(yong)如Charles、Fiddler等網絡代理工(gong)(gong)(gong)具(ju)進行(xing)HTTP/HTTPS請求和響(xiang)應(ying)的(de)(de)代理分析與校驗(yan)。雖然這(zhe)類工(gong)(gong)(gong)具(ju)適(shi)合進行(xing)數據(ju)包(bao)的(de)(de)抓取和分析，但它們通(tong)常無法(fa)(fa)深入小(xiao)程(cheng)(cheng)序(xu)(xu)的(de)(de)內部(bu)(bu)架構，因(yin)此(ci)無法(fa)(fa)全(quan)方位控(kong)制(zhi)或感知應(ying)用(yong)的(de)(de)內部(bu)(bu)狀態。運用(yong)圖像(xiang)處(chu)理技術(shu)的(de)(de)自(zi)動化測(ce)試(shi)(shi)(shi)工(gong)(gong)(gong)具(ju)如Airtest進行(xing)測(ce)試(shi)(shi)(shi)，它們主要關注于界面層面的(de)(de)操作，未能觸及應(ying)用(yong)程(cheng)(cheng)序(xu)(xu)背后(hou)(hou)的(de)(de)邏(luo)輯處(chu)理，因(yin)此(ci)仍(reng)屬于“黑(hei)盒(he)測(ce)試(shi)(shi)(shi)”的(de)(de)范疇。利用(yong)微信官(guan)方提供的(de)(de)Minium小(xiao)程(cheng)(cheng)序(xu)(xu)測(ce)試(shi)(shi)(shi)工(gong)(gong)(gong)具(ju)來(lai)執行(xing)更為精細的(de)(de)測(ce)試(shi)(shi)(shi)操作，能夠進行(xing)諸如API Mocking等內部(bu)(bu)控(kong)制(zhi)。然而(er)，該方法(fa)(fa)操作復雜(za)，并依(yi)賴于微信開發(fa)者工(gong)(gong)(gong)具(ju)，而(er)后(hou)(hou)者與真機(ji)環境之間存(cun)在一(yi)定(ding)(ding)差異(yi)，可能影響(xiang)測(ce)試(shi)(shi)(shi)結果(guo)的(de)(de)準(zhun)確性。開發(fa)專用(yong)的(de)(de)自(zi)研調試(shi)(shi)(shi)面板用(yong)以驗(yan)證程(cheng)(cheng)序(xu)(xu)邏(luo)輯和測(ce)試(shi)(shi)(shi)特定(ding)(ding)場景，但這(zhe)些工(gong)(gong)(gong)具(ju)設計時常常專注于特定(ding)(ding)小(xiao)程(cheng)(cheng)序(xu)(xu)，不(bu)易遷移(yi)至其他應(ying)用(yong)，而(er)且它們通(tong)常不(bu)支持自(zi)動化測(ce)試(shi)(shi)(shi)流程(cheng)(cheng)。

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

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

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

小(xiao)程序可測(ce)性(xing)(xing)(xing)的目標在于構建一(yi)套(tao)全方位的通用(yong)小(xiao)程序可測(ce)性(xing)(xing)(xing)能(neng)(neng)力集合。該體系(xi)無縫支持真機和模擬器環境，兼(jian)容多端(duan)、多平臺，并允許不同應用(yong)以低(di)成本(ben)輕松接入(ru)。它能(neng)(neng)深(shen)入(ru)核心(xin)，為小(xiao)程序提(ti)供全面而多元的可觀(guan)測(ce)性(xing)(xing)(xing)與可控(kong)性(xing)(xing)(xing)，覆(fu)蓋應用(yong)界面、內部(bu)狀(zhuang)態、存儲等關(guan)鍵領域。這(zhe)一(yi)體系(xi)旨在賦(fu)能(neng)(neng)測(ce)試者更便捷地應對復雜測(ce)試場景，顯著提(ti)高測(ce)試的效(xiao)率與深(shen)入(ru)度(du)。

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

2.1 使用方(fang)式(shi)與效果

在(zai)實(shi)際(ji)的手工以(yi)及(ji)自動(dong)化測(ce)試工作中(zhong)，小程序(xu)可測(ce)性(xing)能力(li)能夠很方(fang)便的使用，并(bing)在(zai)多(duo)個場景下發揮了重(zhong)要(yao)的作用。

2.1.1 手工測試

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

在實(shi)際的測試工作中(zhong)，會結合Lyrebird使(shi)用小(xiao)程序可測性(xing)(xing)，Lyrebird是(shi)美團到(dao)店(dian)研(yan)發平臺(tai)自(zi)研(yan)的終(zhong)端(duan)測試工作臺(tai)，包含終(zhong)端(duan)狀態數據管(guan)理、網絡請(qing)求(qiu)代(dai)理與(yu)Mock、缺(que)陷記錄、自(zi)定(ding)義插件(jian)擴展等能(neng)力(li)。同時它還(huan)提供了圖形化(hua)(hua)操作界(jie)面(mian)，是(shi)手(shou)工與(yu)自(zi)動化(hua)(hua)測試中(zhong)使(shi)用可測性(xing)(xing)能(neng)力(li)的入口(kou)。

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

緩存管理

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

頁面跳轉

頁(ye)(ye)面跳(tiao)轉(zhuan)是小程(cheng)序(xu)業務測試(shi)中(zhong)重度使用(yong)的能力，可(ke)以(yi)利用(yong)該(gai)功能跳(tiao)轉(zhuan)到如表單頁(ye)(ye)，商品詳情頁(ye)(ye)等中(zhong)間(jian)頁(ye)(ye)面，不再需要(yao)從(cong)首頁(ye)(ye)一步一步操作(zuo)進(jin)入目標被測頁(ye)(ye)面，減少測試(shi)前置準備工作(zuo)，具(ju)體可(ke)以(yi)在(zai)該(gai)Lyrebird頁(ye)(ye)面中(zhong)輸入頁(ye)(ye)面路徑(jing)進(jin)行跳(tiao)轉(zhuan)。

2.1.2 自動化測(ce)試

將可(ke)測(ce)性能(neng)力結(jie)合Lyrebird應用于(yu)自動化測(ce)試。如(ru)通(tong)過(guo)頁(ye)(ye)(ye)面跳轉能(neng)力直達測(ce)試場(chang)景，然后利用通(tong)過(guo)可(ke)測(ce)性錄(lu)制的(de)頁(ye)(ye)(ye)面狀(zhuang)態(tai)數據進(jin)行(xing)場(chang)景狀(zhuang)態(tai)還原后進(jin)行(xing)頁(ye)(ye)(ye)面渲(xuan)染，獲取(qu)頁(ye)(ye)(ye)面上的(de)數據/布局(ju)展(zhan)示，最后將實際(ji)運行(xing)圖和(he)預(yu)先(xian)設(she)置好的(de)頁(ye)(ye)(ye)面基準圖進(jin)行(xing)對比，提供(gong)渲(xuan)染的(de)差(cha)異結(jie)果，進(jin)行(xing)視覺DIFF測(ce)試。

這類“視覺(jue)(jue)測(ce)試”以頁(ye)面為單(dan)位(wei)，通過深(shen)度(du)鏈接跳轉(zhuan)技(ji)(ji)術配合一系列終端應用本(ben)身的可(ke)測(ce)性改進(jin)，直(zhi)達測(ce)試場景，并通過圖像處理(li)技(ji)(ji)術如長圖融合、圖像增(zeng)量對比和文本(ben)識(shi)別能力進(jin)行視覺(jue)(jue)DIFF測(ce)試。

可(ke)測(ce)性建設的是對應用(yong)內(nei)部(bu)狀(zhuang)態(tai)的可(ke)觀可(ke)控能(neng)力，對于任何測(ce)試方法(fa)，只要(yao)涉及應用(yong)內(nei)部(bu)，可(ke)測(ce)性都(dou)能(neng)發(fa)揮重要(yao)作(zuo)用(yong)。比如(ru)在(zai)健壯性測(ce)試中通(tong)過可(ke)測(ce)性構造(zao)破壞性異常場(chang)景，或者在(zai)功能(neng)測(ce)試中模擬小(xiao)程序不同的進入方式（如(ru)二維碼(ma)、視頻(pin)號、搜(sou)索(suo)等）來測(ce)試所有可(ke)能(neng)的使用(yong)場(chang)景下(xia)小(xiao)程序的運行情況(kuang)。

2.2 接入方式

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

跨平臺運行

除(chu)了對(dui)微(wei)信小程序(xu)的支(zhi)持之外，小程序(xu)可(ke)測性能(neng)(neng)力SDK通(tong)過集成(cheng)一個(ge)適配(pei)器（Adapter）將能(neng)(neng)力擴展(zhan)到多個(ge)宿主應(ying)用，包(bao)括美(mei)團、支(zhi)付寶、快手(shou)、百度(du)等平臺的支(zhi)持。這些平臺的基礎庫API與(yu)微(wei)信類(lei)似，適配(pei)器會根據不同(tong)平臺的特(te)點，對(dui)代碼進行(xing)相應(ying)的調(diao)整，包(bao)括基礎庫API、前端語法或(huo)文件(jian)類(lei)型等，以保(bao)證(zheng)在各(ge)個(ge)平臺上的兼容性和一致性，實現跨平臺運行(xing)。

2.3 實現原理

小(xiao)(xiao)(xiao)程序可(ke)(ke)測性(xing)(xing)實現的(de)核心(xin)思路(lu)是通過(guo)JavaScript Hook的(de)方(fang)式，在小(xiao)(xiao)(xiao)程序JavaScript Runtime中對如(ru)微信(xin)小(xiao)(xiao)(xiao)程序JS基礎庫、業務公共(gong)基礎組件等目標模塊進行透明化介入(ru)，實現對其內(nei)部的(de)可(ke)(ke)觀可(ke)(ke)控(kong)。在此(ci)之(zhi)后，通過(guo)可(ke)(ke)測性(xing)(xing)SDK內(nei)的(de)中控(kong)與外(wai)部建立網絡(luo)鏈(lian)接，從而實現在遠(yuan)端對小(xiao)(xiao)(xiao)程序內(nei)部狀態與功能的(de)可(ke)(ke)觀可(ke)(ke)控(kong)。

JavaScript Hook介紹(shao)

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

函數(shu)(shu)Hook：直(zhi)接覆(fu)蓋或修改原函數(shu)(shu)：

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

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

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

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

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

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

// 創建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：小程(cheng)序構建時在(zai)特(te)定文件(jian)中直接修改其JavaScript源代碼(ma)。

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

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

下面將以網絡請(qing)求(qiu)可(ke)觀可(ke)控(kong)為例介紹(shao)小程序可(ke)測性(xing)的(de)實現(xian)原理(li)。

網絡請求代理

當外(wai)部(bu)希望(wang)控制小程(cheng)序設置網絡代理(li)時，整體流(liu)程(cheng)如下：

外部（人/機器(qi)）首(shou)先通(tong)過(guo)HTTP/WebSocket方(fang)式(shi)傳(chuan)遞包含設(she)(she)置小(xiao)程序(xu)請(qing)(qing)求(qiu)代(dai)理(li)(li)的(de)(de)(de)(de)指(zhi)(zhi)令，如圖(tu)即攔(lan)截小(xiao)程序(xu)發(fa)送的(de)(de)(de)(de)請(qing)(qing)求(qiu)轉發(fa)到127.0.0.1:1234代(dai)理(li)(li)服務器(qi)；可(ke)測性(xing)SDK在(zai)(zai)通(tong)信層(ceng)(ceng)(ceng)(ceng)接收(shou)相應的(de)(de)(de)(de)指(zhi)(zhi)令后(hou)。將(jiang)其傳(chuan)遞給(gei)指(zhi)(zhi)令分(fen)(fen)(fen)發(fa)層(ceng)(ceng)(ceng)(ceng)。在(zai)(zai)指(zhi)(zhi)令分(fen)(fen)(fen)發(fa)層(ceng)(ceng)(ceng)(ceng)中(zhong)，收(shou)到指(zhi)(zhi)令后(hou)進(jin)行(xing)(xing)解析，并按預定規則對(dui)(dui)指(zhi)(zhi)令執行(xing)(xing)進(jin)行(xing)(xing)編排，確定執行(xing)(xing)順序(xu)；指(zhi)(zhi)令分(fen)(fen)(fen)發(fa)層(ceng)(ceng)(ceng)(ceng)按編排順序(xu)調用功能(neng)層(ceng)(ceng)(ceng)(ceng)設(she)(she)置網絡代(dai)理(li)(li)并傳(chuan)入(ru)開啟狀態和代(dai)理(li)(li)服務器(qi)地(di)址(zhi)(zhi)參(can)數(shu)，功能(neng)層(ceng)(ceng)(ceng)(ceng)通(tong)過(guo)修改(gai)這兩個變量(liang)，控制Hook層(ceng)(ceng)(ceng)(ceng)對(dui)(dui)請(qing)(qing)求(qiu)API的(de)(de)(de)(de)攔(lan)截，從而改(gai)變請(qing)(qing)求(qiu)代(dai)理(li)(li)的(de)(de)(de)(de)狀態；Hook層(ceng)(ceng)(ceng)(ceng)攔(lan)截微信基礎庫里(li)wx對(dui)(dui)象的(de)(de)(de)(de)request方(fang)法，如下(xia)(xia)圖(tu)代(dai)碼所示，分(fen)(fen)(fen)為以(yi)下(xia)(xia)流程： a.保(bao)存(cun)wx.request原(yuan)始方(fang)法的(de)(de)(de)(de)引用（3行(xing)(xing)），并通(tong)過(guo)Object.defineProperty將(jiang)wx對(dui)(dui)象設(she)(she)置為可(ke)寫(xie)狀態（4-8行(xing)(xing)）； b.將(jiang)wx.request修改(gai)為Hook的(de)(de)(de)(de)新方(fang)法。新方(fang)法的(de)(de)(de)(de)入(ru)參(can)與原(yuan)始wx.request一致(zhi)，包括請(qing)(qing)求(qiu)頭、請(qing)(qing)求(qiu)地(di)址(zhi)(zhi)、響應體等，因此可(ke)以(yi)對(dui)(dui)這些參(can)數(shu)進(jin)行(xing)(xing)修改(gai)（12行(xing)(xing)），比如替(ti)換請(qing)(qing)求(qiu)域(yu)名、增加(jia)請(qing)(qing)求(qiu)頭、修改(gai)響應體數(shu)據等； c.最后(hou)用修改(gai)后(hou)的(de)(de)(de)(de)參(can)數(shu)使(shi)用原(yuan)始方(fang)法進(jin)行(xing)(xing)執行(xing)(xing)（13行(xing)(xing)）。

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

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

在(zai)(zai)到店眾多應用了小程序可(ke)測(ce)(ce)性能(neng)力的(de)業務中，美(mei)團門票業務從2021年(nian)開始即參與了小程序可(ke)測(ce)(ce)性建設，目前在(zai)(zai)門票質(zhi)量保(bao)障工作(zuo)中，可(ke)測(ce)(ce)性相關(guan)能(neng)力均深度(du)應用在(zai)(zai)新需求測(ce)(ce)試(shi)、回歸測(ce)(ce)試(shi)、線上巡檢等各種(zhong)類型的(de)測(ce)(ce)試(shi)活動(dong)中。

3.1 可測性落地

下面通過門(men)票(piao)業務一個具體的新需求測(ce)試(shi)例子(zi)來介紹(shao)可(ke)測(ce)性如何在(zai)測(ce)試(shi)活(huo)動中進行落(luo)地。

需求背景

用(yong)戶(hu)從商品(pin)詳情頁(ye)進入到填(tian)單(dan)頁(ye)，在選(xuan)擇日期、數量或(huo)填(tian)寫(xie)游玩人等(deng)信息后，為了減少(shao)用(yong)戶(hu)的操作路徑，再次進入該填(tian)單(dan)頁(ye)需要(yao)保持之前填(tian)寫(xie)的這些信息不變(bian)。

操作路徑劃分

該過(guo)程(cheng)需要經過(guo)以(yi)下步驟：進(jin)入填(tian)單(dan)頁 —> 打開價格日歷彈層，選(xuan)擇相應的日期 —> 添加(jia)數量 —> 填(tian)寫(xie)或者選(xuan)擇游玩人 —> 點擊返回(hui)退出填(tian)單(dan)頁 —> 再次進(jin)入填(tian)單(dan)頁，查看它當前的狀態。我(wo)們選(xuan)擇對緩存(cun)進(jin)行可測性改進(jin)，依靠指令數據驅(qu)動+內(nei)部方法(fa)調用(yong)來達到同等UI操作的效(xiao)(xiao)果，保障此類場(chang)景測試(shi)的穩定性并(bing)提高執行效(xiao)(xiao)率。

技術實現

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

測試分析

由(you)于進入(ru)填單(dan)頁需要讀(du)取(qu)緩(huan)存進行(xing)渲染，因此測(ce)試過程中首先應(ying)從UI上進行(xing)驗證，判斷(duan)第二次進入(ru)的(de)日期、數(shu)量(liang)和(he)游(you)玩人是否與上一(yi)(yi)次進入(ru)時(shi)選擇的(de)狀態一(yi)(yi)致；其次還(huan)應(ying)從數(shu)據(ju)上進行(xing)驗證，即進入(ru)填單(dan)頁有“讀(du)”緩(huan)存的(de)動(dong)作(zuo)；在退出填單(dan)頁時(shi)，需要將暫存的(de)數(shu)據(ju)寫入(ru)緩(huan)存，因此測(ce)試過程中應(ying)驗證數(shu)據(ju)能正確地(di)寫入(ru)緩(huan)存，而且緩(huan)存里有正確的(de)值。

可測性能力實踐落地

門(men)票(piao)業務在小程(cheng)序測(ce)(ce)試(shi)上目(mu)前(qian)已經落地多種可(ke)測(ce)(ce)性能力，如下圖所示，包括控(kong)制頁面跳轉(zhuan)、請求代理、控(kong)制登錄(lu)、日志上報、隱私治理、前(qian)后(hou)端環(huan)境、錄(lu)制回放、自動化交(jiao)互(hu)控(kong)制等都(dou)在門(men)票(piao)測(ce)(ce)試(shi)活(huo)動中有相應的落地，發揮(hui)著(zhu)非常重(zhong)要的作用。

3.2 業(ye)務實踐總結

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

4. 總結與展望

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

Q&A

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

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

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

A：不需要，可測性(xing)SDK對于(yu)業務應用(yong)是透明的。

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

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

Q：針對小程(cheng)序(xu)可測(ce)試性能力(li)建設與實踐，我想問下(xia)，如(ru)果(guo)我們要用你們的測(ce)試工具，需要做什么適配嗎？

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

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

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

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

小程(cheng)序(xu)(xu)可(ke)測(ce)性(xing)主要(yao)針對(dui)小程(cheng)序(xu)(xu)前端(duan)手(shou)工(gong)與自(zi)動(dong)化場景(jing)進行能(neng)力提升，它(ta)是(shi)具(ju)備一(yi)套通用(yong)可(ke)擴展(zhan)框架，可(ke)以(yi)按照業務(wu)需(xu)(xu)求(qiu)低(di)成(cheng)本進行可(ke)測(ce)性(xing)能(neng)力擴展(zhan)，然而，存在特定情況下(xia)其適用(yong)性(xing)受限：首(shou)先，由于(yu)運行環境的(de)約束，針對(dui)宿主應用(yong)如(ru)微(wei)信或(huo)支(zhi)付(fu)寶自(zi)身的(de)可(ke)測(ce)性(xing)需(xu)(xu)求(qiu)，小程(cheng)序(xu)(xu)的(de)可(ke)測(ce)性(xing)無(wu)法支(zhi)持。此(ci)外(wai)，小程(cheng)序(xu)(xu)可(ke)測(ce)性(xing)專(zhuan)注于(yu)終端(duan)測(ce)試(shi)，因此(ci)對(dui)于(yu)那些需(xu)(xu)求(qiu)后端(duan)服務(wu)鏈路驗證的(de)場景(jing)，并不適用(yong)，需(xu)(xu)配合針對(dui)性(xing)工(gong)具(ju)使用(yong)。