自动化测试可视化

为什么80%的码农都做不了架构师？>>>   

最近打算把自动化测试的门槛降下来，好把皮球再踢出去。
我司自动化测试主要是用了ruby的cucumber框架，之前的负责人已将feature和step分开。
接皮球的童鞋，估计对一坨代码会有根深蒂固的畏惧感，又是多人协作，简单的想法是把这些用例搬到网页上，最好能点点鼠标就能用的。

所以，最后确定了一个ruby on rails来做。理由有三：
1、语言统一，都是ruby，虽然我不会ruby
2、我是前端新手，需要借助一个框架起步
3、java web太重，我不会python

cucumber这个框架，初步的印象就是依赖正则匹配。每个feature负责测一小块功能，分为若干scenario。每个scenario（其实Given不同参数可变成scenarios）主要就是Given xxx，When xxx，Then xxx组成的一个操作序列。Given是给参数控制生成多个场景的，When是给出应用具体所需的参数的，对我司的黑盒测试来说，就是凑api的参数了，凑齐了就向服务器发出http请求，获取响应并解析为结果，Then就是对结果的预期，整个框架就是用来验证某种输入下获得反馈是否符合预期。Given、When、Then后面跟的都是自然语言，放在feature文件里面。step把自然语言转换成代码，一个正则表达式将When xxx映射到一块代码，代码里面就是xxx所对应的参数的选取和赋值。

step是没指望了，再往下的基础支持也没指望。但是基础支持还是比较稳定的，step可能会需要添加一些新的。但这块工作主要在用例的维护上，即对scenario的维护。

所以目标就是把scenario的操作序列的编辑放到网页上，操作序列可以从下拉列表中选取，这个只读。但操作序列里面的参数要能编辑，这就需要正则表达式了。没准达到这个效果需要上ajax了。分离操作序列中的可变参数倒是有点眉目，咱也可以上正则表达式，step中有现成的正则表达式，至于文本变正则表达式是用的eval。

现在的进展是，努力的向框架靠拢，把文件解析成一块一块的当做记录再塞到数据库里面，好符合人家curd的预期——框架就是这点不好。刚解决了一对多的问题，因为靠自增长的不稳定的id来关联其实不靠谱，本打算用个文件名当外键，rails不许，也没找到改的地方，就不hack了，有那功夫自己整个还用啥框架啊。想想还是每次塞数据库写点sql同步算了。

转载于:https://my.oschina.net/mylbs/blog/224286