软件测试自动化成功的7个步骤(4)

　　下面是一些候选的验证概念的试验：

　　回归测试：你准备在每个版本运行同样的测试用例吗?回归测试是最宜采用自动化测试的环节。

　　配置测试：你的软件支持多少种不同的平台?你打算在所有支持的平台上测试执行所有的测试用例吗?如果是的，那么采用自动化测试是有帮助的。

　　测试环境建立：对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。

　　非GUI测试：实现命令行和API的测试自动化比GUI自动化测试容易的多。

　　无论采用什么测试方法，定义一个看得见的目标，然后集中在这个目标上。验证你自动化测试概念可以使自动化更进一步迈向成功之路。

　　步骤四：支持产品的可测试性

　　软件产品一般会用到下面三种不同类别的接口：命令行接口(command line interfaces，缩写CLIs)、应用程序接口(API)、图形用户接口(GUI)。有些产品会用到所有三类接口，有些产品只用到一类或者两类接口，这些是测试中所需要的接口。从本质上看，API接口和命令行接口比GUI接口容易实现自动化，去找一找你的被测产品是否包括API接口或者命令行接口。有些时候，这两类接口隐藏在产品的内部，如果确实没有，需要鼓励开发人员在产品中提供命令行接口或者API接口，从而支持产品的可测试性。

　　下面，更多多的讲解GUI自动化测试相关内容。这里有几个原因导致GUI自动化测试比预期的要困难。第一个原因是需要手工完成部分脚本。绝大多数自动化测试工具都有“录制回放”或者“捕捉回放”功能，这确实是个很好的方法。可以手工执行测试用例，测试工具在后台记住你的所有操作，然后产生可以用来重复执行的测试用例脚本。这是一个很好的方法，但是很多时候却不能奏效。很多软件测试文章的作者得出结论“录制回放”虽然可以生成部分测试脚本，但是有很多问题导致“录制回放”不能应用到整个测试执行过程中。[Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999].结果，GUI测试还是主要由手工完成。

　　第二个原因，把GUI自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。经常要在采用众多专家意见和最新的GUI接口技术才能使GUI测试工具正常工作。这个主要的困难也是GUI自动化测试工具价格昂贵的主要原因之一。非标准的、定制的控件会增加测试的困难，解决方法总是有的，可以采用修改产品源代码的方式，也可以从测试工具供应商处升级测试工具。另外，还需要分析测试工具中的BUG，并且给工具打补丁。也可能测试工具需要做相当的定制，以便能有效地测试产品界面上的定制控件。GUI测试中，困难总是意外出现，让人惊奇。你也可能需要重新设计你的测试以规避那些存在问题的界面控件。

　　第三个原因，GUI设计方案的变动会直接带来GUI自动化测试复杂度的提高。在开发的整个过程中，图形界面经常被修改或者完全重设计，这是出了名的事情。一般来讲，第一个版本的图形界面都是很糟糕。如果处在图形界面方案不停变动的时候，就开展GUI自动化测试是不会有任何进展的，你只能花费大量的时间修改测试脚本，以适应图形界面的变更。不管怎样，即便界面的修改会导致测试修改脚本，你也不应该反对开发人员改进图形界面。一旦原始的设计完成后，图形界面接口下面的编程接口就固定下来了。

　　上面提到的这些原因都是基于采用GUI自动化测试的方法完成产品的功能测试。图形界面接口当然需要测试，可以考虑实现GUI测试自动化。不过，你也应该考虑采用其他方法测试产品的核心功能，并且这些测试不会因为图形界面发生变化而被中断，这类测试应该采用命令行接口或者API接口。我曾经看到有人选择GUI自动化测试，因为，他们不打算修改被测试产品，但是，最终他们认识到必须对产品做修改，以保证GUI测试自动化可以正常工作。无论你选择哪种方法，自动化都需要对被测试的产品做修改。因此，采用可编程的接口是最可靠的。

　　为了让API接口测试更为容易，应该把接口与某种解释程序，例如Tcl、Perl或者Python绑定在一起。这使交互式测试成为可能，并且可以缩短自动化测试的开发周期。采用API接口的方式，还可以实现独立的产品模块的单元测试自动化。

　　一个关于隐藏可编程接口的例子是关于InstallShield——非常流行的制作安装盘的工具。InstallShield有命令行选项，采用这种选项可以实现非GUI方式的安装盘，采用这种方式，从提前创建好的文件中读取安装选项。这种方式可能比采用GUI的安装方式更简单更可靠。

　　另一个例子是关于如何避免基于WEB软件的GUI自动化测试。采用GUI测试工具可以通过浏览器操作WEB界面。WEB浏览器是通过HTTP协议与WEB服务器交互的，所以直接测试HTTP协议更为简单。Perl可以直接连接TCP/IP端口，完成这类的自动化测试。采用高级接口技术，譬如客户端JAVA或者ActiveX不可能利用这种方法。但是，如果在合适的环境中采用这种方式，你将发现这种方式的自动化测试比GUI自动化测试更加便宜更加简单。

　　我曾经受雇在一家公司负责某个产品GUI相关的自动化测试，该产品也提供命令行接口，不过，他们已经实现了GUI的自动化测试。经过一段时间的研究，我发现找到图形界面中的BUG并不困难，不过，用户并不关注图形界面，他们更喜欢使用命令行。我还发现我们还没有针对最新的产品功能(这些功能即可通过GUI的方式，也可以通过命令行的方式使用)实现自动化测试。我决定推迟GUI自动化测试，扩展命令行测试套，测试新增的产品功能。现在回过头看这个决定，我没有选择GUI自动化测试是最大的成功之处，如果采用了GUI自动化测试所有的时间和努力都会浪费在其中。他们已经准备好做GUI自动化测试了，并且已经购买了一套测试工具和其他需要的东西，但我知道在开展具体的GUI自动化测试活动中，会遇到各种各样的困难和障碍。

　　无论你需要支持图形界面接口、命令行接口还是API接口，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，未来的测试工作中，你很可能成功。尽可能早的启动自动化测试项目，提出可测试性需求，会使您走向自动化测试成功之路。

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