接口测试 接口测试用例设计

测试zzZ · October 29, 2019 · Last by Test44 replied at November 05, 2019 · 2654 hits

最近刚开始接口测试,但由于没经验再加上接口文档的不完善,一直进展不起来,有几个问题求大家解惑,谢谢了
问题1:我们项目有web端和app端,web端是后台,app是产品
app首页显示文章是由后台控制的,即后台已发布的文章才能才app端显示
那么我测app首页接口时,应不应该考虑后台,首页接口有个pagesize的参数,参数的意思是首页显示的文章数
这个参数应不应该按照后台已发布的文章数量做对比设计用例?还是接口测试用例只需要考虑单个接口返回,不需要考虑逻辑
下面是我的接口测试用例,这样写可以吗

问题2:基于问题1,如果一般接口测试只需要测单个接口,那接口自动化一个用例需要考虑多个接口吗?
例如下单,需要考虑购物车,库存,余额这些接口吗?如果不需要考虑逻辑,那接口自动化作为回归有什么意义呢?
求大佬们解惑啊,困扰我很久了,公司就我一个测试,很难受

共收到 14 条回复 时间 点赞

这种问题我也在纠结,学完了但是想拿公司实际演练一下,发现公司的业务主要依赖定时器工程,真正的核心业务流程全部都是定时任务。然后就是接口关联的,上接口的部分响应数据做下接口的入参数据,如果全部使用python中的动态属性去做的话感觉总是差了那么点,但是如果使用mock只是为了做接口而做接口的话感觉没有必要,个人感觉核心的业务流程来做自动化回归更重要。不知道有没有大佬有好的答案,期待ing、、、

当然要考虑逻辑
按道理来说,接口测试是能够cover掉你所有的手工测试逻辑的,那为什么不呢?

仅限个人的一些看法,欢迎交流
问题1:app和后台是分不开的,如果你要测试app接口的话,预设条件就是后台已经初始化好,置于你的首页接口有个pagesize的参数,你只要针对pagesize进行校验,看app接口返回是不是你预期的结果,但这一步也是依赖于你后台已经设置好了文字数量,可以为0也可以多篇。
问题2:看你的目标是什么,是为了实现单接口校验还是为了流程性校验,对于单接口而言,一个接口就应该考虑各种场景,而对于流程性校验而言,只要保证我下单前库存存在,有余额即可,详细的校验可一步步添加

JIMMY 回复

我跟群里的测试讨论了一下,他们说测单个接口,不用考虑逻辑,只需要看返回就可以了。但是pagesize的值的设定还是应该根据后台的文章数量进行比对。
第二个问题,涉及到回归,如果接口自动化只是为了单个接口校验,感觉失去了自动化的意义,已经写好的接口基本上不会更改,因此不太能理解。我觉得自动化就是为了回归,新功能加入的时候,有逻辑关系的接口应该都有相对应的改变。

Karaser 回复

因为没有一个统一的标准,我看了很多人的接口测试用例,只是更换参数值,看返回数据。

个人愚见, #问题2的情况假如一个业务是由多个接口来实现的,需要对单个接口做接口测试还要多个接口串起来做自动化测试。 比如购买会员或者下单这种业务。

8Floor has been deleted

如果是,不考虑逻辑的前提下,那覆盖率能达到多少呢?如果覆盖率足够高也有一定意义
这样业务逻辑上可以通过UI自动化补充实现

测试zzZ 回复

单接口的回归有下面这种情况, 是我真实遇到的:
1, 新功能的迭代可能影响老功能(degrade), 这种时候跑一边单接口可以检验老功能是否降级;

接口测试我个人感觉是既需要单接口测试, 还需要流程测试(上下文依赖的情况), 结合项目实际情况和人员配比(你说你们就你一个人, 那么也许你不能有足够的精力维护过多接口)以及项目实际周期来定夺到底要设计怎么样的接口测试用例, 宗旨我感觉就是尽可能的用现有的资源更大的保证产品质量.

zhang 回复

主要是后端给的接口一般是不会更改吧,所以不太理解,接口的回归测试的意义

第一,针对问题1的接口问题,首先你要确定APP请求的接口response有什么数据,然后你在看web请求的接口response又是什么数据,打个比方,如果APP接口返回的response里有文章的数量节点number,还有文章的排序节点sort,那么你一定要校验web接口返回的文章数量和排序是否一致做对比;其次你还需要对APP接口获取到的内容与web端获取到的内容做对比(一般都是存数据库,内容对比意义不大,翻到是id对比有意义)。
第二,针对问题1的用例设计,首先提示不要用功能用例的设计思维去设计接口用例,你要明白接口测试的核心是什么(最简单是4个点:1.接口的格式是什么,2.接口的数据怎么动态,3.接口的业务怎么关联,4.接口的响应怎么验证),如果你用Excel这种功能用例方式来维护接口用例,灵活性差不说,维护成本非常高(建议你前期直接用接口工具维护测试用例,利用工具输出测试报告作为留本。后期熟悉了技术上来了再用数据驱动的方式管理用例)。
第三,针对问题2,接口测试如果仅仅关注单接口的格式和数据验证,那么接口的灵魂就没有了。所谓接口测试,1.是为了在功能测试之前提前规范和消灭bug,减少功能测试的负担和盲点;2.是作为回归,减少测试人力的同时保证系统每日的稳定运行,同时也在系统出问题是得知问题所在(打个比方,一个系统有很多个接口,如果你的接口脚本每天都在线上定时跑,A接口报错了,但是用户没有返回,说明暂时没人发现,这个时候你们就可以在用户发现前解决问题)。所以,接口的业务关联性是最重要,这点取决于你对系统的熟知程度来设计业务场景,也能体现出你的测试嗅觉。
综上所述,这都是我的一番废话而已,接口这条路好好走下去吧。

Test44 回复

看过其他测试人员的接口测试用例,好像只是对单个接口做数据验证
一般接口文档比较晚上,包括参数的数据类型,是否必填,以及返回数据都有详细描述,他们的用例就是,输入正常或异常的参数,看是否返回预期结果。
按照这样的话,接口自动化用例是不是要分两类,一种是不考虑逻辑,只跑单个接口。一种是考虑逻辑,即修改上个接口,会对其他接口产生影响的用例,感觉最后还是回到了功能测试的逻辑。

现在接口测试用例写的怎么样了

测试zzZ 回复

我打个比方,单接口的数据验证=高中的英语难度,多接口的业务关联验证=考过GRE的英语水平,接口全自动化=你在华尔街工作的英语水平。难度,技术,关注点和认可度,以及对项目的作用,可想而知。
接口是为业务服务的,如果接口最终的闭环回不到业务上,那么这个接口测试就没有了灵魂

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up