午夜大片免费男女爽爽影院久久 ,免费福利在线视频,久草精品视频在线观看

2. 工業(yè)界REST API測試平臺案例分析

接下來，本文將列舉和介紹目前業(yè)界主要的API自動(dòng)化測試平臺，對它們的特性進(jìn)行分析和比較。

3. 業(yè)界平臺實(shí)現(xiàn)特點(diǎn)

????目前來說，業(yè)界的REST API測試平臺案例存在以下特點(diǎn)：

1.注重對復(fù)雜技術(shù)架構(gòu)的兼容性和可擴(kuò)展性

大型企業(yè)的軟件系統(tǒng)具有復(fù)雜和多樣化的技術(shù)架構(gòu)，涵蓋多樣化的技術(shù)棧和API調(diào)用協(xié)議類型（如Thrift、gRPC等）。API自動(dòng)化測試平臺需要實(shí)現(xiàn)應(yīng)用在不同語言、協(xié)議等技術(shù)環(huán)境的測試框架，以集成到復(fù)雜企業(yè)軟件架構(gòu)中，確保API測試平臺的適用性。

2.與業(yè)界軟件生態(tài)深度結(jié)合

業(yè)界API測試平臺更注重于向公司提供豐富的基礎(chǔ)能力，提供測試任務(wù)構(gòu)建、測試執(zhí)行、檢查點(diǎn)校驗(yàn)和測試報(bào)告生成等功能的一站式自動(dòng)化平臺，并結(jié)合業(yè)界良好的產(chǎn)品生態(tài)，與SDLC（Secure Software Development Life Cycle）深度結(jié)合，優(yōu)化一線人員的使用體驗(yàn)。

例如：字節(jié)跳動(dòng)的BAM通過對接內(nèi)部的代碼倉庫平臺Codebase來實(shí)現(xiàn)公司內(nèi)部全部服務(wù)的統(tǒng)一接口管理；美團(tuán)的Lego開發(fā)團(tuán)隊(duì)將API測試的SDK推廣到一線研發(fā)和測試人員使用，向測試人員提供線上接口調(diào)用流量排序等信息，幫助測試人員制定計(jì)劃優(yōu)先維護(hù)哪些API的測試用例。

3.偏重于黑盒測試

目前來說，業(yè)界僅支持API的黑盒測試，也就是著眼于接口的功能，依賴測試人員創(chuàng)建測試任務(wù)，通過API執(zhí)行的反饋信息進(jìn)行斷言判斷和測試報(bào)告生成。純黑盒測試雖然增強(qiáng)了API測試平臺的通用性，降低了平臺的接入成本，但是在純黑盒測試達(dá)到瓶頸時(shí)，只能通過白盒測試提供信息來進(jìn)一步提升測試效果。比如在測試中納入覆蓋信息，就可以在API測試中提供更多的信息，引導(dǎo)測試探索更多的程序行為。

學(xué)術(shù)界的REST API測試工具探索

1. 學(xué)術(shù)界REST API測試平臺概述

近年來，學(xué)術(shù)界對REST API測試的研究日益活躍，相對于工業(yè)界API測試平臺通常注重于解決復(fù)雜技術(shù)架構(gòu)的兼容性和可擴(kuò)展性問題，學(xué)術(shù)界的API測試工具更關(guān)注REST API測試用例自動(dòng)化生成的高效性和準(zhǔn)確性。目前，學(xué)術(shù)界已經(jīng)發(fā)布了多個(gè)開源REST API 測試工具，這些工具不僅在前沿研究（SOTA：State-of-the-Art）中表現(xiàn)突出，有些還通過與工業(yè)界合作開展了實(shí)證研究，進(jìn)一步驗(yàn)證了工具的應(yīng)用價(jià)值。接下來，本文將簡要介紹兩款具有代表性的學(xué)術(shù)界REST API 自動(dòng)化測試工具。

2. 學(xué)術(shù)界REST API測試平臺案例分析

1. Restler

Restler 是學(xué)術(shù)界提出的第一個(gè)有狀態(tài) REST API Fuzz 測試工具。Restler主要接受REST API的Swagger Specification（一種REST API的接口描述文檔）作為輸入，解析Swagger Specification并自動(dòng)化生成并執(zhí)行一系列API調(diào)用，對REST API進(jìn)行Fuzz測試。

Restler主要通過以下兩種方式生成API調(diào)用序列：

?通過接口描述文檔靜態(tài)分析請求參數(shù)依賴

Restler Compiler提供對REST API Specification文檔的靜態(tài)分析結(jié)果，通過參數(shù)類型推斷請求之間的生產(chǎn)者-消費(fèi)者關(guān)系（如下圖中POST請求返回的id信息和DELETE、GET和PUT請求的id參數(shù)存在生產(chǎn)者-消費(fèi)者依賴），用于創(chuàng)建API調(diào)用序列。

?基于API調(diào)用的反饋信息動(dòng)態(tài)維護(hù)調(diào)用序列

??? Restler Test Engine支持在Swagger文檔靜態(tài)分析結(jié)果的基礎(chǔ)上的自動(dòng)化測試用例生成和執(zhí)行。Restler還可以對測試執(zhí)行的反饋進(jìn)行學(xué)習(xí)，動(dòng)態(tài)維護(hù)調(diào)用序列：如果生成的API調(diào)用序列 A-B-C 在使用過程中 A 或 B 遇到類似 500 等錯(cuò)誤狀態(tài)碼，則將該序列加入黑名單，之后不再維護(hù)與生成。

Restler已經(jīng)在GitLab、Azure和Office365云服務(wù)中得到應(yīng)用，發(fā)現(xiàn)了一系列有效的代碼缺陷。

2. EvoMaster

??? EvoMaster 是第一個(gè)在GitHub開源的AI-driven的自動(dòng)化測試生成工具，它使用進(jìn)化算法（Evolutionary Algorithm）和動(dòng)態(tài)程序分析（Dynamic Program Analysis）自動(dòng)化生成API測試用例。EvoMaster可以自動(dòng)為web/企業(yè)應(yīng)用程序生成系統(tǒng)級測試用例。它不僅支持對REST API執(zhí)行Fuzz測試，還可以支持GraphQL API和RPC的Fuzz測試。

如下圖，在架構(gòu)上，EvoMaster的實(shí)現(xiàn)主要?jiǎng)澐譃樨?fù)責(zé)和SUT（System under Test）交互的Driver和負(fù)責(zé)測試用例生成的Core兩個(gè)組件，Driver和Core之間通過HTTP進(jìn)行通信。

本文將EvoMaster的特點(diǎn)從算法和功能上總結(jié)如下：

1.在算法上

EvoMaster 內(nèi)部使用進(jìn)化算法和動(dòng)態(tài)程序分析來生成有效的測試用例。具體來說，該類方法從一個(gè)隨機(jī)的初始種群開始進(jìn)化測試用例，試圖最大化代碼覆蓋率和缺陷數(shù)量等指標(biāo)。

此外，EvoMaster還利用了多種在軟件測試領(lǐng)域廣泛應(yīng)用的啟發(fā)式算法來提高工具性能。

2.在功能上

EvoMaster 主要特性包括：支持 Web API (REST、GraphQL 和 RPC) 的黑盒和白盒測試模式、對JVM語言的字節(jié)碼分析和SQL handling白盒測試（利用SQL數(shù)據(jù)庫的交互信息產(chǎn)生更高覆蓋率的測試用例）等。

3. 學(xué)術(shù)界工具特點(diǎn)

1.聚焦于自動(dòng)化測試輸入生成

學(xué)術(shù)界工具主要致力于自動(dòng)化REST API測試輸入的生成，其通過推導(dǎo)API調(diào)用序列蘊(yùn)含的參數(shù)依賴關(guān)系，自動(dòng)化生成符合API規(guī)范合法性和業(yè)務(wù)邏輯的API調(diào)用操作序列，從而對API測試的復(fù)雜場景進(jìn)行測試，發(fā)現(xiàn)程序缺陷。

2.依賴狀態(tài)碼和返回信息作為反饋信號

目前，學(xué)術(shù)界的API自動(dòng)化測試工具依賴于公開 API 的狀態(tài)碼和返回信息作為反饋信號，一種可能的原因是用于評估工具的數(shù)據(jù)集不得不包含一些被廣泛使用、API 數(shù)量大、可被外部訪問的網(wǎng)站或服務(wù)（如 Youtube、Twitter 等），但這些網(wǎng)站或服務(wù)通常不提供源代碼。這種情況下，學(xué)界的測試工作難以深入探索白盒 API 測試，而更多局限于黑盒測試。

LLM如何賦能于REST API測試技術(shù)

隨著GPT-4.0、Gemini、Claude等LLM（Large Language Model：大語言模型）的推出，LLM已成為技術(shù)創(chuàng)新的焦點(diǎn)，展現(xiàn)出巨大的發(fā)展?jié)摿蛷V泛的應(yīng)用前景。處于大模型技術(shù)應(yīng)用的藍(lán)海時(shí)期，我們不禁期待LLM能夠如何賦能于REST API測試技術(shù)，是否會引領(lǐng)新一代智能化REST API測試的潮流，激發(fā)出該領(lǐng)域的創(chuàng)新活力。

因此，基于初步的調(diào)研與分析，本文提供了五個(gè)可能有潛力的LLM賦能于REST API測試的方面，希望能夠?qū)ο嚓P(guān)技術(shù)人員和研究人員有所啟發(fā)。

1. REST API參數(shù)依賴增強(qiáng)和生成

REST API參數(shù)依賴指的是在一個(gè)REST API調(diào)用序列中，API的參數(shù)值和調(diào)用返回值之間的約束和依賴關(guān)系，被用于指導(dǎo)自動(dòng)化測試用例生成工具構(gòu)造REST API調(diào)用參數(shù)，生成REST API調(diào)用操作序列。傳統(tǒng)方法中，API參數(shù)約束和依賴主要通過對API Specification文檔靜態(tài)分析獲得。比如在ICST’20的工作RESTESTGEN中采用了ODG（Operation Dependency Graph）的圖結(jié)構(gòu)建模API調(diào)用序列的參數(shù)依賴關(guān)系（API調(diào)用操作getPetById的參數(shù)petId依賴于調(diào)用getPets返回的petId序列）。

將LLM應(yīng)用于REST API的參數(shù)約束和依賴提取，其在以下兩個(gè)方面具有相對于靜態(tài)分析的優(yōu)勢：

1.對基于自然語言的接口描述信息的理解和提取（文檔信息提取）

靜態(tài)分析傾向于對結(jié)構(gòu)化的文本進(jìn)行分析建模，而接口文檔中包含了部分開發(fā)人員的自然語言的描述信息，它們描述了參數(shù)的含義和功能，LLM可以提取這些信息增強(qiáng)或者生成REST API的參數(shù)約束和依賴關(guān)系。

2.結(jié)合項(xiàng)目背景知識和領(lǐng)域知識遷移的語義上下文理解（語料知識推斷）

LLM可以具有強(qiáng)大的上下文理解能力，結(jié)合項(xiàng)目背景和習(xí)得的大規(guī)模語料庫知識，可以生成符合真實(shí)語義的參數(shù)依賴關(guān)系。比如向LLM提供一個(gè)火車訂票的需求場景和兩個(gè)接口字段：出發(fā)時(shí)間和到達(dá)時(shí)間，可以得到一組參數(shù)依賴關(guān)系：出發(fā)時(shí)間 <（早于）到達(dá)時(shí)間。

2. 初始Seeds生成

在API Fuzz測試中，F(xiàn)uzzer需要在執(zhí)行前從語料庫中選擇隨機(jī)seeds來生成一組測試的初始輸入，一組多樣化的初始seeds可以在測試中覆蓋更多的功能，觸發(fā)被測程序的深層次行為，發(fā)現(xiàn)更多的代碼缺陷。

然而，目前API Specification僅僅為極少字段提供默認(rèn)值或有效示例，初始seeds生成比較依賴隨機(jī)生成或者由研究人員提供一個(gè)默認(rèn)的字段值字典。

????基于LLM的seeds生成的主要優(yōu)勢在于：針對特定項(xiàng)目背景的REST API，LLM可以結(jié)合其在大規(guī)模語料庫訓(xùn)練中積累的領(lǐng)域知識，生成符合項(xiàng)目背景的多樣化初始seeds，使得Fuzz可以探索更深層的程序行為。

3. Fuzzing harness自動(dòng)化生成

Fuzz harness是負(fù)責(zé)調(diào)用目標(biāo)代碼，將測試輸入傳遞到特定的函數(shù)或接口的代碼框架。它的主要目標(biāo)是將Fuzz Engine和Fuzz targets連接起來，執(zhí)行Fuzz 測試。

Google發(fā)布的Fuzz工具OSS-Fuzz為了解決在開源軟件項(xiàng)目中的fuzz blockers（盡管消耗了大量的CPU時(shí)間，F(xiàn)uzz測試的行覆蓋率依然較低，約為百分之三十）問題，提出并嘗試向LLM提供項(xiàng)目的低覆蓋率部分代碼信息，自動(dòng)生成Fuzz harness，引導(dǎo)改善項(xiàng)目的Fuzz測試覆蓋率指標(biāo)。截至目前，借助LLM生成Fuzz harness，OSS-Fuzz在開源軟件項(xiàng)目TinyXML2中將Fuzz測試的行覆蓋率指標(biāo)（LOC）從38%提高了69%。

4. 搜索空間剪枝

SBST（Search-Based Software Testing）是一種使用搜索算法（如BFS、遺傳算法等）來自動(dòng)化生成測試用例，旨在最大化代碼覆蓋率并且發(fā)現(xiàn)更多程序缺陷的自動(dòng)化軟件測試技術(shù)。SBST 的核心挑戰(zhàn)之一在于搜索空間往往極其龐大，需要對搜索空間進(jìn)行剪枝，提升搜索效率。

??? LLM可以利用API Specification中的語義信息和大規(guī)模語料庫中的知識來輔助搜索空間剪枝，為搜索空間生成若干啟發(fā)式語義規(guī)則，動(dòng)態(tài)調(diào)整搜索空間的邊界，優(yōu)化搜索的效率。

例如對于Integer類型的字段age，它的基本類型取值范圍是-2147483648 <= age <= 2147483647。雖然這一取值范圍涵蓋了整型變量的所有可能值，但不符合現(xiàn)實(shí)世界的常識性約束。LLM 可以根據(jù)常識性知識生成啟發(fā)式規(guī)則：人的自然年齡不可能為負(fù)數(shù)，且?guī)缀醪豢赡艹^ 200 歲。因此，可以通過剪枝將搜索空間縮小為 0 < age < 200，顯著提高測試效率。

這種基于語義信息的空間剪枝策略，結(jié)合了 LLM 的常識推理能力，能夠有效減少不合理輸入的生成次數(shù)，幫助 SBST 在龐大的搜索空間中更高效地探索有意義的測試用例，從而提高缺陷發(fā)現(xiàn)的效率和覆蓋率。

5. Test Oracle 自動(dòng)化生成

本文調(diào)研結(jié)果涉及的在學(xué)術(shù)界工具中采用的REST API測試的Test Oracle主要分為以下兩種：

1.REST API的返回狀態(tài)碼結(jié)果 (Response Code = 2xx，4xx，5xx等），判斷REST API調(diào)用引起的系統(tǒng)崩潰行為等。

2.REST API的返回的資源對象（HTTP JSON Body）是否和API Specification的描述在語法上一致，進(jìn)行JSON資源對象的約束檢查。（例如返回的資源對象的字段數(shù)目、類型等）。

同時(shí)，在業(yè)界，API測試平臺通過手工配置基于API調(diào)用返回的資源對象JSON屬性的約束點(diǎn)，超時(shí)檢查的規(guī)則完成自動(dòng)化約束點(diǎn)檢查。這些約束規(guī)則的編寫需要對項(xiàng)目具有經(jīng)驗(yàn)的專業(yè)人員根據(jù)需求結(jié)合專業(yè)背景耗費(fèi)大量精力進(jìn)行編寫。

LLM可以根據(jù)REST API的接口文檔和業(yè)務(wù)功能描述自動(dòng)化生成測試用例。通過對文本的解析和學(xué)習(xí)，LLM能夠識別程序邏輯，預(yù)測程序行為，從而生成相應(yīng)的Test Oracle。這種方法不僅可以提高測試效率，還可以幫助改善測試用例的全面性和準(zhǔn)確性。

結(jié)語

在現(xiàn)代化軟件架構(gòu)中，API測試變得越來越重要，它不僅確保了單個(gè)服務(wù)能夠正常提供業(yè)務(wù)功能，還涉及對多個(gè)服務(wù)之間的通信和協(xié)作的質(zhì)量保障。

展望未來，我們期望相關(guān)從業(yè)者和研究者可以基于已有的API測試中具備價(jià)值的功能和設(shè)計(jì)，利用LLM強(qiáng)大的上下文理解和文本生成能力，提高API測試的智能化水平，改善API測試的效率和準(zhǔn)確度，推動(dòng)其在實(shí)際應(yīng)用中的落地和發(fā)展。

聲明：本文對業(yè)界的調(diào)研結(jié)果基于中文互聯(lián)網(wǎng)公開的開源代碼社區(qū)、技術(shù)經(jīng)驗(yàn)博文和工具項(xiàng)目文檔資料，由于調(diào)研資料的完整性和時(shí)效性的不足，可能存在調(diào)研結(jié)果不全面和與當(dāng)前現(xiàn)狀產(chǎn)生偏差的情況，請讀者以實(shí)際情況為準(zhǔn)，也歡迎與我們聯(lián)系和反饋進(jìn)一步的情況。