接口的设计实例（接口设计案例）

本篇文章给大家谈谈接口的设计实例，以及接口设计案例对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享接口的设计实例的知识，其中也会对接口设计案例进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、接口用例设计
• 2、接口测试用例设计
• 3、如何简单设计接口测试用例

接口用例设计

目的：测试接口的正确性和稳定性；

原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；

重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；

核心：持续集成是接口测试的核心；

优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显

用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统接口（验证系          统处理后的数据是否正常）；
输入参数主要从以下几各方面设计：

a 必填项校验

接口文档中有是否必填的说明。参考接口文档即可。

b 参数长度校验

参考接口文档即可。

c 参数值的有效性校验

所以参数有效性的校验就需要结合实际业务场景，判断哪些数据是真实有效的数据，一定要确保所有真实有效的数据是可以验证通过的。

d 参数组合校验

不同的参数组合可能会存在不同的业务场景；

e 如果参数是枚举值，一定要各种枚举值都要测试，因为可能不同的枚举走的不同的业务流程；

f 参数值的默认值的校验

参考接口文档。

g 某些参数具有特定的生成规则，要单独针对生成规则设计用例，一定要保证真实有效的数据是可以验证通过的。
接口逻辑我用的设计方法是分支覆盖—路径覆盖—场景覆盖,同样也是要结合实际业务场景，根本不发生的业务场景就是无效的测试用例。

a 第一步先把业务流程图画出来；

b 依据路程图中的分支分别设计，不同分支不同的场景，这里就要把异常的场景考虑进去；如接口超时，接口异常，接口请求成功或失败，成功后怎么处理，失败后流程是否继续执行，失败后的数据怎么处理；

c 测试逻辑设计完成后要想一想不同的业务场景怎么去测试，需要哪些人员协助，

如接口超时怎么去测试，请求重复怎么去测试，请求并发怎么去测试
输入结果：正常输出和异常输出，常用的方法有错误推断法（列举出程序中可能存在的错误或者异常，根据他们选择测试用例）

接口测试用例设计

接口测试发现的典型问题：

（1）传入参数处理不当，导致程序crash；

（2）类型溢出，导致数据读出和写入不一致；

（3）因对象权限未进行校验，可以访问其他用户敏感信息；

（4）状态处理不当，导致逻辑出现错乱；

（5）逻辑校验不完善，可利用漏洞获取非正当利益等。
用例设计：

1：入参类型：

数值型 ：

如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。

类型的特殊值：-1,0

数据类型的边界值：int的最小值最大值；

特殊值处理不当导致程序异常退出；

类型边界溢出

取值范围外值未返回正确的错误信息等
字符串型：

字符串型的参数，主要考虑字符串的长度和内容：

特殊值：空字符；

边界值：String的最大长度；

字符串内容可考虑类型：数字，非数字；

特殊字符。

超长字符未进行处理，导致存储、显示等异常
 数组或链表类型

参数类型为数组或链表时，用例可以考虑：

例如批量提交任务的接口submitTask(int[] taskID)，参数用例设计考虑：

正常取值：1-5个权限，范围外：6个权限；

边界值：1-35的边界值，请求允许最大最小值；

特殊值：0个；

合法ID和不合法的；

重复的ID等。

可能存在的问题和风险：

0个item时程序异常退出；

重复的item处理时未去重导致结果异常等。
2：针对逻辑设计

约束条件分析

（1）数值限制：分数限制、金币限制、等级限制等等。

例如：兑换Q币活动要求积分50才可参与。

（2）状态限制：登录状态等。

例如：同步用户信息需要先登录账号。

（3）关系限制：绑定的关系，好友关系等。

例如：帮家人防骗功能只能查询绑定家人的来电信息。

（4）权限限制：管理员等。
3： 针对输出结果

接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。例如提交积分任务的时候我们通常能想到的是返回正确和错误，错误可能想到：无效任务，无效登录态，但是不一定能否完全覆盖所有错误码，而接口返回定义的返回码可以设计更多用例：

覆盖返回码也是用例设计的一种思路。

常见问题和风险：

（1）错误前端处理不足，导致前端异常；

（2）错误提示处理不当，导致用户看到晦涩的错误码；

（3）错误提示不当，导致用户不知道哪里出了问题，如何解决。
4：接口超时

（ 1）未进行超时处理，导致整个流程阻塞

（2）超时后又收到接口返回，导致逻辑出现错乱

如何简单设计接口测试用例

接口测试是项目测试的一部分
，它测试的主要对象是接口
，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。
如何设计接口测试用例?首先，明确出发点，和所有的测试一样
，接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向
，你的设计行为就会尽量朝这个方向，更易发现问题
其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口
，每个接口如果分别测试
，那将是很痛苦的一件事情，而且任何一个内部接口的变动
，都将导致我们用例的不可用。
可将这些最外层的接口分为两类:一类是数据进入系统的接口;一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用
，模拟外部的使用;而流出的接口则是我们用例真正该验证的点。数据从哪里流出，流出时的状态如何
，此时系统又是什么状态都是我们所应该验证的。
然后，确认完整的测试对象的功能:确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。
最后当出发点、对象、功能都确定了，就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。
接口测试用例设计和测试用例设计一样，用例设计的内容应该包括:主要测试功能点、测试环境、测试数据、执行操作以及预期结果。
1)接口测试环境分为两种:一种是程序内部的环境;一种是程序的所调用外部接口的环境。
2)接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列
，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据
，使用例更容易发现问题。
3)测试功能点，如果一个接口功能复杂时推荐对接口用例进行结构划分
，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。
4)接口测试用例执行操作非常简单，就是所测接口的调用。
5)预期结果验证，这也是接口用例设计的很关键的一步
，应该细而不冗余。每个用例均需验证
，避免一个用例中重复做相同的验证
，提高测试用例的效率。
如何设计接口测试用例小例子:
简单划分可以按照2个基本组成要素进行划分:1.
参数
2.
业务
以下为最简单的一种划分用例的方法，可能涵盖不全，但只为说明一种划分接口用例的方法方式以及需要考虑的测试用例的测试点
为何要如此设计，是为了更好的将用例分类为程序规定型以及业务限制型，尽量的保证覆盖，尽量细化到点的划分形式来保证工作时间的预估和计划。
所有的自动化接口的测试用例
都基本围绕三部曲进行，传数据，执行，校验返回的数据和期望数据是否一致来构成每个简单的测试用例。
有清晰的线路和清晰的思维，才能做好整体测试的掌控。

关于接口的设计实例和接口设计案例的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口的设计实例的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口设计案例、接口的设计实例的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。