上下文驱动的自动化测试方法（一）
作者：James Bach，Michael Bolton
审稿人：Tim Western，Alan Page， Keith Klain， Ben Simo，Paul Holland， Alan Richardson，Christin Wiedemann， Noah Sussman...
在这篇白皮书中，我们提供了一个测试自动化的远景，它将测试人员置于测试的中心，同时促进一种为有可以解决我们许多事情的工具而开心的思考方式，并且，我们积极使用工具而不放弃我们作为技术人员的职责依然在测试工作的主导地位。
工具是很强大的，而且我们可以说出有关它们的激动人心和有用的东西。但“自动化”会暗藏危机、不可信任——不仅仅是因为标签”自动化”指的是一堆不一样的东西。因此，我们必须从清醒的角度来看清一些对“自动化”的基本误解。“自动化”很可能给困难的工作、甚至最好的时光带来可怕的浪费、混乱和痛苦。如果您需要好的测试，那么好的工具支持将是测试蓝图的一部分，这意味着您必须理解为什么我们的工具出了问题。
机器人，帮帮忙！
我们可以将测试自动化的主要观点概括为“通过使用户自动化操作来完成自动化测试”。 我们并没有声称人们真的会这样做，只是他们试图去做。我们在简化测试上发现至少三个重大问题：
“自动化”这个词是有误导性的。我们不可能使用户自动化。我们将他们做的一些行为进行自动化处理，用户实际上做得比这多得多。
输出检查可以自动进行，但测试人员做的远不止这些。
自动输出检查很有意思，但是工具的功能远不止于此。
自动化带来了易于接受和易理解的事：用可靠、快速、高效的机器人取代凌乱、复杂的人力！考虑旁边的图片，它完美地总结了令人印象深刻的愿景：“自动化完成无躁乏味的事物”。好，那么图片给我们带来什么启示？
它向我们展示了一台旨在当作人的机器。机器人被构造成人形机器人。它正在使用一种通常由人类操作的工具，其方式与人类操作它的方式完全相同，而不是通过更适合机器人的方式。图片里没有描述对机器人进行编程或控制机器人的过程，或者在发生错误时纠正机器人的过程。背景中没有毁坏的的机器人，没有人的角色，即使在背景中也没有人出现。图片传递的信息是：机器人在不改变过程本身的情况下，取代人类无趣的任务，并且没有任何人类存在、指导或表达工作意图的痕迹。那这是什么自动化？它是如何工作的？没有！
当然，这是一幅轻松的漫画，不太需要认真对待。问题是，在我们遍布整个行业的观察中，我们看到客户用这个卡通里的形式看待真正的测试、真正的自动化以及真正的人。因此，来自这方面有着非常深的误解。
有多严重？在作者的经验中，观察80年代的项目，我们发现，很常见到对自动化尝试检测琐碎且明显的GUI级错误上浪费了他们的预算，浪费了许多时间和精力本应该用来寻找其他严重而微妙的问题——我们称之为深层问题。此外，典型的自动化方法具有Rube Goldberg机器的特点。非常需要依赖关系，
并且很容易崩溃。这种自动化几乎成为项目的一个新的利益相关者；就像某些特别爱干净的强迫症女患者，如果房间不是一尘不染，她是不会进入房间。我们相信，在大多数情况下，相对直接投资给以复杂和社会的方式与产品交互的人们(也发现了浅层的bug)，或投入到更便宜的支持工具中帮助测试人员更好地测试，投资于自动化是更好。
没有人能否认自动化工具用于销售的演示令人印象深刻。我们所否认的是，人们对“自动化”的理解，应该是什么，以及这些用来销售的样品演示如何转化为可被大众用在普通项目里的实用价值。
“自动化”的麻烦
“测试自动化”的问题始于单词本身。测试是在“设计工作室”中发生的创造性和关键的工作中的一部分，但是“自动化”鼓励人们去思考在“工厂的地板”上完成机械化装配线的工作。
“测试自动化”这个术语的含义也不明确。听到有人说像“运行自动化测试”这样的句子是很常见的，其实这个术语是专门指测试工具的。像“测试自动化是值得去做的”这样的句子不仅是对工具，也对创建、维护、测试和操作那些工具的企业是成立的。在第一层意义上，测试自动化根本不像人类的行为。它非常快而且便宜，因为你不用支付给电脑费用。在第二种意义上，测试自动化是一种由编写和操作软件的人在数小时、几天或几周内完成的技术性活动——你必须为这些人的时间付费。
我们观察到，按照一般的说法，“测试自动化”的驱动策略是编写产品使用者的普通的、机械的行为，并且那个使用者是一个相当自满的、缺乏想象力的用户，然后让机器以令人眼花缭乱的速度敲击键盘，然后检查指定的动作和输入是否产生指定的输出。由此得出，开始将“测试自动化”看作是一种测试人员的测试工具只是一小步。但即使是一个低技能的人类测试人员做的也远远多于盲目遵守规定的这些动作，而且观察到的也远远超过某些功能的输出。人类有复杂的生活、议程、天赋、想法和问题。虽然可以模拟某些用户和测试人员的操作，但用户和测试人员自己却不能在软件中被复制。未能理解这一点简单的事实将会使测试变得琐碎，并且会让许多bug逃过我们的注意。
我们怎么能更清楚地思考这些呢？
第一：称它们为工具（而不是“测试自动化”）
我们将工具定义为任何有助于实现人类目的的人类发明。一个测试工具可以是软件、硬件、地图、文件或工件，或者其他一些辅助实现测试目的的启发式方法。在此，我们主要关注的是基于软件的工具。
“测试工具”一词让我们与普通的日常理解联系起来，即这些发明在没有人类指导的情况下是无法工作的，他们扩展了适当技能的人类的能力。此外，“工具”打开了许多可以减轻负担和增强测试人员能力的方法的大门。
与此同时，“测试自动化”这个术语可能会使人们脱离工作。要理解为什么，你必须考虑测试是什么。测试是去寻找产品的真实状态，而在复杂的产品中，它是隐藏在随意的视图中。测试人员这样做是为了发现问题。一个测试人员，在有限的资源下工作，必须在期限之前找出问题。这需要在快速和持续的学习过程中，仔细注意产品行为中的微妙线索。测试人员所从事的意识形成、批判性思考和实验，这些都不能通过机械手段完成。然而，在我们的长期访问中，访问了数百家公司和团队，我们发现那些将自动化测试当口头禅一样经常说的测试经理和技术专家，经常忽略这些知识过程。我们试着提醒他们——以及他们的同事——有时这些关键元素不能编码到测试用例或测试软件中。“哦我们同意，”他们可能会说，但是马上又回到了讲话中，就好像测试的本质在某种程度上表现在他们的“测试自动化”中一样。经过多年的斗争，我们得出结论，这个词本身就是一种麻醉剂。
计算机软件严格地由显式编码的模式组成。任何有价值或重要的行为模式都不会发生，除非它是用代码来表达的。这是显而易见的。不太显而易见的是，告知人类测试人员行为的大部分都是隐性知识。（然而，显性知识是指任何被表示为一串比特的知识，隐性知识是指没有或不能被这样代表的知识。）
当一个测试人员与产品交互时，他自发地对各种令人惊讶和错误的事件做出反应，却不会意识到对它们的期望。例如，如果一个窗口变为紫色，或者一根额外的线出现了，或者一个过程在十次中有一次花了更长的时间来完成，他几乎毫不费力地就会注意到并有所反应。但是当这个测试员讲述这个测试的故事时，也许通过写下它的步骤和预期的结果，只有一小部分真实的期待被表达出来了。没有测试人员会编码无意识的期望或意料之外的行为。因为既然测试是人类实际上无法用语言来表达的，那么它们也不能被编码，不能被自动化。我们不应该使用一种术语暗示它可能可以。
每个人都知道编程不能自动化。尽管许多早期的编程语言被称为“自动编码”，早期的编译器被称为“自动编码”，这种说法在1965年前后的3年时间达到高峰。“编译器”一词变得更加流行。换句话说，当软件开始被编码时，他们将该活动的名称改为编译、汇编或解释。这样一来，程序员就成了一个总是坐在所有技术之上的人，没有一个经理会说“我们什么时候可以自动化所有这些编程？”
为了生产高质量的产品和服务，我们需要有技术的人使用合适的工具来完成测试的任务。使用术语“手动测试人员”或“自动化测试人员”来区分测试人员是一种误导，因为所有有能力的测试人员都使用工具。程序员和研究人员也使用工具，但是没有人提到“自动编程”或“自动化研究”。没有哪个经理会要求自动化测试来自动化代替他的管理。人们认为自动化测试很有趣的唯一原因是，他们真的相信测试不需要技巧或判断。
由于所有的测试人员都使用工具，我们提议一个更有趣的区别是，一些测试人员也会编写工具——编写代码并开发工具来帮助测试。我们建议将这些技术测试人员称为“toolsmiths（工具匠？）”。尽管toolsmiths和他们的工具有助于扩展、加速，并加强测试中的某些活动，但它们不会自动进行测试。 因此，从这一点就可以说明，我们将尽量避免使用术语“测试自动化”。
第二：认为测试远远好过输出检查
我们说：测试是通过探索和实验来了解产品的评估，这在一定程度上包括：质疑、研究、建模、观察和推断等。
我们用词必须谨慎。测试必然是一个人类执行的过程，只有人类才能学习，只有人类才能决定价值。价值是一种社会判断，不同的人对事物价值的看法是不同的。技术人员可能认为他们可以通过将需求编码为脚本来自动评估需求，但是评估是直到它被人类审查前都是临时和不完整的。几乎总是有这样的情况，经理说“该工具报告了一个错误，但在这种情况下确实不是问题。”
探索是我们对测试的定义的核心，因为我们在找到bug之前都不知道bug在哪里。的确，对于任何新产品，我们都必须找到可以寻找到问题的地方，而还有太多地方需要我们去检查全部。我们甚至不知道什么算是bug，这是一个在项目过程中会改变和转换的判断过程。我们强调实验，因为好的测试实际上是科学意义上的实验。在任何人都不知道软件会是什么，或者是什么的300年以前，“自然哲学家”会通过他们的实验系统地测试自然。科学家的实验的意义正是我们所说的测试。测试必然是一个渐进的、投机性的、自我导向的搜索过程。
最后，在文章最后的“等等”是一个信号，意味着——测试包含了许多其他与分析相关的活动和学科。那些不是测试自身的活动，比如研究规范，会在测试目的完成时进行测试。
让我们进一步分解测试。当测试的时候，我们具体做什么？测试是一种包括几种正在进行的并行活动的性能：
我们通过学习和建模产品来设计我们的测试，确定测试条件来覆盖，生成特定的测试数据，识别和发展Oracle（即我们遇到问题时识别问题的手段，测试预言），并建立探索和实验的程序。
我们通过配置、操作和观察产品来与产品交互。
我们使用适当的test Oracle来评估产品，以发现产品/品质和我们认为理想中的不一致。
我们记录并报告已完成的测试工作。
我们管理测试工作，包括了解测试的现状，分析产品风险，确定和分配测试任务。
所有这些活动都可以通过工具得到帮助。
区分检查和测试
我们发现有必要来区分检查（check）和测试（test）。检查是一个通过将算法决策规则应用于产品的具体观察来进行评估的过程。这与测试的其余部分是不同的：它可以是完全自动化的。因此检查是可以使用“自动化”这个词的。
在测试中，设计和执行帮助我们理解产品的状态的实验。这种理解是一种解释、一个评估，但不是事实。简单的事实可以说是“可证实的”，但质量绝不是一个简单的事实。质量是一个正在工作的假设。当你使用软件并没有发现某个具体问题时，你没有证明或证实“它成功运行了”。你所知道的只是你还没有遇到到失败。你所证明的就是产品能运行。这项产品可能会以一种你没有或无法察觉的微妙方式失败。也许现在还行，但十分钟后就不行了。那么，它真的，可以，深入地工作吗？没有输出检查可以告诉你如此。没有输出检查的收集可以告诉你如此。
事实上，任何广告商、深夜电视广告员或者舞台魔术师都可以向你展示某些东西似乎在起作用。作为测试人员，我们的工作不是服从广告，直接接受这个结论，或者相信戏法。我们的工作是找出广告遗漏了什么产品不符合要求的地方，或者魔术师是如何欺骗我们的。虽然例行的输出检查是我们工作的一部分，我们不断地重新进行非常规的、新奇的观察。我们的态度一定是寻找问题，而不是核实问题的缺失——否则我们只能以浅薄的方式进行测试并使我们对产品的本质视而不见。
评估质量是一项需要熟练，复杂，非算法性调查和判断的任务。这个任务可以通过工具来支持和加速，但是不能由工具本身来执行。
检查是很重要的
良好的检查是测试的一个子集。检查和测试不一样就好像咬人和吃东西，轮胎和汽车是不一样，拼写和编辑是不一样的。良好的检查始终是设计、实施和解释这些人为活动检查过程中的产物，这些构成了测试。测试给了检查价值和意义。然而，检查保持测试的基础。
自动检查是测试的一种策略，并且相当具有价值。对自己的代码采用自动检查的程序员可以提供快速、低成本的反馈。通过图形用户级别下的API进行检查是非常有用的。在设计这种低级别的检查中，程序员和测试人员可以在一起进行有益的工作。
我们更怀疑在GUI级别自动检查。在图形用户层面上测试是出了名的挑剔，因为非技术人员可以看到并讨论它们，GUI比只有程序员看到的底层接口更容易变化，这可能导致巨大的、高成本的只是为了保持简单的检查运行维护工作。此外，图形用户界面的设计是为了让人们感到自然和舒适，而不是为了其他软件。您可能需要一名熟练的全职程序员来维护所有尝试模拟快速但不熟练的人体测试人员所需的代码。这可能不是一个省钱的办法。
第三：探索使用工具的多种方法！
单独测试人员的技能集和思维方式是负责工具使用的核心。然而，当我们说到这一点时，一些人似乎以为听到我们说工具不重要，或者上下文驱动的测试人员讨厌工具。没有什么比这更偏离真相了。