软件世界对自动化完全疯狂。也许要感谢 DevOps，如果有的话，这种狂热正在增加。一些公司正在取消测试人员的角色，转而支持具有编程经验的工具匠，他们可以构建框架；有时这被称为“开发人员生产力”。这些公司使用的语言是一种替代语言；放弃人类以支持机器。
我想建议一种不同的语言：补充语言，我们认识到测试和编程是不同的，自动化解决某些类型的问题并创造其他问题。为了获得最佳结果，我们两者都需要。
让我们首先介绍测试和自动化的不同之处。
测试
在过去的几年里，我一直在为“ 软件测试” 的定义而奋斗。软件测试人员在实践中所做的与我们通常听到的来自学校系统的“测试”一词有很大不同。对于大多数人来说，从 5 岁到 20 岁出头的某个时间点，测试是一件有明显正确或错误答案的事情。老师和教授将问题组放在一起，通常是选择题或作文式的答案，通常是为了看看我们是否记得他们在课堂上和教科书上说过的内容。
在科学和软件领域，测试是不同的野兽。当我测试软件时，我在一个软件中进行实验并仔细观察。那么，测试是一种表演，是一种有技巧的事情——它不仅包括这些实验的设计，还包括根据上次测试的结果学习和改变我们的计划。例如 ， 域测试 是发现有关可能适用于或可能不适用于变量的数据类型的信息的好方法。不过，最重要的信息往往是靠运气以某种方式被发现的。
通常，我会发现自己在探索某个功能的某些方面并注意到一些有趣的事情。这种“有趣的事情”帮助我形成关于在一系列条件下发生的事情的想法，并指导我决定下一步做什么。
测试就是探索、观察、了解周围环境以及根据您的经验做出决定和判断。
检查
检查是 Michael Bolton 和 James Bach 用于表示我们使用的大多数测试工具执行的操作的词。他们创建的定义是：检查是通过将算法决策规则应用于产品的特定观察来进行评估的过程。我想稍微简化一下，说检查是关于软件产品的问题，可以用“是”或“否”来回答。测试工具非常适合执行检查，事实上，这就是它所能做的。
以下是您在自动化用户界面时可能会看到的示例：
Navigate to ebay.com
Log in with $user and $password
Assert you are returned to ebay.com
Assert text (“Hello ” + $firstname + ” !”) is displayed
每次您在该示例中看到
Assert
一词时，都表示将执行检查。该工具必须对“我是否已返回 ebay.com？”的问题进行比较并做出是或否的决定。和“登录后是否在主页上向我致意？”检查会精确地查看您识别的内容，而它们会完全忽略其他所有内容。检查不会观察、探索、学习或判断。它只是返回确认是否满足您预期的条件。
有时，我们尝试使用检查列表和非常详细的测试用例来重新创建此检查操作。
重复性
我看到创建检查的最大动机之一，它可以在单元级别、用户界面或两者之间运行，是能够重复完全相同的场景和问题集，只要你可以运行程序。或者，至少在您尝试测试的软件更改足以使检查无用之前。创建环境、数据库种子脚本和创建测试可能需要大量工作。但是一旦你在那里，重复测试通常是微不足道的。
可重复性通常也使得不太可能找到有关产品的新信息。
布赖恩马里克通过雷区的概念来描述这一点。想象一下，你面前有一个 雷区 ，当你踩到某个地方时就会爆炸。你现在不知道地雷在哪里，你只能走几条非常具体的路。当你走这些路时，你会发现几个地雷并将它们移除（希望不会被炸毁）。每次你在第一条之后走那条路，你不太可能再次在相同的地方找到地雷。
人们非常不擅长精确地重复步骤。当我在一家严重依赖详细测试脚本的公司工作时，尽管我的任务是遵循脚本并尝试像机器人一样，但我的眼睛和头脑一直在思考。这种偏离的需要是一件好事。在适当的时候脱离脚本意味着让自己接触新信息。
雷区想法支持这样一种想法，即除了运行可重复检查以确认我们认为我们知道的内容之外，人们还应该探索和测试以发现新信息。
时间投资
从测试中获取信息所需的时间发生在一个范围内。在“尽可能快地键入”这一范围的一端是所谓的 快速攻击 。快速攻击是一种几乎不需要设置或计划的测试方式。您可以执行它们并观察会发生什么。这听起来可能微不足道，但它们非常强大，因为您可以如此快速地运行它们，而且它们往往会产生大量错误。我在 Excelon Development 的同事 Matt Heusser 喜欢指出，一个“训练有素”、高度成熟的程序员，尤其是结对工作的程序员，可以自己发现其中的大部分错误。就目前而言，这当然是真的。与我合作的大多数公司都雇用了他们，因为它们还不是很成熟……还没有。
除了快速攻击之外，还有许多技术可以对需求、平台甚至代码进行更详细的分析。这些“频谱的另一端”技术需要时间来设计、特殊的数据条件，并且通常在我们可以运行测试并获得结果之前设置条件。
自动检查本身需要大量的设置时间；必须有人编写代码或至少使用工具进行记录和检查。我敢说，通过检查从想法到信息的绝对最快速度接近通过人工测试获得的最慢速度。创建检查后，假设您想多次运行它们，您将不得不担心如何使它们与您的产品同步并针对您的产品运行。使用工具创建支票通常就像创建一个与您销售的软件项目并行的软件项目。
偶尔，我看到工具辅助测试被用作减少或取消所有测试部门的理由。如果您没有花费大量时间重构组件架构，您可以在其中快速打开和关闭功能，也没有创建复杂的监控系统来发现出现问题的情况，那么繁重的检查策略可能不适合您。即使您是，上下文也很重要，例如，有很多生命攸关的系统，我不会冒险。
你会注意到替代的微妙想法再次出现在对话中。它很强大。但我认为我们可以做得更好。如果测试需要大量可以编写脚本的设置，并且我们 希望多次运行它 ，那么我们可以在代码中执行此操作，或者也可以使用 - 降低重新运行的成本。我们还可以使用检查将我们带到一个有趣的地方——例如，两个具有相同名称的用户，或者在我们尝试自己编辑页面时编辑页面，测试并发问题。 Michael Larsen 称之为“出租车测试”；脚本会比人类更快地将我们带到一个有趣的地方，然后我们跳出来进行测试。
黑天鹅
当你一生只看到白天鹅时，你不会想到黑天鹅的到来。这个想法，即只有白天鹅的存在并不能反驳黑天鹅的存在，是中世纪逻辑课的一个例子……直到 1697 年 Willam De Vlamingh 在澳大利亚 发现黑天鹅 。
“黑天鹅事件”让我们大吃一惊。事后看来，它们似乎很明显，但很难预先预测。我们无法想象的事情，比如 风暴摧毁了亚马逊主要数据中心的电源， 或者更糟的是，大地震后的 海啸 引发了核灾难，可能会产生巨大的影响。
重复运行的检查一遍又一遍地询问相同的问题。根据定义，他们几乎无法找到黑天鹅。测试是一种让人们能够发现黑天鹅的策略，有时是故意的。这里的事情变得有点复杂。检查可以嵌入到测试中。这意味着，可以运行检查，然后一个人可以使用该检查的结果来学习一些有趣的东西，然后开始调查——就像我们的出租车示例。因此，即使检查无法发现重大问题，审查该检查结果的人也可能获得发现问题所需的信息。
如何谈论这个
“检查”和“测试”这两个词是经过精心挑选的，但这个话题在很大程度上植根于哲学和社会科学。特别是哈里·柯林斯 (Harry Collins) 在他的著作 《行动的形态》(The Shape of Actions ) 和 《隐性和显性知识》(The Shape of Actions) 中的著作。阅读有点枯燥和学术。然而，有一些实际意义可以用于日常工作。人们执行的软件测试是一种用于发现产品的新的和重要的东西的策略。
支票可能在某种程度上帮助这些人，但它们本身只能对简单的问题回答是或否。
