二十年前，软件测试来到中国。二十年来，逢UI自动化，必有数据文件，美其名曰，数据驱动。
为什么？
为了代码和数据分离啊，你不知道？你看那些牛哄哄的架构师谁不是这么设计？ （这从另一角度佐证了一个猜想：开发人员对测试人员的补充，从来没有停止过。）
什么是数据驱动，搞明白了吗？
数据驱动，有两个特征：
一、通过脚本以外的数据模块，决定测试用例执行的业务流程；
二、通过外部数据模块定义对象库中对象属性；
数据驱动，有三大优点：
一、数据驱动的优势在于外部数据可读性优于代码；
二、外部数据容易查询、复制、更改、复用；
三、处理数据的代码可以复用、开发效率高。
代码的抽象可复用，是一个进步。但是高可复用和低耦合，是一对矛盾。
下面言归正题，说说缺点。所有的UI自动化测试，要么死在前期的架构设计阶段，要么死在后期的使用阶段，少有逃过厄运。
原因不是界面变化快，不是业务变化快，测试让产品和业务背了太多锅了。
原因只有一个：成本！
当一个UI自动化测试体系建立起来以后，外部的数据驱动文件的存在将大大增加新的脚本的开发和维护成本。
外部数据驱动的隐性成本包括：
一、要设计外部数据结构和数据解析脚本的对应关系，对于界面复杂、业务复杂的系统，UI自动化在这里就会夭折；
二、架构中出现额外的数据解析方法和外部数据文件，必然要培训脚本开发人员学习他们的对应关系，增加人员成本；
三、只要数据文件结构发生变化，数据解析脚本必然受到影响，这就是高耦合性的弊端；
四、当外部数据为文件形式时，脚本在不同测试人员机器上的移植成为问题（最基本的盘符路径是绕不过的）；
五、当外部数据为关系型数据库时，数据库服务器的稳定性、网络通讯的稳定性，都会制约的脚本的正常执行；
网友评论