Rest-Assured把GET測試寫成7種姿勢

2024年StackOverflow開發者調查顯示，Java仍是企業后端首選語言之一，但API測試工具的選型混亂讓無數團隊踩坑。有人用Postman手動點，有人寫HttpClient裸奔，還有人直接把生產日志當測試用例。

Mohammad Faisal Khatri在Medium發布的這篇教程，把Rest-Assured測GET請求的玩法拆成了7個遞進層級。這套寫法被他用在了LambdaTest的自動化測試框架里，覆蓋了從單接口驗證到全鏈路斷言的完整場景。

第一層：裸請求——驗證通路是否活著

最基礎的GET請求只需要三行代碼：given()、when()、get()、then()。Khatri的示例里，這套鏈式調用直接返回200狀態碼就算通過。

這種寫法適合冒煙測試，但別用在生產環境——它沒校驗響應體，也沒處理超時。

Rest-Assured的DSL（領域特定語言）設計讓HTTP動詞變成了可讀性極強的英文句子。對比Apache HttpClient的樣板代碼，同樣功能能省掉60%的行數。這也是很多從Python Requests轉Java的測試工程師，寧愿加依賴也要用它的原因。

第二層：Query參數——從硬編碼到Map注入

帶查詢參數的GET請求有兩種寫法。一種是鏈式.param("key","value")逐個追加，另一種是直接把參數塞進HashMap一次性注入。

Khatri更推薦Map方式。他的原話是：「當參數超過3個時，鏈式調用會變成橫向滾動的災難。」

這個細節被很多初學者忽略。我見過有團隊的測試代碼里，單個GET請求的param鏈寫了12行，Code Review時直接被架構師打回。Map結構還能從配置文件或數據驅動源動態加載，這是參數化測試的前置條件。

第三層：Path參數——RESTful路由的動態填充

/users/{id}這種路徑模板是RESTful API的標配。Rest-Assured用.pathParam("id", 123)做占位符替換，語法和Query參數保持一致。

這里有個隱蔽坑點：Path參數和Query參數的混用順序會影響URL編碼結果。

Khatri的示例代碼里，pathParam必須在get()之前聲明，否則部分特殊字符會被雙重編碼。這個bug在2023年的Rest-Assured 5.2版本里還存在，5.3之后才修復。如果你還在用舊版本，建議把路徑拼接抽成獨立工具類做防御性處理。

第四層：Headers——認證與內容協商的戰場

Header的處理是GET請求測試的分水嶺。基礎場景只需要Content-Type，但生產環境繞不開Authorization、X-Request-ID、自定義簽名等字段。

Khatri列出的示例覆蓋了Bearer Token和Basic Auth兩種模式。他的代碼結構值得抄：把Header組裝抽象成RequestSpecification對象，測試用例里只關注業務斷言。

這個設計讓團隊代碼量直接腰斬。我們組去年重構測試框架時，把分散在200+個用例里的Header硬編碼，全部收斂到3個Specification工廠類里。維護成本從人均每周4小時降到15分鐘。

第五層：響應斷言——從狀態碼到JSON Schema

then()之后的斷言鏈是Rest-Assured的核心競爭力。Khatri的教程里演示了statusCode()、body()、time()三類校驗，覆蓋了接口測試的黃金三角：功能正確性、數據完整性、性能基線。

body()斷言支持Hamcrest匹配器和JsonPath兩種風格，但混用會導致代碼可讀性驟降。

我的建議是：簡單字段用Hamcrest的equalTo，嵌套結構用JsonPath的深層提取。Khatri的示例代碼偏向后者，因為現代微服務的響應體普遍超過三層嵌套。Hamcrest的嵌套匹配器寫起來像Lisp，調試時想殺人。

響應時間斷言容易被忽視。Khatri在示例里加了.time(lessThan(2000L), TimeUnit.MILLISECONDS)，這行代碼能攔住90%的性能回歸。我們曾在凌晨的CI流水線里，靠這個斷言抓到一個N+1查詢的慢接口——DBA白天剛加的索引，被ORM的懶加載配置抵消了。

第六層：數據提取——給下游用例喂數據

extract().response()把響應體變成Java對象，這是構建測試流水線的關鍵能力。Khatri展示了提取單字段和整個JSON兩種模式。

提取的數據可以存到ThreadLocal，也可以直接return給調用方。我們組的實踐是：用提取器生成POJO，再通過對象映射做跨接口的字段傳遞。比如創建訂單接口返回的orderId，自動注入到查詢、支付、退款的后續用例里。

這個模式比Postman的環境變量更類型安全，比JMeter的正則提取更易維護。代價是多寫一層POJO定義，但MapStruct或Lombok能把這個成本壓到接近零。

第七層：認證封裝——Basic Auth的實戰樣板

最后一節講Basic Auth，放在這里有點微妙。OAuth2才是當下主流，但Khatri選Basic Auth做示例，可能是因為它的代碼最簡潔——.auth().basic("user","pass")一行搞定。

生產環境別這么寫。密碼硬編碼是安全審計的紅線，至少得走環境變量或密鑰管理服務。Khatri的示例代碼里沒提這個，但他在LambdaTest的公開項目里用了Spring Cloud Config做配置外部化。

這個反差說明：教程代碼追求最小可運行，工程代碼追求最小權限。兩者不能混為一談。

Rest-Assured的邊界與替代方案

Khatri的教程沒覆蓋的一個場景：GraphQL的GET請求。Rest-Assured對Query參數的處理是扁平KV結構，但GraphQL的復雜查詢需要嵌套變量對象。這時候得換WebTestClient或手寫HTTP客戶端。

另一個盲區是并行執行。Rest-Assured的線程模型基于RestAssuredConfig，默認配置在高并發下會出現連接池耗盡。我們組壓測時踩過這個坑，最后切到WebClient + Reactor才解決。

但這些都是進階話題。對于占Java API測試80%場景的RESTful GET請求，Khatri這7層模型已經足夠覆蓋從入門到生產落地的完整路徑。

你們組現在用什么工具測GET接口？是Rest-Assured、Postman腳本，還是直接curl | grep？