Testing and Checking Refined

还是James大叔的文章：http://www.satisfice.com/blog/archives/856 
本文提出了Testing和checking的定义和他们之间的区别。

 

＝＝＝＝＝＝＝＝＝＝＝＝以下是译文＝＝＝＝＝＝＝＝＝＝＝

 

测试和使用工具在被人类认识的一开始就是两件事（不仅是两件事，而且是两件具有很多不同特征的事情）。 

测试是脑力劳动并且是无形的，而工具的使用是公开的（可见的和有形的）。工具已经侵入到每个流程并且改变了那些流程，因此，至少成百上千年我们都在思考：是我做的还是工具在做？我到底是真正的战士还是只是将矛扔了出去？我是农民还是只是用犁耕地的人？

正如Marshall McLuhan说的那样：我们创造了工具，然后工具造就了我们。进化是一个我们如何标记自己和周围事物的内在的过程。我们也许见证了工业化如何将橱柜工人编程橱柜工厂，并且诱惑我们谈论橱柜制作者如何改变角色，但是橱柜工厂的工人肯定不会突变成橱柜工人。橱柜工人仍然存在，尽管是少数的，但是他们真是存早在工厂的周围，仍在制造昂贵的和好质量的橱柜。优秀的橱柜工人仍然有市场，去解决宜家不能解决的问题。这样的情景也出现在科学和医学界。它甚至出现在任何地方：工具在人类劳动中的演变说明了什么？任何追求卓越的人都必须和工具所对应的角色斗争。

测试是一个在很多方面引入了工具的过程，也是对测试人员思维挑战的过程。如果我们想要快速测试一个产品，应该怎么做呢？也许你会说让工具来做吧。这给那些熟练的软件测试人员带来了巨大压力，同时那些并不熟练的测试人员的测试就像工业化时期的橱柜工厂。诚然，在某种程度上一直存在压力。现在“持续部署”的敲响了另一场战争的擂鼓。我们相信熟练的认知工作不是工厂工作。那就是为什么要理解什么是测试，工具怎样支持测试。

 

Checking vs. Testing

基于上述理由，在快速软件测试方法论中，我们区分了机器可以做的和仅能由熟练测试人员完成的部分。我们采用一个普通的英语单词“checking”指代工具可以做的部分。就像我们已经达成共识的区分“编程”和“编译”一样。编程是程序员做的，编译是程序员使用特定的工具做的，尽管编译的结果也是由程序员决定的。让我们来思考一下，没人谈论自动化编程和手动编程，在编程的同时，由很多其他东西是靠工具来做的，一旦工具也能做这些东西，那就不能再被称之为编程了。 

我和Michael用了超过三年的时间去寻找一个新的关于人工验证和机器验证之间的区别的定义。

首先我们来看看测试和验证。下面是我们给出的新定义： 
Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc. 
(A test is an instance of testing.） 
测试是通过探索和实验的方式（包括：质疑，学习，建模，审查，推理等）学习产品并评估产品的过程。

Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product. 
(A check is an instance of checking.) 
验证是通过将算法决策规则应用到特定审查过程并对产品做出评估的过程。

 

注解：

• “评估”（“evaluating”）就是对价值做出判断，好的？不好的？通过？失败？好在哪里？不好在哪里？

• “评估”（“evaluations”）作为一个名词指的是对产品的评估。

• “学习”（“learning”）是发展人的思维的过程。只有人类能够学习我们正在使用的词的完整意思，因为我们同时指的是隐性和显性的知识。

• “探索”（“exploration”）指的是测试天生就具有探索性。所有的测试都在进行某种程度上的探索，但也可能被某些脚本元素限定。
• “实验”（“experimentation”）指的是在进行过程中与主题的互动和观察，也包括涉及纯粹假设的“思想实验”。也说明了测试就是一门科学。
• “算法”（“algorithmic”）代表能被工具执行的可以显示表达出来的一种方法。
• “审查”（“observations”）指的是整个观察过程，而不仅是结果。

 

一些隐藏在定义中的东西：

• 测试包含验证，但验证不包含测试。
• 验证由工具执行而不是人，工具只能辅助测试。当然，工具的作用远不止验证。
• 我们并没有说验证必须是自动化的，但是验证是可以完全自动化的，而测试则天生是人类活动。
• 测试是开放式的调查，就像福尔摩斯破案一样，而验证是基于特定事实和规则的事实验证。 
  验
• 验证和确认（confirming）是不同的，验证是确认经常使用的方式（回归测试中最为典型），我们也能想像他们不用于确认（例如一套自动生成的验证随机的通过一个巨大的空间，寻找任何的不同） 
  我们经常遇到的问题是验证和测试被混淆了，因此我们的目标就是消除这种混淆。 
  在计算机科学意义上讲，断言，就是验证。但不是所有的验证都是断言。即使在有些断言中，断言之前的代码是验证的一部分，而不是断言的一部分。

这些定义并非道德批判。我们并不认为验证是一件坏事。正好相反，验证是非常重要的。我们主张好的验证是在计算机测试过程的上下文中发生。也就是说验证也是一种测试的策略。

 

Human Checking vs. Machine Checking

我们需要区分人可以做的和工具可以做的。因为除了测试和验证的基本差别，我们还要区分人工验证和机器验证的差别。这可能会让人疑惑，因为根据定义，验证是由机器来做的。但是人工验证和机器验证是不一样的。 

在人工验证的过程中，人们试图遵循一个显示的算法流程。工具不仅遵循这一流程，他们还完整具体地体现了这一流程。 
人类不能完整具体地体现这些流程。下面这个实验会证明我所说的：告诉人类去执行一组他不可能完成的指令，看看他会怎么做。他不会乖乖的坐在那里直到精疲力尽。他会停下来并且改变或退出流程。人类会比他遵循和试图遵循的流程表现出更多的东西。对这些普通人甚至是只具有基本认知能力的人来说没有例外。在这个过程中，人类始终会做的更多（比起完全遵循某些流程）。人类会经常调整他们的行为，而工具却做不到。

人类会采取积极的措施；工具只能展示出预定的行为。结论是：你能定义一个足够简单的验证，但是人类在验证过程中或多或少会做些改变，而工具则不会。

需要理解的是，当我们朝着熟练的，强大的和有效的测试前进的时候，我们必须使用健壮的测试工具。我们要注意人工和机器两方面的因素。工具可以帮助我们很多，而不仅仅是自动化的验证。但是，他们必须作为一个辅助性角色。不恰当的使用工具反而会带来麻烦。

你也许会问为什么我们不把人工验证定义为测试。人工验证是测试的一部分。以下是我们给出的验证的定义： 
Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product.

以及三种验证的方式： 
Human checking is an attempted checking process wherein humans collect the observations and apply the rules without the mediation of tools. 
人工验证是人类在没有工具辅助的情况下搜集观察结果并且使用规则的验证过程。

Machine checking is a checking process wherein tools collect the observations and apply the rules without the mediation of humans. 
机器验证是工具在没有人类辅助的情况下搜集观察结果并且使用规则的验证过程。

Human/machine checking is an attempted checking process wherein both humans and tools interact to collect the observations and apply the rules. 
人工／机器验证是人类和机器交互的情况下搜集观察结果和使用规则的验证过程。

 

如需转载，请注明出处，这是对他人劳动成果的尊重～