# 自动化测试

    # 测试用例设计原则

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

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

    # 搭建自动化测试工程

    # 创建测试空间

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

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

    # 创建场景集

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

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

    # 创建单场景

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

    • 主语+动词+名词,例如:企业添加成员
    • 动词+名词,例如:新建应用
    • 名词+动词,例如:构建记录查询

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

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

    # 数据准备和数据清理

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

    对于测试数据的管理,建议如下:

    • 用于自动化的测试数据需和手工测试数据保持独立。
    • 模块间若使用相同的测试数据,尽可能使用两份数据。
    • 测试环境、预发环境、线上环境的测试数据需相互隔离。
    • 只读测试数据应和状态有改变的测试数据分离。
    • 线上环境测试数据需避免干扰正常用户行为,测试数据使用后需恢复至原始状态,避免在环境中遗留垃圾数据。

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

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

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

    # 接口请求

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

    # 接口校验

    接口校验目前支持状态码、响应头以及 Response Body 校验。下列为常用的接口校验项:

    • 返回状态码校验。
    • 新增类接口建议校验新生成的数据标识不为空。
    • 更新或删除类接口建议校验返回消息中 success 为 true。
    • 列表查询类接口建议校验返回的查询记录数是否正确。
    • 数据详情类接口建议校验核心字段数据准确性。

    # 配置环境

    完成自动化测试工程搭建后,全局参数需通过新增环境配置维护,以支撑接口自动化用例调试和测试计划执行。一般情况下可根据不同环境或业务域划分创建全局环境变量。

    # 环境域名

    不同的环境可通过域名进行区分。参数配置中可对环境域名进行配置,支持 HTTP/HTTPS 协议。

    不同的环境支持不同的 Header 配置。例如在 Header 中设置 Cookie 信息,则整个测试计划的执行中都将使用该 Cookie 信息进行操作,无需重复为每个接口设置 Cookie。

    # Global

    为在不同环境中执行同一份场景测试用例,您需将请求参数变量化,抽取部分公共的、受环境影响的参数作为 Global 变量使用,例如数据库信息、平台账号密码等。

    变量名称建议采用驼峰命名法,例如 orgId、clusterName。常量则以全部大写、下划线分割的形式命名,例如 MYSQL_HOST、MYSQL_PORT。

    # 调试

    完成环境配置后,您可对已添加的接口和场景进行调试。

    # 单接口调试

    完成接口步骤添加后,点击 保存并执行 选择环境开始调试。执行结束后即可查看接口返回值及断言是否正确。

    # 场景调试

    场景调试需重点关注上下文接口及对应出入参的调试。

    完成单接口调试后,点击场景中的 执行 选择环境开始调试。执行结束后可通过执行明细查看执行结果。

    • 场景入参:场景中支持添加场景入参,其值分为引用值和调试值。单场景调试使用调试值,测试计划执行则使用引用值。
    • 前置接口出参:场景中的后续步骤可引用之前步骤的出参作为入参以串联接口间的业务场景。

    # 执行测试

    完成场景调试后,可在执行计划中编排测试场景集用于整体执行测试,也可接入持续集成进行持续测试。

    # 执行测试计划

    测试过程中可根据项目的版本或业务域、模块划分测试计划。冒烟测试、回归测试或集成测试以测试计划为单位执行。

    测试计划中可加入多个场景集以及场景集的编排。

    # CI/CD

    自动化测试最大的价值之一是在持续集成中进行持续测试。实际项目实施中,应用通过流水线构建部署后,可通过在流水线中添加 自动化测试计划执行 的 Action,将自动化测试加入 CI/CD 流程中。应用构建部署完成后即可进行自动化测试,以便快速发现迭代缺陷。

    # 查看测试报告

    手动及 CI/CD 触发的测试计划执行,均可通过执行明细查看详细信息。