软件测试自动化的纠结

　　人们在谈到软件测试自动化时，首先会想到测试工具，包括功能测试工具、性能测试工具等。而测试工具能执行各种不同的、具体的测试，就依赖于测试脚本。测试人员通过开发测试脚本(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 的自动化测试，相对容易。
　　如果采用关键字驱动脚本的开发模式，个人能力得不到提高。而且感觉，一旦离开公司原有的脚本开发经验几乎没有价值。而如果采用原生态的脚本语言，个人编程能力得到实实在在的锻炼，这些能力是业界普遍需要的，所以个人的价值得到提高。从这个职业发展角度看，测试人员更乐于采用原生态的脚本语言，而不愿采用关键字驱动脚本，特别是对那些看作个人发展的员工，会有一个权衡的考虑。

原文转自：http://www.uml.org.cn/Test/201011171.asp