原文链接： 5 Best Practices for Data Driven API Testing
当你决定迈出这一步，开始将数据驱动测试过程应用到 API 质量保障中，很快就会开始从这种高度灵活的策略中受益。数据驱动测试方法的优点如下：
- 能够整体验证综合的应用逻辑
- 能获取准确的性能指标
- 高效利用技术栈
- 与敏捷软件交付技术同步
- 为自动化测试做准备
在数据驱动的 API 测试中，遵循以下这 5 个简单的最佳实践，一定会浮现有价值的结果。
1.使用真实数据
这一点看似是凭直觉推论而无切实依据，但实际上，如果测试数据越接近于 API 在生产中遇到的情况，测试过程就会越全面和准确。
确保测试数据真实的最佳方法，是从源头开始 —— 即 API 需要支持的业务过程。
质量保障过程中，需要注意业务用户和 API 测试之间的差距：在设计和实践中，要先了解 API 背后的基本原理以及它的信息交互过程。
同样重要的是，需要考虑到数据之间存在的“不明显的关联”：某些输入值可能取决于传输到该 API 的其他信息，返回值同样如此。
尽量使用适当的工具集，可以在你的测试数据中准确地表示这些关系。
2. 测试正面和负面结果
大多数人只考虑到来自 API 的正向响应：传输有效的数据，服务器端操作成功完成，响应返回给 API 的调用者。
但这只是开始 - 与正向验证同样重要的场景是，向 API 发送不正确或无效的参数，触发负面结果（通常是错误消息或其他问题指示）。
此外，功能测试可以也配置为：中断测试的错误情况是否被适当地处理。
这种 API 评估方法，可以让测试人员更轻松地找出故障点，不必费力地查看完整的结果集。
相反，只有在预期的正向结果变成负向结果（反之亦然）时，这些case才需要深入处理。
3.使用数据驱动动态断言
断言是表达 指定 API 请求的预期响应 的规则。
断言用于确定 API 的行为是否符合其规范，因此是质量的主要指标。
一方面，许多测试人员错误地对这些断言进行硬编码，这会给 API 评估过程引入非必要的维护开销和脆弱性。
另一方面，动态断言需要是灵活的，能够从一个 API 请求传递到另一个 API 请求。
例如，一个电商运费计算器 API ，传入一条 50 美元的测试数据，预期响应为免费送货（即响应中的运费为 0 美元）。
下一条测试数据可能是价值 49.99 美元的订单，应该会产生 5.99 美元的运费。动态断言可以让测试人员将 0 美元运费的预期响应与 50 美元的输入订单一起存储，同理存储 49.99 美元订单和 5.99 美元运费。
后续新的测试场景也可以如此添加到输入数据集中，而无需对功能测试本身进行任何更改。如果运输政策发生变化，只需更改测试的数据和断言——其他一切都将保持不变。
4. 跟踪记录 API 响应
许多测试人员仅关注每个 API 调用的成功或失败与否，而在完成功能测试后就丢弃了响应集。
非常可惜，因为来自 API 的响应数据是非常有用的产物。如果不记录这些测试结果，就会丢失重要的历史数据。
如果一个 API 经历了多次更改后，在回归测试过程中发现了一个新错误，那如何准确识别是哪个修改导致了缺陷，将是一项艰巨的任务。查阅存储的 API 请求和响应库，可以更轻松地确定缺陷的引入时间并快速修复。
5. 利用数据驱动的功能测试来提高性能和安全性
值得注意的是，许多团队使用高度不切实际、范围狭窄的性能和安全测试，这些测试也受到范围狭窄的硬编码测试数据集的阻碍。
设置正确配置、适应性强的数据驱动功能测试需要花费大量时间和精力，因此一旦对此进行了投入，为什么不将其用于多个目标呢？
重用数据驱动的功能测试能力，可以为性能和安全评估过程注入一剂强心针。
