（3）最后当出发点、对象、功能都确定了，就可以设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。
接口测试用例设计和其他测试用例设计一样，都应该本着尽可能的发现bug的目标。用例设计的内容应该包括：主要测试功能点、测试环境、测试数据、执行操作以及预期结果。
接口测试环境分为两种，一种是程序内部的环境；一种是程序的
（1）所调用外部接口的环境。
用例在设计环境上有一个原则即：设计真实而危险的环境，不忽视偶发环境。真实，即你的用例在测试某种功能时，应该去思考这种情况发生时内部、外部环境是什么，通过各种手段将最准确的环境模拟出来。危险，即在这种环境下系统出问题的概率会很大。在设计用例环境时，如果两种环境都能达到你本用例的要求，更推荐选择更危险的环境。所谓偶发，即这种环境出现的概率很小。不要因为这种环境很少出现就无视它，此处很有可能隐藏着问题。
（2）接口测试数据分为接口参数数据和用例执行所需系统数据。
数据的设计学问大，不要在设计、准备测试用例的数据上偷懒。要通过好的测试数据使用例查错的功能充分发挥。接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据，使用例更容易发现问题。
（3）测试功能点
如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。
（4）接口测试用例执行操作非常简单，就是所测接口的调用
预期结果验证，这也是接口用例设计的很关键的一步，应该细而不冗余。所谓细，用例中应详细列出应该验证的点。每个用例均需验证，不要因为前几个用例有验证就认为全部是正确的。避免一个用例中重复做相同的验证，提高测试用例的效率。
五、API接口的定义
应用程序接口（Application Programming Interface 简称API）在现代软件中随处可见，目的在于为某个组件的功能提供一个逻辑接口，同时隐藏该模块内部的实现细节。是对问题的抽象，以及客户与解决问题的软件组件之间进行交互的方式。总的来说：API是一个明确定义的接口，它可以为其它软件提供特定的服务。
比如读取图像的API可能仅仅提供一个LoadImage()函数，它接收一个文件名作为参数，然后返回一个2维像素数组，而所有文件格式和数据压缩的细节全部隐藏在这个看似简单的接口之下。客户端代码可以通过调用该API的公有接口。
六、内外部接口的调用
1.外部接口
对外部提供的接口（提供给第三方使用的接口)
例如：我们自己开发系统调用调用微信或支付宝支付接口，微信或支付宝供我们调用的接口为外部接口，外部接口需要覆盖各种正常和异常情况。
2.内部接口
对自身系统提供的接口（供系统内部调用的接口）
一般为了尽早的介入测试，所以一般接口开发完成测试人员就可以进行内部接口测试。一般大公司可能要求比较高，需要考虑安全问题，那么内部接口测试也是一定要测的。对于小公司都是不对内部接口进行测试的，直接在UI层测试即可。这样做的原因是为了防止攻击者会绕过前端的验证直接对接口进行攻击，那么后端接口的验证也是必不可少的。
七、接口测试的范围
（1）接口范围包括：
一、被测项目中同层之间的接口（如DAO层、Service层），一个接口调用了其他的接口
二、外部系统与系统之间的交互点（如一个App调用了第三方支付宝的API）
三、各个子系统之间的交互点（如App客户端调用了服务端的Http接口）
（2）被测接口范围：
接口很多，依据公司的测试资源，项目特点来进行对部分接口/全部接口进行筛选被测API。在一般的中小型公司里，第1类的接口是由相应的开发同学去做。测试同学主要是测试第2种
（3）接口测试的重点测试范围： 着重测试主要业务，业务复杂的接口
