探索测试

本文翻译自《Testing Without A Map_》——_Michael Bolton
[

](http://www.testingeducation.org/BBST/foundations/Bolton_2005-01-TestingWithoutAMap.pdf)

你不需要总是等到有了详细的说明才开始测试——by Michael Bolton

有时我们会面对不熟悉的应用，当我们直接测试它的时候，感觉就像在未经探索的海域规划航程。你不知道在航行中会发现什么，但是你积累了经验，明确了自己想要什么，慢慢也知道自己想往哪走。如果你遇到了一些惊喜或者没有预料的事情，你可以记录下来。这些探索的方法，是你开始所需要的。

有一些测试，主张在没有完整的说明时绝不能开始测试。这是不现实的建议。首先，一些场景中有大量上下文，没有正式说明，需要你去确认：当你在评估一个商业软件是否符合公司的需求时；当你在敏捷项目中工作时；当组织的产品代码太老，有大量修补时，即使找到了原始文档说明，很可能也变得没有任何意义。其次，完整性是完全依赖于愿景和上下文的。即使是被称为“完整的”说明也存在许多隐性的内容。事实上，文档越明确，也会更冗长，相对的，很少会有人能完整读完。最终，某些类型的说明通过对话、邮件、自己的推断的方式提供，而不是正式的文档。结合自己识别价值、风险和问题的能力，与老板快速会面的方式，可能会获得你所需要的许可，以给管理人员提供有用的信息。

一个有能力的测试人员总是能通过探索获得有价值的信息，即使探索的唯一目的是为了更细致的测试策略而收集信息。

prepare for the journey —— 准备

当有经验的探险家在未知水域启航时，他们并非毫无准备的出发。他们知道太阳和繁星，他们会带上罗盘、六分仪和计时器，不仅是为了导航，也是为了制作地图。更重要的是，他们在探险的时候是拥有强大的背景知识和技能的，包括航位推算法，天文导航和基本常识。对于探索式测试人员，作为一个测试专家，使用的知识常常由两种术语表示：预言法和启发法。预言是一种原则或方法，主要通过一些准则来判断软件是否可行；一个预言根据依据提供一个正确的答案。在调查和解决问题时，启发是一种临时的、易错的的指南；也是一种通过探索而获得发现而进行学习的方法。

James Bach 提供了一套有帮助的预言启发式方法，这里以助记词的形式呈现：HICCUPPS。在这种观点下，一个产品应该包括：
History：假设现在没有充分的理由去更改的话，特性或功能的当前行为应该和过去保持一致。这种启发法在测试现有项目的新版本时特别有用。
Image：产品的样式或行为，应该和开发组织想要项目呈现给客户或内部用户的想法一致。看起来劣质的产品，产品本身通常就是劣质的。
Comparable product：我们可以使用其他产品作为一个粗略的、实际上的标准来和自己的产品进行对比。
Claims：产品的呈现应该像一些文档、工件或者人所说的那样。产品的声明可以在说明书、帮助文档、广告、电子邮件信息或者走廊交谈中提出，个人或机构在制定声明时必须具备一定程度的权威性，让声明成立。
User’s expectations: 特性或功能的行为方式应该与我们对用户需求的理解以及他们的合理期望相一致。
The Product itself：给定功能的行为应该和可比较的产品功能或功能模式的行为保持一致，除非有特殊的原因导致不一致。
Purpose：特性、功能或产品的行为应该和明显的目的一致。
Statutes：产品的行为应该遵守法律或监管规定。

请记住：启发法是指导方法，不是法令；它们是易错的。它们并不是通用的——我们可以通过其他方式决定一个产品是可接受的还是不可接受的。一些点之间存在概念上的重叠——但是对一个探索者来说，新领域的特征也会重叠。

Explore and discover —— 探索和发现

有了这些工具，可以想象一下我工作在一个小的初创团队，公司将在CD光盘上发布他的软件。公司没那么多钱，花每一分钱都得斟酌，所以我的老板让我评估一下项目中的光盘：流行的Nero光盘刻录软件。打印CD的封面是一个需求，所有她要求我去看一看Nero的封面设计，CD 刻录包的一个子集，以确定是否应该用它。没有写详细的测试计划，我只是快速投入，在有更多信息时停止，然后再决定怎样继续进行。图1展示了启动项目之后我在主屏幕上看到的内容。

Yogi Berra 说的是对的：仅通过看，你就能观察到很多东西。我最先注意到的事情是看上去有一个默认设置的字体：Arial字型，16字号。我的老板不需要告诉我去测试字体；我脑子里跟启发式目的一致性告诉我：如果任务是去打印CD封面，图形和文本——那么字体——很可能是任务的一部分。我是否关心字号大小的准确度和图形的色度？有可能，但是我会在完成其他测试之后再想这些事情。我会做关于询问精准度问题的笔记并继续进行。

我需要在封面上添加一些东西，所以我选了一个插入对象。我点击Object，Insert，Testbox。然后双击出现的新的对象，弹出图2所示的新的对话框。

有些东西已经感觉很有趣了。在新的字型属性区，字型的名字消失，字号大小现在显示为8。根据在产品启发法的一致性，可能会认为主屏幕和新的对话框的字型属性应该保持一致。我们是否有了第一个bug？我会说是，但是也许我们应该做些检查。我会记录下来。

investigate new findings —— 调查新发现

我们没有详细的文档说明，但是windows项目一般都有帮助文档。一个项目应该和它自己制定的声明保持一致，而帮助文档通常有项目支持功能的声明。所以我们按F1键看看。

为什么按F1？Windows用户有一个规则，F1应该触发帮助文档，由Windows用户界面指南提供。封面设计是一个Windows项目，一个项目的行为应该和类似的项目保持一致。如果有一个无法抗拒的原因，导致项目需要有区别，那偏离事实上的 UI 标准可能是值得的。否则，和其他产品的一致性对用户来说是有帮助的，这样既节省了她的时间，也避免了学习不同做事方式的麻烦。

当我们按F1时，工具提示出现在鼠标指针的热点处：

工具提示“你可以更改文本的内容”。难道不应该说“你可以更改文本框的内容”？这有点模凌两可，在某些情况下我会把它当成第二个bug。如果这是我的项目，我可能发现不准确的英文会有些尴尬，这违背了启发法中愿景的一致性：一个产品的愿景应该和公司希望的愿景一致。另外：不是应该按F1弹出帮助对话框而不是工具提示的形式？Windows本身的规范是，当鼠标悬停在组件上时，工具提示应该显示。我会记录更多关于帮助问题的笔记；它们可能代表其他的一两个bug。

我想打开帮助文档。有其他的方式——我可以点击Help按钮打开，点击Find标签，找到所有涉及“text box”的列表。（见图3）

这里没有任何看起来像是对文本的引用。事实上，这里没有任何看上去涉及封面设计相关的东西。我们可以做索引，查找“封面设计”。我所看到的只是 NeroCD-ROM 刻录软件的帮助。这意味着要么没有关于封面设计的Help功能，要么没有帮助文档，它不是来自 封面设计软件内部的问题。
这是一个基于启发法中用户期待一致性的问题——一个用户可以合理期待在应用程序内调用一份关于应用程序的帮助文档。

看起来好像我要在“Help”功能上放弃，很显然。让我们回到第一个假定的bug，做一些调查。我并不完全清楚我的公司将要在CD封面上放些什么，但是细节不重要，所以我会放一些我猜测会在项目中用到的文字。（见图4）

当我在输入“Beatles Compilation”，事实上，在敲B键时——字号大小立即由8转为16，先前空白的字体下拉框突然设置为Arial。启发法中用户合理期待的一致性主张在用户输入文字时，不应该改变所选字体，除非用户有要求这么做。即使这纠正了我记录的第一个问题，它确实让我犹豫了一会，这是目前另一个有争议的bug；我会记录下来。我把输入的文字设为高亮，选择一个不同的字型和大小；再次强调，细节不重要。我会选择Comic Sans MS 字型和26号大小。（见图5）

然后，我按下“OK”关闭对话框。现在，我立即点击文本框，再次打开对话框。（见图6）

快看！字型设置回到了Arial，字体大小设置回到16。这里违背了启发法中目的的一致性。很显然按下“OK”（而不是“cancel”）是为了在我明确想改变它时，保留我设置的属性：特性、功能或产品的行为应该和明显的目的一致。这是另一个要记录的bug。

注意在这个对话框中，有钢笔、毛笔、图片和文字选项标签。我试了试，发现每次我重新打开文本框更改其中的属性时，字体信息消失——真很不方便，很让人恼火，即使没有文档说明，很明显也是一个bug。我对此感到失望，因为我好像记得在之前版本的Nero封面设计中有这种功能。这违背了启发法中历史版本的一致性：程序的行为方式应该和自身历史或产品的先前版本保持一致。

这个程序中的错误很容易发现，最后一个太棘手了，我对程序的其余部分产生了严重的怀疑。在5分钟的测试后，我能对我的老板说她不应该用这个产品去制作公司的CD封面——谢天谢地，在面对一些程序员明显没有阅读过的不完整的说明文档时，我没有浪费时间去准备一个详细的测试计划。

The Journey Ends——结束

这是一个极其恶略的例子，但是如果你还是坚持你在开始测试前需要一个详细的说明，考虑一下在下面两个问题下的背景。首先，我们需要向管理方提供一个重要的、可信的、及时的说明文档？其次，研究和准备详细文档的成本——等待它准备好——对于报告的价值是否有明显的提升？

正如你所看到的，在许多情况下不需要根据详细说明去测试，它不仅完全可以，而且完全可取。在Windows用户界面的背景知识帮助我识别了一些问题，置身于用户视角也提供了一些帮助。几分钟的探索，随意浏览一个程序的特性，通过启发法探索性测试观察，不仅帮助我发现了bug，也帮助我可靠的确定了我为什么会认为它们是bug，即使我没有一个完整、正式、书面的文档说明。即使我没有地图指引，我也能一路探索和编译。

[

](http://www.testingeducation.org/BBST/foundations/Bolton_2005-01-TestingWithoutAMap.pdf)