自动化测试

测试用例设计原则

优秀的接口自动化用例应遵守 AIR 原则，即 Automatic（自动化）、Independent（独立性）和 Repeatable（可重复）。

自动化：全自动执行的而非交互式的。测试用例通常用于定期执行，执行过程需实现完全自动化。
独立性：为保证自动化测试稳定可靠且便于维护，场景用例之间应尽量避免互相调用，且不依赖于执行的先后次序。
可重复执行：可在不同的环境下重复执行，不受外界环境的影响。由于测试用例常用于持续集成中，对外部环境（网络、服务、中间件等）强依赖容易导致持续集成机制的不可用。为保证测试用例可重复执行，自动化测试数据必须实现独立，因此需注意以下两点：
- 设置全局参数配置，接口请求的 URL 使用相对路径，参数涉及环境相关的使用全局变量。
- 新增场景有名称唯一性校验，请求入参的名称应尽量使用 Mock 随机数，或在新增用例执行前先进行唯一性的数据清理。

一个项目下可创建多个测试空间，测试空间之间无任何关联，相互隔离。

测试空间名称建议以项目名称+版本号的方式命名，可通过复制旧版本的测试空间快速创建新版本的测试空间，以复制原有的测试用例。

场景集一般以业务场景为导向，并按照具体模块进行划分。不同的场景集之间可通过拖拽的方式进行编排。

若场景集下的场景均依赖于公共数据，则建议将数据预置的场景作为场景集的第一个场景，将数据清理的场景置于最后，从而降低各场景重复执行数据预置带来的时间成本。

场景名称的定义需简洁、易懂，便于他人了解场景信息，降低学习成本。以下格式可供参考：

不同场景之间可通过拖拽的方式进行编排，以更改场景的执行顺序。

不同步骤之间也可通过拖拽的方式进行编排，以更改步骤的执行顺序及执行方式（并行或串行）。

环境和测试数据是影响自动化稳定性的两大因素。测试数据的管理将直接影响用例的维护成本。

对于测试数据的管理，建议如下：

常用的数据管理有以下两种方式：

执行 SQL 脚本初始化或清理数据
- 优势：执行速度快，成功率高。
- 劣势：SQL 脚本易遗漏个别关联表，因此要求对预置数据的表结构非常熟悉，且由于是数据库手动侵入行为，后续可能出现数据冲突问题。
调用新增接口初始化或清理数据
- 优势：对系统无侵入行为，不影响后续系统运行。
- 劣势：执行速度慢。

Erda 通过数据银行中配置单的方式实现数据准备和数据清理。配置单中可添加 MySQL 或 Redis 脚本，示例如下：

接口入参中的请求参数不建议设为固定值，尤其是依赖外部数据的参数。尽量使用全局变量以保证在不同测试环境下可重复执行。例如新增项目接口时，入参需企业 ID、集群名称等数据，建议对这些参数使用全局参数管理。
请求入参中的名称或者编码不建议设为固定值，尤其是有名称重复性校验的业务。为保障用例可重复执行，参数名称后建议添加 Random 参数。
每个测试场景均为一个完整的流程，包括数据准备、测试执行、数据清理等步骤，以实现场景内部闭环，保障测试场景执行后无数据残留。