配置 case
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
自定义的 case 名称，建议：见名知意。
case 名称全局唯一。
在 method 管理界面注册过的method。
如果是通过 proto file 或者 GraphQuery 注册的method，会自动渲染初始结构。字段值默认为该类型的空值，或者指定的默认值：
自定义标签，可用于标识：所属模块，使用范围等。
在 case 列表界面，可以根据标签进行搜索。
在做统计分析时，可以按照标签作为维度分析。
比如：接口 CreateUser 于2020年初上线 V1.0 版本后就一直没有变化，同时接口 UpdateUser 也于 2020年初上线 V1.0 版本，但分别于 2020 年末和上个月上线了 V1.1 和 V1.2 版本。
那么在配置 case 时，只需要对 UpdateUser 接口增加 V1.2 版本的配置。CreateUser 接口无需任何变动。
此时，如果 plan 选择 V1.2 版本运行，则会运行 V1.2 版本的 UpdateUser 和 V1.1 版本的 CreateUser；
如果 plan 选择 V1.1版本运行（比如私有部署，比如回滚回归），则会运行 V1.1 版本的 UpdateUser 和 V1.1 版本的 CreateUser。
即：plan 会运行不高于自己版本的最高版本 case 。
在许多 http（get、post） 请求中，参数是拼接在url 中的。此时，url 需要可以被参数渲染，例如，Commander (来也科技业务线之一，详见：UIBot)，在 siber 上的测试案例：“获得流程下所有数据指标统计” 中对于 url 参数的配置:
?flowid={{VARIABLE.flow_id}}show
url 参数支持 parameter 渲染（ FUNCTION 和 VARIABLE 的解析）。
支持 http（包括 GraphQL）、gRPC 两种协议的 request header。
request header 支持 parameter 渲染（ FUCTION、VARIABLE 和 SiberAuth 的解析）。
使用 SiberAuth 可以支持对接口进行鉴权。当前已内置通用鉴权算法，可以自己在 siber 上添加自定义的鉴权算法。
通常而言，一个测试场景，我们倾向于使用一个用户从头测到尾（不妨碍你下次执行的时候换个不同权限的用户）。对于一个产品线，我们可以配置一个或多个用户进行测试。
自定义鉴权算法的结构
三段式的 Key：（以#分隔）
Siber#siber_open_source#siberOpenSource
Siber : 用于标识产品线
siber_open_source：环境名，在环境管理中配置
siberOpenSource：应用配置名称，在环境管理中配置
标识算法的 Value：
SiberAuth 为内置鉴权算法（详见源码），如果有其他鉴权算法，诸如公司内部的自定义的算法，可以自由在源码上添加。
我们也鼓励大家向 Siber 提交代码。
SiberAuth 的渲染示例：
图片左边为请模板，及用户配置的内容。
右边为渲染后的内容，即实际发送的请求内容。
pubkey 在环境中的配置：
当前 siber 支持对图片做 base64 编码，图片将会上传至 oss 或者 minio 上（取决您配置的是什么）。
上传成功后，前端会返回图片所在路径，然后使用 siber 的 FUNCTION进行说明，下面是一个 request body 的示例：
request body。支持 parameter 渲染（ FUCTION、VARIABLE 和 SiberAuth ）。
如果是通过 proto file 或者 GraphQuery（来也科技内部服务），配置的 method，在配置 case 基础信息的时候会自动渲染初始化 request body。字段值默认为该类型的空值，或者指定的默认值。
用户在此基础上修改即可。
request body 支持 parameter 渲染（ FUCTION、VARIABLE 的解析）。
将指定内容保存到变量中，在同一 flow 的后续 case 中，使用 {{VARIABLE.***}} 的格式进行访问。
variable 的值可以来自：
request header、request body 全部或部分内容
response header 、response body 全部或部分内容
response status ，即接口响应码值
response time，即接口响应时间
注意：
同一个 flow 中，variable 名称唯一，如果同一个 variable 被保存两次，则后面的覆盖掉前面的。
variable 在 flow 内共享，不在 flow 之间共享。
检查指定内容是否符合预期，检查内容包括：
request header、request body 全部或部分内容
response header 、response body 全部或部分内容
response status ，即接口响应码值
response time，即接口响应时间
检查方式包括：
= 等于，支持数字、字符串、数组、嵌套数组、map 等
!= 不等于，支持数字、字符串、数组、嵌套数组、map 等
> 大于，支持数组、字符串
>= 大于等于，支持数组、字符串
< 小于，支持数组、字符串
<= 小于等于，支持数组、字符串
exist 存在，判断检查的内容中是否存在指定的 key
length 长度：支持字符串长度、数组类型
in 检查的内容是否被包含在指定内容中，支持字符串、数组类型
include 检查的内容是否包含指定内容，支持字符串、数组类型
not include 检查的内容不包含指定内容为符合预期，支持字符串、数组类型
执行完此 case 后，休眠多长时间进行后续操作。
使用以下命令获得相关内容：
在 case 列表页，点击“复制”，进行 case 复制。除名称、创建时间、最后修改时间不一样外，所有信息与源 case 保持一致。
复制出的 case 名称为：源 case 名称 + 时间戳。
inject 类型case，主要的目的在于注入变量。
比如说：我们不同环境使用不同的测试用户，那么配置 inject 类型 case 如下：
在后续的 case 中，直接调用 variable 即可：
在不同环境运行时， inject case 会根据运行环境自动为该 case 注入不同的 account id。
siber 内部使用 来摘取指定内容，感兴趣的同学，可以点击链接查看详细信息。这里做些简单的示例，假设存在 json 如下：
