第 4 章 HTTP 接口自动化测试
4.1 HTTP 简介
在 TCP/IP 中，HTTP 属于传输层协议。HTTP 采用「请求—应答」模式，并且该协议是无状态的，即后续的处理如果需要用到前面的信息，则必须重传。HTTP 通过 SSL/TLS 加密成为 HTTPS，与 HTTP 相比，HTTPS 的安全性更好，但传输速度不及 HTTP。
HTTP 中有多种请求方法。
1．GET 方法
GET 方法用于获取指定资源，可理解为「读取」资源。在 GET 方法的 URL 中可以携带参数，携带参数的格式为「key1=value1&key2=value2&key3=value3」。
2．POST 方法
POST 方法用于创建或修改指定资源，比如常见的提交表单或上传文件等。POST 方法既可以在 URL 中携带参数，也可以在请求体中携带参数。POST 方法和 GET 方法是最常用的两种 HTTP 请求方法。
3．PUT 方法
与 POST 方法一样，PUT 方法也用于创建或修改指定资源，区别在于，PUT 方法是幂等的，即调用一次与调用多次的效果一样；而 POST 方法是非幂等的，即调用多次效果可能有差异。
4．DELETE 方法
DELETE 方法用于请求服务器删除指定的资源。
5．OPTIONS 方法
OPTIONS 方法一般用于检测服务器支持的请求方法，响应报文中包含一个名为 Allow 的响应头字段，该字段的值表示了服务器支持的 HTTP 方法。
6．CONNECT 方法
CONNECT 方法一般用于代理服务器。比如，服务器使用 HTTPS 进行数据传输，且浏览器需要代理服务器，那么浏览器首先使用 CONNECT 方法以明文方式向代理服务器发送目标服务器的 IP 地址和端口，在代理服务器与目标服务器建立连接后再进行后续的数据传输。这样做的好处是代理服务器不会破坏 HTTPS 传输过程的安全性。
在客户端发起 HTTP 请求后服务器会进行响应，不同的响应码对应不同的场景。响应码由 3 位数字组成，第一个数字代表当前响应的类型。
1XX——提示信息，服务器的临时响应，此时客户端应继续发起请求。
2XX——成功，请求已被服务器成功处理，比如 200 OK。
3XX——重定向，需要客户端进行后续操作才能达成目的，比如 302 Found。
4XX——客户端错误，客户端请求发生错误，比如 404 Not Found。
5XX——服务器错误，服务器处理正确请求时发生错误，比如 500 Internal Server Error。
4.2 部署待测程序
1．安装 JDK
在即将部署待测程序的服务器PC上安装 JDK
2．部署待测程序
从笔者的 GitHub 下载待测程序，程序名为 httpinterface-0.0.1-SNAPSHOT.jar，下载后放在服务器上，执行以下命令运行即可：
java -jar E:httpinterface-0.0.1-SNAPSHOT.jar
上述命令把本地电脑作为了服务器，且把待测程序放在 E 盘根目录，读者可根据实际情况替换以上路径。运行成功后如图 4-1 所示。
4.3 手工测试用例设计
4.3.1 分析待测接口
在做接口测试时，需要以接口文档作为标准。接口文档一般以 Word 文档、Excel 表格或接口文档服务器(例如Eolinker)等形式呈现。下面以 Excel 表格形式给出待测程序的接口文档，文档内容如表 4-1 所示。
表 4-1
这是一个简单的接口文档，在实际项目中，接口文档应该更为规范。
1．RESTful 接口分析
待测程序有两个 RESTful 接口。
/mobilePhone GET 接口：入参为手机型号，接口功能为通过手机型号获取手机信息，包括手机品牌、手机型号和手机操作系统。
/mobilePhone POST 接口：入参为手机信息，接口功能为保存手机信息。
2．SOAP 接口分析
待测程序只有一个 SOAP 接口，入参为手机型号，接口功能为通过手机型号获取手机信息，包括手机品牌、手机型号和手机操作系统。
SOAP 接口的功能和上面的/mobilePhone GET 接口的功能是一样的，这样编写待测程序的目的是方便读者比较两种接口的差异。RESTful 接口一般基于 JSON 传输数据，而 SOAP 接口基于 XML 传输数据，因此 RESTful 接口的效率更高，这也是目前 RESTful 接口更为流行的原因之一。
4.3.2 测试用例设计
接口测试常用的工具有 JMeter、Postman 和 SoapUI 等，无论使用哪个工具，都应提前做好接口测试用例设计。
接口测试用例设计应该从入参、返回值、接口逻辑、性能和安全等各个方面考虑。这里以入参作为示例设计手工测试用例，后面会将这部分手工测试用例转换为自动化测试用例。
1．RESTful 接口测试用例设计
（1）/mobilePhone GET 接口
① 参数必填项。
② 参数长度。
接口文档未提及参数长度，理论上 GET 请求没有参数长度限制，但我们可以提交一个相对较长的参数。
Case 4：model=「01234567890123456789012345678901234567890123456789」——返回空
③ 参数组合。
在多个参数的接口中，参数可能相互响应或制约，因此对参数组合的用例设计必不可少。本接口不涉及（因为只有一个参数）。
④ 参数规则。
一般特殊的参数会有相应规则，比如手机号、身份证号或统一社会信用代码等。本接口不涉及。
⑤ 参数枚举。
有些参数只接收几个固定的参数值，这类参数在服务端大多用枚举定义，这种情况下需要测试每种枚举值。本接口不涉及。
综合以上各种情况，/mobilePhone GET 接口一共设计了 4 条手工测试用例。
（2）/mobilePhone POST 接口
① 参数必填项。
② 参数长度。
接口文档未提及参数长度，理论上 POST 请求没有限制请求体长度，但我们可以提交一个相对较长的参数。
这里没有对 os 参数做参数长度测试，稍后会说明原因。
③ 参数组合。
本接口不涉及。
④ 参数规则。
本接口不涉及。
⑤ 参数枚举。
os 参数代表操作系统，目前主流的手机操作系统是 Android 和 iOS。接口文档示例中 os 的值为「ANDROID」，在 Java 中枚举用大写表示，故推测该字段在后台以枚举方式定义。
os 的值为「ANDROID」，上述已有用例覆盖，因此不再单独设计用例进行覆盖。
综合以上各种情况，/mobilePhone POST 接口一共设计了 11 条手工测试用例。
2．SOAP 接口测试用例设计
由于待测程序中 SOAP 接口的功能和上面的/mobilePhone GET 接口的功能是一样的，因此手工测试用例设计参考/mobilePhone GET 接口，不再赘述。