【学习】API接口测试用例编写规则

为什么要写用例

功能测试用例,大家都写过。但接口测试用例,估计很多人没有写过。在写之前,我们来讨论下,为什么要写接口用例。
*** 理清思路,避免漏测和重复测

  • 提高测试效率
  • 跟进测试进度
  • 告诉领导做过
  • 跟进重复性工作
  • 更好的记录问题,发现问题,复现问题
  • 同时这也是是接口测试流程中的一个产物(测试用例)**

上面七点,有经验的同学结合自己测试的实际经验,应该是很好理解和认同的。
有用例,就有思路,跟着用例测试,可以避免随机测试那种没有目的性的测试,提高测试效率,做到心中有数。
有用例,上级问你完成的进度,你好用数据回答。
有用例,用来标记你执行的结果,证明你做过测试,避免将来发生问题,人家说你没有测试,有数据和证据说话。
有用例,测出问题你可以根据用例将问题轻而易举的浮现出来,不至于等你反馈或者复现的问题时,你忘记是如何操作才回出现问题。接口测试也需要重复跑,跑几轮,或者用自动化天天跑。这样的重复性工作,用例可以保证每次重复做的是一样的情况。

接口主要设计用例点

主要从四个方面来设计接口用例:功能,逻辑业务,异常,安全

功能:
1)功能是否正常;
2)功能是否按照接口文档实现
比如论坛发布文章,需要登录才能发布。也就是业务要求不支持游客发布文章功能,如果设计一个没有登录的用户,然后去测试发布文章接口,结果接口能发布成功,说明功能不正常,不符合需求和接口文档描述。

逻辑业务:
1)是否依赖业务
该接口调用之前,需要调用登录接口,如果不登录也能请求数据,不符合业务规则。

异常:
1)参数异常:关键字参数,参数为空,多,少参数,错误参数
2)数据异常:关键字数据,数据为空,长度不一致,错误数据
打个比方,不管数据异常还是参数异常,测试点差不多,一个参数有key和value,key表示参数,value表示数据。第一,看看参数和数据能不能支持关键字,例如Java中的保留关键字等等。第二个就是参数和数据都为空,看看是否做了判断。第三个,参数多和少,例如有两个参数的接口,你需要设计一个三个参数的用例,一个只有一个参数的用例。数据那边长度不一致,例如设计很长的字符串是否支持,因为数据库创建表过程都设置好了每个字段的长度。输入错误的参数和数据,例如故意输出单词等等。

安全:
1)cookie:有cookie才能获取数据,如果不带cookie还有信息返回,说明有问题
2)header:正常接口带header信息,删除header看是否能够返回数据。
3)唯一识别码:app手机识别码,一般是唯一的。

安全测试主要从上面三点检查。第三个是唯一识别码,主要是指app上手机的识别码,一般很少用到,除非很严格的接口测试,例如银行app登录,需要指纹,而指纹来源手机,一般有一个手机识别码判断过程。

接口管理和测试工具

不管是一开始的接口文档、接口用例还是到后续的接口测试和返回报告,都需要通过工具来实现,之前很多人用的是国外的Postman,但是现在越来多的人因为各种原因选择国内的工具像Eolinker等。
下面演示一下Eolinker添加测试用例流程。

首先直接在官网上注册个账号,就可以自动跳转到Saas版本开始在线使用,Eolinker支持免费试用体验全部功能,无需付费。

接着进入测试用例页面,点击 创建用例 按钮,在弹窗中填写 API 的请求地址、请求参数、校验规则等信息,然后保存,就可以在界面里执行测试操作了。

同时Eolinker也有其他泛用性很强的功能,国内奇安信、广联达等龙头企业也都在使用。
使用地址:www.eolinker.com

原文地址:https://www.cnblogs.com/dc20181010/p/14752165.html