收钱吧的 Python 高效自动化测试实践

1. 背景

收钱吧业务服务千万级商家，业务庞大，产品背后有复杂的应用支撑。我们采用了微服务架构，有成百上千个不同类型的后端服务，使用了包括Node.js、Java、Go、Python等后端语言，还有Mysql、MongoDB等数据库以及Elasticsearch、Kafka、Redis、Apollo、RabbitMQ等中间件。

随着产品需求复杂性的不断上升，传统功能测试的片面性及滞后性导致测试成本急剧增加、测试效率大幅度下降，仅靠功能测试已难以持续保障项目质量及交付效率。

而自动化测试可以帮忙测试人员在项目初期就能发现系统深层次的问题，并且降低了问题修复的时间成本，其好处显而易见。自动化测试也在各大互联网公司逐步地落地，这是大势所趋，收钱吧质量工程部在这几年里一直在践行高效的自动化测试，并且有了一些成果。

2. 测试策略

自动化测试是一个泛称，它包含了诸如单元测试、接口测试、Web 测试等具体测试手段，每个自动化测试手段有其优劣势，找到适合收钱吧技术状况的自动化策略是能够实践成功的第一步。

在微服务架构下，相比测试金字塔[1]，我们更加推崇蜂窝型分层[2]。

 这是因为：

1. 对于微服务模型的项目来说，服务即『单元』，接口表达了『单元』的能力，并实现了单元之间的通讯，编排接口的调用则完成了业务、产品逻辑；

2. 单元测试代码量大、开发工程师无法投入较多的精力进行维护，且不能够通过单元测试来实现服务之间的集成测试、覆盖业务场景，实际收益其实并不明显；

3. 在项目初期有接口定义的情况下，测试工程师可以较早地介入项目当中设计、开发接口测试用例，无需等开发工作全部完成，实现测试左移，可以更早地发现系统问题，提高了整体的效率。

接口自动化测试兼顾了介入早、维护成本低、业务逻辑覆盖完整等优点，因此它成了我们自动化测试重点投入的方向。

2.1 细化微服务下的测试策略

除了明确接口测试是重点以外，我们还要基于微服务架构的分层特点，进一步细化自动化测试策略。

我们简明扼要的描述下当前的系统架构，如图：

• 接入层：面向客户端，客户端通过调用接入层的接口来请求应用层的服务，得到响应后，包装数据返回，给客户端使用。比如API网关，它的主要职责包含请求认证鉴权、安全校验、返回值的包装、请求的转发，其本身并没有业务逻辑；

• 应用层：服务面向业务，它通过对一个或者多个领域层服务的调用、编排来实现业务功能。例如我们系统中的业务开通服务，它依赖用户中心、商户中心、进件、银行卡等领域层的服务来实现其功能；

• 领域层：面向领域对象，领域对象是具有高内聚、低耦合的特点，且具有单一的职责。例如我们系统中的支付服务、银行卡服务、分账服务等，它们只实现本身的业务规则和逻辑，可能会依赖一些三方服务、内部服务；

• 基础设施层：如关系型数据库、缓存服务、消息队列等。

成百上千个后端服务有不同的分层界定，我们可以从接入方调用的视角简化成下图