基于OpenStack的大規(guī)模云負(fù)載測試平臺研究

晉文明，李昌建，錢 巨,2

(1.南京航空航天大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，江蘇 南京 210016；2.江蘇省軟件新技術(shù)與產(chǎn)業(yè)協(xié)同創(chuàng)新中心，江蘇 南京 210023)

0 引 言

隨著互聯(lián)網(wǎng)的普及，以電子商務(wù)網(wǎng)站(eBay、亞馬遜、淘寶)和典型云服務(wù)(如Gmail、OneDrive)為代表的許多大型軟件系統(tǒng)承受越來越多的訪問流量[1]，這給軟件系統(tǒng)的服務(wù)質(zhì)量帶來了一定的不確定性。負(fù)載測試作為軟件測試的一種，是為了檢測系統(tǒng)在負(fù)載方面的相關(guān)問題從而對系統(tǒng)進(jìn)行評估的過程[2]。因而，為了保障大型軟件系統(tǒng)服務(wù)質(zhì)量的可靠性，有必要對其進(jìn)行有效的大規(guī)模負(fù)載測試[3]。人們研發(fā)了LoadRunner[4]、JMeter[5]、httperf[6]等一系列負(fù)載測試工具[7]，但這些測試工具一般存在兩個(gè)問題。一是支持的腳本類型過于單一化，二是僅支持采用進(jìn)程或線程并發(fā)方式發(fā)起負(fù)載，負(fù)載生成機(jī)制不夠豐富，負(fù)載生成消耗不夠優(yōu)化，在資源受限的情況下難以生成較大規(guī)模的負(fù)載。同時(shí)，這些測試工具在分布式環(huán)境下的部署流程較為復(fù)雜，加大了測試的難度。云測試能夠降低負(fù)載測試的實(shí)施難度，在云負(fù)載測試服務(wù)方面，以阿里云PTS[8]為代表的云測試系統(tǒng)同樣存在負(fù)載生成不夠優(yōu)化的問題，執(zhí)行大規(guī)模負(fù)載測試需要大量云資源作為支撐，增加了測試成本。在云測試工具的相關(guān)研究中，文獻(xiàn)[9]實(shí)現(xiàn)了一個(gè)IaaS云平臺測試系統(tǒng)，該測試系統(tǒng)的負(fù)載生成依賴于Apache JMeter來模擬并發(fā)負(fù)載，只支持以線程并發(fā)方式執(zhí)行JMeter測試腳本，難以在有限資源下生成較大規(guī)模的負(fù)載。文獻(xiàn)[10]實(shí)現(xiàn)了一種自動(dòng)化云測試平臺，基于測試工具Selenium執(zhí)行測試腳本以實(shí)現(xiàn)自動(dòng)化測試。但Selenium引擎執(zhí)行開銷非常大，導(dǎo)致能夠發(fā)起的負(fù)載規(guī)模十分有限，并且該平臺主要用于功能測試。文獻(xiàn)[11]設(shè)計(jì)了一個(gè)基于云計(jì)算的軟件測試系統(tǒng)框架，使用動(dòng)態(tài)優(yōu)先權(quán)調(diào)度算法實(shí)現(xiàn)測試任務(wù)的資源分配與執(zhí)行。其資源分配沒有考慮測試任務(wù)的資源特征，僅以測試執(zhí)行時(shí)間為優(yōu)化目標(biāo)，可能導(dǎo)致測試資源分配不夠優(yōu)化。文獻(xiàn)[12]也設(shè)計(jì)了一個(gè)云性能測試工具，支持分布式測試服務(wù)器間的同步控制功能，其工作流程為：由控制服務(wù)器向測試服務(wù)器發(fā)送測試執(zhí)行命令，測試命令保證了所有接收到命令的測試服務(wù)器同步執(zhí)行測試。但是該測試工具只能保證負(fù)載測試在初始狀態(tài)的同步性，無法保證整個(gè)測試在不同階段的同步性。因而，現(xiàn)有研究的測試工具往往存在負(fù)載生成機(jī)制不夠豐富、測試資源分配不夠優(yōu)化等問題，導(dǎo)致大規(guī)模負(fù)載測試成本過高且不易實(shí)施。

為了能夠高效地實(shí)施大規(guī)模負(fù)載測試，該文研究了多類型的負(fù)載生成、智能化測試資源分配和分布式負(fù)載同步控制技術(shù)，設(shè)計(jì)和實(shí)現(xiàn)了一種基于OpenStack[13]的大規(guī)模云負(fù)載測試平臺。該平臺支持進(jìn)程、線程和協(xié)程負(fù)載并發(fā)機(jī)制，結(jié)合多類型測試腳本以生成客戶端負(fù)載；能夠預(yù)測負(fù)載測試任務(wù)的資源需求，并為其確定云測試主機(jī)(OpenStack中部署了測試執(zhí)行引擎的虛擬節(jié)點(diǎn))資源，實(shí)現(xiàn)智能化測試資源分配；采用同步控制算法保證不同測試主機(jī)間測試進(jìn)度的同步性。該平臺為大規(guī)模負(fù)載測試提供了一個(gè)功能豐富、經(jīng)濟(jì)易用的平臺，輔助以智能化測試資源分配、分布式負(fù)載同步控制等功能保證了負(fù)載測試的執(zhí)行效果，同時(shí)可幫助降低大規(guī)模負(fù)載測試的實(shí)施難度。

1 系統(tǒng)結(jié)構(gòu)

基于OpenStack的大規(guī)模云負(fù)載測試平臺的總體界面如圖1所示。平臺通過導(dǎo)入測試腳本，對待測Web應(yīng)用進(jìn)行負(fù)載測試，收集相關(guān)指標(biāo)數(shù)據(jù)，并據(jù)此來分析承載Web應(yīng)用的被測云服務(wù)設(shè)施的相關(guān)表現(xiàn)情況。該平臺支持云負(fù)載測試執(zhí)行、分布式負(fù)載同步控制、智能化測試資源分配等主要功能，此外，還支持測試腳本管理、測試結(jié)果管理等輔助功能。

圖1 平臺總體界面

為保證靈活性，云測試平臺采用如圖2所示的物理結(jié)構(gòu)，整個(gè)系統(tǒng)由前端Dashboard、測試控制中心CloudTest、測試執(zhí)行引擎TestAgent、監(jiān)控器VMMonitor四大基本模塊構(gòu)成。

圖2 系統(tǒng)物理結(jié)構(gòu)

前端Dashboard是一個(gè)Web前端頁面，在該頁面下，包含測試集群、云應(yīng)用、云主機(jī)、測試腳本、云應(yīng)用性能測試、測試結(jié)果等主頁面。測試管理中心CloudTest一方面通過暴露的RESTful接口與Dashboard交互；另一方面與測試執(zhí)行引擎交互，接收實(shí)時(shí)負(fù)載執(zhí)行數(shù)據(jù)；與監(jiān)控器交互，接收主機(jī)的實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)。測試執(zhí)行引擎是執(zhí)行負(fù)載測試的主要模塊，對用戶配置的負(fù)載測試任務(wù)進(jìn)行解析，按照預(yù)設(shè)的負(fù)載變化策略在指定的時(shí)間節(jié)點(diǎn)上生成相應(yīng)規(guī)模的負(fù)載，發(fā)起對被測目標(biāo)應(yīng)用的網(wǎng)絡(luò)調(diào)用，并統(tǒng)計(jì)每個(gè)負(fù)載的執(zhí)行數(shù)據(jù)，匯報(bào)至測試控制中心。監(jiān)控器周期性地采集宿主機(jī)的資源使用信息匯報(bào)至測試控制中心。其中，測試控制中心、測試執(zhí)行引擎、監(jiān)控器等模塊均支持部署在私有云OpenStack上，亦可部署在公有云環(huán)境中。

2 支持協(xié)程的負(fù)載并發(fā)機(jī)制

由于進(jìn)程或線程并發(fā)是多個(gè)子例程通過操作系統(tǒng)時(shí)間片輪轉(zhuǎn)來實(shí)現(xiàn)，占據(jù)資源大、任務(wù)切換代價(jià)較高，導(dǎo)致進(jìn)程或線程并發(fā)方式下單機(jī)的負(fù)載執(zhí)行性能一般。協(xié)程是一種程序組件[14]，其高性能主要體現(xiàn)在如下幾個(gè)方面：(1)協(xié)程間的切換由用戶空間控制，無需操作系統(tǒng)參與，上下文切換的開銷極小；(2)協(xié)程本身是輕量級的，資源占用小，基本不存在數(shù)量限制；(3)協(xié)程具有非阻塞異步I/O模型的特性，在IO密集型程序中執(zhí)行性能非常高。因而，協(xié)程可模擬大規(guī)模負(fù)載。

該云測試平臺在支持進(jìn)程、線程負(fù)載并發(fā)機(jī)制的基礎(chǔ)上，引入了協(xié)程負(fù)載并發(fā)機(jī)制。Quasar為Java提供了高性能的輕量級線程，使用Quasar Fiber可實(shí)現(xiàn)Java協(xié)程，平臺利用Quasar Fiber和異步Appache Http組件實(shí)現(xiàn)并發(fā)客戶端負(fù)載的生成，其主要流程如圖3所示。

圖3 協(xié)程執(zhí)行流程

如圖4所示，平臺利用云環(huán)境(如，OpenStack)中的測試主機(jī)來發(fā)起大規(guī)模負(fù)載測試，通過分布式并發(fā)并行調(diào)用產(chǎn)生對目標(biāo)應(yīng)用的并發(fā)客戶端負(fù)載。測試主機(jī)上具體由訪問被測目標(biāo)應(yīng)用的任務(wù)進(jìn)程、任務(wù)進(jìn)程內(nèi)的任務(wù)線程或任務(wù)協(xié)程來完成網(wǎng)絡(luò)訪問。不同任務(wù)進(jìn)程、任務(wù)線程以及任務(wù)協(xié)程模擬了不同的虛擬客戶端，總的任務(wù)進(jìn)程、任務(wù)線程和任務(wù)協(xié)程的數(shù)量大致對應(yīng)了所生成客戶端負(fù)載的總體規(guī)模。

圖4 負(fù)載并發(fā)機(jī)制

3 基于多類型腳本的負(fù)載生成

傳統(tǒng)負(fù)載測試工具支持的腳本過于單一化，導(dǎo)致無法很好地適用于不同的測試目標(biāo)和目的。文中的云測試平臺支持執(zhí)行Selenium、JMeter、Java等類型的測試腳本，基于多類型測試腳本來生成客戶端負(fù)載。腳本間比較如表1所示。

表1 不同類型的測試腳本

如Selenium腳本示例所示的腳本能夠描述Web頁面的打開、點(diǎn)擊等行為，可表達(dá)復(fù)雜動(dòng)態(tài)頁面Web應(yīng)用上的動(dòng)作，靈活性最強(qiáng)，能測試的Web應(yīng)用類型最廣。但是腳本的執(zhí)行開銷非常大，并且依賴Python引擎支撐，而當(dāng)前大部分Python引擎的并發(fā)執(zhí)行性能都較弱。因而，在資源較為一般的測試主機(jī)上，很難發(fā)起較大規(guī)模的負(fù)載。

from selenium import webdriver

st=tester();

class Addbook(unittest.TestCase):

def setUp(self):

self.driver=webdriver.Firefox()

self.driver.implicitly_wait(30)

self.base_url="http://192.168.1.130/"

def test_addbook(self):

driver=self.driver

driver.get(self.base_url+"/BookManager?method=list")

driver.find_element_by_link_text(u"添加圖書").click()

if __name__ == "__main__":

unittest.main()

如JMeter腳本示例所示的腳本是一段XML配置，描述了一組針對Web應(yīng)用的網(wǎng)絡(luò)訪問報(bào)文。利用JMeter腳本執(zhí)行引擎可以提取JMeter腳本中所描述的網(wǎng)絡(luò)報(bào)文，對其進(jìn)行重放。JMeter腳本執(zhí)行引擎的一個(gè)優(yōu)勢是可以直接利用其他工具的腳本。相對Selenium腳本，JMeter腳本的負(fù)載生成能力明顯更強(qiáng)。然而，JMeter腳本不能像Python腳本那樣隨意修改，輕松插入新的動(dòng)作代碼，因此，靈活性弱于Selenium腳本。

class="HTTPSamplerProxy" testname="Open blazemeter.

com">

entType="Arguments">

weibo.com

/

GET

如Java腳本示例所示的腳本使用Apache HTTP庫通信，對網(wǎng)絡(luò)的訪問較為直接，避免JMeter中的腳本解釋開銷。Java腳本支持協(xié)程等高性能機(jī)制，依賴于協(xié)程并發(fā)方式執(zhí)行腳本，相對于其他測試腳本，其資源開銷最低，執(zhí)行效率最高，在同樣的CPU和內(nèi)存配置下，腳本能夠更大規(guī)模的并發(fā)。然而，此種腳本需要手工編寫，且需要事先編譯，制作代價(jià)較高。

import java.util.*;

public class TestCase implements Runnable{

private static String URL = "http://www.baidu.com";

public void run() {

ResultStatus status = ResultStatus.PASSED;

try {

Response response = Request.Get(URL).execute();

StatusLinestatusLine = response.

returnResponse().getStatusLine();

int statusCode = statusLine.getStatusCode();

if(statusCode!=200) {

status = ResultStatus.FAILED;

}

}

}

}

4 智能化測試資源分配

在實(shí)施大規(guī)模負(fù)載測試的過程中，由于單臺機(jī)器的硬件資源能力較為有限，難以生成較大規(guī)模的負(fù)載。為了生成足夠規(guī)模的負(fù)載，往往需要多臺測試主機(jī)同時(shí)提供測試服務(wù)。分配的主機(jī)資源如果過少，將會(huì)導(dǎo)致無法發(fā)起相應(yīng)規(guī)模的負(fù)載；分配的主機(jī)資源如果過多，將會(huì)造成測試資源的冗余。因而，如何為負(fù)載測試任務(wù)分配資源顯得十分關(guān)鍵。

文中的云測試平臺支持智能化測試資源分配功能。平臺以每一處理周期內(nèi)用戶下達(dá)的負(fù)載測試任務(wù)的序列T=為處理對象。首先使用機(jī)器學(xué)習(xí)方法預(yù)測出T中各測試任務(wù)Ti的資源需求Ri。在資源需求的基礎(chǔ)上，基于遺傳演化的多目標(biāo)資源分配算法[15]，確定提供測試服務(wù)的云測試主機(jī)等所需資源的分配方案，依據(jù)分配方案，將各個(gè)負(fù)載測試任務(wù)分配到對應(yīng)的OpenStack云測試主機(jī)上執(zhí)行。

4.1 測試資源預(yù)測

對于目標(biāo)負(fù)載測試任務(wù)序列T中的每個(gè)測試任務(wù)Ti，云測試平臺按照如下流程預(yù)測得到其資源需求向量R=。

首先，從平臺的測試腳本池中選擇目標(biāo)負(fù)載測試任務(wù)(假設(shè)目標(biāo)負(fù)載規(guī)模為5 000)的測試腳本(如，edit_order.jar腳本)作為訓(xùn)練的對象，平臺支持為其自動(dòng)配置一個(gè)較小負(fù)載規(guī)模(一般為500)的測試活動(dòng)，并在單臺測試主機(jī)(一般配置為2 CPU核心和4 GB內(nèi)存，其資源向量可用CPU核心數(shù)和內(nèi)存大小的二維向量(2, 4)表示)上自動(dòng)執(zhí)行該測試活動(dòng)，完成預(yù)熱執(zhí)行工作。

第二步，在預(yù)熱執(zhí)行過程中，部署在測試主機(jī)上的測試執(zhí)行引擎收集實(shí)時(shí)負(fù)載執(zhí)行數(shù)據(jù)L(t)={(t,load)}，監(jiān)控器實(shí)時(shí)收集測試主機(jī)的資源使用數(shù)據(jù)R(t)={(t,R)}，使用處理函數(shù)M(X,Y)將負(fù)載執(zhí)行數(shù)據(jù)和資源使用數(shù)據(jù)融合，使其在時(shí)間節(jié)點(diǎn)上對應(yīng)，得到負(fù)載_資源數(shù)據(jù)LR，可表示為：

LR=M(L(t),R(t))={(load,R)}

第三步，以負(fù)載資源數(shù)據(jù)LR作為訓(xùn)練模型的輸入，通過回歸學(xué)習(xí)方法，抽取edit_order.jar腳本的資源模型(可用映射f:load→R表示，其輸入為目標(biāo)負(fù)載規(guī)模load，輸出為負(fù)載測試任務(wù)所需資源向量R)。如圖5所示，其中CPU資源模型為fcpu(x)=0.284lnx+0.07，內(nèi)存資源模型為fram(x)=0.013x2/3+0.29，從而預(yù)測負(fù)載測試任務(wù)的資源需求為(2.49，4.09)，則至少需要3臺配置為1核心CPU和2 GB內(nèi)存的云測試主機(jī)提供測試服務(wù)。重復(fù)上述步驟，預(yù)測出目標(biāo)負(fù)載測試任務(wù)序列中每個(gè)測試任務(wù)的資源需求向量。

圖5 資源模型

4.2 測試資源分配

對于待分配資源的負(fù)載測試任務(wù)序列T，基于4.1節(jié)所述的方法可預(yù)測其資源需求向量為R。云測試平臺采用一種基于遺傳演化的多目標(biāo)資源分配算法為T分配云測試資源，其總體執(zhí)行流程如圖6所示。在資源分配的過程中，為了減少資源的浪費(fèi)，降低測試的成本開銷，并保證測試的執(zhí)行效率，算法以最小資源冗余、最低測試執(zhí)行成本為一組優(yōu)化目標(biāo)，關(guān)于目標(biāo)函數(shù)的定義這里不再贅述。

圖6 算法執(zhí)行流程

首先，平臺支持獲取當(dāng)前云測試環(huán)境OpenStack的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖(物理節(jié)點(diǎn)、虛擬節(jié)點(diǎn)以及路由節(jié)點(diǎn)間的網(wǎng)絡(luò)通信結(jié)構(gòu))。依據(jù)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)以及虛擬節(jié)點(diǎn)可用資源等信息生成負(fù)載測試任務(wù)序列T的一組初始化資源分配方案，并按照向量S所示編碼方式對資源分配方案進(jìn)行編碼。

然后，對編碼后的資源分配方案進(jìn)行交叉、變異操作，形成初步子代種群。對初步子代種群中的資源分配方案進(jìn)行修復(fù)并優(yōu)化，確保分配方案的可行性與優(yōu)越性；父子種群合并，將合并后的種群中的優(yōu)良分配方案選擇進(jìn)入新的種群，使得分配方案的最小資源冗余、最低測試執(zhí)行成本等目標(biāo)朝著更優(yōu)的方向進(jìn)化，從而完成一次進(jìn)化。重復(fù)上述過程直至預(yù)設(shè)進(jìn)化代數(shù)，最終得到目標(biāo)負(fù)載測試任務(wù)序列的最優(yōu)資源分配方案。

最后，平臺依據(jù)最優(yōu)資源分配方案，將負(fù)載測試任務(wù)序列中的各測試任務(wù)分配到對應(yīng)的OpenStack云測試主機(jī)上，并由平臺對云測試主機(jī)進(jìn)行統(tǒng)一化管理。分配完成后，即可開始目標(biāo)負(fù)載測試任務(wù)的執(zhí)行，平臺收集實(shí)時(shí)負(fù)載執(zhí)行數(shù)據(jù)以對測試進(jìn)行運(yùn)行時(shí)監(jiān)控，從而形成對各負(fù)載測試執(zhí)行的性能評估。

給定如圖7所示的云測試環(huán)境G和一組資源需求已知的負(fù)載測試任務(wù)T=，在文中的云測試平臺上分別采用多目標(biāo)資源分配和隨機(jī)資源分配方法為其分配測試資源。實(shí)驗(yàn)結(jié)果如圖7所示，在相同規(guī)模的云測試環(huán)境下，對于相同的負(fù)載測試任務(wù)序列，多目標(biāo)資源分配方法相較于傳統(tǒng)的隨機(jī)分配方法，能夠減少云測試主機(jī)的占用數(shù)，降低測試執(zhí)行成本。

圖7 實(shí)驗(yàn)環(huán)境與實(shí)驗(yàn)結(jié)果

5 分布式負(fù)載同步控制

隨著測試的執(zhí)行，不同測試主機(jī)上的測試進(jìn)度可能差別越來越大，最終導(dǎo)致不同機(jī)器上對待測Web應(yīng)用的訪問可能不是按預(yù)期來并發(fā)的，所產(chǎn)生的負(fù)載壓力與預(yù)期設(shè)定不符。

文中的云測試平臺支持分布式負(fù)載同步控制功能。對每個(gè)負(fù)載測試配置，測試平臺支持為其設(shè)定一組同步集合點(diǎn)，典型的同步策略包括按比例同步，即當(dāng)一定比例的任務(wù)進(jìn)入同步點(diǎn)后，已經(jīng)進(jìn)入同步點(diǎn)的任務(wù)即可繼續(xù)向下執(zhí)行；以及按絕對數(shù)量同步，即當(dāng)某指定數(shù)量的任務(wù)進(jìn)入同步點(diǎn)后，已經(jīng)進(jìn)入同步點(diǎn)的任務(wù)即可繼續(xù)向下執(zhí)行。

在為負(fù)載測試配置設(shè)定了同步集合點(diǎn)后，可以在測試腳本中添加同步集合點(diǎn)進(jìn)入原語，如含同步集合點(diǎn)的測試腳本示例中的st.rendezvous("dosearch")。測試腳本執(zhí)行到該同步集合點(diǎn)語句時(shí)，會(huì)進(jìn)入等待狀態(tài)，直到退出同步集合點(diǎn)的條件得到滿足。該同步集合點(diǎn)可以使得該集合點(diǎn)后的語句都盡可能在同一時(shí)刻得到執(zhí)行。

st=tester();

class Baidu(unittest.TestCase):

def setUp(self):

self.driver=webdriver.Firefox()

self.base_url="https://www.baidu.com/"

def test_baidu(self):

driver=self.driver

driver.get(self.base_url + "/")

st.rendezvous("dosearch")

driver.find_element_by_id("su").click()

if __name__ == "__main__":

unittest.main()

同步集合點(diǎn)僅對負(fù)載變化策略中同一時(shí)刻點(diǎn)上發(fā)起的負(fù)載有效。對于原定測試計(jì)劃中理論上應(yīng)發(fā)生于同一時(shí)刻的客戶端負(fù)載，平臺采用同步控制算法以確保同步集合點(diǎn)能夠有效發(fā)揮作用，保證不同測試主機(jī)間測試進(jìn)度的同步性。同步控制算法的總體流程如下：

input：待執(zhí)行的負(fù)載測試活動(dòng)

output：每個(gè)步驟上的有效負(fù)載規(guī)模的集合?(load)

begin

獲取負(fù)載變化策略，測試集群的主機(jī)數(shù)量testClusterSize和負(fù)載變化步驟數(shù)steps；

while step

讀取當(dāng)前步驟上預(yù)設(shè)的負(fù)載規(guī)模loadScale；

whiletrue

為每個(gè)負(fù)載啟動(dòng)一個(gè)負(fù)載執(zhí)行器；

在負(fù)載執(zhí)行器內(nèi)執(zhí)行測試腳本；

腳本進(jìn)入renderzvous語句后，向測試主機(jī)發(fā)出enterRendezvous消息；

當(dāng)前等待執(zhí)行的腳本數(shù)actualLoad++；

if actualLoad==loadScale(測試主機(jī)滿足退出同步集合點(diǎn)的條件) then

測試主機(jī)向測試控制中心發(fā)出enterRendezvous的消息;

等待執(zhí)行的測試主機(jī)數(shù)agentCount++;

actualLoad→?(load)；

while agentCount

阻塞等待執(zhí)行的測試主機(jī)上進(jìn)入同步集合點(diǎn)的腳本;

end while

測試控制中心向測試集群中各測試主機(jī)發(fā)出exitRendezvous；

測試主機(jī)將同步退出消息轉(zhuǎn)發(fā)給各個(gè)正在等待的腳本；

腳本收到消息后，繼續(xù)向下執(zhí)行測試腳本中的后續(xù)語句；

end

end while

end while

return ?(load)；

end

6 結(jié)束語

研究了多類型負(fù)載生成、智能化測試資源分配和分布式負(fù)載同步控制技術(shù)，實(shí)現(xiàn)了一種基于OpenStack的大規(guī)模云負(fù)載測試平臺。該平臺具有如下特性：支持進(jìn)程、線程和協(xié)程負(fù)載并發(fā)機(jī)制，結(jié)合多類型測試腳本生成客戶端負(fù)載，相較于已有測試工具，客戶端負(fù)載生成更為高效；支持智能化測試資源分配功能，實(shí)現(xiàn)面向云負(fù)載測試任務(wù)的資源優(yōu)化分配；支持分布式負(fù)載同步控制功能，保證不同測試主機(jī)上網(wǎng)絡(luò)活動(dòng)的并行性。該測試平臺為測試人員實(shí)施大規(guī)模負(fù)載測試提供了一個(gè)功能豐富、經(jīng)濟(jì)易用的平臺，能夠降低大規(guī)模負(fù)載測試的難度。