改进测试和检查（Testing and Checking Refined）

发表于2013年3月26日

  这篇文章是我和迈克尔·波顿共同撰写的。我们几乎每一句话都花了好几个小时去讨论。同时感谢伊恩麦科华特做的快速审查和注解。
  测试和工具的使用是人类起源时就带有的2个特性（虽然不是只有这2个特性，但一定是人类许多特性中的其中2个）。 然而测试依赖头脑又有不确定性，所以工具的使用会比较开放。工具渗透进每一个接触到的领域并改变了这些领域。因此，几百上千年来引起我们更多思考的是：“是我在做还是工具在做？我是士兵或仅仅只是掷矛器？我是农民或仅仅只是推犁的？”正如马歇尔·麦克卢汉说：“我们创造了工具，然后工具塑造了我们”。
  这种演变是一个隐秘的过程，它挑战我们对自身和事物的定位。见证了工业化如何改变橱柜工人以及橱柜工厂，当然，橱柜工人不会全部变成流水线上的工人。他们中的少部分人在流水线外，在一个类似工厂的地方，制作一些昂贵又精致的橱柜。橱柜专家（我差点去goole是否有一个词适合橱柜专家）仍然有需求，他们可以解决一些IKEA解决不了的问题。这种情形在科学和医学领域也存在。各行各业都存在这样一种思考：工具的发展对技术工种有着怎样的影响？在行当里追求卓越的每一个人都必须善加利用工具。
  因此，我们对测试不要感到惊讶，它是一个涉及多种工具的过程，也挑战了测试人员的想法。
  从1987年起，我就一直在思考和探索这个问题，有关它的文献至少可追溯至1961年。一些新事物的诞生，那就是大规模的移动和分布式计算。在我看来，微机出现是对传统测试最大的挑战。到底它为什么是一个挑战？因为在复杂的产品和平台日益壮大的时代，对分布式和快速更新的软件有强大的市场需求。
  我们希望快速测试产品。如何做呢？你很可能会说：“让工具来做！”。这样就把重担交给测试开发人员了。同时，不具备软件开发技能的测试人员就看到了类似于早期橱柜工厂的景象。是的，某种程度上，压力一直存在着。现在，“持续部署”的鼓声掀开了另一条战线。
  但我们相信，技术活并不是流水线上的操作。这就是为什么理解测试以及如何使用工具比以往任何时候更加重要。

检查 vs. 测试

  出于上述的原因，在快速软件测试方法论中，我们将测试过程分成机器实现和人工实现两个部分。我们将工具能做的部分称之为“检查”。这两个部分就像“编码”和“编译”。 编码是程序员干的活，编译则由工具替程序员来完成，尽管从技术上讲，编译器所做的活看起来就像程序员干的。想到这，没人能声称自动编程或手动编程。编程还有很多其他的东西需要工具来完成。如果一个工具完全做到了这一点，那编程应该不再能称为是编程。
  我和迈克花了三年多的时间区分“检查”和“测试”，我们进一步区分了手工检查和机器检查。
  首先让我们来看看测试和检查。我们提出如下新的定义，并很快将取代使用已久的定义：

• 测试就是通过探索（exploration）和实验（experimentation）来学习（learning）一个产品，从而对其进行评估（evaluating）的过程，这过程包括：提问（questioning），研究（study），模拟（modeling），观察（observation）以及推理（inference）等。
  (A test is an instance of testing.)
• 检查就是应用算法性（algorithmic）决策规则对产品特定的观测（specific observations）做出判值（evaluations）的过程。
  (A check is an instance of checking.)

要点解释：

• “评估（evaluating）”指价值判断；好或坏？通过或失败？多好或多坏？诸如此类。
• “判值（evaluations ）”作为涉及到产品评估的名词，在检查中，它是人为设定的某种类型的值，例如位串。
• “学习（learning）”是开发思维的过程。只有人类能做到我们这里所说的学习，因为它涉及到常识。
• “探索（exploration）”意味着测试本质上是探索性的。所有测试在一定程度上都是探索性的，但也可以由脚本来建构探索过程。
• “实验（experimentation）”意味着和对象互动并观察它的运行，同时还可以指涉及纯属假想互动的“思考性实验”。我们谈实验，并不是在否定或排斥其他的学习方式，而只是要表达，实验是表征测试的一种行为。这也意味，测试与科学精神一致。
• 上述测试定义中包含的单词并不能涵盖测试的方方面面，只代表我们认为测试的最重要特征。
• “算法性（algorithmic）”意味着以一种工具能够执行的方式显式地表达出来。
• “观测（observations）”包括观察的整个过程，而不仅仅是结果。
• “特定的观测（specific observations）”意味着观察过程中生成位串（否则，算法性决策规则将无从操作）。

上述的定义将产生这些影响：

• 测试包含检查，而检查不能包含测试。
• 检查时，工具原则上可以替代人；测试时，工具只能起支持的作用。因此，工具不仅用于检查。
• 我们不是说检查必须自动化，但根据检查的定义，它完全可以是自动化的，然而测试本质上却是人的活动。
• 测试是“福尔摩斯”式的侦探全集，而检查是简短的“事实核查”并关注事实及与其相关的规则。
• 检查不等于证实。虽然检查通常被用于证实（最典型是在回归测试中），但我们也能想象它被用于证伪随机探索的情况（例如，在一个足够空间内，自动检查不同的随机值）
• 在我们行业普遍存在检查与测试混为一谈的问题。我们的目的就是要减少这样的混淆。
• 检查是可描述的，而测试却并非如此（因为，不像检查，测试涉及到计算机无法表达的知识）。
• 断言，从计算科学上说，是一种检查。但是并非所有的检查都是断言。断言之前的编码是检查的一部分，而非断言的一部分。
• 这些定义都没有标准的判断原则。我们不是说检查本身不好。相反，检查可以做很重要的事情。我们主张检查必须合理地使用在测试过程中。检查是测试的一种手段。

  如果你关注过我们的工作，就会知道我们很重视所谓的有技术含量的（sapience）测试。有技术含量的测试需要测试人员具备适当的技能，需要一个懂技术的人去执行。我们一直讲有技术含量的测试，这样不免给人一种印象：一个没有技术含量的测试是一个笨蛋执行的笨测试（尽管这个测试并不需要测试人员采用多少技术）。因为有技术含量“sapience”这个词听起来像有智慧“intelligence”，我们因此饱受同行的诟病。因此应该提供一些特定的术语来展示它华丽外表内的隐藏的含义。

手工检查 vs. 机器检查

  虽然有技术含量测试是个容易引发问题的叫法，我们仍然需要区分什么是人工可以做，什么是工具可以做。 除了检查和测试之间的基本区别，我们也区分手工检查和机器检查。这也许和文章一开始提的说法有点冲突，因为根据前文的定义，检查能够由机器来做。也许你还会想：手工检查和机器检查所做的事情是不是一样，当然不是，也不可能是。
  在人工检查中，人们只能努力去跟踪算法，而机器却能真正与算法紧密结合，这是人办不到的。以下的例子证明了这点：让一个人连续地听从命令。你会发现让他完完全全地按照命令行事是不可能的。他不会坐等自己渴死。他会阻止自己，然后做出改变或退出。我们都知道这样的事实，人不会简单听从命令，无关聪明与否，无论做什么总是会开小差，人会按照不同的方式解释和判断自己的行为，机器不会。
  虽然人有积极能动性，工具只能表现程序化的行为（见哈里·柯林斯和马丁·库施的名作《行为的塑造》，书中详尽解释了个中原因）。可关键是：你能轻松定义一个检查，可相较于机器执行这个检查来说，人工检查不会像机器一样执行同样的算法，不是不足就是过头。
  请理解，工具在测试中的角色必须被接受。我们朝有技术含量，功能强大，高效的测试目标迈进的过程中，得小心关注人与机器之间的平衡。在许多方面，工具对我们的帮助远不止自动化检查。但在这里，它必须扮演支持测试员的角色，工具的乱用将导致可怕的后果。

  你也许会问，为什么不能将手工检查称为测试。记住，上图中所有的事情都是发生在测试中。手工检查也只是测试的一部分。尽管一个人如何集中注意力也无法一步步跟着检查走。检查只是测试的一种手段，而不是整个测试。
  抱着澄清混淆，明确观点，促进合作的目的，回顾下检查的定义：

• 查就是应用算法性（algorithmic）决策规则对产品特定的观测（specific observations）做出判值（evaluations）的过程。

  以此出发，我们定义了三种检查：

• 手工检查是一种探索性的检查方法，其中人工地收集结果和运用规则，无需调度工具。
• 机器检查在无人工干预的情况下，在工具收集的观测结果中，按照一定规则进行检查的过程。
• 人/机检查是一个人机互动收集观测结果并应用规则的测试过程。

原文链接：http://www.satisfice.com/blog/archives/856
翻译：谢信喜 校验：魏情