一、背景介紹

日常的迭代或者技術改造之后，系統(tǒng)常常會出現(xiàn)一些功能丟失、新增接口權限和頁面白屏等問題。盡管事后可以依靠監(jiān)控大盤查看監(jiān)控數(shù)據(jù)來定位問題，但是這些手段是滯后的，無法提前發(fā)現(xiàn)系統(tǒng)已有問題。

為了保障系統(tǒng)的穩(wěn)定性和強壯性，常見的方案包括代碼層面覆蓋單元測試，保證已有代碼的強壯性，如前端平臺商家組已經(jīng)推行單元測試用例覆蓋，但是也存在以下問題：

• 單元測試測試顆粒度較小
• 大部分單側(cè)邏輯局限于函數(shù)級別的驗證，難以覆蓋整體流程

除了單元測試保障之外，系統(tǒng)集成測試在保障質(zhì)量方面也起著重要作用。然而，集成測試同樣面臨時間成本高、遺漏問題、重復性測試等挑戰(zhàn)。特別是在功能全量回歸場景下, 測試用例數(shù)量龐大，手動回歸測試變得非常繁瑣。盡管業(yè)界已經(jīng)有一些成熟的自動化回歸集成方案，例如通過錄制手段來自動生成測試用例，但這種方案仍然存在一些挑戰(zhàn)： 

• 改變研發(fā)流程具有挑戰(zhàn)性：研發(fā)團隊通常會專注于新功能的開發(fā)和問題修復，所以增加測試用例錄制的環(huán)節(jié)可能會對時間和資源帶來壓力。
• 用例維護成本較高：在敏捷迭代中，頁面UI頻繁變動和核心鏈路不斷更新迭代, 錄制生成的測試用例可能在下一次迭代中變得不再適用或無法執(zhí)行,意味著測試用例需要進行不斷的更新和維護。

確實，為了應對迭代變更帶來的挑戰(zhàn)，的確需要尋找更靈活有效的自動化回歸方案。我們研發(fā)了一款創(chuàng)新的測試工具—Monkey Testing(簡稱Monkey)。本文將深入闡述Monkey的出發(fā)點、創(chuàng)新過程以及落地情況，探討其可行性和價值。

二、Monkey誕生

Monkey , 也有人叫做搞怪測試，一般指用毫無規(guī)律的指令或操作去測試被測系統(tǒng)，觀察被測系統(tǒng)的穩(wěn)定性。

出發(fā)點

基于Monkey自動化平臺與前端平臺B端大倉組件的配套研究方向，圍繞B端單品組件ProTable、ProForm自動化測試可行性驗證。首先模擬真實用戶行為，通過數(shù)據(jù)填充，模擬不同類型的數(shù)據(jù)輸入，并通過Click事件觸發(fā)條件搜索, 來達到驗證接口異常場景下的健壯性的目的。同時，我們將通過劫持請求、捕獲JS執(zhí)行上下文錯誤、網(wǎng)頁截圖判定白屏等方式，發(fā)現(xiàn)潛在的穩(wěn)定性問題，從而提高系統(tǒng)的穩(wěn)定性。

我們提供低成本的自動化回歸方案，需要具有以下效果：

• 測試流程的自動化，降低測試成本同時提高準確性和覆蓋率。
• 線上問題前置化，及早現(xiàn)版本可能存在白屏、接口請求響應異常、JavaScript運行時報錯等常見的通用問題，保障系統(tǒng)在線上環(huán)境的穩(wěn)定性。

核心能力介紹

Monkey端側(cè)自動化能力

圖片

Monkey平臺化能力建設

圖片

Monkey自動化測試核心流程

圖片

上述Monkey自動化測試實現(xiàn)，主要分為以下四個階段：

• 準備階段：在這個階段，首先需要進行B端SSO系統(tǒng)的免登，以確保Monkey能夠正常登錄系統(tǒng)。同時還需要獲取天網(wǎng)菜單數(shù)據(jù)源，以便后續(xù)的操作可以正確地找到對應的頁面和元素。
• 執(zhí)行階段：在這個階段，使用Puppeteer提供的客戶端瀏覽器環(huán)境，搭載隨機測試腳本，模擬用戶的行為操作(簡稱Monkey Runner)。通過這種方式，Monkey執(zhí)行ProTable、ProForm測試模型用例，包括點擊、輸入、選擇等，以覆蓋不同的測試場景。
• 數(shù)據(jù)劫持：在執(zhí)行階段下的操作行為中，Puppeteer會捕獲異常情況。這些異常可能包括頁面加載失敗、元素找不到等問題。通過捕獲這些異常，可以及時發(fā)現(xiàn)并處理潛在的問題，以提高系統(tǒng)穩(wěn)定性。
• 數(shù)據(jù)清洗：在這個階段，基于Node服務實現(xiàn)數(shù)據(jù)上報和清洗。Monkey會將執(zhí)行階段下的操作行為數(shù)據(jù)上報給后臺服務，后臺服務可以對這些數(shù)據(jù)進行分析和處理，以生成測試報告、統(tǒng)計指標等。同時，也可以對數(shù)據(jù)進行清洗，以去除無效或冗余的信息，保持數(shù)據(jù)的準確性和可用性。

三、Monkey創(chuàng)新過程

智能模擬用戶行為

Monkey通過模擬真實用戶的隨機操作(例如點擊、滾動、輸入等）來測試應用程序的輸入輸出是否具有穩(wěn)定性和健壯性，以此來發(fā)現(xiàn)應用程序中的問題和異常行為，例如崩潰、卡死、界面異常等等，覆蓋系統(tǒng)各個功能模塊，發(fā)現(xiàn)潛在問題。

圖片

Monkey以其簡單粗暴的方式隨機生成用戶輸入來模擬各種用戶行為，具有以下特點：

• 高覆蓋率：通過隨機輸入的方式，能夠觸發(fā)系統(tǒng)中各種不同操作。
• 發(fā)現(xiàn)意料之外的異常：由于隨機性，Monkey 能夠發(fā)現(xiàn)一些預料之外的異常情況，幫助提前發(fā)現(xiàn)潛在問題。

盡管Monkey有很大的優(yōu)勢，但也存在一些局限性：

• 準確性和可重復性受限：由于隨機生成輸入的特性，Monkey 無法保證測試的準確性和可重復性，可能導致某些特定場景下的行為無法被模擬。
• 無法模擬特定場景下的用戶行為：由于隨機性導致無法模擬特定用戶行為和上下文環(huán)境，不利于測試特定場景下的交互和功能。

為了收斂Monkey 隨機性，達到更加精細化執(zhí)行測試目的 ，我們將探索Monkey與B端組件二相互結(jié)合的可行性測試。

Monkey結(jié)合B端組件測試

結(jié)合大倉組件能解決什么問題

大倉組件旨在解決前端平臺應用中的交互一致性和可復用性問題。結(jié)合大倉組件，我們可以將組件固化的操作行為拆解為多個測試步驟，每個步驟對應多條測試用例，以確保每個組件都具有各自的交互流程。在Monkey執(zhí)行過程中的用例腳本階段，能夠準確模擬用戶行為，從而消除Monkey測試中的隨機性。

結(jié)合大倉組件實踐

01ProTable單品類組件行為分析&拆解實戰(zhàn)

圖片

操作行為分析

對ProTable組件的操作行為進行分析時，可以著重考慮以下方面：

1. 表格數(shù)據(jù)加載：用戶打開包含ProTable組件頁面時，首先會加載數(shù)據(jù)并顯示在表格，數(shù)據(jù)源通過接口請求獲取。
2. 條件篩選和重置：對ProTable進行條件篩選以便查看數(shù)據(jù)，也可以重置篩選條件以恢復初始狀態(tài)。
3. 表格分頁查詢：使用分頁器進行翻頁等操作，以便展示更多的數(shù)據(jù)內(nèi)容。

拆解步驟

以ProTable組件為例，可以將組件的操作行為拆解成以下步驟：

步驟1：組件加載

• 測試用例：通過DOM Class 或者ID查詢判定是否存在元素。

步驟2：篩選和搜索和重置

• 測試用例: 驗證表格的搜索功能是否正確響應用戶輸入，并能正確篩選和顯示符合條件的數(shù)據(jù)。
• 測試用例：模擬點擊重置按鈕，并確保表單數(shù)據(jù)被成功重置為默認值。

邊界：這塊我們能做的是模擬用戶輸入行為按鈕點擊觸發(fā)搜索。

步驟3：分頁切換

• 測試用例：點擊頁面切換按鈕或輸入頁碼，驗證表格切換 調(diào)用接口有無異常。

邊界：這塊我們能做的是 模擬點擊頁碼行為  劫持請求是否異常。

步驟4：數(shù)據(jù)列渲染

• 測試用例：請求到數(shù)據(jù)，列表元素正常渲染。

注意事項

安全區(qū)域操作約束在測試環(huán)境中，一些刪除或更改操作可能會導致測試數(shù)據(jù)的不一致性或損壞，因此需要對測試環(huán)境中的點擊行為進行約束，確保在安全區(qū)域內(nèi)進行操作。

// 檢查一個元素是否在另外一個元素中 原理類似于JQ   $("#container").has(".selector"); 
const isSafeArea = (parentElement, childElement) => {
  const childClassNames = Array.from(childElement.classList);
  return childClassNames.every(className => parentElement.querySelector(`.${className}`));
};
const layoutContentElement = document.querySelector('.layout-content');
const isisSafeAreaResult =  isSafeArea(layoutContentElement,element)

優(yōu)化導航欄點擊許多B端系統(tǒng)中，導航欄是一個常見的元素。為了更加精確地進行測試并提高效率，我們需要規(guī)避導航欄的點擊或者A鏈接點擊跳轉(zhuǎn)，專注于當前頁面的操作。

element.matches('a')

圖片

02ProForm單品類組件行為分析&拆解實戰(zhàn)

操作行為分析

對ProForm組件的操作行為進行分析時，可以著重考慮以下方面：

1. 數(shù)據(jù)加載或關閉：通過點擊入口按鈕顯示彈窗，彈窗加載表單項：當用戶完成操作后點擊關閉按鈕，彈窗關閉。
2. 表單操作：在彈窗表單項中可以進行數(shù)據(jù)輸入、選擇選項、上傳文件等操作。
3. 數(shù)據(jù)校驗：填寫完表單數(shù)據(jù)后，ProForm組件會對表單數(shù)據(jù)進行校驗，確保輸入數(shù)據(jù)符合規(guī)定的格式要求。
4. 數(shù)據(jù)提交：填寫完表單數(shù)據(jù)后，通過點擊提交按鈕將數(shù)據(jù)提交到后端接口進行保存或更新。

拆解步驟

以ProForm組件為例，可以將組件的操作行為拆解成以下步驟：

步驟1：組件加載

• 測試用例：通過DOM Class 或者ID查詢 判定是否存在元素。

步驟2：表單輸入填充

• 測試用例：表單項漸入數(shù)據(jù)
• 測試用例：驗證表格的搜索功能是否正確響應用戶輸入，并能正確篩選和顯示符合條件的數(shù)據(jù)。
• 測試用例：模擬點擊重置按鈕，并確保表單數(shù)據(jù)被成功重置為默認值。

邊界：開發(fā)FormFilter 函數(shù)盡量滿足通用的場景下的數(shù)據(jù)漸入能力；目前文件上傳場景、下拉聯(lián)動場景、遠程搜索場景未覆蓋。

步驟3：表單驗證

• 測試用例：驗證輸入字段是否滿足預期的格式，如郵箱地址格式、密碼強度等。
• 測試用例：驗證表單的必填字段是否被正確地標記，并且不能提交空值。

邊界：Monkey本身不具備帶有規(guī)則限制表單填充能力；數(shù)據(jù)來源于ProTable頁面數(shù)據(jù)和Input Types類型數(shù)據(jù)填充。

步驟4：表單提交

• 測試用例：模擬點擊提交按鈕攔截接口是有異常。

步驟5：表單取消

• 測試用例：模擬點擊重置按鈕，并確保表單數(shù)據(jù)被成功關閉。

ProForm準確提交率

衡量標準：通過劫持接口請求來判斷Proform是否成功提交，并且服務端接口是否返回狀態(tài)碼200。

指標說明：

• 前端準確提交率：確保表單項數(shù)據(jù)填充完整且點擊提交按鈕能觸發(fā)提交接口(填寫的數(shù)據(jù)能夠通過前端校驗)
• 業(yè)務準確提交率：前端準確提交基礎上，要求提交接口返回的HTTP狀態(tài)碼為200且bsCode為200(填寫的數(shù)據(jù)能夠通過服務端校驗)

統(tǒng)計過程如下：

圖片

1. 為每個巡檢的頁面 URL 分配唯一的 UID，并記錄 UID 與 Page URL 的映射關系。
2. 當頁面彈出新增彈窗時，填充完數(shù)據(jù)并點擊提交，記錄事件類型為 event_type = 'CLICK'，同時記錄時間戳和 UID。
3. 劫持接口數(shù)據(jù)，并記錄事件類型為 event_type = 'RESPONSE'。
4. 對 event_type = 'RESPONSE' 的時間戳進行分組統(tǒng)計，確保大于 event_type = 'CLICK' 的時間戳。

根據(jù)當前數(shù)據(jù)統(tǒng)計，前端準確提交率約為60%+，繞過服務端校驗準確提交率約為20%+。

圖片

表單項數(shù)據(jù)填充

表單項數(shù)據(jù)填充主要有2種類型，分別為Input types填充和劫持表格數(shù)據(jù)源實現(xiàn)精準填充。

圖片

01表單項 - Input types 通用填充

B端系統(tǒng)未接入類型檢測工具,  接口請求參數(shù)類型約束不嚴格。Monkey 會根據(jù) Input Types 類型隨機生成字符串，填充表單項以觸發(fā)接口調(diào)用，發(fā)現(xiàn)接口參數(shù)類型錯誤。

1. Input types 類型窮舉表單項的填充方式(MDN輸入元素)：文本類型(input type="text")、數(shù)據(jù)類型 (input type="number")、郵箱類型 (input type="email")、日期類型(input type="date")、單選框 類型(input type="radio")、復選框類型(input type="checkbox") 

圖片

圖片

// input type 集合
const defaultMapElements = {
    textarea: fillTextAreaElement,
    'input[type="text"]': fillTextElement,
    'input[type="password"]': fillTextElement,
    'input[type="number"]': fillNumberElement,
    select: fillSelect,
    'input[type="radio"]': fillRadio,
    'input[type="checkbox"]': fillCheckbox,
    'input[type="email"]': fillEmail,
    'input:not([type])': fillTextElement,   
 };
 
 // 填充邏輯
 const fillTextElement = async (element, character) => {
  const selectedCharacters = Array.from({ length: 5 }, () =>randomizer.getCharacter[Math.floor(Math.random() * randomizer.getCharacter.length)]).join('');
  const newValue = element.value + (character ? character : selectedCharacters);
  if (element) {
    triggerSimulatedOnChange(element, newValue, window.HTMLInputElement.prototype);
    return newValue;
  }
 };
 
 // Hacky function to trigger react, angular & vue.js onChange on input
 const triggerSimulatedOnChange = (element, newValue, prototype) => {
      const lastValue = element.value;
      element.value = newValue;
      const nativeInputValueSetter = Object.getOwnPropertyDescriptor(prototype, 'value').set;
      nativeInputValueSetter.call(element, newValue);
      const event = new Event('input', { bubbles: true }) as CustomEvent;
      // React 15
      event.simulated = true;
      // React >= 16
      let tracker = element._valueTracker;
      if (tracker) {
          tracker.setValue(lastValue);
      }
      element.dispatchEvent(event);
  };

2. 接口參數(shù)類型錯誤

案例：后臺頁面Barcode條件篩選系統(tǒng)異常。

歸因：前端未限制Barcode只能輸入Number類型；服務端用Long類型字段接收BarCode字段，隨機輸入了String類型的值時，系統(tǒng)出現(xiàn)異常。

• 場景 - 服務端接口參數(shù)未校驗

圖片

• 場景 - 服務端接口參數(shù)已校驗

圖片

圖片

圖片

02表單項 - 精準填充

圖片

說明：在 ProTable 篩選和 ProForm 表單項數(shù)據(jù)填充場景下，希望數(shù)據(jù)填充能夠精確匹配，表單項的數(shù)據(jù)源來自于 ProTable 表格數(shù)據(jù)。統(tǒng)計該數(shù)據(jù)是為了衡量表格數(shù)據(jù)與ProTable & ProForm 輸入項的匹配率指標，該指標為輔助性指標。指標的數(shù)值越高，ProTable場景代表覆蓋篩選場景越多；Proform場景代表表單校驗驗證通過率越高。根據(jù)目前的數(shù)據(jù)統(tǒng)計，整體匹配率占比約為 50%+左右。

實時驗證前后端接口參數(shù)一致性

案例：后臺頁面篩選條件返回結(jié)果錯誤。

歸因：接口字段改動，前端接口請求參數(shù)字段名錯誤。

為解決服務端接口字段調(diào)整導致前端無法及時感知接口參數(shù)變化的問題，我們擬計劃接入文檔接口平臺開放API。通過查詢接口API獲取請求參數(shù)、響應參數(shù)及其類型，以驗證前后端接口參數(shù)的一致性。若接口正常但文檔定義存在問題，可反向約束規(guī)范接口定義文檔流程。

圖片

自動化錯誤捕獲

通過劫持請求、捕獲JS執(zhí)行上下文錯誤、網(wǎng)頁截圖判定白屏等方式，來快速檢測頁面故障。

錯誤類型分類

圖片

常規(guī)錯誤捕獲

除了上述捕獲的錯誤問題,還列舉些其他常見錯誤。這里我們通過場景模擬，驗證Monkey的錯誤捕獲能力。

1. 模擬接口請求404場景 - 劫持請求檢測

圖片

2. 模擬白屏場景 - 白屏檢測

3. 模擬JS 執(zhí)行上下文異常 - 劫持JSError檢測

用例模型定制化配置

在用例管理的前期階段，我們將首先支持系統(tǒng)生成的通用類型用例。這些通用類型用例是根據(jù)業(yè)務需求在開發(fā)過程中編寫的，涵蓋B端系統(tǒng)的主要功能和常見場景。經(jīng)過驗證和測試后，這些用例可以作為基準用例使用。

為了滿足不同場景下的測試需求，將逐步開放定制能力。為用戶提供文檔和示例、可視化配置界面以及插件化擴展機制，降低用戶編寫用例的難度和上手成本。具體內(nèi)容如下：

1. 文檔和示例：提供詳細的文檔和示例，幫助用戶理解如何配置Monkey的用例模型，以及如何利用上述的配置文件、可視化界面和擴展機制來定制Monkey的行為。這樣可以讓用戶更容易上手，并且了解如何利用Monkey的定制化設置來滿足不同的測試需求。
2. 可視化配置界面：為了提高易用性，可以開發(fā)一個可視化的配置界面，讓用戶可以通過圖形化界面來配置Monkey的行為模式和參數(shù)，而不需要直接編輯配置文件。這樣的界面可以提供簡單的拖拽、下拉菜單等操作，讓用戶能夠直觀地配置Monkey的行為。
3. 插件化擴展機制：為了未來開放給用戶并支持更多定制化需求，設計一個插件化的擴展機制，讓用戶可以編寫自定義的插件來擴展Monkey的行為模式。這樣的擴展機制可以提供接口和文檔，讓用戶能夠編寫自定義的行為模式、觸發(fā)條件等，從而實現(xiàn)更靈活的定制化設置。

四、Monkey可行性探索情況

我們成功接入了《運營后臺系統(tǒng)》項目，并順利完成了流程。經(jīng)過數(shù)據(jù)收集和清洗等步驟，產(chǎn)出了數(shù)據(jù)分析報告。

數(shù)據(jù)分析

圖片

圖片

有效錯誤率統(tǒng)計

圖片

注：在每次任務中，錯誤數(shù)量保持相對穩(wěn)定的水平。

五、總結(jié) & 規(guī)劃

Monkey作為一種創(chuàng)新的測試工具，為系統(tǒng)穩(wěn)定性的保障提供了新的思路和方法。通過結(jié)合B端組件可行性探索，我們發(fā)現(xiàn)Monkey在實際項目中具有良好的應用前景和價值。根據(jù)數(shù)據(jù)分析結(jié)果，Monkey在系統(tǒng)穩(wěn)定性的提升方面展現(xiàn)出了巨大的潛力。通過對有效錯誤率、分類錯誤項和優(yōu)化方案的分析，我們發(fā)現(xiàn)Monkey可以幫助識別各種類型的錯誤，從而提升系統(tǒng)的穩(wěn)定性和可靠性。這些數(shù)據(jù)清晰地展示了Monkey在實際項目中的應用前景和價值，預示著Monkey將為系統(tǒng)穩(wěn)定性的提升帶來新的可能性。

在未來的優(yōu)化計劃中，我們將重點關注以下幾個方面：

1. 優(yōu)化現(xiàn)有組件的數(shù)據(jù)匹配準確率。
2. 組件品類的擴充，擴大支持的組件品類，覆蓋更廣泛的測試場景。
3. 定制化配置用例模型，旨在提高錯誤類型識別的準確性。
4. 提高系統(tǒng)的運行效率，計劃整合CI/CD流程。