看完秒懂原来接口测试用例设计这么简单

1123 篇文章 44 订阅
649 篇文章 11 订阅

什么是接口

接口:服务端程序对外提供的一种统一的访问方式,通常采用 HTTP协议,通过 不同的url,不同的请求类型(GET、POST), 不同的参数,来执行不同的业务逻辑。

客户端大多数的业务操作,都是需要 调用 服务端接口来获取一些数据, 或者触发某些业务,然后客户端拿到接口返回的数据后,会根据数据内容做不同的处理和展示。

为什么要做接口测试

A、在公司里,客户端和服务端通常是由不同的团队开发的,在项目开发过程中,客户端和服务端开发的进度不一致,比如服务端先开发完了,这个时候可以先对服务端进行接口测试,确保服务端逻辑和返 回数据是正确的,然后再测试客户端。或者是某些测试部门,专门测试服务端开发团队,因此,他们的 测试对象就是接口。

B、在测试某些业务时,不能仅仅通过前端来测试,比如用户注册,前端限制了用户名不能为空,但是有些人可能通过工具绕过前端直接调用服务端接口,如果服务端没有做相关的逻辑判断,就会造成数据 错误。包括接口数据传输过程中是否对关键信息加密等。所以必须 针对服务端接口单独做测试

C、在开发提测后,可以先通过工具把服务端的接口测试跑一遍,确保接口测试用例都是通过的,快速判断服务端接口是否符合预期。然后 再通过UI界面进行测试。否则接口有bug,前端页面必定有bug。

接口测试的意义

按照分层测试模型,处于中间层的接口测试,在稳定性,效率,成本,技术,实施难度上综合来讲,是收益最大的。相较于传统的UI层次的测试,接口测试把测试提前了(时间上,架构上),并且能够覆盖到一些UI测试无法触及的功能点,提高了测试的覆盖率,对质量控制提升了信心。接口测试也更容易实现自动化持续集成,支持后端快速发版需求,利于CT(持续测试)的开展。

(分层测试模型 - 图片摘自 51testing 网站)

接口用例设计方法

接口测试用例设计的重点,在于功能性的业务逻辑检查和参数检查。

1.功能:检查接口基础功能,是否完成了业务逻辑要求。此处的用例设计方法,和普通的测试用例设计方法一样。可以把接口当作一个待测模块,分析接口功能需求,利用常规用例方法设计测试用例。可供参考的用例设计方法如下:

1

2

3

4

5

6

7

8
1.等价类划分法

2.边界值分析法

3.错误推测法

4.因果图法

5.判定表驱动法

6.正交试验法

7.功能图法

8.场景图法

2.数据:分析接口的输入参数,覆盖各种可能的场景。

(1)检查接口的输入,数据格式、数据类型、数据范围等

(2)检查接口的参数边界(传递的参数足够大或者为负、空值时)

(3)检查接口的参数的组合,可选、必选等

(4)检查接口的约束条件,不符合约束条件的,不需要设计用例

3.性能:接口是否造成性能瓶颈,能承受的压力范围

4. 安全:接口是否涉及安全性

接口用例设计举例

下面以一个web接口作为案例,接口说明文档如下:

1

2

3

4

5
接口名称:获取用户订单

请求URL:{$url}/getUserOrder

请求方式:POST

返回举例:

请求参数:

名称必填类型说明
uidYString用户id
orderNumNInt订单数量

根据(1)业务流程(2)输入参数(3)输出返回(4)性能(5)安全 5块内容对接口进行用例设计。用例参考如下:

业务流程用例
获取用户订单成功
用户订单不存在
用户不存在
获取用户订单异常
输入参数用例
uid不为空,orderNum不为空
uid为空,orderNum为空
uid为空,orderNum不为空
uid不为空,orderNum为空
uid正确,orderNum不为空
uid正确,orderNum为空
uid错误,orderNum不为空
uid错误,orderNum为空
orderNum=-1
orderNum=0
orderNum=1
orderNum=5
orderNum=100000
orderNum
uid数据格式错误
orderNum数据格式错误
输出结果用例
返回空值
返回有效订单
返回错误信息
返回超时信息
性能用例
安全用例

用例筛选:

此接口,接近30个用例,已经比较全面了,但实际上有点冗余。比如,如果调用接口的界面是个用户选择界面,那么参数上,会受到约束,uid/orderNum都从前端传入,是一些固定的值,那么就不会产生一些特殊情况。类似以下情况,就不会在实际中遇到,因此这些用例的价值趋于0,完全可以在用例文档中去除。

uid为空,orderNum为空
uid为空,orderNum为空
orderNum=-1
orderNum=0
orderNum=100000
orderNum数据格式错误
uid数据格式错误
uid错误,orderNum不为空
uid错误,orderNum为空

设计的用例在考虑全面之后,需要再做一次减法,保证用例的实效性。对无法出现的场景设计出来的用例,毫无价值,只会增加我们的工作量,对产品质量提升没有帮助。因此,测试用例并不是越多越好,在于该用例是否能真正预防bug。

接口测试质量评估

接口测试用例在执行了一段时间后,需要对用例进行质量评估,即是对用例进行维护和优化。评估的内容可以参考如下几条:

(1)业务功能需求覆盖率;

(2)异常场景覆盖是否完整;

(3)代码覆盖率;

(4)用例的有效性,检查出bug的概率;

(5)用例的错误率,bug误报指数;

(6)测试数据维护成本,mock数据的准确性;

通过评估,可以得到接口测试的一些结果数据,对下一阶段接口测试的进行有参考意义,也有助于不断提高测试的质量和效益。


学习资源分享

最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走

这些资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助…….

  • 0
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
接口测试用例设计可以按照以下步骤进行: 1. 确定测试目标:明确要测试的接口功能和预期结果。 2. 划分测试范围:根据接口的不同功能和参数,将测试用例划分为不同的模块或功能点。 3. 设计测试数据:确定需要使用的测试数据,包括正常数据、边界值数据、异常数据等。 4. 编写测试用例:根据测试目标和测试数据,编写具体的测试用例,包括输入参数、预期输出、前置条件等。 5. 设置测试环境:搭建测试环境,包括准备必要的测试工具和模拟数据。 6. 执行测试用例:按照设计测试用例,执行接口测试,并记录测试结果。 7. 分析和报告:根据执行结果,对测试用例进行分析,找出问题并生成测试报告。 在设计接口测试用例时,需要考虑以下几个方面: - 正常情况下的输入和输出:确保接口在正常情况下能够正确处理输入参数,并返回符合预期的输出结果。 - 边界值测试:对于接口的输入参数,要考虑边界值情况,例如最大值、最小值、空值等,确保接口能够正确处理这些特殊情况。 - 异常情况处理:对于非法输入或错误操作,测试接口是否能够正确地进行异常处理,例如返回适当的错误码或错误信息。 - 接口间的调用关系:如果接口之间存在依赖关系,要确保在测试过程中正确模拟这些调用关系,并验证接口之间的数据传递是否正确。 - 并发和性能测试:对于高并发或大数据量的场景,需要设计相应的测试用例来验证接口的并发性能和稳定性。 请根据具体的项目和接口需求,结合以上原则来设计适合的接口测试用例

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值