今天，很多软件产品部提供可以用来实现测试的编程接口（公共API）。没有提供编程接口的软件产品可能有不公开的接口(私用API)，如果提出要求设计者会提供。所以，如有需要应提出要求。

公共API作为软件产品的一部分要写入文档。公共API不会有很大变化，其稳定性对测试自动化很有吸引力。私用API会极为有用，但是要确定其稳定性如何。

由于没有注意到这些API，很多测试自动化设计人员都关注可见性最好的GUI。可悲的是，GUI通常是最困难的测试自动化接口。几乎所有编程接口都更容易使用，即更稳定、更可靠①。在前面介绍的经验中，已经讨论了有关GUI自动化问题，并提出了一些处理策略建议。但是最好的方法还是完全避免使用GUI。编程接口更可能提供稳定性，而且还有利于错误检测和隔离。

当我们检查所观察的很多产品测试工作时，发现是否提供编程接口与开发强有力的自动化测试包之间有很强的相关性②。编程接口包括API、命令行接口、COM接口、HTTP等，所以测试员需要学习不同的语言和技术。不要期望程序员会对测试工作指导，没有几个程序员是有耐心的，有时间的程序员就更少了。如果真想搞好测试自动化，就必须学习或找了解这些编程接口的人帮忙。

即使GUI测试自动化设计人员也发现需要学习GUI技术细节。在技术层上，GUI实际上比其他接口技木还复杂。设计人员总要通过某种方式学习自动化测试所使用的接口技木细节。设计人员要做出选择。我们认为GUI应该放在选择表的最后。

以下是一个简单例子。很多人要我们就使用GUI测试工具自动化安装器提出建议。最好的方法就是放弃这样的工具。很多安装器都有提供更好方法的脚本接口。例如，InstallShield是很流行的安装系统，用来为很多产品创建了安装器。很多测试员不知道可以运行InstallShield安装器，通过选项记录所选择的安装远项。这些数据记录在应答文件中。以后安装时，安装器可以使用应答文件自动确定安装选项。这很容易、很便宜，应答文件也很简单、易读、易编辑。这是自动化安装的一种效费比很高的方法(请参阅“创建无交互自动安装”，http://support.installshield.com/kb/display.asp?documents_id=101901)。

① Paul Szymkowiak不同意这种观点，“我的经验与此不同。我发现很多用户界面比可用的编程接口更稳定——当然是从测试自动化的观点看。原因可能是用户界面对于客户是看到的，并在培训材料中使用，印在用户手册中。因此，适应不断变更用户界面的成本更高。我曾经与一些项目经历交流过，他们会在等效的编程接口‘冻结’之前，首先要求很好地冻结用户界面。很多编程接口文档都编写得不好，因为程序员是预想用户，软件提供商/开发人员都不会在乎编程接口的不断改变。我还发现很多编程接口错误严重，与用户界面一般预期的‘可使用性门限’相比，编程接口的可使用性门限更低。”

② Douglas Hoffman的经验与此类似，“我取得的最大成功是在一个著名的桌面出版软件包上。其引擎是不可见的，产品要通过其所见即所得GUI了解。由于计划要在n+1版本上彻底检查用户界面，我们完全避免了自动化GUI测试，而是使用公共API实现功能测试自动化，并手工测试GUI。我们发现了大量缺陷（大多数都是在自动化测试时发现的），通过功能测试可以容易得多地确定GUI问题。”

但是现在测试的不是GUI！要把注意力集中到帮助最大的测试自动化上。有时可以有效地自动化GUI测试，有时则不能。不要让别人关于自动化测试应该是什么的先入之见束缚自己。