上周末给一些小伙伴分享了目前工作中的自动化测试设计，在这里总结一下。

本次分享的主要内容是自动化的设计，所以虽然是采用go实现的，但内容并没有涉及go语言。内容如下图所示：

如果你时间有限，只能再看一句话，那么请看这句：以测试场景为核心，向下梳理业务流程，向上抽象测试流程。

好了，有兴趣和时间的同学可以继续往下。

第一部分是基本想法，主要是测试需求和设计

首先，从工作中的测试需求看。主要三个：一个是在集成阶段，需要确保各接口的联通性、基本业务的正确性；一个是在上线前的预发布阶段，需要进行大量的回归；最后一个是，每周例行的并发和性能的检查。主要对应的测试规模，用例数量在1K级别，属于中小规模的测试。如下图所示：

从抽象分层的角度看，分为：接口、业务流程、测试场景三层。从形式上说，底层接口构建业务流程业务流程构建测试流程，测试流程配合开关形成测试场景。用例文件，包含运行配置、测试流程编码、开关、测试数据。从思路的实质上说，以测试场景为核心，向下梳理业务流程，向上抽象测试流程。如下图所示：

代码组织与抽象的层次基本也是相对应的：

而测试数据的划分，简要说考虑三个维度：测试环境、阶段、业务。

第二部分，介绍了一个重打款并发的实例

首先从测试场景出发，重打款有以下4种重要的场景：

1 对一笔订单重试的手动并发：

2 对多笔订单重试的手动并发：

3 对多笔订单的定时并发：

4 对多笔订单，定时和手动并发：

从这4种场景出发，向下梳理涉及到的业务有：账户信用不足，打款暂停处理；信用充足时，手动重试或定时重试；扣款，需要验证金额，订单状态。这些业务与接口的对应如下：

从这4种场景出发，向上抽象出一个测试流程来覆盖这4种场景，并从测试流程中提取需要的数据，形成case，如下图所示：

case包含的内容：

1 运行配置：打款总笔数、打款并发数、手动打款并发数、定时并发数；

2 开关：定时开关、手动重试开关；

3 数据：信用不足额度、信用充足额度、商户号、打款卡信息。

没理解？没关系，请记住这句话：”以测试场景为核心，向下梳理业务流程，向上抽象测试流程“。

---

有不足之处，欢迎指正，共同学习。

多谢