（上篇）API测试在测些什么，这些方向你值得拥有
引言
在现代在软件生态中，API已经随处可见了。不管是云服务比如AWS、政府平台比如税务，还是一个小的应用系统中后端与前端的交互，大多以暴露API的方式在提供服务。另一方面，我们谈论了无数年的测试金字塔也强调了API测试的重要性。可是经过观察却发现，有相当一部分项目对API测试是不充分的，要么认为不需要专门API测试、要么测试覆盖不够。
本文是API测试相关两篇文章中的“上篇”， 主要来谈谈“API测什么”。“下篇”会主要集中在实践上“API怎么测”。
要不要测API?
在具体展开“测什么”之前，先来简单讨论下要不要测的问题。
图一：API及其访问方式
如图一所示：用户（包括恶意用户）可能会通过多种途径访问API(s)，同时意味着系统将要承受由于暴露API(s)后带来的各种可能的风险。如果不进行测试，我们对这些潜在的风险及其影响将一无所知。
所以对API得进行测试，从而才能了解其质量状况。但对相关质量问题采取什么措施可以依据其风险高低来决定。比如在用户场景有限、用户数有限且网络环境安全的To B系统中，系统由暴露API带的风险就比To C系统中的风险小得多。
测什么？以终为始，从质量的角度出发
对质量的关注是我们进行测试的主要驱动力。但每个项目的上下文都不一样，所以测试内容和侧重点也会各有不同。接下来讨论的更多的是有关API测试的共性，如果项目有更多特定的业务或技术选型，可以此为基础展开。
在具体讨论前，有必要申明下本文所用的“测试”一词的含义，请参考以下公式：
已测试 = 已检查（Verification, Validation） + 已探索（Explore）
其中，检查（Verification, Validation）意味着去执行根据需求和假想中的软件/系统而提前写就的测试用例/脚本，但真正的软件/系统在书写测试用例/脚本时还不存在。而探索意味着对真正的软件/系统进行有目的的交互，从而了解更多之前不可能预见的软件/系统行为。
针对单个API（功能）
1. 一个API能完成最基本的业务功能吗?
- 测试内容：测试最可能的或者当时能想到的数据组合（包含正、负向数据）
- 测试特点：虽然一个API一次执行本身的很容易，但是在环境中准备相应的数据条件有时并不容易，对结果的判断如果还是凭“肉眼”观察，那么执行的可重复性和效率都会比较低。另外，一次执行后或多或少对系统都作出了某种程度的改变，还原系统或重置数据也需要考虑。
- 测试数据量： 一般比较小
- 测试复杂度： 相对较低
2. 一个API能否处理“足够多类型”的正向数据?
- 测试内容：测试和探索当不同类型的合法请求时，系统的表现
- 测试特点：请求数据的可能组合是随变量数指数级增长，完全测试又不可能达到，过低的测试覆盖又不足以了解系统的质量，需要尝试“足够多”的组合。组合测试在正交场景下有不错的效果，但是更一般的场景下效果却不甚理想。有时引入模糊测试能收到更好的效果。
- 测试数据量： 高
- 测试复杂度： 高，可能有模糊测试分析
3. 一个API能否处理“足够多类型”的负向数据?
- 测试内容：测试和探索当不同类型的负向数据请求时，系统的表现
- 测试特点：基本同上2。需要注意的是负向数据对系统更具破坏性。
- 测试数据量： 高
- 测试复杂度： 高，可能有模糊测试分析
4. 一个API能否持续正确处理可能的正向和负向数据?
- 测试内容：测试和探索更多正向和负向数据请求，以及系统经过功能迭代和重构后的表现
- 测试特点：经过上面的1、2、3，我们对系统有了更全面的认识，以此为基础，结合业务和系统设计，补充更多的数据。至此，就有了一套相对全面的功能测试数据和回归集。
- 测试数据量： 中
- 测试复杂度： 中
5. 一个API能否正确处理多个同时发生的请求?
- 测试内容：测试和探索系统的并发场景时的处理逻辑
- 测试特点：并发的手段在功能和性能测试中都能发挥巨大的作用。通常一个API在单个请求时工作良好，但在并发处理多个请求时却并一定满足预期，场景包括但不限于Unique ID生成、资源扣减与释放、底层处理死锁等。
- 测试数据量： 中
- 测试复杂度： 中
针对多个API（功能）
6. 多个API能否完成系统期望的“场景”?
- 测试内容：调用多个API，且有参数、值传递和执行依赖
- 测试特点：理论上，通过系统的API之间的组合调用就能完成系统承诺的功能，但需要针对API进行测试才能证明这点。另外，多个API之间的执行是否有需要“间隔”才能成功也是重要测试点之一，这在异步场景中尤其重要。（曾经碰到两个请求虽然有前后，但时差小于1秒时系统报错的情况）
- 测试数据量： 中
- 测试复杂度： 中
7. 多“场景”并发进行，系统能否隔离不同场景和用户?
- 测试内容：验证多个用户同时进行相关“场景”时，系统能隔离不同场景和用户数据
- 测试特点：一个用户能走完他期望的流程并不困难，但当不同用户同时对系统操作时，用户之间是否会数据影响呢？
- 测试数据量： 中
- 测试复杂度： 中
特定的技术选型相关
8. 缓存能否平衡数据准确性和时效性?
- 测试内容：测试缓存是否在有效期内生效，过期后失效
- 测试特点：缓存的存在一定程度上影响了系统数据的准确性，需要测试和评估缓存在可用、不可用等情况系统的整体质量？
- 测试数据量： 中
- 测试复杂度： 中
9. 数据库分区或者主从后是否还能稳定提供服务?
- 测试内容：多分区时数据的一致性，主从时数据同步延迟可能的影响
- 测试特点：数据库分区或者主从后的对数据一致性有着影响，需要对系统所承诺的一致性级别进行验证
- 测试数据量： 中
- 测试复杂度： 中
10. 第三方调用和依赖?
- 测试内容：第三方服务可能出现成功、失败、超时时，调用方的处理方式
- 测试特点：第三方服务的各种可能性能对系统产生不同的影响
- 测试数据量： 中
- 测试复杂度： 中
系统稳定与安全
10. API能否允许同一用户无限次调用？
- 测试内容：系统限流是否生效，或者对业务产生负面的影响
- 测试特点：系统每处理一次请求都是有代价的，不良的请求势必会影响系统处理正常请求的能力。作为系统保护措施之一，API限流是一种常见的方式。
- 测试数据量： 中
- 测试复杂度： 中
11. 性能和安全?
- 性能和安全是专门的测试内容，此处更多地是引起重视，但由于篇幅所限在此不展开讨论。
测试效率是测试成功的另一个关键
到了项目中后期，API已经累计到几十上百，测试数据成千上万也不少见，不当的安排会让一次执行的代价相当大（人力和时间）。而系统还在不断地添加新功能、不停地重构，随时可能让测试与系统不匹配。
而且，一个系统的测试内容远不止API测试，如果在API测试耗掉太多的测试时间，势必减少其它类型测试的时间，这样系统处于另外的风险中。
所以，测试准确、有效是测试的一方面，测试效率也是测试成功与否的关键。
