架构

浏览器：b/s架构

客户端跟服务器交互：c/s架构

接口测试：通过调用接口来模拟合法的、非法的、无效的请求来检查服务端的输出结果、性能、异常处理结果是否与需求文档一致。

接口测试必须掌握的知识点：

URL：http[s]://host[[:port][abs_path][parameter]]

Header:头信息，包含报文的描述信息

Method:请求方法

Request Parameters:请求参数

Respouse Status:响应状态码

接口测试的意义：

1.确保主要流程以及系统稳定性

2.将bug控制在项目前期阶段（接口测试先行）

3.缩短产品的研发周期

4.检查服务器的异常处理能力

接口测试的方法：

1.通过编写脚本代码进行测试

2.通过工具进行测试

3.通过手工在浏览器访问接口进行测试

接口的使用场景：

1.系统与系统间的调用

2.上层服务队下层服务的调用

3.系统内，服务于服务间的调用

接口测试流程：

参与需求讨论与评审>>>接口设计和接口定义（开发，入参，参数个数，返回的参数类型）>>>设计与评审测试用例（正常测试点、异常测试点、评审用例涉及到哪些需求哪些功能点、开发以及产品人员进行补充）>>>执行测试（先了解每个接口应在哪个环境下测试）

接口测试用例形成：

需求文档、自己对业务流程的理解+接口设计、wiki文档

wiki文档包含接口请求方式、入参个数、入参类型、返回格式、返回参数个数、返回参数类型、返回参数具体含义。

接口测试用例设计：

1.请求参数的必填项和可选项

2.请求参数的合法输入、无效输入、非法输入

3.请求参数的边界值

4.请求参数的异常处理，例如：未带入必填项参数等（查看返回的错误码）

5.基于业务场景的考虑，例如：登录态、权限、依赖性等

6.设计到DAO层调用，考虑数据增删改查的正确性（前后台数据的正确性）

接口测试的重要异常关注点：

1.接口有翻页时，页码与页数的异常值测试（翻页后的内容是否重复、翻页时是否出错、传入超出最大页码数）

2.数据库的增删改查，比如一个post接口操作完成后，通过列表也接口看下新的数据是否和刚才的post一致（前后台数据的正确性）

3.每个接口入参的默认值、异常类型、非空校验（无默认值、为空时怎么处理？）

4.接口返回的图片地址能否打开，图片尺寸是否符合需求

5.当输出参数有联动性时，需要校验返回两参数的实际结果是否都符合需求

6.所有列表页接口必须考虑排序顺序

7.所有功能都要考虑兼容旧版本

8.入参支持传多个值时，要考虑传的值的个数多的情况下，接口会不会报错（输入超出规定的参数个数）

9.输出参数类型

接口测试常用工具：

手动辅助工具：fiddler、postman、httpwath

自动化第三方工具：soapui、robotframework+httplibrary

性能第三方工具：jmeter、gatling、loadrunner

好用的抓包工具：Burpsuite  (http://drops.wooyun.org/tools/1548)