下面，更多多的讲授 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 接口，如果你绝可能早的在产品设计阶段提生产品的可测试性设计需求，将来的测试工作中，你非常可能成功。绝可能早的开动自动化测试项目，提出可测试性需求，会使你行背自动化测试成功之道。

　　步骤五：具有可延续性的设计

　　在启篇的故事中，我们望到因为自动化工程师把注意力仅仅集中在怎样使自动化运转止来，导致测试自动化达不到预期的后果。自动化测试是个临时的进程，为了和产品新版原的功效和其他相干改动坚持分歧，自动化测试须要不停的保护和扩充。自动化测试设计中斟酌自动化在将来的可扩充性是非常要害的，不外，自动化测试的完全性也长短常主要的。假如自动化测试程式讲演测试用例执行通过，测试人员应当置信失掉的解因，测试执行的实践成果也当当是通过了。实在，有非常多具有答题的测试用例外表上执行通过了，真际上却执行失利了，并且没有记载一切差错日志，这便是失败的自动化。这类失败的自动化会给整个项纲带来灾害性的效果，而当测试人员构修的测试自动化采纳了非常糟糕的设计计划或由于当时的修正引进了过错，皆会导致这种失败的测试自动化。失败的自动化通常是由于没有闭注自动化测试的机能或者没有充足的自动化设计招致的。

　　性能： 提高代码的机能往往增添了代码的庞杂性，因此，会要挟到代码的可靠性。非常少有人关怀怎么对自动化自身加以测试。通过我对测试套性能的分析，非常多测试套都是花省大批的时间等待产品的运转。因此，在不提高产品运行性能的条件下，无法更有效的提高自动化测试执行效力。我疑惑测试自动化工程师只是从计算机课程了解到应该关注软件的性能，而并没有实际的操作经验。如果测试套的性能问题无法篡改，那么应该考虑提高硬件的性能;测试套中经常会出现冗余，也能考虑掏出测试套中的冗余或减少一个测试套中完成的测试任务，都是非常好的方法。

　　便于分析： 测试自动化执行失败后应该分析失败的结果，这是个辣手的问题。分析执行失败的自动化测试结果是件困难的事情，需要从多方面动手，测试上报的告警信息是真的还是假的?是不是因为测试套中存在缺陷导致测试执行失败?是不是在搭建测试环境中出现了错误导致测试执行失败?是不是产品中确凿存在缺陷导致测试执行失败?有几个方法能帮助测试执行失败的结果分析，某些方法能找到问题所在。通过在测试执行之前反省罕见的测试环境搭建问题，从而提高测试套的可靠性;通过改进错误输出报告，从而提高测试自动化的错误输出的可分析性;此外，还能改进自动化测试框架中存在的问题。练习测试人员怎么分析测试执行失败结果。以至能找到那些不可靠的、冗余的或功能比较独立的测试，然后平安地将之删除。上面这些都是减少自动化测试误演讲警、提高测试可分析性的积极有效的方法。另外，有一种错误的测试结果分析方法，那就是采用测试结果后处置程式对测试结果自动分析和过滤，尽管也能采用这种测试结果分析方法，不过这种方法会使自动化测试系统复纯化，更首要的是，后处理程式中的 BUG 会严峻侵害自动化测试的完整性。如果由于自动化测试本身存在的缺陷误把产品中的正常功能视为非常，那该怎么办?我原来看到测试小组花费研发测试自动化两倍的时间来修改测试脚本，并且不愿意开展培训过程。那些仅仅关注非常浅层次测试技术的测试治理者对这种方法非常感兴致，他们排挤采用隐蔽测试繁杂度的方法。

　　综上所述，应该集中精神关注能延续使用的测试套，从以下几方面考虑，测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。

　　可读性： 非常多情形下，在测试人员开端测试项目之前，公司已有了一套测试脚本，并且已具有非常多年了。我们能称之为 “ 聪慧的橡树 ”(wise oak tree)[Bach 1996] 。自己非常依赖他，不外并不晓得他是什么。因为 “ 聪亮的橡树 ” 类型的测试脚原缺少可读性，正在详细利用中，那些脚本经常出有多大的适用价值，越来越让己困惑。因而，测试职员非常难确定他们实践在测试什么，反而会招致测试人员对于本身的测试才能有功高的估量。测试人员可以检视测试脚本，并且理解测试脚本毕竟测试了什么，这长短常要害的。佳的白件是解决答题的手腕之一，对测试脚本齐方面分析是另外一个手法。由上里两种办法能引申出其他的相干法子，人本来在一个项纲中使用过引申之后的方式。在测试脚本中拔桩，把一切执行的产品相闭的命令记录到日志里。这样，该剖析日志肯定执止了哪些产品命令，命令采取了何类参数设放时，能降求一个十分好的测试忘录，里面记载了自动化测试施行了什么，没有执行什么。假如测试足本可读性没有好，非常轻易变得过火依好并没有完整懂得的测试脚本，非常容易以为测试脚本真际上做的工作比您念象中的还要多。测试套的可读性进步后，能更轻易的展开同行评审运动。