自动化测试框架:与FinaIBUIder

　当自动化测试的脚本编辑器完成之后，根据使用者反馈，编辑器确实大大提高了工作效率，并且代码的管理确实变得有效而可控。而且现在此项目已经开始向另一个管理类软件系统尝试应用。可以预计，会有一些新的功能加入。 
　　不过，我们回过头来思考最开始的一个问题——自动化的问题。这是我们最终的目的。虽然说自动化测试框架能够解决软件本身的执行问题，但是一次完整的测试，必然是要覆盖全过程的。很显然，我们的框架不能解决这个问题。 
　　因为我做过很多项目的每日版本构造，对FinalBuilder比较熟悉，同时也意识到FinalBuilder可以弥补我们框架在这方面的缺陷。很自然地，我将这个软件引入到我们整个系统中来。 
　　这个软件在业界是非常有名的，很多人都很熟悉其用法。不过原来都是开发人员在使用，测试人员不是很熟悉。所以有必要对参与自动化测试的测试人员进行简单的培训。 
　　考虑到这篇文章的部分读者也是测试人员，所以我在这里也简单的介绍一下FinalBuilder。 
　　FinalBuilder解决的是任务流的问题。就像我们以前的D0s系统的大部分程序一样，没有界面交互部分，一次输入，直接返回最终处理结果。这点和我们的自动化目标不谋而合。 
　　在FinalBuilder中，最本质的就是一个任务的执行。任务的执行包括两部分：执行环境加上执行数据。 
　　执行环境往往包括Windows系统自带的一些程序，包括Copy、XCopy等Shell命令，也有系统中已经安装的程序，如Delphi、VC、SVN等。而执行数据，则是指我们的输入。由于我们要实现在执行中不存在界面交互，那么就必然要求我们将所有需要交互的信息一次性地输入。与此同时，我们的环境程序，也必须同时支持此种模式(一般情况下，这种模式称为命令行模式)。 
　　对于使用FinalBuilder人来讲，就有必要了解相关程序的命令行调用方式。这样有助于我们使用和编写任务。如果是我们自己研发一个程序，那么因为要使用到FinalBuilder中来，也有必要支持命令行模式。 
　　在FinalBuilder中，最主要的还是顺序流程，当然它也支持条件、分支、循环。最新的版本还有多线程协同，不过在使用初期，主要还是以顺序流程为主。 
　　最关键、最基础的就是Run DoSCommand和Execute Programe两个任务了。有了这两个，几乎可以完成任何事情。当然，FinalBuilder还提供了很多现成的控件，使得你可以通过配置(而不是命令行)来编写任务，这大大降低了使用难度。不过，不可避免的会有一些需求需要我们自己编写命令行，因此这两个任务必须掌握。 
　　FinalBuilder的自动执行，是使用Windows的计划任务来完成的。在其菜单中有生成计划任务的功能。顺便说一句，FinalBuilder本身也一样支持命令行模式，因此多个FinalBuilder之间，可以互相调用。这对我们的自动化非常有利。 
　　在经过简单的介绍后，我们发现，使用FinalBuilder确实可以帮助我们解决问题。 
　　那么，我们需要解决哪些问题呢？下面是我按照顺序列出的一份清单： 
　　◆卸载已经安装的目标软件； 
　　◆删除所有目标软件的相关目录，保障干净环境； 
　　◆从服务器获取并复制目标软件的安装程序； 
　　◆从源代码服务器获取自动化测试脚本和框架程序； 
　　◆安装目标软件； 
　　◆安装自动化测试框架， 
　　◆执行目标软件； 
　　◆执行与目标软件配套的自动化测试脚本，如：冒烟测试； 
　　◆生成自动化执行日志，分析结果； 
　　◆发送邮件通知自动化负责人。 
　　所有需要完成的功能，其实上面这些都已经做好了。因为我们通过手工确实可以走到最后。但是要做到覆盖全过程的自动化的想法，还需要各个工具软件互相协调。 
　　首先是软件的安装和卸载，这需要软件能提供命令行模式的安装运行(安装和卸载都是需要人工交互的)，由于我们自身的安装程序支持这个模式，自然省去了很多麻烦。对于网络上流行的免费的和收费的安装软件，也都是支持安全模式的，这些只要多查查资料就可以了。 
　　复制文件就简单多了，FinalBuilder和Windows都已经提供了很多命令。 
　　关于工作流程的自动化执行，那就是我们的自动化测试框架。针对这个需求，我花费了很多工夫才加进去。主要是程序的协同性问题。必须等到目标软件的主窗体完全启动完毕。另外，需要对中途的意外退出做出严格的防范，保障自动化测试能够有始有终。这里面增加了一个超时的概念，可以保障最后程序的退出。 
　　分析日志更是重要。事实上，没有日志的自动化测试没有人愿意去做。目前还是先根据一些简单的需求，做了一些统计，相信以后还会增加的功能是版本日志对比，这样可以看到系统的稳定性变化趋势。 
　　而自动化最重要的就是完成从电脑到人的连接。将报表按照分类发送到相关人员信箱中，他们就可以继续根据测试结果进行处理。 
　　说到底，FinalBuilder就是帮助我们解决了工作流的问题。将自动化测试的流程固化在脚本中。最关键的是，这个流程的管理，我们可以使用现成的方案，而不需要再去自己造一个新的轮子。这样符合我们系统架构的基本原则。 
　　当然，FinalBuilder不是唯一的选择。事实上有很多开源软件也都可以完成这样的功能，最简单的就是直接使用批处理BAT文件。同时，专业的软件，可以提供更多的调试和辅助功能。
　　OK!我们的自动化测试框架，在使用FinalBuilder之后，已经初步将一个完整的自动化测试过程构建起来。正如博文的一位读者所说的，下面要重点关注脚本的方案设计了。 
　　当自动化测试的脚本编辑器完成之后，根据使用者反馈，编辑器确实大大提高了工作效率，并且代码的管理确实变得有效而可控。而且现在此项目已经开始向另一个管理类软件系统尝试应用。可以预计，会有一些新的功能加入。

不过，我们回过头来思考最开始的一个问题——自动化的问题。这是我们最终的目的。虽然说自动化测试框架能够解决软件本身的执行问题，但是一次完整的测试，必然是要覆盖全过程的。很显然，我们的框架不能解决这个问题。 
　　因为我做过很多项目的每日版本构造，对FinalBuilder比较熟悉，同时也意识到FinalBuilder可以弥补我们框架在这方面的缺陷。很自然地，我将这个软件引入到我们整个系统中来。 
　　这个软件在业界是非常有名的，很多人都很熟悉其用法。不过原来都是开发人员在使用，测试人员不是很熟悉。所以有必要对参与自动化测试的测试人员进行简单的培训。 
　　考虑到这篇文章的部分读者也是测试人员，所以我在这里也简单的介绍一下FinalBuilder。 
　　FinalBuilder解决的是任务流的问题。就像我们以前的D0s系统的大部分程序一样，没有界面交互部分，一次输入，直接返回最终处理结果。这点和我们的自动化目标不谋而合。 
　　在FinalBuilder中，最本质的就是一个任务的执行。任务的执行包括两部分：执行环境加上执行数据。 
　　执行环境往往包括Windows系统自带的一些程序，包括Copy、XCopy等Shell命令，也有系统中已经安装的程序，如Delphi、VC、SVN等。而执行数据，则是指我们的输入。由于我们要实现在执行中不存在界面交互，那么就必然要求我们将所有需要交互的信息一次性地输入。与此同时，我们的环境程序，也必须同时支持此种模式(一般情况下，这种模式称为命令行模式)。 
　　对于使用FinalBuilder人来讲，就有必要了解相关程序的命令行调用方式。这样有助于我们使用和编写任务。如果是我们自己研发一个程序，那么因为要使用到FinalBuilder中来，也有必要支持命令行模式。 
　　在FinalBuilder中，最主要的还是顺序流程，当然它也支持条件、分支、循环。最新的版本还有多线程协同，不过在使用初期，主要还是以顺序流程为主。 
　　最关键、最基础的就是Run DoSCommand和Execute Programe两个任务了。有了这两个，几乎可以完成任何事情。当然，FinalBuilder还提供了很多现成的控件，使得你可以通过配置(而不是命令行)来编写任务，这大大降低了使用难度。不过，不可避免的会有一些需求需要我们自己编写命令行，因此这两个任务必须掌握。 
　　FinalBuilder的自动执行，是使用Windows的计划任务来完成的。在其菜单中有生成计划任务的功能。顺便说一句，FinalBuilder本身也一样支持命令行模式，因此多个FinalBuilder之间，可以互相调用。这对我们的自动化非常有利。 
　　在经过简单的介绍后，我们发现，使用FinalBuilder确实可以帮助我们解决问题。 

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