我的书签
添加书签
移除书签自动化测试快速上手
介绍
欢迎使用 Erda 自动化测试！在这里你可以领会如何自动化测试你的项目。
在使用之前你需要提前掌握必要的知识：
- 自动化测试理念，Google 的经验
- HTTP 基本知识
你将学到
- 从工程角度如何管理自动化测试用例
- 自动化测试用例编写规范
- 接口测试快速入门：发送你的第一个请求
- 以及 接口测试的方方面面
从工程角度如何管理自动化测试用例
项目进入正轨后，往往伴随着成百的业务流程，以及成千的 API，而一个接口又有可能有多种参数场景。自动化测试工程师在编写测试流程以及流程中的单元接口时，尤其时多人协作编写时，需要有合理的规划和管理才能让自动化持续。
Erda 提供了【测试空间】>【场景集合】>【场景】三级管理能力。
自动化测试用例编写规范
::: tip 建设中，尽情期待 :::
功能指路
发送你的第一个请求
平台页面入口：
DevOps 平台 -> 我的项目 -> 项目详情 -> 测试管理 -> 测试用例 -> 自动化测试
若没有测试空间，则创建一个，进入空间后先创建 场景集合（或者说流程） 再创建 场景
点击场景步骤的 “+ 接口”，填写接口请求参数
点击“保存”即完成了场景中一个步骤，也可以点击“保存并执行”进行单接口的调试
测试空间
一个项目下可以创建多个测试空间，测试空间之间无任何关联，不互相影响，是完全隔离的空间。 很多项目只需要一个默认测试空间即可，使用多个测试空间有以下几种情况：
- 一个项目下有多个子项目，子项目间没有产品上的联动，它们的自动化用例可以完全独立在自己空间
- 一个项目要同时支持多个版本，那可以一个版本一个空间，当进入新版本迭代时，可以通过复制老版本的空间以创建新版本的空间，并在新版本空间上进行功能变动后的调整
注意：空间复制需要较长时间，复制过程中时，原空间无法操作
场景集合
场景集合 是一个完整闭环的自动化测试流程，这个完整的流程由多个场景组成，场景之间有简单的依赖（包括执行依赖和数据依赖） 场景集合或者说自动化测试流程有以下几个例子：
- 登录流程
- 购物流程
- 退货流程
而一般来说流程中可能有正向的场景（比如登录成功、下单成功等）也有逆向或者预期失败的场景（比如密码错误次数过多登录失败、退货成功后不能退货），这些场景可以自由的在流程中添加和编排，你可以详细阅读 场景 以了解。
场景
场景 是自动化测试管理的最小单元，可以对应到功能测试的一个用例。如字面意思，是自动化测试的一个场景，以下将按几种场景集合分别举例：
- 登录流程：
- 正常登录场景
- 异常登录场景
- 密码错误次数过多场景
- 登录成功后校验登录态场景
- 等
- 购物流程：
- 商品查看场景（能够正确查询/或者下架商品无法查询）
- 下单场景（无货时购买失败、优惠计算正确、库存扣减成功等逻辑）
- 等
- 退货流程：
- 订单关闭退货失败的场景
- 退货成功场景（成功后，后续状态流转正确、通知正确等逻辑）
- 等
场景的设计理念是短小、尽量内聚，在同一个场景集合下场景们有一定的关联，一定的执行依赖，一定的数据依赖。
场景中的步骤
场景步骤可选有 “接口”、“配置单”、“等待”。步骤为接口可以测试接口是否按照预期执行和返回，步骤为配置单可以执行 SQL 等数据准备逻辑，步骤为等待可以为这个测试场景插入思考时间。
步骤默认为串行执行，即按自上而下的顺序执行；点击步骤左侧上下箭头即可进行上下拖拽调整顺序。
点击右侧“+”，步骤也可以进行按组并行，默认添加到组内的最后。
此时拖动（1）则是拖动组间的串行顺序，拖动（2）则可以拖动步骤到其他的组或者拖出后单独成组。
场景中的步骤 - 接口
点击场景步骤的 “+ 接口”，填写接口请求参数
这些操作让你可以更好的测试接口：
- 通过 选择接口集市的规范接口 填充接口定义，以减少接口参数的配置工作
- 利用 接口小试一把 快速试错接口的配置
- 设置断言以进行有效测试
- 在 同场景下 Cookie 保持 ，维持场景的用户登录状态
- 步骤间数据传递 实现“上个接口”的结果作为“当前接口”的参数
- 获取前置场景的结果 以实现流程（场景集合）的编排
场景中的步骤 - 配置单
配置单是可以被多个场景/多个场景集合（或者说流程）使用的，可复用的数据初始化/数据清理的公共逻辑。 所以配置单的配置在独立的入口：数据银行。
选择已经创建好的配置单，按照配置单定义的入参配置即可。
场景中的步骤 - 等待
设置等待时间以实现场景执行的暂停和恢复。
设置断言以进行有效测试
::: tip 若测试没有断言，那所有用例都将通过，没有阻塞。 :::
在接口配置页切换到 “Tests” 以设置出参以及断言。
API 执行结果返回的 Response，出参是从当前请求的 Response 中截取需要的内容，该参数可以在该用例后面的API请求中作为参数使用，在一个 API 中可以定义多个出参。 参数解析支持状态响应码，Header:K/V，Body:JSON(body) 三种形式。
出参说明：
- 出参名：只能包含英文字母、数字和下划线。
- 来源：
+ Body：JSON ：以 JSON 格式解析 Response Body+ Header：K/V ：以键值对格式解析 Response Header+ 响应状态码 ：提取 Response 中的状态码
- 解析表达式：从 Response 截取需要的内容，对应到当前变量。例如：data.items[0].id
断言说明： 断言用于从业务维度判断请求是否成功。 将某个出参的临界值定义为业务异常判断标准，类似检查点，格式为: Key + Value + Description， 检查点可分为响应状态码、响应 Header、响应 Body 3 种类型。 多个断言之间是”且”关系。支持形式如下：
- 大于、大于等于、小于、小于等于: 支持整数，小数。
- 等于、不等于: 支持整数，小数，字符串，对象(数组，Map)。
- 包含、不包含: 支持字符串和正则匹配。
- 为空、不为空: 支持判断数组，Map，字符串是否为空。
- 存在、不存在: 判断出参是否存在。出参为 Response 的 Key。
- 属于、不属于: 支持正负整数、0、字符串。
- 数值：请按照标准的数学表达式规范填写。示例如下： 区间支持开区间和闭区间、示例闭区间：[-20,20] 表示集合：{[-200,200],-1,2}
- 字符串仅支持集合、示例：{“abc”,”bcd”,”200”,”-200”,”已报名”,”报名成功”}
选择接口集市的规范接口
自动化测试工程师最苦恼的是和开发工程师沟通接口的定义，如果接口数量庞大并且频繁修改，所有的时间都将消耗在无止尽的沟通和调整测试用例。
在接口配置界面便可以直接选择集市中已上传的规范接口，如果和你对接的开发工程师是 “API-first” 理念的践行者，那一切都变得很容易。
接口小试一把
编写完成的接口测试可以被立即执行，方便自动化测试工程师调试接口测试的配置，比如网络是否联通、是否有拼写错误等小毛病。
同场景下 Cookie 保持
::: tip 暂未实现，尽情期待 :::
步骤间数据传递
前置接口必须要先定义出参，才能被后继接口使用，如下图：
后继接口在填写参数值时，便可以通过“选择器”选择：【前置接口出参】>【选择接口】>【前置接口定义的出参】。
也可以直接输入运算表达式：
${{ outputs.1845.userId }}
其中 1845 是接口 ID，这个 ID 可以在步骤上看到。
::: tip “选择器” 以及表达式的使用可以查看：表达式规范 :::
获取前置场景的结果
::: tip 建设中，尽情期待 :::
全局配置
::: tip 建设中，尽情期待 :::
数据银行
平台入口：
DevOps 平台 -> 我的项目 -> 项目详情 -> 测试管理 -> 数据银行
::: tip 建设中，尽情期待 :::
表达式规范
::: tip 建设中，尽情期待 :::
