简单说一下业务接口自动化测试

概述

---

在创业公司里，项目都比较赶，测试人员也是疲于测试功能模块，基本没空去写什么自动化测试，以提升回归测试的效率。但一个必须承认的事实便是，依赖测试人员去做全面回归测试，保证上线质量，是不可取的，因为难度太大，成本太高。因此自动化测试还是要做一些的，具体如何着手呢，下文说一下我这边的做法。

注意:本文主要描述一下业务接口自动化测试的方案，至于GUI自动化测试和压力自动化测试不在本文的讨论范围内。

---

什么是自动化测试

---

定义：把人对软件的部分测试动作转化为由机器来执行。

自动化测试只能部分替代人工，不要指望所有业务场景都通过自动化case来验证。

---

做自动化测试的动机

---

最大的动机：提升回归测试的效率。

为了让垂直拆分出去的微服务能独立发展，不耦合太多不相关的业务逻辑，一般会有一些聚合的微服务应用，用于调用多个后端微服务，汇总数据后提供给前端。在创业公司里，建议先做聚合服务的自动化自测，原因是：

聚合层是提供给小程序/APP/H5 等用的，聚合汇总了各种后端服务，针对其做自动化测试，可以用相对低的成本，尽量多的覆盖业务case。至于针对后端的各个微服务接口做自动化的，实施起来代价比较大，有大量的代码成本和维护成本，可以后续再考虑。

聚合服务也有很多业务接口，不可能都去写对应的自动化测试代码，建议先做主流程接口的自动化测试。比如一个电商的聚合层应用，像商详、购物车、首页、订单结算页、下单，可以先做。重要业务接口的自动化测试case，尽量做到多而全，争取全面覆盖。

---

数据创建的时机和手段

---

接口自动化测试中，第一个要解决的问题，就是测试数据的准备。

数据创建的时机

时机	描述	优点	缺点
即时创建	执行测试用例的时候，立刻创建测试数据，用例执行完后，删除掉	不会有脏数据	1、会导致测试用例执行时间延长了; 2、环境不稳定的时候，无法创建数据;
开箱即用	先提前创建好测试数据，执行测试用例的时候，直接使用，并将测试数据标记为不可用（这个实施起来难度高）。	测试用例执行速度快	有脏数据，因为提前创建好的数据，可能会被使用掉。

建议使用即时创建的方案是，原因如下：

1. 自动化case之间保证独立性和相互不影响，实在太重要了，而即时创建数据就是保证这个的重要前提，且实施起来不难，虽然开箱即用 也能做到，但是代价太大，需要有专门的测试数据构建平台，成本有些大；
2. 环境稳定性问题，可以通过时间戳开的方式，例如：晚上跑自动化测试。
3. 如果后续自动化case多了，即时创建的方式，会导致case执行时间长，可以通过并行执行的方式。对刚搞自动化测试的，需要执行的case的量也不大啦。

数据创建的手段

一般有三种：

1. 调用后端服务api创建数据；
2. 手写sql创建数据；
3. 组合1和2；

大部分情况下，使用第一种方式就行了，因为造数据的后端接口，大部分都是有的。对于少部分没有的，则手写sql创建数据。

---

接口入参格式和返回值断言

---

接口入参格式

测试团队熟悉哪种就用哪种，excel或者json或者完全用代码。

接口返回值断言

同上，测试团队熟悉哪种就用哪种，以excel为例，期望的返回值也可以一并写在excel里，自动化case调用接口获取到业务数据后，与excel中的期望值进行断言操作即可。

---

编写自动化case的语言

---

测试团队熟悉哪个语言就用哪个，如果是Python那就最好了。

---

执行环境

---

1. 将自动化测试代码，部署到一个独立的自动化测试机器上，使用jenkin job执行自动化测试代码；
2. 被测试的目标应用，建议重新搭建一套。

---

test dashboard

---

case跑完后，需要生成测试覆盖率报告和列出执行成功和失败的case。