VBScript是Visual Basic Script的简称，即 Visual Basic 脚本语言，有时也被缩写为VBS。由于QTP的脚本语言是基于VBS的，因此VBS对于学习自动化还是起到了相当大的作用，VBScript可以通过 Windows脚本宿主调用COM，因而可以使用Windows操作系统中可以被使用的程序库，比如它可以使用Microsoft Office的库，WSH，AOM等，当然它也可以使用其它程序和操作系统本身的库。因此学习VBScript对于测试人员来说就显得非常的重要。

• 定义变量 ----  Dim

例如：

Dim helloworld  '定义变量

helloworld = "zzxxbb112"  '给变量进行赋值

msgbox helloworld '弹出消息框显示变量

复制以上保存为helloworld.vbs后直接运行后

 

由于VBScript语法不是非常的严谨，因此我们其实可以不用申明变量就可以直接使用

例如：

helloworld = "zzxxbb112"  '给变量进行赋值

msgbox helloworld '弹出消息框显示变量

这样的话就可以省去很多申明变量的时间，增加代码开发的速度，但是这样却会有一个问题，我们来看一下脚本

例如：

helloworld = "zzxxbb112"  '给变量进行赋值

msgbox helloword '弹出消息框显示变量

保存以上脚本后，运行之后，会发现弹出框并没有任何数据，而是一个空值

为 什么？因为我们这里输入的helloworld 被我们拼写成了helloword少了一个L，因此导致打印出来一个空值，当我们在大量声明变量的时候其实是很容易范这种错误的，因此这里就要给代码中加 上显示声明，这样才不会出现上述的这种情况，下面就来看一下具体怎么使用。

• 显示声明 ----  Option Explicit 强制所有变量必须先声明才能使用

例如：

Option Explicit '显示声明变量

Dim helloworld '定义变量

helloworld = "zzxxbb112"  '给变量进行赋值

msgbox helloword  '弹出消息框显示变量

运行以上代码就可以直接定位问题，出现错误提示“变量未定义”

很多朋友在VBS时，比较懒，不喜欢使用显示声明，其实显示声明能够检查你的程序，建议大家能够养成这个好习惯，否则在大量的变量面前你一定会束手无策，或者累死累活，简单总结下它的优点：

1. 显示声明是对脚本编写人员的一种好习惯
2. 可以防止很多不必要的错误发生，大型项目更加明显
3. 减少资源的占用
4. 代码提示的优势

一天和同事聊天，他试图实现一个功能，让一个程序在系统重启后能自动启动，并且加载指定的配置。

　　我分析了一下发现实现这个功能会比较复杂，主要是涉及多处配置文件的修改。回头再看看，发现这个系统很少会重启，可能一年就4，5次。于是我建议他放弃这个想法。因为维护配置文件会成为一个负担，考虑到系统重启的频率，这会是得不偿失。

　　但是看来他并不以为然。他说他的目标是这些配置工作完全不用人来参与，“最好是在家里动一个手指所有的配置工作都自动化的为我做好了”。看到他信心满怀的样子，我不愿意扫他兴。但我相信如果即使有一天他真正实现了这个目标，维护这个自动化系统也会让他寝食难安。

　　这样悲观的看法，我想在两三年前我肯定没有。那个时候我像他一样对“自动化”抱有无限美好的期望，好像只要测试自动化了，软件测试工作马上变得和“公务员一样轻松”，只需要动一下指头，所有的testcase都自动化得跑起来。

　　但随着做了更多的自动化测试项目，也看了更多的成功和失败的案例。对自动化的特点了解得来越多，对自动化的期望也在一直不断的下降。

　　这种看法的变化，我倒觉得是越来越贴近真实的“自动化测试”。

　　如果要充分利用一个工具，一定要了解其特点。现在在业界，自动化软件测试就像一个人见人爱的香馍馍。自动化测试好像已经和“高科技”，“高测试效率”，“成熟的测试team”…这些褒义词联系了起来。在这种一边倒的氛围下，自动化程序的缺点和不足和必须要付出的代价被掩盖了起来。

　　认识自动化的不足，我觉得首先要转变的一个想法是“自动化测试并不是用来发现bug的”。原因很简单，自动化测试基于testcase，但所有的bug中只有大约1/4是仅仅按照testcase来测试就能发现的，其它的bug，来自于聪明的“人”的经验，分析，发散思维和说不清道不明的“灵光一闪”，而这些特性对于自动化程序来说完全是无能为力。所以，幻想“动一下手指”，所以的bug都被自动化程序发现出来是完全不可能实现的。

　　自动化另外一个特点是自动化本身也是程序，也需要投入大量的人力来实现。一个软件买出的copy越多，它的价值越大。对于自动化测试程序来说，它运行的次数越多，它的价值越大。有下面一些原因都可能减少自动化测试程序运行的次数，甚至导致自动化项目的失败。

　　1）测试产品功能或界面变化频繁

　　2）自动化的case本身不需要频繁的测试，比如安装过程或者一些非核心的功能

　　3）自动化程序不稳定，容易跑“死”掉

　　看到了一些自动化测试程序因为这些原因而效果大打折扣，我对“自动化一切”的热度慢慢退烧了。

　　最后一个需要注意的自动化测试程序的特点是，自动化测试程序不是商业产品，它的用户都是专业人士，所以它不用商业产品那样高的扩展性，灵活性，可配置性，友好的交互性。因为这些特性的得来是要付出高昂的代价的，那就是人力投入和软件的复杂度大大增加。对于设计师来说，如果要在这些特性和简单中选择的话，一定要选择简单。

　　1）对于错误处理要简单直接，而不要灵活和聪明。打印错误并直接退出是最好的选择，不要试图猜测错误的根源并试图从错误恢复。这里包括用户输入，环境错误等。

　　2）对于环境设置，要求单纯一些，不要去兼容环境变化。一般来说测试环境都是有测试人员在维护。试图兼容环境可能导致代码大大增加。

　　3）对于自动化测试的代码来说，也不要用太炫的设计技巧和复杂的设计模式。因为自动化测试的代码最好能被使用它的测试人员读懂，甚至能做简单的修改和排错，这样能提高自动化测试的次数。

　　对自动化期望不能太高和自动化程序不要设计得太完美，是我对自动化测试程序设计和使用过程中获得的最深刻的体会。

本文出自lifr的51Testing软件测试博客：http://www.51testing.com/?764

　自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

　　1.  自动化测试的前提条件

　　实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：

　　1)   软件需求变动不频繁。

　　测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

　　项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

　　2)   项目周期足够长。

　　由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。

　　3)   自动化测试脚本可重复使用。

　　如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。

　　另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。

　　2.  自动化测试的过程

　　自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。

　　1)   自动化测试需求分析。

　　当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。

　　2)   自动化测试框架的搭建。

　　所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。

　　而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：

　　a.    公用的对象。

　　不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。

　　b.    公用的环境。

　　各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。

　　c.    公用的方法。

　　当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。

　　d.    测试数据。

　　也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。

　　在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。

　　3)   自动化测试脚本的编写

　　该编写过程便是具体的测试用例的脚本转化。初学的自动化测试人员均会使用录制脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写脚本为主要行为，以避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。

　　4)   脚本的测试与试运行

　　事实上，当每一个测试用例所形成的脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变，都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例，也仅能被称作是半自动化测试，这会极大的影响自动化测试的效率，甚至不能满足夜间自动执行的特殊要求。

　　因此，脚本的测试与试运行极为重要，它需要祥查多个脚本不能依计划执行的原因，并保证其得到修复。同时他也需要经过多轮的脚本试运行，以保证测试结果得一致性与精确性。