一、前言

小米分散式測試平臺（Pecker）是一款整合各種測試的平臺。包括但不限於效能測試、功能迴歸測試、上線准入測試等。測試種類不限於 RPC、HTTP、自定義 Java 介面等等。

二、背景

你的服務跑的有多快？你的服務平均響應時間是多長？你的服務能抗多少流量，能抗多久？每次新服務上線或新活動上線前，相關研發同學通常會思考這幾個問題。“這也許只有QA同學應該知道吧”。

流量猛增，服務雪崩，不應該啊！服務容量已經算上buffer了，為什麼還是敗在大流量之下？

在這樣的背景之下，我們著手開發了小米分散式測試平臺-Pecker。旨在盡最大可能解放研發人員生產力，提前發現服務瓶頸和缺陷，保證服務穩定執行。

小米分散式測試平臺（Pecker）是一款整合各種測試的平臺。包括但不限於效能測試、功能迴歸測試、上線准入測試等。測試種類不限於RPC、HTTP、自定義Java介面等等。

三、小米分散式測試平臺介紹

測試平臺採用了業界比較成熟的三層架構方案。如下：

• 最上層為控制檯，使用者在此層操作。例如建立相關測試任務、檢視執行歷史、報表等資料。

• 中間層為排程層，對測試任務進行排程。

• 最底層為容器雲，即任務執行層。每個測試任務最終都是在Pod中執行並完成。

1、效能測試種類

目前我們實現了三種壓測種類，分為RPC、HTTP和自定義Java介面壓測。

其中針對HTTP服務，我們引入了變數替換模式。

一個生動的栗子：假設現有一個HTTP GET請求為：http://www.mi.com/test?item=a，其返回值為：{“res”: “a”}。針對這樣的介面，我們不可能一直構造一個不變的請求，也不可能建立成千上百個類似的任務。

在測試平臺上建立該任務時，可以定義為：http://www.mi.com/test?item=${item}，其返回值為：{"res": "${res}"}。使用者只需要上傳包括${item}和${res}的CSV檔案，平臺則會在請求前自動進行替換。

而且，對於HTTP的結果集驗證，我們提供了三種校驗。分別為：請求過程驗證、HTTP狀態碼驗證和使用者自定義斷言驗證，下圖為使用者自定義響應斷言：

平臺提供的功能過於通用，使用者想測試SQL操作，怎麼辦？

對於這種情形，我們在架構上完成了解耦的工作，將測試模組與測試客戶端進行解耦，將測試模組與統計資料模組進行解耦。使用者完全可以通過實現我們的介面完成測試。

public interface TestClient {
    default void setUp();
    SampleResult runTest();
    default void tearDown();
}

2、效能測試方式

效能測試平臺目前提供了兩種測試模式：使用者增長模式和QPS增長模式。

**使用者增長模式：**每個測試階段內使用者數量固定，隨著階段的增加定量增加使用者數。

例如：我們總共需要壓測10個階段，每階段持續10分鐘。初始階段使用者為1W，每個階段遞增1W。此模式現支援分散式測試模式。

**QPS增長模式：**每個測試階段內固定QPS傳送請求，隨著階段的增加定量增加QPS。

例如：我們總共需要壓測10個階段，每階段持續10分鐘。初始階段期望QPS=1W，每個階段期望QPS遞增1W。此模式暫不支援分散式測試模式。

其底層實現方式為：動態計算響應時間、執行緒數和Delay方程式。

3、報表資料展示

報表資料我們提供了基礎資料資料以及錯誤資料展示，如下：

為了展示資料更加直觀，我們同樣提供了圖資料：

4、其他功能

因為效能測試多數為自動執行任務，使用者並不想每次都去控制檯上手動操作。針對這種情況，我們開放了一些介面便於使用者進行指令碼執行或者Jenkins排程。

測試平臺實際上模擬Client端操作，但使用者想實時獲取被壓測服務的執行狀態。針對這種情況，我們的統計模組可以動態展示開啟JMX服務的CPU、記憶體以及GC相關資料。

5、與主流測試工具對比

與Jmeter和Gatling對比

四、未來規劃

1、基準測試完善

測試平臺目前處於高速開發階段，為了不影響其效能，需要完善其基準測試，提供更多的測試場景以及基準資料。

2、介面平臺

可以看到，極大多數效能壓測都是對某些介面進行發起。後期我們提供更完備的介面平臺。介面管理更方便，效能/功能測試一目瞭然。

3、功能測試平臺

目前測試平臺主要實現了效能測試功能，現正在開發功能測試平臺。支援上傳測試用例併發起功能測試。