谷歌把PUT测试藏了12年，开发者发现后集体懵圈

2024年Stack Overflow调研显示，67%的API故障源于更新操作。但PUT测试的文档缺口，让这个数字连续五年没降过。

一个HTTP方法，三种死法

Rest-Assured（一种Java接口测试框架）处理PUT请求时，开发者踩的坑出奇一致：幂等性假设错误、状态码误判、响应体漏检。某金融科技团队曾因此把"部分更新"写成"全量覆盖"，生产环境丢了用户配置数据。

问题出在教程的断层。GET/POST的示例铺天盖地，PUT像被塞进了技术文档的地下室。官方文档有代码，但缺场景；博客有场景，但缺边界条件。

代码里的陷阱：当200不等于成功

Rest-Assured的PUT测试最基础的写法长这样：

given().contentType("application/json").body(requestBody).when().put("/api/resource/123").then().statusCode(200);

这行代码能跑通，但离"测对"差得远。200只说明服务器收了请求，不说明数据真的更新了。某电商团队在促销期间就栽过：接口返回200，数据库没写入，缓存和DB数据撕裂了四小时。

正确的姿势需要显式校验响应体。Rest-Assured的body()方法支持JsonPath（一种JSON查询语法）断言，比如验证name字段是否从"旧值"变成"新值"。代码多三行，故障少九成。

幂等性：PUT的隐藏契约

PUT的语义是"全量替换"，发十次和发一次结果相同。但很多开发者把它当PATCH（部分更新）用，只传改了的字段。服务器如果按PUT标准实现，没传的字段会被置空——这不是bug，是协议理解偏差。

测试时必须覆盖这个边界。用Rest-Assured连续发两次相同PUT请求，第一次返回200，第二次应该还是200（或204），且最终状态一致。如果第二次返回201，说明服务端把PUT当POST实现了，这在微服务架构里会引发级联混乱。

某云厂商的API网关曾因此暴露漏洞：重复PUT创建了重复资源，账单系统多算了客户三倍费用。

实战：一个能进CI的测试用例

完整的PUT测试需要三层防护：协议层验状态码、业务层验数据一致性、异常层验容错。

协议层用statusCode()和header()做基础断言。业务层用extract().response()拿到实际响应，和预期JSON做字段级比对。异常层模拟网络超时、服务端500、请求体超大等场景，验证重试策略和降级逻辑。

Rest-Assured的given-when-then结构天然适合分层。某支付团队把这套模式模板化后，接口回归测试时间从45分钟压到6分钟，缺陷逃逸率降了62%。

一个细节：PUT的URL通常带资源ID，测试时要覆盖ID不存在、ID格式非法、ID越权三种情况。Rest-Assured的pathParam()方法支持参数化，配合JUnit的@ParameterizedTest（参数化测试注解）能批量生成用例。

某开源项目的测试套件里，PUT相关用例有47%在验证错误路径——这个数字在多数团队是反过来的。

你的CI流水线里，PUT测试覆盖了几种失败场景？