我们需要真正的脚本语言

 大部分测试工具绑定了工具生产商指定的特定脚本语言，我们叫它厂商语言。这些语言很难学，实现得很弱，最重要的是，它们不鼓励测试员与开发人员之间的合作。测试员应该得到全特性的、标准的测试开发语言。为什么呢？
 
        现在市面上的大部分软件测试工具，我们在使用时都要使用工具的脚本语言。令我最烦恼的是，为了使用他们的工具，我必须学习指定的脚本语言。大部分工具有录制功能，为你产生一些脚本，但是不可避免地，你要对脚本进行修改，自己编写脚本。这样的话，你就必须要学习额外的语言-厂商语言-这个语言只是在这个特定的工具上能使用！
 
破坏合作
        因为厂商语言是特定的语言，开发人员对其知之甚少并且也不愿意学习它。我经常鼓励测试员和开发人员在自动化项目中一起合作。这是高效的合作方式。但是厂商语言挡在中间。它们把测试员和开发人员分开，孤立在指定的工具语言上。减少了共享、合作和改进的机会。
 
        要把测试员和开发人员整合在测试过程中，我们已经有很多困难了。现在又多了个厂商语言的学习问题。你如果叫一个开发人员学习VB？没问题，因为他们毕竟可以在将来有使用得上的机会。你如果叫一个开发人员学习一个指定的语言，这个语言只能在这个工具上使用？你做梦吧！你已经很难让开发人员把注意力放在测试上了，现在又增加了一个困难。
 
        为什么要把钱花在一个会破坏测试员与开发人员之间的合作关系的工具上？
 
方言
        有很多这种厂商脚本的方言。有些是类C语言。意味着什么？意味着写出来的代码想C语言的代码，但是没有指针，所以你不能使用在C课程和书本上学习到的任何复杂的数据结构。C作为脚本语言来说是很差的。它是编译的，但是测试脚本语言是解释执行的。这是为什么类C语言不支持指针。
 
        其它的有些使用类VB语言的方言。如果你了解VB，则代码会看起来很眼熟，但是你不能使用VB的标准库。而且，你在VB中学到的东西未必被应用在厂商脚本语言上。
 
        也有一些工具使用类似面向对象的厂商脚本语言。面向对象是好的，但是你会发现对一个类的修改不会继承到它的子类。什么？因为厂商脚本语言认为这样更方便测试的管理安排。这样是否真的能帮助测试员还有待讨论，但是测试员真正需要的不是为测试特定设计的语言。他们应该得到标准的语言实现，这样才会更好地帮助他们的测试工作。
 
        一些更新的测试工具现在开始使用真正的脚本语言，像JavaScript或VB。我希望这种趋势能继续下去。而且，如果一些旧的工具能重新设计以支持标准语言则会更好。标准语言有正式的规范，会帮助你的测试组更好地用在测试上。
 
重复地发明轮子
        最近有些文章在描述怎样使用厂商脚本添加堆栈和队列，这其实是厂商脚本的落后体现。厂商语言使自动化测试人员浪费很多时间和精力在重新发明轮子。堆栈和队列在标准语言上已经得到很好的实现。
 
        我自己也有同感。我必须为不同的厂商语言创建库来支持sting操作、日期计算、计算排列组合等。有些厂商语言也有这样的库，但是标准语言的库会更大、更全面，也更加健壮。
 
回到以前
        很多非测试工具也嵌入了厂商语言。使其更难使用。John Ousterhout发明了TCL（Tool Control Language），使得跟C的集成更容易，并发布到公共领域。TCL现在被用在一些公共领域的测试工具上。
 
        Ousterhout区分了系统编程语言（像Pascal、C、C++、Java等）和脚本语言（像Perl、Python、Rexx、TCL、VB、Unix shells等）。系统编程语言在从头开始构建方面和性能方面会更好点。而脚本语言在重用代码和快速开发方面有优势，是理想的自动化测试语言。
 
有些测试工具的厂商语言是在Ousterhout的TCL出现之前，当时Perl也还不成熟。但是那是那时候，现在则有了很多选择。
 
让厂商脚本语言退休
        因为有了很多的选择，所以厂商脚本语言应该退休了。如果出现异常，没有什么第三方的书可以使用，只能参考和依赖厂商提供的书或帮助文档，这些文档未必会坦白告诉你厂商脚本语言的缺点。语言的课程也很难随工具附上，很昂贵，可能还要你亲自去学习。
 
      测试自动化会很难，如果我们需要熟悉不同工具的不同语言的话。开发人员不会忍受有这么多限制和缺点的编程语言，我们也不应该忍受。

原文转自：http://www.ltesting.net