概述
在创业公司里,项目都比较赶,测试人员也是疲于测试功能模块,基本没空去写什么自动化测试,以提升回归测试的效率。但一个必须承认的事实便是,依赖测试人员去做全面回归测试,保证上线质量,是不可取的,因为难度太大,成本太高。因此自动化测试还是要做一些的,具体如何着手呢,下文说一下我这边的做法。
注意:本文主要描述一下业务接口自动化测试的方案,至于GUI自动化测试和压力自动化测试不在本文的讨论范围内。
什么是自动化测试
定义:把人对软件的部分测试动作转化为由机器来执行。
自动化测试只能部分替代人工,不要指望所有业务场景都通过自动化case
来验证。
做自动化测试的动机
最大的动机:提升回归测试的效率。
为了让垂直拆分出去的微服务能独立发展,不耦合太多不相关的业务逻辑,一般会有一些聚合的微服务应用,用于调用多个后端微服务,汇总数据后提供给前端。在创业公司里,建议先做聚合服务的自动化自测,原因是:
聚合层是提供给小程序/APP/H5 等用的,聚合汇总了各种后端服务,针对其做自动化测试,可以用相对低的成本,尽量多的覆盖业务case。至于针对后端的各个微服务接口做自动化的,实施起来代价比较大,有大量的代码成本和维护成本,可以后续再考虑。
聚合服务也有很多业务接口,不可能都去写对应的自动化测试代码,建议先做主流程接口的自动化测试。比如一个电商的聚合层应用,像商详、购物车、首页、订单结算页、下单,可以先做。重要业务接口的自动化测试case
,尽量做到多而全,争取全面覆盖。
数据创建的时机和手段
接口自动化测试中,第一个要解决的问题,就是测试数据的准备。
数据创建的时机
时机 | 描述 | 优点 | 缺点 |
---|---|---|---|
即时创建 | 执行测试用例的时候,立刻创建测试数据,用例执行完后,删除掉 | 不会有脏数据 | 1、会导致测试用例执行时间延长了; 2、环境不稳定的时候,无法创建数据; |
开箱即用 | 先提前创建好测试数据,执行测试用例的时候,直接使用,并将测试数据标记为不可用(这个实施起来难度高)。 | 测试用例执行速度快 | 有脏数据,因为提前创建好的数据,可能会被使用掉。 |
建议使用即时创建的方案是,原因如下:
- 自动化
case
之间保证独立性和相互不影响,实在太重要了,而即时创建数据就是保证这个的重要前提,且实施起来不难,虽然开箱即用 也能做到,但是代价太大,需要有专门的测试数据构建平台,成本有些大; - 环境稳定性问题,可以通过时间戳开的方式,例如:晚上跑自动化测试。
- 如果后续自动化
case
多了,即时创建的方式,会导致case执行时间长,可以通过并行执行的方式。对刚搞自动化测试的,需要执行的case的量也不大啦。
数据创建的手段
一般有三种:
- 调用后端服务
api
创建数据; - 手写
sql
创建数据; - 组合1和2;
大部分情况下,使用第一种方式就行了,因为造数据的后端接口,大部分都是有的。对于少部分没有的,则手写sql创建数据。
接口入参格式和返回值断言
接口入参格式
测试团队熟悉哪种就用哪种,excel
或者json
或者完全用代码。
接口返回值断言
同上,测试团队熟悉哪种就用哪种,以excel
为例,期望的返回值也可以一并写在excel
里,自动化case
调用接口获取到业务数据后,与excel
中的期望值进行断言操作即可。
编写自动化case的语言
测试团队熟悉哪个语言就用哪个,如果是Python
那就最好了。
执行环境
- 将自动化测试代码,部署到一个独立的自动化测试机器上,使用
jenkin job
执行自动化测试代码; - 被测试的目标应用,建议重新搭建一套。
test dashboard
case
跑完后,需要生成测试覆盖率报告和列出执行成功和失败的case
。