产品概述
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