topic

https://docs.google.com/presentation/d/1KITWbK46rm-lDZce_SqxegHTPjc9Ez-broxDTpfBpK8/pub?slide=id.gd8cf2c7b7_0_0
topic 名字是在 twitter 服务之间测试集成, 实际内容讲的是 diffy 工具.
我已经看这个工具的源代码 2 个月了. 所以对这个 topic 很感兴趣.

内容解读

研发修改了一小块的代码, 如何保证整个产品的正确性?
如果软件从开头修改了一个简单的分支, 那么它在下游的调用函数那里可能会带来一场规模庞大的蝴蝶效应.
做好单测是很好的保证手段, 但是单测的断言并不能做到全部功能覆盖. 它只能保证软件在修改前后的"基本正确"

diffy 开启了一个新的时代, 直接通过真实的使用场景来驱动, 并严格对比每个场景.
做法如下

• 抽样线上的流量并引流
• 在新版本, 老版本和参考版本三者中同时发送请求并获得相应
• 通过三者数据来进行对比.参考版本的数据用于降噪. 新老版本的对比是核心

个人经验

因为我最近在研究这个工具, 说下我对这个工具的看法吧.
优点

• 使用了 twitter 的一个框架 finagle 可以对流量进行多播. 代码很简单. 这个做的很 cool, 这点类似 gor 和 tcpcopy, 但是更简单
• 引入参考版本这个概念用于降噪有效解决了误报.
• 数据对比方面. 他把 xml json html 和 protobuf 协议都进行了解析并生成一个树形结构. 然后对比每个子节点的值. 这样的 diff 很精准

缺点

• 一般公司都搭建不起来三套环境. 做法就是把参考版本的地址可以用老版本代替. 可以节省下一套环境.
• 适合纯读的请求, 如果是有读写. 需要确保这几套环境的数据也要是一致和独立的. 所以这点也不容易, 至少在我们公司是行不通的
• Diffy 在发送请求后并不返回某个版本的响应. 所以你不能把接口测试用例直接用上, 还得再搭建一层 Gor 工具或者 TcpCopy,

我最后的解决方案是通过了跑接口测试, 保存下针对不同环境的请求数据, 然后对比. 这样不再是多播多个环境. 也可以保存历史数据作为对比基准.
我也一直在研究 diffy. 试图改进它.

topic 精华

软件的复杂度在一定条件是很难通过单测来真正的保证的. 或者付出的成本会越大.

Diff 的架构设计

测试结果