RESTler是第一個有狀態的針對REST API的模糊測試工具，用於自動化的測試雲服務並找到雲服務中存在的安全性和可靠性問題。

本篇文章主要介紹一下微軟推出的模糊測試工具RESTler是如何分析RESTful API介面的依賴關係並執行測試的。

上一篇文章中已經介紹過RESTler會分析Swagger規範，從中獲取所有的介面資訊，並分別為之構造一個請求，關於該步驟的詳細過程可以參考前一篇文章，我們將Swagger規範中的所有請求資訊用reqSet來表示。

引言

首先說一下結論，即RESTler之所以說自己是有狀態的（Stateful）且能夠分析不同API介面的先後依賴關係，是因為它能夠根據請求的輸入引數和返回值之間的依賴關係，仍然用下圖blog管理的API介面為例，從中我們可以發現，想要去呼叫DELETE、PUT方法去傳送請求的前提是我們能夠拿到相應的ID資訊。

RESTler中的一些形式化描述

reqSet：所有請求req的集合；

seqSet：包含依賴關係的請求序列集合；

消費者：傳送某個請求req時必須要的引數；

生產者：當執行一系列的請求req後，我們能夠在介面的返回訊息中獲取到某些引數，這些引數可以被消費者使用；

依賴關係：當請求req（消費者）所需要的引數集屬於其他請求序列seq的響應資訊（生產者）中的引數集合的子集時，我們可以認為請求req依賴於seq。

有了上述的基礎後，我們可以將RESTler測試用例生成拆分為如下步驟：

構造請求序列：根據請求所需的引數資訊和返回值構造請求序列

根據請求替換fuzz：根據請求序列中的請求資訊，替換請求中可以fuzz部分的值

更新請求序列：分析響應資訊，若響應資訊的狀態碼有效（HTTP Status Code200），則更新請求序列

重複執行步驟1、2、3，知道次數達到使用者指定次數

詳細的虛擬碼如下圖所示，每一步的具體流程可以從虛擬碼中清晰看出：

結論

本篇文章主要是介紹了RESTler模糊測試工具是如何分析RESTful API介面的依賴關係並執行測試，解釋了paper中描述的stateful的含義。