本文通过同一个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，通常国人相比美印的同事不善表达，代码是种更有力的表达方式。
网友评论