Exploratory Testing 3.0

最近看了James Bach新发的一篇文章，名为Exploratory Testing 3.0，文章链接：http://www.satisfice.com/blog/archives/1509

这篇文章介绍了探索式测试的发展历程，现翻译如下（非全文逐字翻译，仅翻译个人认为关键的部分）

By James Bach and Michael Bolton

在软件测试的早期阶段，没有人区分探索测试和脚本测试。Jerry Weinberg 在他1961年出版的《计算机编程基础》一书有关测试的章节中，描述了测试的本质是探索，并且表达了他对正在被形式化的测试的担忧。他写到：

“It is, of course, difficult to have the machine check how well the program matches the intent of the programmer without giving a great deal of information about that intent. If we had some simple way of presenting that kind of information to the machine for checking, we might just as well have the machine do the coding. Let us not forget that complex logical operations occur through a combination of simple instructions executed by the computer and not by the computer logically deducing or inferring what is desired.”

“在没有大量关于程序员意图的信息的情况下，用机器检查程序是否符合程序员的意图是很困难的。如果我们能用一些简单的方法表达此类信息，我们也能直接让机器编程了。不要忘记计算机实现复杂的逻辑操作是通过执行简单指令的组合，而不是通过计算机的逻辑推导来实现的。”

Jerry明白人和机器的差别。但是后来的formalizers（形式主义者？）误导了大家。formalizers－正式开始于1972年出版的第一本测试书籍 － Program Test Method (<<程序测试方法>>)。这本书关注的是测试的形式而非本质。形式指的是单词，图片，字符串，文件，表格，流程图和其他显式建模，他们是我们能够看，读，指向，从一个地方移到另一个地方，计数，存储，检索的东西。但是测试不是任何没有生命的东西。测试，是人们利用这些没有生命的东西思考和活动的结晶。基于这些没有生命的东西的测试没有人就像先进的医疗诊所没有医生和护士：在最坏的情况下，对无辜的正试图利用他们的人是危险的。

ET 1.0 反叛（潜龙勿用）

基于脚本和不基于脚本的测试是不一样的。首先，我们来说一说不基于脚本的测试关于质量的理解。当我们做探索式测试，我们发现更多更好的缺陷。我们觉得它看上去做的更好，但没有发现为什么会这样。因此，第一阶段的探索式测试关注于逃离脚本测试的紧箍咒，制造空间来做“更好的测试”。我们面对的质疑是：Ad hoc不可控和不可管理；不应该这样做。” 我们反对这种想法，在这种假设下探索式测试是一种特殊的测试活动。探索式测试的拥护者把它作为一项技术对待，并提倡使用这项技术。“丢掉脚本，关注产品！和产品互动！才能发现缺陷！”

大多数人仍然人为探索式测试是一项技术和不同于其他测试的测试活动。这样的描述是错误的。这是一个好的开始，但一直这样就会进入死胡同。直到今天很多人甚至写探索式测试书籍的人，貌似还在这样认为。

ET1.0 在1995年开始退出历史舞台。那时只有少数人在尝试探索式测试，尽管所有测试人员都在无意识的或非正式的使用它。然而这些少数人，还不足以使探索式测试走出黑暗。

ET 1.5 展露头角（见龙在田）

90年代末期，北美的一个小的测试社区（最后成长为世界性的上下文驱动测试社区）也在尝试理解和思考有助于测试工作的技能和流程。他们有两条主线。一个是Jerry Weinberg的以人为本的软件工程方法，他结合了系统性思维和家庭心理学。另一个是Cem Kaner拥护的认知学和Popperian批判理性主义。这项工作很快就引起了我们对脚本测试和ET

ET 1.5 展露头角（见龙在田）

90年代末期，北美的一个小的测试社区（最后成长为世界性的上下文驱动测试社区）也在尝试理解和思考有助于测试工作的技能和流程。他们有两条主线。一个是Jerry Weinberg的以人为本的软件工程方法，他结合了系统性思维和家庭心理学。另一个是Cem Kaner拥护的认知学和Popperian批判理性主义。这项工作很快就引起了我们对脚本测试和探索式测试的反思。这是因为我们对测试本身的深层次理解是与时俱进的。

1995年James加入 ST 实验室，他第一个致力于发展软件测试的视觉和方法。这是他和Cem15年合作的开始，也是快速软件测试方法论的开始。第一个重大创新是启发式引导，这是一种实用的，加入了实时测试人员思维，具有全面综合模型的测试过程。列出测试技术和文档模版曾经花费了很多时间。随着我们为一般情况下的软件测试开发了词汇表和认知模型，我们开始看到探索式测试的新曙光。我们开始比较和对比脚本测试和探索式测试的重要组成以及他们之间的联系，而不是将他们视为感觉上不同的两种活动而已。

1996年James创建了第一个测试课程叫“Exploratory Testing”。他已经暴漏了设计模式的思想并试图将这些加到课程里。他定义了测试能力。

1999年James被委任定义微软标准ET流程。这与标准 ad hoc流程看上去是矛盾的。然而这个冲突通过James和Cem的一系列建设性的辩论得到了解决。这些辩论引导我们进入了ET 2.0。

直到2000年，测试界的大多数人开始听说探索式测试的一些东西。我们终于开始了让这个世界更好，更安全的测试旅程。

ET 2.0 集成（惑龙在渊）

ET 2.0经历了很长时间。我们不再称探索式测试为一项技术，而是作为一种适用于技术的途径（Cem称之为一种“style”）。现在我们有丰富的技能和元素测试的思想。它已不再是某些“创造性和神秘”的行为，就像某些人与生俱来就知道如何使用“直觉”一样。我们已经有特定的机构，模型和流程，所以我们觉得可以单独将探索式测试作为一种有效的测试方法分离出来。我们在90年代称之为探索式测试，现在我们称之为“自由式探索式测试”。

直到2006年，我们给出了探索式测试的定义：

“a style of testing that emphasizes the freedom and responsibility of the individual tester to continually optimize the quality of his work by treating test design, test execution, test result interpretation, and learning as mutually supporting activities that continue in parallel throughout the course of the project.”

“强调独立测试人员的自由和责任，依靠测试设计，测试执行，测试结果展示和持续学习的贯穿整个项目过程的交互式活动，持续提升测试人员的工作质量。”

探索可以意味着很多东西：搜索空间，赋予创造性，做前人没做过的事情，自发行动等等。我们意识到大多数不同概念的探索已经成为了测试的核心。探索带来了什么，与脚本化有什么不同。一言以蔽之：自我管理。

探索式测试的定义在后来James和Michael教学和快速软件测试咨询中日趋明显。你可以在没有任何废纸的情况下进行脚本测试（脚本测试也没有要求你逐字遵循文档）。你可以在没有任何事先计划的情况下进行脚本测试（有人会在适当的时候告诉你该怎么做）。你也可以做一个即兴的脚本测试（有人会给你脚本，你也可以自己写一个）。。。。。脚本测试的本质是：测试不是由测试人员控制的，而是由其他机构或流程掌控的。我们花了很多年才弄明白这个简单的至关重要的道理。

2009年Michael指出了测试和验证的区别。测试不能被自动化，而验证可以完全自动化。验证嵌入在测试中。首先，James表示反对，因为测试已经有定义了，这样的区分是没有必要的。James认为验证只是简单的不需要动脑的测试。我们逐渐认识到验证和测试比动脑和不动脑更好的描述了我们的意图。因为不动脑听上去就是愚蠢的，听上去像是我们在谴责不动脑的测试。

ET 3.0 标准化（飞龙在天）

ET 3.0作为一个术语有点矛盾，因为我们正在弃用探索式测试这个术语，取而代之的是快速软件测试的术语。为什么呢？因为我们现在将所有的测试定位为探索。

我们现在对测试的定义是这样的：

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.”

“测试是通过探索和实验评估产品的过程，这个过程包括：质疑，学习，建模，观察，推理，结果验证等等。”

在定义探索式测试过程中，脚本测试变成了一个过客，变成了一个可能有用却又陌生的元素，一个在特定情景下的有趣的讨论和应用策略。一个优秀的测试人员不应轻视脚本测试，就像一个伐木工人不应被重型机械轻视一样。这些东西可以帮助也可以毁灭你，不应忽略它们。

你正在做测试吗？那么你准备好做探索式测试了吗？你正在做脚本测试吗？如果你负责地在做脚本测试，你也正在做带脚本的探索式测试（也许也带着验证）。如果你仅仅只在做脚本测试，那么你正在做动机不明的验证。我们会说你不是真正在做测试。你只是一台机器，而不是负责人的测试人员。

ET 3.0是脚本测试技术的降级，但是确实探索性测试的飞跃。

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