自动化测试的7个步骤

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

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

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

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

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

<<上一页 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 下一页>>

数据挖掘实验室