题外话: 从数据驱动测试的工具聊GUI背后

FitNesse就是典型的数据驱动测试工具

　　通过建立一个决策表描述业务对应的处理场景. 然后讲决策表的数据传入功能模块, 得到执行结果并与期望结果比对. 完成测试

　　所以这里的数据驱动测试就是一种API级别的功能测试

DDT测试显然需要工具支持表格形式的数据写入. 也即: 除了现成的框架外, 还可以自己简单实现一个框架. 只需要保证分层合理, 能从标准化的格式内读取数据做到上面说的效果就可以了

除了Fit外, soapUI也可以实现DDT测试. 因为soup可以读取excel或者在文本文件中循环遍历. 因而也可以用于数据驱动测试

 

为什么很少有人谈及这样的测试工具? 因为它只能作为其他测试的补充. 或者需要通过组合其他工具来实现效果. 而且有更好的方式来替换它. 

或者说, 如果业务逻辑中总是和数据打交道, 那么决策表显得合情合理. 可是如果输入输出还要涉及到GUI层面上的交互或者改变, 而且GUI显得很重要.

那么, 往往会选择GUI层的工具进行开发.

 

在聊GUI层之前, 忍不住想要问自己. 为什么总是功能测试? 为什么功能测试总显得很无力和繁重?

个人觉得是由于分层测试的应用不彻底或者压根没有. 

如果任何改动, 都需要团队在牵涉表现层的情况下进行业务逻辑测试. 显然回归的范围和效率是不如意的. 

诚然GUI的好处就是完美面向业务. 但是手工测试对于GUI测试也有不足的地方. 比如要测试一个分页, 如果每页显示200条, 你至少得准备201条测试数据.

而这些数据往往都是一条条敲进去. 而在应对变更时显得非常笨拙. 所以基于数据被置换成参数, 才有了robot framework这样的框架

 

GUI有点像通俗的DSL, 只要有语言能力, 就能基本通过阅读交互了解系统. 而RF这样的则是彻底的DSL. 

就RF来谈,

使用DSL编写用例而不是使用录制回放, 还是为了解决维护成本的问题. 但是DSL的阅读难度不小, 比方说,

用selenium开发的UI自动化脚本, 封装得当, 就是一种DSL. 阅读者至少需要了解 python 或者 java 的基本语法, 才能通过阅读脚本明白被测试的业务逻辑

同时往往测试人员开发的脚本, 封装又不得当, 步骤和判定条件,执行过程都写在一起, 阅读起来总是含有很多不应被关注的东西.

对于DSL语言, 把所有的处理判断都进行了封装, 只保留了逻辑关键字和数据关键字, 使用团队都可以理解的约定格式进行框架编写.使得参与测试设计的难度和阅读的难度降低了. 

但也不是说一种工具就是万能的. DSL框架实现, 比直接用selenium编写脚本, 难度上面显然有明显的差别. 而且针对每种组件和每个套接方法都要开发对应的接口.

一个DSL框架下来, 也相当于实现了一个没有GUI的系统.

 

但是不论任何测试方式, 最后还是回归了一个问题: 由代码设计产生的可测试性