从0到1，TOBY实践

本文通过同一个test case在不同框架里的表现，对比JT分析了TOBY的利弊，并阐述一些自己的想法，希望能帮助读者对TOBY有一定程度的了解。

Hack it

TOBY对于用惯JT的工程师是个全新的东西，人类对未知事物会有畏难情绪。
在周三下午Jon做的TOBY分享之前我对TOBY的了解为0，听过之后基本上理清了TOBY的框架结构。理解了就不难，就更容易产生兴趣使用它。
当我跃跃欲试的时候，Spark随口一说『周末能不能做完？』，刚好有两天时间没有测试任务，索性就来次一个人的hackathon。

目标：用TOBY重写一个case

vSRX MiniPDT中的VPN concentrator是个比较典型的PDT individual case，根据二八分原则，80%的PDT individual case能用TOBY以同样的方法写出来。VPN Concentrator的JT case也是我写的，于是成为重写目标。该Case包含以下内容：

• Configuration: 19710行set命令
• Devices: 6个vSRX，其中两个组成HA，其余四个是SA。
• Feature and Scaling：

Feature	Scaling
Policybased VPN	100 SA, 1K sessions, 1000pps UDP traffic
Routebased VPN	100 SA, 1K sessions, 1000pps UDP traffic
MPID	100 SA, 1K sessions, 1000pps UDP traffic
ADVPN	101 hub SA, 101 spoke SA, 100 sortcuts, 1K sessions, 1000pps UDP traffic

• Topology:

vSRX MiniPDT Topology

开发

• 快速入门 Quickstart Guide
• 项目地址 PDT/Test Suite

完成

用了两个工作日，赶在周末前达成了目标。TOBY case实现了对VPN Concentrator配置，实现了Policy based VPN、Router based VPN、MPID、ADVPN的验证，生成正确的report，生成了正确的日志。

优势

1. 更易用

实践TOBY从0到1仅用两天时间，足见其易用性.

TOBY使用松耦合设计，两个lib（core library，User library）分的很开。这样做的好处是80%的case只要用core lib就可以完成，20%的case才需要开发使用自己的User library。而在JT里100%的case同时使用core lib和User lib。比如PDT的lib有个函数叫verify_number，基本每个case都在用。

Core library的强大得益于对DCL（device control layer）的进一步抽象，做出了HLDCL（High layer device control layer）。HLDCL抽象出4个Engine：

• Init Engine
• Config Engine
• Traffic Generators
• Verification Engine

Init Engine负责初始化类和函数，连接设备并获取接口信息，生成log entry。JT case经常会abort，如果较长时间没对某个device进行操作，原因是JT不会自动进行重连接。TOBY则没有这个缺陷，任何时候对任何设备的操作都不会没有响应，除非这台设备真的挂掉了。

Config Engine可以让工程师快速部署配置而不用写脚本。原因在于其直接使用了Junos configuration作为数据模型，支持set命令或者层级结构，支持模板，支持变量，支持缩放。数据结构保存在yaml文件中。

Traffic Generators控制测试仪，四个库agilent、ixia、ostinato、spirent中，只有spirent库完成了开发。目前没有任何文档和实例参考。（将持续关注，并在本文以后的版本中更新。）

Verification Engine可以让工程师写个简单的yaml文件完成测试点检查。不需要写脚本，只需要定义好command、xpath、value这三个值，所有测试点检查即可完成。Command是你的命令行，value是你的期望值，xpath是XML路径语言。命令执行后TOBY得到的返回内容为XML文件，根据提供的xpath，TOBY得到返回值。XPath 中文教程

2. 代码量更少

TOBY帮助工程师将精力放在设计case上，而不是浪费时间写脚本。代码写的越少，相关的工作比如handover、code review时间也越少，维护的成本也会大大减少。以VPN Concentrator为例，同一个Case，TOBY用了166行代码，JT用了316行。

JT sub	lines of codes
TC5	59
verify_vpn_statics	47
get_ha_type	21
verify_ipsec_sa	53
verify_flow_session	136
Total	316

TOBY files	lines of codes
MiniPDT_VSRX_conf.yaml	2
MiniPDT_VSRX_vfy.yaml	124
MiniPDT_VSRX.robot	40
Total	166

TOBY比JT少了约一半的代码量

3. 执行速度更快

得益于log非实时显示，所有的output都以文件形式供TOBY后台使用，省去很多buffer和屏显的时间。整体执行时间减少了约60%，试想如果JT case全部改成TOBY，对效率将是巨大的提升。

TOBY执行时间减少了约60%

4. 可读性更高

JT只有log，没有report。

TOBY同时提供Report和log，直接通过网页访问HTML文件，可读性更高，参考 MiniPDT VPN Concentrator Report。而且支持标签功能，可以被用来做分类报告、统计或选择性的运行测试。

5. 更多可能性

ROBOT扩展性强，本身集成了很多库。还可以自己开发库，TOBY本身也是ROBOT的一个库而已。除了测试命令行，通过额外的库文件还能做web测试、UI测试、API测试、UT测试。这就给我们更多的想象空间，比如：

• 集成Selenium，做命令行验证的同时验证jweb（or SD）。
• 集成自己开发的服务，比如完成测试后，自动通过邮件发送 MiniPDT report 到指定群组

缺陷与未知

在开发TOBY case的过程中对以下问题进行了思考：

• Traffic Generators不完善，暂不能使用IXIA测试仪发送流量。一种规避方法是使用PC Server安装的IXIA API发送流量。
• yaml无法定义逻辑。比如，HA环境中如果只在primary上出现计数（如路由相关计数和ipsec statistic计数），TOBY不能同时抓取两个node上的返回值做『或』判断。规避方法：failover到同一边。
• Longeivity case需要开发自己的lib控制sleep time和failover。
• 没有job管理系统，不知RM未来是否支持TOBY，如果不支持可以选用第三方软件例如jenkins。
• 可能有自动链接拓扑的功能，尚待确认。Regression team有大量User Case，每个UC的拓扑结构都不一样，但设备有限，动态拓扑功能日趋重要。
• 没有实时log。当工程师想实时查看脚本执行过程中某个检查点时，需要等待CASE执行完成才可以。这个问题可以通过两种方法解决，一种是打断点；另一种是通过标签，通过分类，通过细化case，只跑你想要查看的测试点。TOBY的执行时间短，是种弥补。 （根据Jon的研究，TOBY可以查看实时log。使用 toby -b runtime.log 参数，会在日志目录下生成一个debug 文件而且实时输出，用 tail -f runtime.log就可以看）

大部分问题归根结底是TOBY lib不完善导致的，随着lib不断完善必然会越来越容易。

其他

虽然学习成本并不高，但总归算是学习成本。掌握以下知识就可以开始写TOBY case了：

• TOBY架构
• XML & xpath
• git & gitlab
• Python（只有需要开发User lib的时候才使用）

总结

TOBY易用，开发难度低效率高，执行速度快，测试结果可读性强，框架扩展能力强。虽然有lib不完善的缺点，但这同时又是个机会——为TOBY lib贡献代码。Talk is cheap show me the code，通常国人相比美印的同事不善表达，代码是种更有力的表达方式。