接口测试测试用例包括：1. 某个用例的测试目的是什么；2. 接口信息的来源；3. 一些基本原则。其中，在进行接口测试脚本的编写前，我们应该明确这批脚本的预期目标在哪里，是为了验证什么内容。
一、接口测试测试用例
1. 某个用例的测试目的是什么
在进行接口测试脚本的编写前，我们应该明确这批脚本的预期目标在哪里，是为了验证什么内容。根据个人的经验，一般会把接口用例分成三类：
- 单接口验证：以验证接口参数、权限、返回值为主，保证接口“能用”，这类用例一般在接口设计定稿后，配合Mock服务就可以完成用例编写；
- 场景逻辑验证：以用户场景为基础，验证接口间的参数传递及业务流程能够正常流转，用例复杂度较高，需要非常熟悉业务与接口之间的关系。这是接口测试最核心的价值。
- 异常验证：主要验证参数异常、逻辑异常等情况下，接口是否能处理并给出友好的错误信息。通常情况下，关注参数异常的场景会比较多，可以用等价类、边界值等方式来处理。需要注意的是多关注下异常的返回信息是什么，信息是否明确，提示是否友好等等。
2. 接口信息的来源
当我们明确好测试目标后，再开始编写测试用例，会有更针对性的去设计测试数据和接口组合。接下来的问题是什么呢？去哪里确认你的接口信息是有效的？基本上有两种路径：
- 接口文档：开发人员都不喜欢自己写文档，同时也很讨厌别人不写文档。所以测试人员如何获取一份真实有效的接口文档是件比较麻烦的事。般团队内都会有一个统一的接口文档管理工具（如果没有，就找开发多磨麿，让他们弄个，并不难），我们需要关注接口文档的有效性和及时性。现在也有很多的插件或者工具能够帮助研发人员自动生成接口文档，例如Swaager、apidoc等等。
- 接口抓包：如果什么都没有，那就自力更生，通过Fiddler之类的工具，通过抓包分析的方式来获取接口，这类的场景如果较多的话，可以把Fiddler抓到的接口导出，然后写个小程序，直接转成接口平台可以识别的脚本，效率会更高一些。
在获取到接口信息后，需要与开发人员多交流，明确参数的意义及来源，以便我们针对性的做测试用例设计，这个环节不要过多的自己猜（很多测试人员经常会自己猜想），直接找开发问就好了。在这个接段，还要梳理并区分接口的重要程度和优先级。这样就可以确认哪些接口优先设计用例，哪些接口可以先放放，在有限制的时间内，做最大价值的事。
3. 一些基本原则
拿到接口后，明确了参数说明，结合测试目标，我们就可以开始设计并编写测试用例了。区别于功能测试用例，接口测试用例（脚本）一些原则需要注意：
- 自动化：好像是废话，所有的用例应该是非交互试，最常见的就是Token之类的生成，需自动处理好（我见过每次执行用例前，需要自己手动生成Token再粘贴进去的脚本，特别是分环境执行的时候）。
- 独立性：每个用例应该是独立的，没有依赖的。需要在一个用例里处理好前置条件，而不是多个用例相互依赖。
- 可重复：用例测试可重复执行，所以需要注意参数的生成方式。
- 可持续性：如果代码修改导致已有接口测试执行失败，必须修复代码问题或者测试代码逻辑。
延伸阅读：
二、什么叫测试用例
测试用例（Test Case）是为某个测试目标而编制的一组测试输入、执行步骤以及预期结果的集合，以便测试某 个程序的路径或验证软件是否满足某个特定需求 测试用例的概念包含以下几个方面的特性： 1.目标：测试用例的目的是为了达到一定目标 2.作用：去验证某个路径或某个特定的需求 3.集合：表示测试用例由多个项组成：如输入数据、步骤、预期结果等。
