软件测试自动化的纠结

　　人们在谈到软件测试自动化时，首先会想到测试工具，包括功能测试工具、性能测试工具等。而测试工具能执行各种不同的、具体的测试，就依赖于测试脚本。测试人员通过开发测试脚本（test script），来实现测试用例所要进行的具体操作和验证。一旦选定测试工具，则测试脚本的开发就成为测试人员的日常工作之一，也是测试自动化的最主要的工作。也就是说，测试脚本的开发和维护直接关系到软件测试自动化的成败，至少对自动化测试的投入产出存在巨大的影响。

　　测试脚本从最初的录制脚本发展到结构化脚本、数据驱动（data-driven）脚本，再发展到关键字驱动（keyword-driven）脚本。从历史发展过程来看，数据驱动脚本和关键字驱动脚本对提高自动化测试脚本开发效率有显著的帮助，而且也有利于脚本的维护。下面这个表，可以充分说明不同类型的测试脚本对自动化收益的影响是很大的。

自动化测试脚本类型	成本	收益	净收益
录制和回放	8.3	11	2.7
数据驱动脚本	8.4	18	9.6
关键字驱动脚本（自动化测试框架）	9.8	15	5.2
关键字驱动/数据驱动混合结构	11.6	19	7.4

　　下面是一个简单的关键字驱动脚本示例：

命令	对象	值
open	/change_address_form.html
type	address_field	Betelgeuse state prison
clickAndWait	//input[@name='Submit']
verifyTextPresent	Address change successful<

　　从中看出，这样的业务逻辑很清楚，操作起来简单。而且，伴随着关键字驱动脚本的诞生，也相继出现了各种自动化测试框架，形成良好的脚本开发环境或平台，使得自动化测试脚本的开发更具开放性、可视性和层次性，测试人员开发和维护脚本都变得更轻松、容易，从而在整体上进一步提高自动化测试的效率和应用范围。

　　当然，任何事情都不会十全十美，会存在另外一个问题。一旦自动化测试框架及其工具完成之后，测试人员的脚本开发工作简单，缺乏技术含量，可能缺少编程的锻炼机会，从而在自动化测试的实施过程中带来一个新的纠结问题——是使用关键字驱动脚本开发模式还是使用原生态的脚本语言（如Python、VBScript，甚至C++/C#、Java等）开发模式？这里主要指Frontend功能测试的自动化，涉及UI。如果是backend 或API 的自动化测试，相对容易。

　　如果采用关键字驱动脚本的开发模式，个人能力得不到提高。而且感觉，一旦离开公司原有的脚本开发经验几乎没有价值。而如果采用原生态的脚本语言，个人编程能力得到实实在在的锻炼，这些能力是业界普遍需要的，所以个人的价值得到提高。从这个职业发展角度看，测试人员更乐于采用原生态的脚本语言，而不愿采用关键字驱动脚本，特别是对那些看作个人发展的员工，会有一个权衡的考虑。

　　站在公司角度看，应更多考虑自动化测试的投入产出，毫无疑问选择关键字驱动脚本，保证自动化测试效率。如果选用原生态的脚本语言，那么自动化测试的开发工作量会增加，要求测试人员和开发人员达到1：1的配备，将来自动化测试的脚本维护也会是一个很大的问题。如果选择像C++/C#这样高级语言来写自动化测试脚本，脚本变得复杂，会带来脚本本身测试/验证的问题，形成了一个无穷的“递归循环”。

　　从管理角度看，可以采取行政命令，统一行动，全面采用优秀的自动化测试框架和关键字驱动脚本，确保有高产出投入比（ROI）。同时，过于强制实施某套方案，可能会不利于员工的工作积极性或主动性，也会对生产力产生负面影响。

　　站在公司角度，也要关怀员工，帮助员工的职业发展，如何创建更多的机会给员工来提高自己的能力。所以，全面推行关键字脚本的软件开发呢，还是允许部分团队采取那种相对原始的脚本开发模式呢？这是一对矛盾，需要平衡和疏导。有些独立的项目、周期短的项目、局部的项目可以放开，由团队自己来决定，而对最核心的全局产品开发、周期长的项目统一到同一个支持关键字驱动脚本的自动化框架上来。