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