>使用单元测试,您可以检查实现的逻辑以获取所请求的数据是否正确,但这还不够.测试API,例如数据序列化/反序列化为各种格式( JSON,XML,ATOM,…),授权和等等.应检查身份验证,异常处理(将应用程序异常转换为HTTP错误代码).应从客户的角度测试API.您可以使用可以发送类似于客户发送的请求的工具来实现它,即 jmeter.
> API测试应该生成包含请求通过/失败的信息的报告.如果请求失败,应提供答复以供进一步调查. API测试应该集成到CI中.
> API测试应包括：

>功能测试：测试参数和参数的不同组合的有效请求,准备模拟客户端请求的测试场景,还应测试无效(坏)请求以检查是否正确处理并且不会使应用程序崩溃
>安全测试：检查来自不同客户端的请求是否相互影响
>性能测试：测量端点的响应时间

例

假设有一个带有查询参数的端点/用户：

> count(count> 0& count< = 100,默认值为10)
> startIndex(startIndex> = 0,默认为0)

相关测试场景可以分为两组：有效和无效请求

有效请求(始终检查响应格式)：

> GET / users – 从第0项开始验证响应是否包含10个项目
> GET / users？count = 1 – 从项目0开始验证响应是否包含1项
> GET / users？count = 100 – 从项目0开始验证响应是否包含100项
> GET / users？startIndex = 5 – 从第5项开始验证响应是否包含10个项目
> GET / users？startIndex = 200& count = 100 – 从项目200开始验证响应是否包含100个项目
> GET / users？startIndex = 0& count = 10 – 从项目0开始验证响应是否包含10个项目

请求无效：

> GET / users？count = 0 – 验证响应代码是400> GET / users？count = -10 – 验证响应代码是400> GET / users？count = foo – 验证响应代码是400> GET / users？count = 10bar – 验证响应代码是400> GET / users？count = 101 – 验证响应代码是400> GET / users？startIndex = -1 – 验证响应代码是否为400> GET / users？startIndex = foo – 验证响应代码是否为400> GET / users？startIndex = foo& count = bar – 验证响应代码是否为400