接口测试 关于接口测试的几点疑惑
我这边的后端是一个 HTTP 服务，以响应 JSON 为主。能想到的测试的覆盖可以从两个层面来做：
- 确保服务返回的 JSON 格式正确，这里的格式包括：结构、数据类型、数值范围等；
- 确保返回的数据值是准确的
上面的第一条，是相对比较容易做的，目前是在通过下面的 YAML 文件来描述（以及校验）：
但对于第二条，不同的环境下，预期的数据值是不同的。以 Kubernetes 为例，实际的 Pod 个数可以通过人工或者自动化手段来确认；但我困惑的在于虽然可以通过自动化手段拿到 Pod 的真实个数，可实际带来的成本也是较高的（如何确保自动化拿到的数据是正确的，自动化获取数据本身的复杂度）。
那么，在大家实际的工作中，是如何确保数据的正确性的呢？
再回到数据格式的话题上，上面是一种相对直白的方式来对格式做校验，理论上也几乎能验证了任意格式。但没有足够的通用性，通过 JSON Schema 是一种行业标准，但 Schema 本身的编写又是相对比较复杂的。大家对此又什么建议呢？
参考
关于数据的正确性，可以采用直接从数据库获得相应的数据，然后和接口获得的数据进行比较。当然这个得你对接口的数据获取逻辑很清楚才行。至于 json 格式我记得有专门判断返回数据格式是否正确的库，可以去搜索下，应该可以解决你的问题
ZW
回复
正如我上面提到的，不管是从数据库还是从什么地方拿 “所谓正确的数据”，这个过程本身具有一定的复杂度，这个过程也需要确认（确保）。按照这个思路下去，可能是个死循环。怎么确认你拿到的 “正确的数据” 就是正确的呢？
LinuxSuRen
回复
这个从来都不能保证是正确的。
去数据库拿数据，可以视为业务的另一种异构的实现。如果正常业务的实现和异构业务的实现一致，只能说明风险较小，不代表完全正确（所以可以加上多人评审，可能能够发现更多问题）。如果不一致，则一定有一方出现了问题。
小狄子
回复
嗯，这么讲，我就比较理解了。从多个渠道（接口）去拿相同数据去做匹配，不匹配就肯定有一方是错误了。那接口测试工具作为验证方，保障自身的准确性就比较重要了。
接口返回的数据和你请求预期数据，数据库中数据是否一致。如说正确性，要根据实际业务和接口实现的功能俩看。
通过下图 JSON Schema 的方式来对 Response Body 做格式校验，有多少人能接受这种方式呢，自我感觉复杂度还挺高
通常情况下，JSON Schema 既强大又方便，一般足够了。