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

　　软件产品一般会用到下面三种不同类别的接口：命令行接口（ 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 接口，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，未来的测试工作中，你很可能成功。尽可能早的启动自动化测试项目，提出可测试性需求，会使您走向自动化测试成功之路。

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

　　在开篇的故事中，我们看到由于自动化工程师把注意力仅仅集中在如何使自动化运转起来，导致测试自动化达不到预期的效果。自动化测试是一个长期的过程，为了与产品新版本的功能和其他相关修改保持一致，自动化测试需要不停的维护和扩充。自动化测试设计中考虑自动化在未来的可扩充性是很关键的，不过，自动化测试的完整性也是很重要的。如果自动化测试程序报告测试用例执行通过，测试人员应该相信得到的结果，测试执行的实际结果也应该是通过了。其实，有很多存在问题的测试用例表面上执行通过了，实际上却执行失败了，并且没有记录任何错误日志，这就是失败的自动化。这种失败的自动化会给整个项目带来灾难性的后果，而当测试人员构建的测试自动化采用了很糟糕的设计方案或者由于后来的修改引入了错误，都会导致这种失败的测试自动化。失败的自动化通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。

　　性能： 提高代码的性能往往增加了代码的复杂性，因此，会威胁到代码的可靠性。很少有人关心如何对自动化本身加以测试。通过我对测试套性能的分析，很多测试套都是花费大量的时间等候产品的运行。因此，在不提高产品运行性能的前提下，无法更有效的提高自动化测试执行效率。我怀疑测试自动化工程师只是从计算机课程了解到应该关注软件的性能，而并没有实际的操作经验。如果测试套的性能问题无法改变，那么应该考虑提高硬件的性能；测试套中经常会出现冗余，也可以考虑取出测试套中的冗余或者减少一个测试套中完成的测试任务，都是很好的办法。

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

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

　　可读性： 很多情况下，在测试人员开始测试项目之前，公司已经有了一套测试脚本，并且已经存在很多年了。我们可以称之为 “ 聪明的橡树 ”(wise oak tree)[Bach 1996] 。大家很依赖它，但是并不知道它是什么。由于 “ 聪明的橡树 ” 类型的测试脚本缺乏可读性，在具体应用中，那些脚本常常没有多大的实用价值，越来越让人迷惑。因此，测试人员很难确定他们实际在测试什么，反而会导致测试人员对自身的测试能力有过高的估计。测试人员能够检视测试脚本，并且理解测试脚本究竟测试了什么，这是很关键的。好的文档是解决问题的手段之一，对测试脚本全面分析是另外一个手段。由上面两种方法可以引申出其它的相关方法，我曾经在一个项目中使用过引申之后的方法。在测试脚本中插桩，把所有执行的产品相关的命令记录到日志里。这样，当分析日志确定执行了哪些产品命令，命令采用了何种参数配置时，可以提供一个非常好的测试记录，里面记录了自动化测试执行了什么，没有执行什么。如果测试脚本可读性不好，很容易变得过分依赖并没有完全理解的测试脚本，很容易认为测试脚本实际上做的工作比你想象中的还要多。测试套的可读性提高后，可以更容易的开展同行评审活动。

　　可维护性： 在工作中，我曾经使用过一个测试套，它把所有的程序输出保存到文件中。然后，通过对比输出文件内容和一个已有的输出文件内容的差别，可以称已有的输出文件为 “ 标准文件 ” （ “gold file” ）。在回归测试中，用这个方法查找 BUG 是不是明智之举。这种方法太过于敏感了，它会产生很多错误的警告。随着时间的推移，软件开发人员会根据需要修改产品的很多输出信息，这会导致很多自动化测试失败。很明显，为了保证自动化测试的顺利进行，应该在对 “ 标准文件 ” 仔细分析的基础上，根据开发人员修改的产品输出信息对之做相应的修改。比较好的可维护性方法是，每次只检查选定的产品的某些特定输出，而不是对比所有的结果输出。产品的接口变动也会导致原来的测试无法执行或者执行失败。对于 GUI 测试，这是一个更大的挑战。研究由于产品接口变化引起的相关测试修改，并研究使测试修改量最小的方法，测试中采用库是解决问题的方法。当产品发生变化的时候，只需要修改相关的库，保证测试与产品的变动同步修改即可。

　　完整性： 当自动化测试执行后，报告测试执行通过，可以断定这是真的吗？这就是我称之为测试套的完整性。在前面的故事中，当没有对自动化测试完整性给予应有的关注的时候，发生了富有喜剧性的情况。我们应该在多大程度上相信自动化化测试执行结果？自动化测试执行中的误报告警是很大的问题。测试人员特别讨厌由于测试脚本自身的问题或者是测试环境的问题导致测试执行失败，但是，对于自动化测试误报告警的情况，大家往往无能为力。你期望自己设计的测试对 BUG 很敏感、有效，当测试发现异常的时候，能够报告测试执行失败。有的测试框架支持对特殊测试结果的分类方法，分类包括 PASS ， FAIL 和第三种测试结果 NOTRUN 或者 UNRESOLVED 。无论你怎么称呼第三种测试结果，它很好的说明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到正确的测试结果是自动化测试完整性定义的一部分，另一部分是能够确认执行成功的测试确确实实已经执行过了。我曾经在一个测试队列中发现一个 BUG ，这个 BUG 引起测试队列中部分测试用例被跳过，没有执行。当测试队列运行完毕后，没有上报任何错误，我不得不通过走读代码的方式发现了这个 BUG 。如果，我没有关注到这个 BUG ，那么可能在认识到自动化测试已经出现问题之前，还在长时间运行部分测试用例。

　　独立性： 采用自动化方法不可能达到和手工测试同样的效果。当写手工测试执行的规程时候，通常假定测试执行将会由一个有头脑、善于思考、具有观察力的测试人员完成的。如果采用自动化，测试执行是由一台不会说话的计算机完成的，你必须告诉计算机什么样的情况下测试执行是失败的，并且需要告诉计算机如何恢复测试场景才能保证测试套可以顺利执行。自动化测试可以作为测试套的一部分或者作为独立的测试执行。测试都需要建立自己所需要的测试执行环境，因此，保证测试执行的独立性是唯一的好方法。手工回归测试通常都相关的指导文档，以便一个接着一个有序地完成测试执行，每个测试执行可以利用前一个测试执行创建的对象或数据记录。手工测试人员可以清楚地把握整个测试过程。在自动化测试中采用上述方法是经常犯的错误，这个错误源于 “ 多米诺骨牌 ” 测试套，当一个测试执行失败，会导致后续一系列测试失败。更糟糕的是，所有的测试关联紧密，无法独立的运行。并且，这使得在自动化测试中分析合法的执行失败结果也困难重重。当出现这种情况后，人们首先开始怀疑自动化测试的价值。自动化测试的独立性要求在自动化测试中增加重复和冗余设计。具有独立性的测试对发现的缺陷的分析有很好的支持。以这种方式设计自动化测试好像是一种低效率的方式，不过，重要的是在不牺牲测试的可靠性的前提下保证测试的独立性，如果测试可以在无需人看守情况下运行，那么测试的执行效率就不是大问题了。

　　可重复性： 自动化测试有时能够发现问题，有时候又无法发现问题，对这种情况实在没有什么好的的处理办法。因此，需要保证每次测试执行的时候，测试是以同样的方式工作。这意味着不要采用随机数据，在通用语言库中构造的随机数据经常隐藏初始化过程，使用这些数据会导致测试每次都以不同的方式执行，这样，对测试执行的失败结果分析是很让人沮丧的。这里有两个使用随机数据发生器的的方法可以避免上述情况。一种方法是使用常量初始化随机数据发生器。如果你打算生成不同种类的测试，需要在可预测，并且可控制的情况下建立不同类型的随机数据发生器。另外一个办法是提前在文件中或数据库中建立生成随机测试数据，然后在测试过程中使用这些数据。这样做看起来似乎很好，但是我却曾经看到过太多违反规则的做法。下面我来解释到底看到了什么。当手动执行测试的时候，往往匆匆忙忙整理文件名和测试数据记录。当对这些测试采用自动化测试方法，该做哪些工作呢？办法之一是，可以为测试中使用的数据记录给固定的命名。如果这些数据记录在测试完成后还要继续使用，那么就需要制定命名规则，避免在不同的测试中命名冲突，采用命名规则是一种很好的方法。然而，我曾经看到有些测试只是随机的命名数据记录，很不幸，事实证明采用这种随机命名的方式不可避免的导致命名冲突，并且影响测试的可重复性。很显然，自动化工程师低估了命名冲突的可能性。下面的情况我遇到过两次，测试数据记录的名字中包含四个随机产生的数字，经过简单的推算如果我们采用这种命名方式的时候，如果测试使用了 46 条记录，会存在 10% 冲突的可能性，如果使用 118 条记录，冲突的几率会达到 50% 。我认为测试当中使用这种随机命名是出于偷懒的想法 —— 避免再次测试之前写代码清除老的数据记录，这样引入了问题，损害了测试的可靠性和测试的完整性。

　　测试库： 自动化测试的一个通用策略是开发可以在不同测试中应用的测试函数库。我曾经看到过很多测试函数库，自己也写了一些。当要求测试不受被测试产品接口变动影响的时候，采用测试库方法是非常有效的。不过，根据我的观察测试库已经使用的太多了，已经被滥用了，并且测试库往往设计的不好，没有相关的文档支撑，因此，使用测试库的测试往往很难开展。当发现问题的时候，往往不知道是测试库自身的问题，还是测试库的使用问题。由于测试库往往很复杂，即便在发现测试库存在问题，相关的维护人员也很不愿意去修改问题。通过前文中的论述，可以得出结论，在一开始就应该保证测试库设计良好。但是，实际情况是测试自动化往往没有花费更多的精力去保证一个优良设计的测试库。我曾经看到有些测试库中的功能根本不再使用了或仅仅使用一次。这与极限编程原则保持一致，即 " 你将不需要它 " 。这会导致在测试用例之间的代码出现一些重复，我发现微小的变化可能仍然存在，很难与测试库功能协调。你可能打算对测试用例作修改，采用源代码的方式比采用库的方式更容易修改。如果有几个测试，他们有某些共同的操作，我使用剪切和粘贴的方式去复制代码，有的人认为我采用的方法不可理喻。这允许我根据需要修改通用代码，我不必一开始尝试和猜测如何重用代码。我认为我的测试是很容易读懂的，因为阅读者不必关心任何测试库的语法。这种办法的优势是很容易理解测试，并且很方便扩展测试套。在开发软件测试项目的时候，大多数程序员找到与他们打算实现功能类似的源代码，并对源代码做修改，而不是从头开始写代码。同样，在写测试套的过程中可以采用上述方法，这也是代码开发方式所鼓励的方法。我比较喜欢写一些规模比较小的测试库，这些库可以被反复的使用。测试库的开发需要在概念阶段充分定义，并且文档化，从始至终都应该保持。我会对测试库作充分的测试后，才在测试中使用这些测试库。采用测试库是对所有面临的情况作权衡的。千万不要打算写一个大而全的测试库，不要希望有朝一日测试人员会利用你的测试库完成大量的测试，这一天恐怕永远不会到来。

　　数据驱动测试： 把测试数据写入到简单表格中，这种测试技术得到了越来越广泛的应用，这种方法被称为表驱动（ table-driven ），数据驱动 (data-driven) 或者 “ 第三代 ” 自动化测试（ "third generation" automation ）。这需要写一个解析器，用来解释表格中的数据，并执行测试。该测试架构的最主要的好处是，它允许把测试内容写在具有一定格式的表格中，这样方便数据设计和数据的检视。如果测试组中有缺少编程经验的业务专家参与测试，采用数据驱动测试方法是很合适的。数据驱动测试的解析器主要是由测试库和上层的少量开发语言写成的代码组成的，所以，上面关于测试库的说明放在这里是同样合适的。在针对上面提到的少量代码的设计、开发、测试的工作，还存在各种困难。代码所采用的编程语言是不断发展的。也许，测试人员认为他们需要把第一部分测试的输出作为第二部分测试的输入，这样，加入了新的变量。接下来，也许有人需要让测试中的某个环节运行一百次，这样加入一个循环。你可以采用其他语言，不过，如果你预料到会面临上述情况的时候，那么做好采用一些能够通过公开的渠道获取的编程语言，比如 Perl,Python 或者 TCL ，这样比设计你自己的语言要快的多。

　　启发式确认： 我曾经看到很多测试自动化没有真正意义上的结果校验，其原因有两个，一个原因是做完全意义上的自动化测试结果确认从技术上讲是很困难的，另外一个原因是通过测试设计规格很难找出自动化测试的预期结果。这很不幸。不过，采用手工校验测试结果的方法是真正意义上的测试校验。标准文件（ Gold file ）是另外一中校验测试结果的方法。首先，捕获被测试程序的输出，并检视程序的输出，然后，把输出信息文档化，并归档，作为标准文件。以后，自动化测试结果与标准文件作比较，从而达到结果校验的目的。采用标准文件的方法，也有弊端。当产品发生变化，自动化测试的环境配置发生变化，产品的输出发生变化的时候，采用标准文方法，会上报大量的误报告警。做好的测试结果校验方法是，对输出结果的特定内容作分析，并作合理的比较。有时候，很难知道正确的输出结果是什么样的，但是你应该知道错误的输出结果是什么样的。开展启发式的结果校验是很有帮助的。我猜想一些人在自动化测试中设计了大而全的测试结果校验方法，是因为担心如果结果校验漏掉了任何信息，可能导致自动化测试自身出现错误。不过，我们在测试过程中往往采用折衷的做法，没有采用大而全的测试结果校验方法，这样就不得不面对少量漏测情况的出现的风险。自动化测试不能改变这种情况的出现。如果自动化工程师不习惯采用这种折衷的方法，那么他必须找相关人员咨询，寻找一种合适的测试结果校验策略，这需要有很大的创造性。目前有很多技术可以保证在不产生误报告警的情况下，找到被测试产品的缺陷。

　　把注意力放在通过设计保证测试的可延续性上，选择一个合适的测试体系架构，你将进一步迈向成功的自动化测试。