前面和大家探讨了编写测试用例的方法,设计框架的思路:导出用例,执行用例,收集用例结果。
这篇文章和大家聊一聊用例结构设(建议自己动手写过一个接口自动化之后再一起来探讨),否则不明白一些做法的初衷
- 1.用例结构设计初衷
- 1.1常见用例结构
- 1.2 使用中的问题
- 1.2.1. 重复字段太多
- 1.2.2 请求参数过多
- 1.2.3 整个用例庞大
- 2.用例结构设计
- 2.1 重复字段太多
- 2.2 请求入参,参数过多?
- 2.3 用例数量庞大?
- 2.4 断言设计
- 2.5 用例附属信息
1.用例结构设计初衷
陈述几个问题,大家可能觉得Excle存储用例比较low,没有yaml,sql存储的高大上之类的
-
- 如果说一个模块,十个接口的用例超过了100条,200条,300条,那么操作体验来看,哪一种存储形式比较容易接受?
- Excle的推广程度,学习成本,上手速度,相较于其他的有优势
- 后期扩展,无论是PyQt做成桌面应用,还是做成WEB平台,操作形式上的相似度是比较高
1.1常见用例结构
关于编写接口用例的方法已经陈述过了,如果还有不清楚的,请转:接口自动化之测试用例设计(一) 。然后,大家就可以愉快的编写测试用例的,但是就有了另外一个问题,接口用例应该是什么样子的?这里取了一个培训机构常见的接口用例模板
上面的模板看起来怎么样?不知道大家日常使用的模板是不是和上面的差不多?
1.2 使用中的问题
我刚接触上面的模板的时候没感觉到有什么问题,接口信息,请求方法,请求数据,入参等字段,的确是接口测试必要的信息。
- 但是在实际的使用过程中,遇到了各种操作不便的问题
1.2.1. 重复字段太多
其实在一个项目中项目地址,同一个接口的API信息等。
1.2.2 请求参数过多
像图示中的两个参数,看起来没什么问题,但是如果是一个大型的表单提交接口呢?参数可能高达50多个左右,都放在一个单元格内,怕不是一屏都不够哦
1.2.3 整个用例庞大
接口的用例相较于功能用例还要多出一部分,如果都在一个标签页里,500条用例,编写,查找起来相当不便
前段时间拜访了用户,咨询一下新系统(ERP类型)使用情况。系统功能完善,UI清爽,很符合用户的预期。但是有一点,录入信息的时候干扰项太多,用户操作起来十分不顺手。总的来说,系统是给用户使用的,怎么方便,怎么来。
自动化用例是给我们自己设计的,怎么操作简单怎么来,从上面的Excle用例来看,是不符合我们日常使用的。
2.用例结构设计
根据上面操作不便的问题,分别进行处理并附以用例更多的功能。
2.1 重复字段太多
重复字段太多,项目地址,同一个接口的API信息等。
- 这里指的重复字段指的是接口信息。通常情况下,一个项目的接口信息来源于接口文档,并且同一个接口的用例接口信息一致。
那么,怎么来解决这个问题?我们另行维护一份自己需要的接口信息文档,然后需要用到的时候进行读取即可。
也就是把上面圈起来的内容,拆分出去,另行维护
拆分后的用例如下所示,界面看起来是不是清爽许多?
2.2 请求入参,参数过多?
例如上图中参数过多的情况,一个单元格内看起来是不是十分臃肿?如果某个添加接口有50个参数,那展开的话,一屏都看不完整。(可能有的人会说,超出单元格隐藏,可以试一试隐藏后的效果哈)
想解决这个问题,其实也很简单,通常情况下,测试用例是保持单一验证的情况。
也就是说,就算有50个参数,那么其他一条测试用例中只会有测试点的参数,其他参数通常保持不变的。
这样子的话,就可以用模板数据,然后在用例中编写变量就好
2.3 用例数量庞大?
模块区分,如果都在一个标签页里,500条用例,编写,查找起来相当不便。解决办法:根据模块来聚合用例,然后查找方便
(举例:
一个模块,20个api,400条case,那么也就像上面的400多行)
2.4 断言设计
想要在Excle去做断言,其实有点难处理,根据响应文本去直接比对?但是有时候需要比对code,message,data等参数,这里借鉴了JMeter的响应结果树,根据规则去匹配:
{
"code":"",
"message":"",
"data":{
"key":"value"
}
}
2.5 用例附属信息
测试用例的测试版本,用例执行人员,项目配置信息(服务地址,数据库地址等),用例执行时间,备注等
那么现在的由一份Excle接口用例,进行自己的加工之后,用例结构如下:
demo示例如下,API配置文件第一阶段以手动维护为主,根据实际项目进行扩展(自动生成)
用例配置,针对于项目情况,用例运行的说明
实际编写的测试用例,界面是不是很清爽?