问答 最近写接口自动化有一个疑惑。我的用例应该按照功能设计还是按照接口设计呢

tester · 2023年09月08日 · 最后由 姜衍 回复于 2023年09月18日 · 7171 次阅读

例如,我现在有一个功能。
点击查看线路,会调用两个接口,A 接口叫查询站点,B 接口叫查询用户信息。这两个接口没有关联,只是会并列显示而已。
那我的自动化测试用例应该怎么写呢?
我之前的设计方法是这样的。将两个接口拎出来,每个接口创建一个 java 文件,然后对这个接口的参数做各种校验。
但是今天被人说我这样设计不对,应该按照功能设计。

可是如果按照功能设计,那我就要建立一个查询线路.java 文件,里面放两个类,每个类表示一个接口。这样真的好吗

共收到 10 条回复 时间 点赞

a, b 是前置接口,你主要校验的功能是查看线路功能,所以 ab 是前置条件,触发后提起对应需要参数,再调用查看线路设计不同场景的 case,进行校验

高内聚低耦合。分开肯定是好的。用你分开的 java 类再拼个功能类不就可以了。甚至,你抽象一个工厂,通过工厂来组装业务(拼接口的类),测试代码只依赖工厂。。。。再抽几个 java 的 interface 类,主要定义测试行为,业务接口的 java 实现这些个 interface😂

我觉得分单接口测试和流程测试吧,单接口那就按照常规接口的方式设计,流程的那就要按使用流程根据接口的上下文串起来设计流程用例,也就是场景用例吧。

4楼 已删除
5楼 已删除

两种类型的用例都需要 特别是系统本身业务流程复杂的话 流程性的用例对于回归来说更重要

如果有合适的业务场景能把俩接口串联起来,一般串起来的接口都是一个写库或者改库的接口 + 一个查询的接口,你这俩查询的放一起意义不大,不如分开呢,俩查询的接口最好上游接上创建或者更改数据的接口

接口解耦,做单接口自动化,另外会新建业务用例集成,该集合用例用带有多个接口的业务流 case,里面的代码就是引用单接口用例

从工程化角度来说,就应该区分原子操作和组合操作。

在这个业务场景,查询信息和查询站点我理解就是一个原子业务操作,无法再继续下拆,所以它们肯定要分开写。两者代码一定要分开,无论是定义为两个不同方法、或者两个不同类,甚至是两个不同代码文件(具体看整个自动化项目别人怎么写,就顺着大家的风格去搞)。

最后在测试用例层面去组合两个原子操作,分别进行校验。这样一来,原子粒度的操作区分开了很容易找到并维护,业务功能层面的一个用例通过组装可读更高(可能十行以内代码量,一行代码调用封装好的查询信息,一行代码调用封装好的查询站点,然后分别校验);而不是在一个用例里堆砌一堆 “请求业务接口,拿到返回数据,拆分数据校验” 这类和抽象的测试用例不直接相关的底层代码。

测试用例文件里,写为两个用例,使用参数化方式实现

润安 回复

我悟了 👍

基本都是,写单接口,流程测试的话,就把他们调用拼接起来

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册