【Explore It】Part 1-1测试和探索-优快云博客

本文链接：https://blog.youkuaiyun.com/csd11311/article/details/136086287

发现一本介绍探索式测试的好书，没有中文版，我在工作之余逐字翻译成中文，希望测试同行和关注我的小伙伴喜欢和批评指正。

如果需要英文原版的话，也可以关注公众号加我微信回复【Explore It】获取。

有一个哲学问题：How do we know what we know?

还有经济问题：When will we know enough to move forward with confidence?

还有一个心理问题：How do we convince each other that one more change is needed, or is not needed?

这本书的作者向我们展示了如何通过一种被称为探索性测试的探究来回答这些问题。她率先将探索性测试应用于敏捷开发，在整个敏捷开发成为主流实践的过程中发挥了重要作用。她是一个富有同情心的人，通过这本书成功地传达了共同工作的简单乐趣，以及发现他人重视的乐趣。

探索性测试真的很重要。

虽然这种方法在任何开发中都能带来价值，但在敏捷开发中尤其适用，因为敏捷开发中快速循环和突然变化很常见。开发和测试方法有很多共同点。两者都重视研究过的手艺。他们期望实践者保持警觉，有动力，能够做出判断。两者都认识到，即使决策看起来非常技术性，甚至晦涩难懂，决策也是基于商业背景的。

探索性测试是可以学习的。

探索性测试为传统问题提供了新的方法。

探索性测试并没有否定许多专业测试方法的价值，而是作为最普遍适用和最明显的协作过程，团队成员可以利用它来了解他们构建的内容以及他人将如何体验它。它用信息奖励好奇心，这些信息本身就可以带来乐趣，并带来巨大的商业价值。

为了真正了解任何事情，你必须探索它。

城市也是如此。当我旅行时，我总是留出至少一点时间在后街漫步，寻找隐藏的宝石。我逃离旅游区，寻找只有当地人去的餐厅和满足日常需求的商店。正是在这些漫步中，我开始了解当地文化，了解这个地方的真正特点。

软件也是如此。如果你想了解软件的真实情况和局限性，你必须走一条不寻常的道路。

然而，漫无目的的闲逛和真正的探索是有区别的，正如杰西卡·哈吉在她的索引式网络漫画《Field 1 notes》中如此雄辩地表达的那样。

杰西卡的漫画中有一个重要的警告。如果你漫无目的地游荡，你将花费大量时间漫无目的地游荡，却很少有洞察力：你会迷路的。

这是一本关于如何探索的好书，你会发现一位大师探索测试家所必备的技能和技巧。

哪些人适合读这本书？

因为这是一本关于软件测试的书，你可能会认为这是为测试人员写的。是的，但不仅仅是测试人员。我写这本书是为了任何对生产可靠和稳健的软件感兴趣的人。这包括程序员、业务分析师、产品经理，甚至那些通常只有在软件接近完成时才会看到软件的人：支持人员。

如果你是一名测试人员，对状态分析等测试设计技术有深入的掌握，你将学会如何使用这些技能在探索的同时进行实时测试设计。

如果你是一个对底层技术有深刻理解的程序员，你会学会如何通过不同的透镜来看待软件，从不同的角度来分析它。

如果你是一名商业分析师或产品经理，你将学习如何改变你与软件的互动，以确保它在各种情况下都能按照你的意图行事。

简而言之，如果你参与开发软件，无论是设计、开发、测试还是技术支持，这本书都适合你。

它也不关心你使用什么样的软件。这本书中的技术适用于各种技术环境，从Web应用程序到桌面应用程序，再到移动应用程序，再到嵌入式实时软件，再到API和Web服务。

本书的结构

这本书分为三个部分：

• 第一部分，探索式测试的基础，介绍了成为探索技能的核心基础。在这一部分中，你将了解如何制定章程来指导你的探索，如何观察真正发生的事情，如何识别有趣的变化，以及如何确定在以前从未考虑过的软件使用方式中应该预期什么行为。

第二部分，你将了解如何使用状态建模和数据建模等分析技术来辅助探索式测试。

• 第三部分，将技术用于软件项目的上下文中。你将了解如何在各种上下文中应用第1部分和第2部分中的想法，包括探索现有应用程序和探索没有用户界面的软件。你还将了解如何分享你的发现，以及如何从一开始就将探索整合到开发周期中。

虽然你可以以任何顺序阅读这些章节，但当你掌握了前面部分中的概念后，你将从每个部分中获得最大的价值。

快乐探索！

第一章

关于测试和探索

在互联网行业，不管你的职位是产品、开发OR项目经理，你肯定都知道测试这个词。测试是开发任何高质量产品不可或缺的一环。软件测试是对产品进一步了解的基础——测试通过与软件系统进行交互，观察其实际行为，并将其与预期进行比较。否则，你对软件的了解都只是猜测。

在《Portraits in Silicon》一书中，Robert Slater讲述了ENIAC的团队建造最早计算机的故事。早期的计算机体积庞大，占满了整个房间。如果你观察计算机的整个内部，你会发现一排排的组件，组件之间有电线连接，当时选择电线是非常关键的设计决策。正如Robert Slater解释的那样：

由于电线至关重要，因此团队必须解决老鼠吃电线这个潜在问题。测试人员就捉一些老鼠关在笼子里，并将其饿了一段时间，然后测试人员提供不同种类的电线给老鼠“喂养”，最终ENIAC团队计划使用老鼠不喜欢“吃”的那种电线。

我们可以了解到ENIAC团队意识到老鼠吃电线这个风险，最终将其化险为夷。他们没有猜测啮齿动物的饮食习惯，而是向饥饿的老鼠提供各种类型的电线。他们利用实验结果来指导其决策。这就是“测试的精髓”：设计一个实验来收集经验证据，并解决存在风险的问题。

不同类型的测试解决不同类型的风险。如果想了解系统在峰值负载下表现如何，你可能会运行一个性能测试。如果想了解一小段代码是否符合程序员设计的预期，你会将这段代码隔离在一组单元测试中。如果想了解用户是否能够在没有帮助的情况下知道如何操作软件，你会进行可用性测试。

本章解释了探索性测试与其他类型测试的不同之处，以及它如何适应于整体测试策略。

1.1 测试的两面

20年过去了，但我仍然记得那次谈话，就像发生在昨天一样。我的同事马歇尔指着她桌子上一堆一英寸厚的纸：“这些测试用例只涵盖了正在测试软件的一小部分功能”。

“这太令人沮丧了！”她叹了口气。“无论我们写了多少测试用例，执行了多少测试用例，当抛开测试用例时，我们总是会发现最严重的缺陷。”当时，我不知道探索性测试这个术语，尽管CemKaner在他1988年出版的《Testing Computer Software》【Kan88】一书中已经创造了这个术语。无论我们在测试套件中添加了多少测试用例，当抛开测试用例时，我们仍然会发现意外惊喜。

在那次谈话后的二十年里，我多次见证这种情况重复出现：无论团队执行了多少计划预期内的测试用例，仍然会有意外惊喜出现。

当一个团队将软件产品发布到生产时，“惊喜可能会更大”。

“用户对软件产品做了最疯狂的事情”。因为生产数据与测试用例构造的数据不同，生产环境实际配置也不像测试机器那样。

现实世界是一个混乱的地方。

这是令人沮丧的，但也是无可否认的：你根本无法通过计划测试来覆盖所有场景，因为数据、配置、交互变化太多了。如果你试图创建一套全面的测试来覆盖每种可能性，你将花费所有时间编写测试用例，而没有时间执行它们。

你需要的不是一套完美的测试用例集。相反，你需要一个测试策略。策略回答两个核心问题：

1. 在它正常运行的情况下，软件是否按预期运行？

2. 还有其他风险吗？

测试的两面

检查

我们可以使用预先设计的测试用例来回答第一个问题，以检查在特定配置和条件下软件实现的行为是否符合预期

我们可以将这些检查视为一个网，当软件的行为不符合预期时，该网就会触发，如下图所示。检查提供的覆盖范围越好，网的编织就越精细。

然而，即使你编织了一张精细的网，你仍然需要回答第二个问题。而这便是探索的作用。

探索

探索性测试可以对网覆盖不到的区域进行检查。我们与实现、设计和执行快速连续的小型测试进行交互，使用上一测试的结果来指导下一测试。

当你发现潜在的风险时，你会进行更深入的测试，利用你的观察和分析能力来调整你的测试。你的实验为你提供了关于软件的能力和局限性的经验证据。在这个过程中，你发现了需要回答的新问题，并计划进行其他类型的测试。

探索提供了一个通过无限可能的变化来指导测试的方法，以引导风险，这是预先计划测试用例所无法做到的。为了发现更多的缺陷，可重复性执行用例不会帮助你——而探索测试可以。

然而，这两个问题代表了测试的两个方面：

测试软件是否符合预期和探索风险；

检查和探索任何一个都不足以满足要求。

Tested = Checked + Explored

已测试=已检查+已探索

在检查软件是否符合预期并探索是否存在其他风险之前，我们不会停止测试。全面的测试策略将同时采用这两种方法。

1.2 探索性测试的基本要点

探索性测试最广泛的定义之一来自詹姆斯·巴赫 2003 年发表的论文《Exploratory Testing Explained》，詹姆斯说：“探索性测试是同时学习、测试设计和测试执行，” 这种测试方式要求你的大脑始终全神贯注：

探索性软件测试是一种软件测试风格，它强调测试人员的个人自由和责任，通过与测试相关的学习、测试设计、测试执行和测试结果解释视为在整个项目期间并行运行的相互支持的活动，不断优化其工作的价值。

我使用詹姆斯的定义来解释这种做法：

同时设计和执行测试以了解系统，使用上次测试的结果来指导下一次测试。

定义的每个部分都很重要：设计测试、执行测试、学习和指导。

设计测试

测试设计涉及确定要改变的有趣事物和以有趣的方式改变它们。这个主题已经有大量文献，包括格伦福德·迈尔斯的《软件测试艺术》【Mye79】和鲍里斯·贝泽的《软件测试技术》【Bei90】等经典作品，以及李·科普兰最近更全面的综合概述《软件测试设计实践者指南》【Cop04】。这些书籍涵盖了边界值分析、决策表和因果图等技术，以及推导技术。

测试来自设计，如你设计用例画的状态图、序列图和流程图。

所有测试设计技术仍然与探索有关。你对测试设计越熟悉，你就越能设计出好的测试。

执行

在探索时，将想到测试场景立即执行。这是将探索性测试与脚本测试区分开来的关键点之一。这种测试执行的即时性将探索与其他测试方法区分开来。你不会在开始执行测试之前预先设计你的测试，而是立刻开始执行。这一点至关重要。

学习

当你探索时，你会发现软件是如何运作的。你会了解它的细致末节和主干功能。你仔细观察，寻找可能隐藏着大量缺陷的地方的进行细微探索。观察是至关重要的：你观察得越仔细，你学到的东西就越多。超越预期看到的东西，才能看到真正发生的事情。

深化

随着你执行的每个实验，你都会对软件的行为有更多的了解。你会注意到软件无法很好地处理哪些问题，并利用这些知识来更努力地推动解决问题。利用到目前为止所学到的知识来激发好奇心，提出下一个有趣的问题，专注于发现最重要的信息是大师级探索测试专家的核心技能之一。

1.3 在既定的时间内工作

探索可以是完全没有限制的。如果没有一些机制来衡量你的努力，你可能会花几个小时或几天在软件中漫无目的地徘徊，最终没有任何有用的信息可以分享。

为了回答这个问题，乔恩·巴赫和詹姆斯·巴赫提出了“ session-2”的做法。在这种做法中，将你的时间结构为一系列基于测试的管理（SBTM）。你提前为会话设定一个焦点，在会话期间，你可以灵活地探索，设计和执行测试，从一个测试到下一个测试，没有停顿。

在每个会话中，你都会做笔记（你可能会记录测试想法、问题、风险、意外情况、缺陷），这样你就知道你探索了什么以及你发现了什么信息。然而，你的笔记是供你使用的。当你与相关同学进行复盘时，你会参考它们，但它们不像传统的测试用例或测试报告，你的原始笔记对其他人可能没有帮助。