环境
env、environment
|诸如：开发、测试、灰度、生产。
可以针对不同产品线的不同环境配置不同的地址。
| |接口
method、interface
|在来也科技内部，通常同一个接口有 http 和 gRPC 两种调用方式。
对内使用 gRPC 协议。
对外使用需鉴权的 http 协议。
| |测试案例
case
|一个接口可以存在多个测试案例。
通过配置检查项检查接口执行结果是否符合预期。
| |测试场景
flow
|由一系列 case 组成，执行时按顺序依次执行。
出错后，可以选择“继续执行”或者“终止执行”。
| |测试计划
plan
|有一个或多个 flow 组成，flow 间并发执行。
除手动执行外，还可以配置“定时执行”和“CI触发”。
| |检查项
checker
| 支持对状态码、响应时间、请求头、请求体、响应头、响应体的全部或部分校验 | |注入项
injector
|将 case 中的输入、输出等内容，全部或部分的保存在变量中。
供后续 case 使用。
| |睡眠时间
sleeper
| 执行完当前 case 后，sleep 多久进行后续处理。 | |参数
parameter
| case 中的渲染项，包括： function、variable、SiberAuth | |预定义函数
FUNCTION。
| 随机字符串、数字、时间函数等。 | |变量
variable
|将 case 中的输入、输出的部分或全部内容。
由 injector 注入。
| |自定义鉴权算法
SiberAuth
|接口鉴权。
已内置通用鉴权算法，可以在源码中添加应用自定义的算法。
| | CI |持续集成。
项目发布后，向 siber 发送信息，siber 自动或强制执行 plan。
| | http | 超文本传输协议。 | | gRPC |Google发起的一个开源远程过程调用系统。
该系统基于HTTP/2 协议传输，使用Protocol Buffers 作为接口描述语言。
| | GraphQL | 一个开源的，面向API而创造出来的数据查询操作语言以及相应的运行环境。 | |proto 文件
proto file
| 描述文件，用于描述 gRPC 接口的定义 | ## 产品亮点 在向你宣传 siber 之前，想请大家先思考几个问题： * 每次上线前，是否对接口进行全量回归测试？ * 涉及到多种语言、协议时，如何测试他人的接口？ * 线上故障，想要回滚其中一个微服务时，如何确认对全局的影响？ * 对不同客户进行不同版本私有部署时，如何对接口的多版本进行测试？ * 测试、开发之间如何共享测试现场、清晰的展示及保存报错信息？ * 对于偶发问题如何进行有效监控？ * …… 对于上述问题，在来也科技内部，统一都使用集成测试平台（siber）来解决。接下来从产品层面向大家介绍下，siber 有哪些亮点： ### 规范的测试管理 #### 统一管理 所有接口测试需要的测试案例（case）、测试场景（flow）、测试计划（plan），都在 siber 上统一创建、维护、查看。避免出现*“你的脚本你知道，我的流程你不懂”等不友好交互的情况。* 用户之间可以共享 case、flow、plan。格式统一，全部使用 json 格式进行交互和校验，避免了*“ grpc 协议我不会调”，“前人用 go 写的测试脚本，但我更喜欢 python ”*等问题。 使用 siber 可以降低接口测试难度，提高测试案例的复用性。 #### 复用、复制 复用：同一个 case 可以出现在多个 flow 中，复用特指复用自己或他人之前配置过的 case。不建议对他人的 case 随意修改。 复制：点击“复制 case”，siber 会为您自动复制该 case 下的全部内容，包括但不限于一个或多个版本的request header 、 request body、checker、injector、sleeper。 如果您想对他人的 case 做出不确定后果的修改，我们建议您使用“复制 case” 功能，这样，不必影响到使用原先的 case 的执行计划。 ### 清晰的结果展示及持久化 在 siber 上执行的测试计划，可以清晰的展示出 plan、flow、case 整体的状态和运行详情。 清晰的记录了请求和返回的详细内容，每个检查项、注入项是否符合预期等结果。 执行结果永久保存，方便测试和开发者之间同步现场、复现、复盘问题。 避免出现：“我这儿没有啊！”，“你是不是参数填错了？”，“无法复现”等许多理不清问题 ### 健全的版本控制 敏捷开发模式下，产品迭代快。部分接口可能每次迭代都有改动，部分接口却可能两年都没有变化。 那如何直观清晰的维护，同一个接口在不同版本下的 case 呢？ siber 支持对同一个 case 配置不同版本的输入、输出及检查。可单独对有更新的接口对应的 case 增添版本，对于没变化的接口，无需额外处理。 当执行 plan 时，会自动执行不高于 plan 指定版本的最高版本 case。 详见： [case 版本说明](https://liu-tongtong.gitbook.io/dba/siber-ji-cheng-ce-shi-ping-tai/cao-zuo-zhi-nan/pei-zhi-case#case-ban-ben-shuo-ming) ### 可适配的 case 协议 在来也科技内部，许多项目配置了 `grpc-gateway` ，使得定义一个 method（method 是延用了 `grpcurl` 中的定义），可以有gRPC 和 http 两种访问形式。 通常而言对内使用 gRPC 协议，对外使用需鉴权的 http 协议。 对于这样的 method，仅需要配置一个 case，便可支持 gRPC 和 http 两种协议的测试。 ### 丰富的 parameter parameter 用于渲染不确定的输入。比如： 1. 测试创建用户接口，需要 random 一个用户名，不然会报“用户已存在！” 2. 根据创建用户接口返回的 UserID ，进行 UpdateUser 接口测试，此时需要获得上 case 返回 UserID，如何获得？ 3. 许多接口需要鉴权，而鉴权算法需要随机字符串和当前时间戳，如何实现？ 针对于上述问题，我们将 parameter 抽象出三个子项： #### function 支持生成随机的字符串、数字；当前时间戳；base64 等。 全部内容和配置方法，详见：[预定义的 FUNCTION](https://liu-tongtong.gitbook.io/dba/siber-ji-cheng-ce-shi-ping-tai/cao-zuo-zhi-nan/yu-ding-yi-de-function) #### variable 支持将同一 flow 中 case 的输入、输出、响应时间、状态码等信息保存在 variable 中，供后续case 使用 #### 自定义的鉴权算法 使用 SiberAuth 可以支持对接口进行鉴权。当前已内置通用鉴权算法，可以自己在 siber 上添加自定义的鉴权算法。 ### 全方位的触发机制 除手动触发外，siber 还支持 CI 触发和 crontab 触发两种触发模式： #### CI 触发 siber 已与来也科技内部 CI 工作流打通。当前支持两种 CI 触发模式： 1. 测试环境发布：**自动执行***所有相关 plan* 2. 生产环境发布：**强制执行***必要 plan* **自动执行：** 项目在测试环境发布后，会自动触发 siber 在测试环境运行相关plan（plan与服务的关系是自动绑定的）。 如有报错会发送到企业微信群中提示用户。 **强制执行：** 在应用上线前会自动检查 siber 上配置了强制执行的 plan 是否通过，如果未通过，不予上线。 #### crontab 触发 有些问题偶发，比如每天凌晨可能会有零星报错。siber 提供定制执行的功能，可以按照 crontab 的方式触发 plan，对于偶发问题提供了可观测的现场。 ## siber 可发现的问题 siber 自上线以来，将许多问题扼杀在了上线前，包括但不限于： 1. docker 少配置：`cannot validate certificate for …… because it doesn't contain any IP SANs` 2. 配置未推送 3. 表结构未变更，数据未初始化 4. proto 版本未更新 ## 贡献者 后端开发：刘桐烔，季琛，董梦囡 前端开发：徐丽婧，邬丹琳，杨子杰 ## 相关链接 1. 试用 demo：