产品概述
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
siber 是来也科技研发团队自主研发，面向接口的集成测试平台。覆盖 http、grpc、graphQL 三种常见类型接口测试。
siber 于2019年末在来也科技内部上线 V1.0 版本。当前已覆盖接口 600 余个，占总接口数量的 85% 以上；配置 case 3300 余个，case 执行次数达 230w 余次。
自 siber 上线以后，多次帮助产品、业务线发现不易察觉的问题，有效的规避了线上故障，极大的减轻了测试同学、私有部署同学回归测试的压力。
术语
含义
集成测试平台（siber）
来也科技研发团队自主研发，面向接口的集成测试平台。
环境
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。
在来也科技内部，许多项目配置了 grpc-gateway ，使得定义一个 method（method 是延用了 grpcurl 中的定义），可以有gRPC 和 http 两种访问形式。
通常而言对内使用 gRPC 协议，对外使用需鉴权的 http 协议。
对于这样的 method，仅需要配置一个 case，便可支持 gRPC 和 http 两种协议的测试。
parameter 用于渲染不确定的输入。比如：
测试创建用户接口，需要 random 一个用户名，不然会报“用户已存在！”
根据创建用户接口返回的 UserID ，进行 UpdateUser 接口测试，此时需要获得上 case 返回 UserID，如何获得？
许多接口需要鉴权，而鉴权算法需要随机字符串和当前时间戳，如何实现？
针对于上述问题，我们将 parameter 抽象出三个子项：
支持生成随机的字符串、数字；当前时间戳；base64 等。
支持将同一 flow 中 case 的输入、输出、响应时间、状态码等信息保存在 variable 中，供后续case 使用
使用 SiberAuth 可以支持对接口进行鉴权。当前已内置通用鉴权算法，可以自己在 siber 上添加自定义的鉴权算法。
除手动触发外，siber 还支持 CI 触发和 crontab 触发两种触发模式：
siber 已与来也科技内部 CI 工作流打通。当前支持两种 CI 触发模式：
测试环境发布：自动执行所有相关 plan
生产环境发布：强制执行必要 plan
自动执行：
项目在测试环境发布后，会自动触发 siber 在测试环境运行相关plan（plan与服务的关系是自动绑定的）。
如有报错会发送到企业微信群中提示用户。
强制执行：
在应用上线前会自动检查 siber 上配置了强制执行的 plan 是否通过，如果未通过，不予上线。
有些问题偶发，比如每天凌晨可能会有零星报错。siber 提供定制执行的功能，可以按照 crontab 的方式触发 plan，对于偶发问题提供了可观测的现场。
siber 自上线以来，将许多问题扼杀在了上线前，包括但不限于：
docker 少配置：cannot validate certificate for …… because it doesn't contain any IP SANs
配置未推送
表结构未变更，数据未初始化
proto 版本未更新
后端开发：刘桐烔，季琛，董梦囡
前端开发：徐丽婧，邬丹琳，杨子杰
详见：
全部内容和配置方法，详见：
试用 demo：
dockerhub：；
github 地址：；
专利申请：