原文链接

The Little Black Book of Test Design

简介

这本小书描述了如何利用那些在进行雄心勃勃的系统测试时所需的多种信息源的方法。在我第 N 次感觉到现有的测试设计技术无法捕捉我过去十年在同一系列产品上的方法后，我开始深入的研究这些东西。这导致我主要与同龄人一起学到的思想得到了扩展。

我将会描述一种测试策略、测试分析、测试设计和测试执行的全面合并；其中的各项活动在理论上可以被分割开来，但在现实中它们互相交织在一起。它并不是关于单个测试用例的细节；测试设计也可以是一行程序、章程或头脑中的一个心智模型。它是关于处理复杂性，技能发展，伴随你的成长。我想要强调的是测试的结果，一个宽广的采样空间，它使偶然性成为必然（应该是偶现问题必然会出现的意思），并针对重要部分实现真正的饱和度。对于专注于任何重要问题的手工系统测试人员，以及期望发现比基于基本需求的通过/失败更多的定性信息的人，它可能是最佳的选择。他涉及的测试设计方法，我和其他许多人已经使用了很长一段时间。

本质

从多种来源中了解，生成相关的测试要素，

综合有测试价值的测试思想，带着随机性去执行

软件测试人员可以遵循社会科学基础理论的思想：我们应该使用主题相关的多种信息来源（需求，说明书，原型，代码，bug，错误分类，用户反馈信息，用户故事（customer stories），用户期望，技术（？），工具，模型，系统，质量目标，质量属性，测试方法，测试思想，与用户的对话，风险，可能性）；我应该将事情归总起来，利用我们的创造性，创作一个由许多可以识别哪些部分对于测试是重要的想法以及结果组成的理论。

我鼓励测试人员使用比需求多得多的东西；理解将不同类型的东西组合在一起的必要性，对全局和细节能够同时关注。这部分的内容是为了有野心的项目（？），可能会跨越好几个版本，而且当资源不足时会显得不值得（测试），或者你十分确定你使用的测试方法是最佳的。

这可能会显得太重，但是人有非凡的潜能。

这些活动依赖于测试人员的技能，这种技能是随着时间的推移而发展起来的，最好是拥有大量的产品和项目背景知识，并且通过形成和共享你自己的经验法则、你的特定测试设计启发来加速发展。

基础理论

我了解在基础理论中一种宽泛的科学、理论基础，在社会科学用作一种现象的定性、彻底分析。

科学家很仔细的对这个主题进行实验，获得了大量的材料、文档化的代码和备忘录上的概念。将它们分门别类之后，一个理论从中构建起来。

在传统的自然科学中，不能已假设作为开始。这与我的软件测试（理念）颇为相似。如果我们认为自己一开始就知道所有重要的问题，将会是很危险的事情。他们承认我们正在处理一个抽样问题，而偶然性是一个有利于你的因素。基础理论是一直发展的，直到没有新的，变化的信息被发现。这样的理论是充分的。

我认为这个理论很适合软件测试，特别是它强调研究者必须使用他的创造力。

当从其他领域借用概念、想法时，你需要考虑是否存在软件测试的一些特殊性导致这些想法不适用。扎根理论是一种试图证明事物的研究方法，其他人使用相同的方法应该能够得出同样的结论。它通常在更大的意义上使用人物访谈而不是测试。

我还没有尝试应用基础理论于软件测试工作中，它是对我的测试设计现实的描述的一个启发。

测试理论

不像传统的测试理论聚焦于测试用例的设计，这种测试设计（理论）主要包括测试策略、测试分析，测试设计和测试执行，但不提倡拆分这些活动。通过一种更全面的方法，你可以在脑海中同时想多项测试活动来获得这些活动之间的互动以及有趣的连接，这些活动可以互相启发。

它可以适用于任何测试策略，但最好的匹配是在开始时没有一个定义好的策略，而是让（多个，不同的）策略与测试思想及其结果一起融合。

一个匹配的高层次的测试策略应该是：

我们正在开发一个花费了相当成本的成品的软件。客户希望产品能够与他们的数据、环境一起满足他们的需求。我们希望避免补丁和其他导致想象丢失的问题。

我们还希望你帮助开发人员加快速度；为他们创造低垂的果实（译注：意指容易获得的成果）。

低层次的测试策略（是的，它们很多）会自然地随着你的学习一起出现，但是你可能应该检查明确的需求，并执行特定的或自由形式的探索性测试。

测试分析在测试文献中是一个没有显著投入的领域，我的猜测是，这是因为传统的，仪式化的测试中不需要这个过程；应该测试的内容已经 “完整的” 在需求文档中描述过了。也是因为 “大部分大多数已发布的测试技术指南都是基于单元/组件测试技术”。这真的很不幸，因为当你选择哪些测试元素要考虑，测试到什么程度，试图找到研究问题的好方法，以及从用户的角度设计方法以找出有关软件的重要内容时，会做出更重要的测试决定。同时，探索性测试的本质正是与此更相关，而且我对测试更有兴趣，而不是检查。

基于多种信息源想出高效的测试方法，是测试设计中最让我着迷的部分。

我对设计测试用例并不感兴趣，我任务设计测试思路更佳，至少比测试用例高一层。实际的执行细节通常由测试人员决定。预期的结果是不必要的，通常我们可以看到我们发现了什么，并报告任何值得注意的事情。

与许多现有的测试设计技术相反，我的重点是寻找相关的资源，分析它们，选择策略/技术，而不是设计测试用例的细节。

我所写的内容部分类似于错误猜测或基于经验的测试，但更多类似于探索性测试，它承认一个事实，如果这有帮助的话，即现有的软件和测试的结果，应该用于指导后续的测试。如果你从许多信息源中寻找知识，你就要专注于学习，这是探索性测试的关键部分。

也许这篇文章只是探索性测试核心领域的另一个呈现，但同时，这个测试设计也同样适用于更多的脚本化测试，这些脚本化的测试希望比需求和规范文档更深入。

什么重要？

我们知道完全的测试是不可能的，因为即便你执行了各种质量维度的代码和方法，你也不能获得用户的数据、需求、环境和感受的所有可能性。这意味着我们面对的是一个采样的难题，我们想要对重要的部分尽可能多的采样。

测试设计应该提出在执行时（有或没有偶然性）将涵盖大部分重要内容的测试思想（需求可以是一个好的开始）。这是非常困难的，因为软件有很多重要的东西，这就是为什么 “测试是一项极具创造性和智力挑战性的任务”。

我相信在具体的情况下，要么你知道什么是重要的，要么你不知道。所以基本的策略应该是学习很多，因为这样你就会知道更多。

你理解什么是重要的技能会随着时间的推移而发展，但是好奇心和协作会加速它的发展。如果你在一个产品上工作了很长一段时间，通过了解产品使用的不同方式来获得优势将会是一个漫长且有趣的学习过程。专项知识协助，与终端用户的联系将概念落到实地，在可行的场景和新的连接上发挥想象力，对漏洞进行严肃的思考，了解技术可以合应该做什么，从而活动一个测试者的思维模式。

我们可以将测试空间视作一片没有边界的空间，其中有一个需求 “盒子” 和软件 “土豆”：

有了对软件及其上下文的基础知识，你可以变着花样来捕获重要的东西。

理解重要性需要价值判断，传统上太多的定量自然科学方法已经被用于测试。计算机不善于决定什么是重要的，而人类擅长。

软件测试灵感

常言说得好，为了能够很好地测试一个产品，你需要考虑的不仅仅是显式的需求。

最重要的理由是，在测试中，我们对产品的了解比实现之前要多，测试人员会查看不同的细节级别。另一个原因是需求总是不完整的（它们不是万能的；隐含的需求几乎是无止境的），有些东西在你理解之前必须先尝试一下，你不想在需求编写上花费太多的资源。

我们也应该问自己测试试图在解决什么问题。我认为有更多类似这样的场景：

我们知道我们构建的产品会存在问题。我们需要你的帮助来保证客户可以无障碍的使用交付的产品，对他们的任务提供令人满意的帮助

而不是这样：

我们必须验证实际的产品满足了需求文档上的所有陈述

对多个信息源的洞察通常伴随着 “其他信息” 的一些例子，例如关于客户需求的一些东西，或阅读代码的必要性，或了解软件运行的技术，或了解特定环境中的质量特征。

在第 10-11 页，有一个完整的清单，可以看作是 “建立自己的清单时的清单”。每件事并不总是相关的，但我建议在每一类上花一分钟。想一想什么是重要的，然后自己决定要深入挖掘哪些信息源。你得到的信息可以立刻给你很好的测试思路，可以指出什么是重要的，并最终指导你的测试设计细节。整体合并使我们了解在许多情况下什么是重要的。

通过使用多个信息源，包括实际的产品和客户需求，你的测试将与现实有更好的联系，它们将是基础。

使用多种模型

需求是软件应该完成的一个重要模型，但是它比需求文档中的结果更复杂。你应该挑战需求，并通过其他来源试图找到隐含的那些重要的。

如果存在任何类型的规范（概念、技术、功能、设计），它们都是有价值的输入。你还可以查看其他功能的规范，在这种情况下，测试规范可能是最有趣的部分。

实际的代码也是一个模型，你可能会从阅读它中受益，或者让阅读过它的人告诉你。特别注意旧的、新的、不稳定的、未读的、已审阅的代码。

帮助对功能进行建模，希望是从用户的角度。

最好的模型是实际的软件，当你能看到它的实际功能时，你就会明白不同的部分是如何交互的。当你使用软件时，你总是对它做一个心理模型，即使你不了解它。

你的内在心理模型不一定能沟通。这没关系；问问你的朋友他们是如何想象一年的，因为有些人没有这样做过，但仍然对这意味着什么有一个完美的理解。你将测试和测试结果组合起来为你的测试空间建模，对于所有模型，你应该同时查看内部和外部。

对别人的模型保持开放的心态，测试员不是完人，也会像其他人一样犯错。

产品和项目

总会有历史的数据，并且会有很大的机会你正在一个发布很多版本的产品持续工作，所以你有很多的之前执行产生的数据可以使用。

你为你工作中经常遇到的 bug 类型建立错误分类吗？

你能给你的 bug 和工单打标签，以便它们在你寻求灵感时重复使用吗？

你是如何在早期成功发现的严重的 bug？那些修复过的 bug 是如果流到线上的？

没有你的软件，客户会如何尝试解决问题？

你是否使用你的营销素材作为重要部分的指导材料？

你在网上搜索关于实际使用和问题的信息吗？

你拥有，并且能够获取关于功能和关联风险的很多信息。你是项目的一部分，流程的一部分，而且你了解所有这些不同的可交付物。

你有可以指导你测试设计的测试执行环境：

你什么时候开始测试，有多少时间？

测试人员有怎样的背景和专业？

其他人会测试什么内容？

在这次测试中你应该尝试什么样的新测试类型？

你准备好迎接那些总是会发生的意料之外的事情吗？

你可能想要一个宽松的、易于变化的、开放的计划

如果你幸运的话，你有或者可以创造质量目标来导向重要的部分。可能有一些信息目标可以很好地指导您的活动。

人员和技能

有大量的知识存在于你的团队和参与者之中；当你有机会的时候，找相关人询问细节。赢得开发人员的尊重，你将在搜索漏洞时获得非正式的内部提示。你对用户的需求、知识、感觉、缺陷了解多少？用户、团队和其他相关方重视什么？

为了找出应该测试什么，你应该使用你自己和你同事的技能：

• 知识、经验、直觉和主观
• 调查：探索与学习
• 分析思维：模型细节和大局观，循序渐进
• 批判性思维：看到问题、风险和可能性
• 创造力：拓宽测试范围，产生新的想法，横向思考
• 测试视角：想要发现错误，发现许多类型（错误），检查很多地方，经常检查，专注于重要的部分，通过其他人的视角观察。

更多灵感

知道很多关于实际的和潜在的产品使用场景是有益的。抓住一切机会去拜访客户或与客户交谈，找出那些导致寻求支持的经历，了解真正的需求：用户在尝试解决什么问题。

你能在内部 “真正” 使用这个产品吗？吃你自己的狗粮（eat your own dog food），喝你自己的香槟？使用实际实现的软件来完成一些有价值的事情是我最喜欢的测试灵感。

你可以从软件产品、内部工具以及模拟系统中来寻找竞争对手；在它们被计算机化之前，类似的功能是如何实现的？

为了理解业务需求、逻辑、信息、知识、标准、法律，您可以尝试与业务专家进行结对测试。

了解技术意味着你知道如何操作软件，以及其中的关键是什么，对于理解如何执行测试并高效地执行测试也是非常重要的。使用你的私人工作的主要平台是一个捷径，知道相关的工具是必要的。

如果你对现有的测试理论了解很多，你可以使用许多不同的技术/方法，并且有更高的机会找到重要的信息。经典的测试设计技术可能并不经常适用（除了一直使用的隐式等价划分），但是在合适的情况下，它们可以非常强大。

从通用的测试思想中获得灵感，如快速测试、旅游、记忆法、启发法、质量特征；或者从书籍、课程、博客、论坛、网站、文章、会议、对话中获得技巧、攻击、清单和其他知识。

不要不经审视得使用任何想法，即便与你的产品有联系。随着时间的推移，你可以创造你自己的测试想法触发器清单，这些触发器很容易在实际项目中转换为富有成效的测试。

双倍工作？

对于使用一个广泛的测试灵感清单会比单纯分析需求的工作量翻倍的观点，有所争论。这在一定程度上说是对的，如果需求文档中有一些附件，包括更多关于属性和参考目录，以及他们收集的一些动机信息，那么成本可能会降低。

同时，测试以需求永远无法做到的方式深入到细节中。需求不会写明在各种情况下每个操作的响应时间，但手动测试人员被允许或者告知这方法的要求，将始终隐式地评估特定的性能。

测试（和开发）需要理解真正的需求（而不仅仅是文档），才能做好工作。这将需要一些双重努力，但也将产生多样性所带来的更丰富、共同的理解。

此外，在做这个练习时，测试人员在评估测试执行时的有趣行为时，会得到一大堆可用作预言的资源

测试想法的 37 个来源

我们建议持续得从各种各样的信息来源中收集测试想法。

参考下面的表格，思考其中的价值、风险和机会；找到捷径覆盖重要的部分

产品	1. 能力 最先想到的而且是显而易见的处理预期产品能做什么的测试想法。需求、样例以及其他的规格说明书，或者实际软件的功能清单都是良好的开端，但也要尽量识别隐含的需求、用户期望的但是并没有在文档中体现的东西。警惕不必要的功能。 2. 失败模型 软件运行过程中会有很多种方式导致报错，所以通过问 “如果……会怎么样” 的问题可以生产测试的想法，揭示对内部的/外部的、预期的/意外的、故意的/无意的、实际存在的/人为引发的报错的处理。挑战系统的容错性；任何的对象或者组件都可以破坏 3. 模型 状态模型有助于识别围绕状态、转换和路径的测试思想。系统解剖图显示了可以测试的内容，并可以突出显示交互作用。使用启发式测试策略模型中的 SFDPOT 等结构创建自定义模型。可视化模型更容易沟通，建模活动通常会带来理解和新的想法。许多丰富的模型给出了更好的测试思路 4. 数据 通过识别有意的和无意的数据（总是会有噪声），你会在获得一串测试想法上有一个良好的开端。通过跟踪贯穿应用的简单或棘手的数据，在内部和外部边界，挑战数据类型和格式，使用 CRUD（创建、读取、更新、删除），利用依赖关系，并在许多地方查看数据。 5. 环境 没有任何产品是孤岛，因此环境兼容性（硬件、操作系统、应用程序、配置、语言）是许多重要的测试问题之一，但也要调查与产品接近的活动。通过了解大系统，您可以获得可靠的测试想法，而这些想法在孤立地看待功能时是牵强的。 6. 白盒 通过将测试人员的破坏性思维放在开发人员对体系结构、设计和代码的视角上，你可以挑战假设，也可以发现代码中容易修复的错误。要特别关注从黑盒测试角度你可能不理解的决定和分支。代码覆盖率并非一文不值，它可以用来查找尚未测试的内容。 7. 产品历史 旧问题可能以新的形式出现。搜索 bug、用户反馈系统或创建错误分类，记住关键故障和根本原因分析。使用旧版本的软件作为灵感和预示。 8. 流言蜚语 通常会有很多关于质量和问题的讨论。一些讨论影响到了产品和组织。利用流言本身作为测试想法。你的任务是对流言的证实或者证伪。 9. 实际的软件 通过与软件的交互，你会得到很多关于什么是容易出错的，什么是连接，什么是有趣的想法。如果你能吃你自己的狗粮（委婉的说法：喝你自己的香槟），你就能更好地理解软件的重要之处。如果 “质量对一个人来说是有价值的”，那么如果那个人是 “我” 就很好了 10. 技术 通过了解软件所使用的技术的内部工作原理，你可以看到有问题的区域和可能出错的地方；了解可能性和安全性；什么时候改哪些参数。你可以做正确的变更，并与开发人员进行技术讨论。 11. 竞品 通过查看类似问题的不同解决方案，你可以获得直接的测试想法，也可以感受到最终用户对哪些特性感兴趣。可能有内部解决方案（如 Excel 表格）可供借鉴，而且通常也存在用于类似目的的模拟解决方案。你能从竞品的支持文档、常见问题解答或其他资料中获得任何有见地的测试想法吗？
业务	12. 目的 产品的总体目的将为你的测试想法指定目标。多问几个为什么？找出真正的目的。这些可以给你可以快速找到非常重要的问题的广泛的开端。 13. 业务目标 公司的最高目标是什么（以及部门分解目标）？是否有与这些目标相矛盾的需求？你了解全局、产品愿景和价值驱动力吗？ 14. 产品形象 在生产或消费软件的人的内心深处，产品的预期行为和特性可能是明确的，也可能是隐含的。如果你知道并能展示对产品形象的威胁，比如指出与营销材料的不一致，你就能写出令人信服的问题报告。 15. 业务知识 如果知道该软件的用途及其运行环境，你可以了解它是否会为客户提供价值。如果你不能获得这些知识，就要与了解需求、逻辑和环境的人合作 16. 法律方面 你需要考虑合同、处罚或其他法律义务吗？什么样的法律问题会使公司损失最大？你有没有律师能给你避免踩坑的提示？
团队	17. 创造性想法 所有的产品都是独一无二的，需要一些以前从未见过的测试想法。尝试横向思维技巧（例如 Edward De Bono 的六顶思考帽、挑衅的操作员、相反的、随机刺激、Google Goggles）来提出创造性的测试想法。隐喻和类比是让你开始新方向的好方法 18. 内部收集 使用或创建在你的环境中通常很重要的事情的清单，一些人称之为质量/测试模式，另一些称为特定产品的快速测试 19. 你 你是用户。你可能是个利益相关者。你很重要。 发挥你从经验、技能、知识和对问题的熟悉中得到的优势。用你的主观性和感觉去理解什么是重要的。别忘了承认你的弱点和盲点。
项目	20. 项目背景 项目的原因驱动了许多决策，为了进行有效的测试，以前（类似）项目的历史非常值得了解。 21. 信息目标 理解测试工作的显式和隐式目的是非常重要的。 如果你不能得到它们，为所有特性创建你自己的质量目标来指导测试想法。 22. 项目风险 项目中的一些难题可以通过测试来定位。你想知道哪些功能开发人员遇到了问题，并且根据需要优先解决的风险来调整计划。 23. 测试工件 不仅你自己的测试想法、日志和结果可以用于后续测试，还可以尝试其他项目的测试结果、测试报告、可用性评估、第三方测试结果等。您希望能够在状态报告中回答哪些问题？ 24. 债务 我们走的捷径常常使债务不断增加。这可能是项目债务，管理债务，技术债务，软件债务，测试债务或任何你想叫的名字。如果团队跟踪债务列表上的内容，可以根据这些项目映射一组测试想法 25. 对话 从人们那里得到的非正式信息可能包含比规范更重要的内容。很多人对你的测试设计是有帮助的，有些人是重要性的更好评价者，你能从中顺嘴提及的信息（MIP：Mention In Passing）中得到什么？如果开发人员知道你可以找到有趣的东西，他们会给你关于软件可疑部分的内幕信息。向开发人员提出的以下问题是很傻的："你认为我们应该测试什么？”？或者 “你希望代码的哪一部分做得更好？” 26. 环境分析 在目前的情况下还有什么应该影响你测试的东西，以及如何影响？你知道市场力量和项目驱动力吗？是否有什么变化导致需要新的测试方法？其他人在测试什么？该项目及其人员有哪些长处和短处？ 27. 许多的可交付物 有很多东西需要测试：可执行文件、安装工具包、编程接口、扩展、代码和注释、文件属性、帮助、其他文档、发行说明，Readme，市场营销，培训材料，演示等等。所有这些都包含了你可以用作灵感的信息 28. 工具 如果某件事能做得很快，试试是个好主意。工具不仅是达到目的的手段，也可以作为探索的起点。
参与人	29. 质量特征 质量特性对于项目的成功总是很重要的，尽管 OK 区域可以很容易到达，也可以很难到达并且很关键。我们的定义包括能力、可靠性、可用性、吸引力、安全性、性能、IT 能力、兼容性、可支持性、可测试性、可维护性、可移植性和大量子类别。其中许多特征可以作为长期的测试想法存在于你测试思维的底层，不实际执行，但准备好识别反例。 30. 产品恐慌 利益相关者真正担心的事情要比风险严重得多，他们不需要优先顺序，他们需要测试。典型的难以验证，但对测试有用的恐惧是：图像丢失、错误的决策、损坏、人们不喜欢软件。不同的人有不同的恐惧；找出最重要的。 31. 使用场景 用户希望通过软件完成或体验一些东西，所以应该创建各种各样的方式来模拟产品行为序列，而不是孤立的测试单个功能。你知道的可信的使用模式越多，执行的测试就越接近现实。还可以尝试使用古怪的肥皂剧测试（？）来扩大测试覆盖范围。 32. 领域信息 除了了解客户失败、他们的环境、需求和感受之外，您还可以花时间了解错误和成功模式下的客户。采访最终用户、售前、销售、营销、顾问、支持人员，甚至更好的方式是：在那些岗位工作一段时间。 33. 用户 考虑不同类型的用户（你认识的人，角色），不同的需求，不同的感觉，以及不同的情况。找出他们喜欢和不喜欢什么，他们接下来做了什么。在测试实验室中设置一个场景，让测试人员扮演不同的用户，从中触发什么测试想法？当然，最好的方法是直接来自用户环境的，没有被过滤的信息。请记住，两个相似的用户对同一领域的看法可能会大相径庭。
外部	34. 公共集合 ** 利用一般或特定的错误列表、编码错误或测试想法。当你正在构建适合自己情况的清单时，请尝试以下操作： Appendix A of Testing Computer Software (Kaner, Falk, and Nguyen) Boris Beizer Taxonomy (Otto Vinter) Shopping Cart Taxonomy (Giri Vijayaraghavan) Testing Heuristics Cheat Sheet (Elisabeth Hendrickson) You Are Not Done Yet (Michael Hunter) 从书籍、博客、会议中学习一些测试技巧或技术；搜索测试设计探索，或为发明最适合自己的方法。 35. 标准 ** 挖掘相关业务标准、法律法规。阅读并理解 UI 标准、安全合规性、策略。有一些文章描述了如何打破一些东西，即使它遵守标准，你能包括他们的测试想法吗？ 36. 参考 各种参考资料是预测和测试灵感的良好来源，例如地理产品的地图册。所有类型的常识都可以很方便使用，维基百科也可以很快了解统计方法。 37. 搜索 使用谷歌和其他方式是一个很好的方法来找到你想要的东西，以及你不知道你需要的东西（看运气）。

分析

测试设计的分析部分处理的问题是：我们应该测试什么？这涉及到对各种信息源的识别和阐述，同时也涉及到弄清楚什么是或可能是重要的。

我想阐述一个测试人员将产品信息分解为可用于测试的元素的本能。它可以是对需求的细化，也可以是与客户交谈时的洞察，或者是网站上的特色口号，这个列表如前一章所提到的那么长。

Kaner 称这个过程为学习，Michael Bolton (and James Bach) 则使用因子化称呼。“因子化是分析一个对象、事件或模型以确定组成它的元素的过程。”

Edward de Bono 有一个通用的横向思维技术分离方法，其中明确包括一个创造性方面：

“一方面不要试图找出场景的正式组成部分，另一方面要尝试去创造那些组成部分。”

在软件测试领域，这个概念不仅仅包含数学意义上的分析并找出组成整体的确切的部分的因式分解。

在测试中，我们更倾向于寻找有用的元素，这些元素包含我们想要测试的内容，以便找到有关产品的重要信息。我们可能会制造不合理的人为分歧，因为它们对我们有益。如果一个用例包含 Firefox 3.6，我们可以添加所有其他我们认为相关且值得测试的浏览器和平台；我们将自动考虑浏览器中的设置。

我们将添加我们知道或认为我们知道的内容；利用我们对重要内容的理解，将元素合成为有用的测试想法。我们还将寻找许多解决方案，重要的不是构成了原始信息源的因素，而是你想要的有用的测试元素，如果它们相互矛盾，那就相当好了。

不仅要关注重要的部分，还要关注可能重要的部分，或者可能产生其他重要的信息的部分。你想要创建可测试的测试，典型的例子可能是那些你不知道它是否重要的测试，但是你想要确保没有问题的部分。

探索式分析

对广阔而相关的测试空间进行分析是一项很难学习和掌握的技能，它涉及到对整体、细节和重要内容的理解。然而，有许多启发式方法，经验法则，你可以使用让分析/设计的交织过程更加强大。以下是你在寻找最佳答案时的一些示例：

1. 尽快 —— 一个关于系统的小知识可以对测试工作产生很大的影响（并且反馈可以对开发工作产生很大的影响）。
2. 寻找更多 —— 需求文档或风险很不错，但它们只是开始
3. 呵呵？真正地？所以呢？—— 你可能不理解，你理解的可能不是真的，真相可能不重要，或者可能比你想象的重要得多。
4. 玛丽有一只小羊启发 —— 对每一个字进行推敲和挑战，使用同义词，反义词和组合。
5. 质疑一切，尤其是这句话——对于重要的事情，挑战其假设。
6. 向人们询问细节、声明和期望。
7. 歧义分析——寻找矛盾、漏洞和容易被误解的东西。
8. 除非式探索 —— 在你的产品、流程或者模型的任何你关心的表述后面加上 “除非……”。然后看看新增的部分引导你到了那些方面。
9. 应用业务知识 —— 学习业务，如果你做不到，就和有业务知识的人合作。
10. 相关性判断 —— 你认为它重要吗？其他人认为这很重要吗？会变得重要吗？用户是否会对这个问题感到不安/恼火？
11. 如果…怎么办？–就可能发生的事情或经验进行头脑风暴。
12. 横向思维 —— 人工分离，类比，寻找替代品，相反方面，随机刺激 — 任何有用的东西都可以做。
13. 测试想法触发点——让自己暴露在你认为能产生好想法的信息/情境中。
14. 拉近拉远 —— 放大或缩小详细程度，并检查内容。
15. 新的联系——以重要的方式将不同的知识、细节和大局结合起来；什么值得仔细研究？
16. 泛化的实例化 —— 将来自泛型测试、分类法、检查表的思想上下文化
17. 制作一张图片、图表或表格——更容易沟通，并能引发新的想法。
18. 神秘的沉默–“当一些有趣或重要的东西没有被描述或记录下来时，它可能没有被考虑过，或者设计者可能隐藏了它的问题。“
19. 多样性 —— 从不同角度思考。
20. 松弛式探索 —— “让你自己分心吧……因为你永远不知道你会发现什么……但是要定期根据任务来评估你的状态 “
21. 投入并退出 —— 从最困难的部分开始，看看会发生什么，想退出就退出。
22. 拉姆斯菲尔德式探索 —— 调查已知的未知，考虑未知的未知。
23. 不要停下来 —— 当你找到你要找的东西时，多想想看是否有更好的东西等着你。
24. 总是暂停 —— 分析（和设计）是一个连续的活动，是不是暂停一下。
25. 由他人完成–找出由他人执行的测试类型；您可以跳过或轻松覆盖它们。
26. 上下文分析 - 找出当前情况下哪些因素可以指导你的测试工作。
27. 测试框架 —— 将你的测试活动与你的测试任务联系起来，并了解更多信息。
28. 我做了什么假设 —— 解释你的测试活动，并提出质疑。

这些活动都围绕着理解什么是重要的。为了获得好的测试元素，这是必不可少的，通过执行此活动，你们将产生相同的理解。这是一个积极的循环，值得花很多时间。

不可见的分析

大多数时候，不可见的分析会在你的脑海中迅速进行；你会注意到一些重要的事情，并立即用一个测试想法进行验证（写下来或执行）。这是非常好的，只有当过程需要审查时才需要记录分析。

如果你通过这种方式来训练你的技能，你可以进行得更快，并通过更好的方式来分享你的思考。

创造力很重要，你对产品的了解和思考越多，就会出现更多的元素和想法。把它们放在名单上，包括那些看起来很疯狂的，以后再删除也不迟。正如 Robert Sabourin 所说：收集所有你能找到的测试想法！我的经验是，有目的的删除一个测试比因为时间不够或忘记而跳过它要好！

备忘录

当你从各种信息源中发现重要的东西时，简要地记录在备忘录上是主要是为了你自己，而不是为了其他人。这将使过程可评审，可重建，并像知识转移一样具有力量。

你可以在任何相关文档上使用编码（例如描述标记）来找到和重新排列信息。

定期更新备忘录的以下部分对许多人来说是适用并有用的：

• 测试想法的资源
• 客户配置
• （用户）工作区
• 用户反馈问题的根本原因
• 在 XX 软件中发现的 bug
• 最重要的质量特征
• 应该优先执行的测试
• 单元测试中需要捕获的典型 bug

也许你可以说服需求分析人员分享备忘录，给出一些细节，一些不能用需求格式表达的需求。一些对用户有实际感受的需求用文字表述时，很多信息就会丢失…

质量特征

质量特性描述了大多数软件受益的属性。它们可以用于整个产品或细节。整个由细节组成。细节的质量是由整体决定的。

这些特性作为任何软件的测试思想触发器是通用并且富有成效的。有些对你来说是无关紧要的，有些容易满足，有些是非常重要并难以满足的。有关能力、可靠性、可用性、魅力、安全性、性能、IT 能力、兼容性、可支持性、可测试性、可维护性、可移植性等领域令人鼓舞的概念的完整列表，请参见下页的海报。这些描述没有数字；度量是危险的，因为数字隐藏了真正重要的东西。

与你的同事/利益相关者一起浏览列表，他们可以帮助你聚焦，同时了解软件（测试）的复杂性。当特性冲突时，讨论项目的每个 case。

这种分类也可以作为更仔细的非功能性测试的起点，它将专门的测试和轻量级方法有效地结合在一起。

软件质量特征

阅读下面的清单同时思考你的产品/功能。为你的上下文（环境）添加细节，并且将这份清单内化为你自己的东西。

能力：这个产品提供了有价值的功能吗？

• 完成度：所有终端用户想要的重要的功能都是可用的
• 准确度：产品中任一个输出或计算都是正确的，并以有效的数字呈现
• 效率：以高效的方式执行其操作（不做不该做的事情）
• 互操作性：不同的功能以最佳方式相互作用
• 并发性：能够执行多个并行任务，并与其他进程同时运行。
• 数据兼容性：支持所有可能的数据格式，并处理噪音
• 扩展性：为客户或第三方提供添加功能或更改行为的能力

可靠性： 在繁多并且困难的场景下，可以信任这个产品吗？

• 稳定性：产品不应该引起崩溃，不应该有未处理的异常或者脚本错误
• 鲁棒性：产品能优雅地处理可预见和不可预见的错误。
• 压力处理：当超过各种极限时，系统如何处理？
• 可恢复性：在发生致命错误后，可以恢复并继续使用产品。
• 数据完整性：所有类型的数据在整个产品中都保持完整。
• 安全性：产品不构成对人身或财产的损害。
• 灾难恢复：如果真的真的很糟糕的事情发生了怎么办？
• 可信赖性：产品的行为是否一致、可预测和可信？

可用性： 产品是否易于使用？

• 自解释性：产品本身会引导用户发现产品的可能性。
• 直观性：很容易理解和解释产品的功能。
• 简约主义：产品的内容和外观没有多余之处。
• 易学性：学习如何使用产品既快捷又容易。
• 可记忆性：一旦你学会了如何做某事，你就不会忘记它。
• 可发现性：通过探索用户界面，可以发现产品的信息和功能。
• 可操作性：有经验的用户可以非常快地执行常见操作。
• 交互性：产品具有易于理解的状态和与应用程序交互的可能性（通过 GUI 或 API）。
• 控制：用户应该感觉到对软件过程的控制。
• 清晰性：是否每件事都有明确和详细的表述，描述用一种可以理解的语言，不留任何怀疑的余地？
• 错误：错误信息翔实，不易出错，出错后容易修复。
• 一致性：整个产品的行为都是一样的，只有一种外观和体验。
• 可裁剪性：可以为灵活性指定默认设置和行为。
• 可达性：该产品可供尽可能多的人使用，并符合适用的可达性标准。
• 文档：有一个帮助，可以帮助并匹配功能。

吸引力： 产品有吸引力吗？

• 独特性：产品是可区分的，并有其他产品没有的东西。
• 满意程度：使用后感觉如何？
• 专业精神：产品是否具有专业精神，并符合目标？
• 吸引力：产品的所有方面对眼睛和其他感官都有吸引力吗？
• 好奇：用户是否会感兴趣并尝试使用该产品？
• 入口：用户在使用产品时是否会被勾、玩得开心、流畅、全神贯注？
• 宣传：产品是否应该使用最新、最好的技术或者想法？
• 预期：产品超出预期，并且满足了你自己都不知道的需求。
• 态度：产品以及其携带的信息是否以正确的态度、使用正确的语言和风格与用户交互
• 直接性：产品给用户的第一印象是否深刻？
• 故事：有没有关于产品的初始、构造或使用的引人入胜的故事？

安全性： ** *** 产品在以非预期的方式使用时是否有保护？*

• 鉴权：产品的用户识别机制
• 授权：产品对经过身份验证的用户可以看到的内容和执行的操作的处理。
• 隐私：不向未经授权的用户泄露受保护的数据的能力。
• 安全漏洞：产品不应该有社会工程学漏洞。
• 保密性：产品在任何情况下都不应披露有关基础系统的信息。
• 牢固性：抵抗渗透攻击的能力
• 无病毒：产品不会传播病毒，也不会被识别为病毒
• 防盗版：让非法复制和分发软件代码变得不可能。
• 合规性：产品遵循的安全规范。

性能： 产品是否足够快？

• 载荷：产品对不同的环境（比如慢速网络）有很多的限制。
• 资源利用：适当使用内存、存储等资源。
• 反应能力：一个操作执行的速度。
• 可用性：系统可以在需要时使用。
• 吞吐量：产品处理许多、许多事情的能力。
• 耐久性：产品能长期承受负荷吗？
• 反馈：系统对用户行为的反馈是否适当？
• 可伸缩性：产品的伸缩性如何？

IT 能力： 产品是否易于安装、维护和寻求支持？

• 系统要求：能够在支持的配置上运行，并处理不同的环境或缺少的组件的情况。

• 可安装性：产品可以安装在合适的平台上，并有合适的输出。

• 升级：易于升级到新版本而不丢失配置和设置。

• 卸载：卸载时是否删除了所有文件（用户或系统文件除外）和其他资源？

• 配置：安装是否可以通过各种方式进行配置，以支持客户的使用？

• 可部署性：产品可以由 IT 部门发布到不同类型的（受限）用户和环境中。

• 可维护性：产品及其工件是否易于维护和为客户提供支持？

• 可测试性：客户如何有效地测试部署的产品？

兼容性： 产品与软件和环境的交互效果如何？

• 硬件兼容性：该产品可与硬件组件的适用配置一起使用。

• 操作系统兼容性：产品可以在制定的操作系统版本上运行，并遵循典型的行为。

• 应用程序兼容性：该产品及其数据与客户可能使用的其他应用程序协同工作。

• 配置兼容性：产品融入环境配置的能力。

• 向后兼容性：该产品能做上一个版本所能做的一切吗？

• 前向兼容性：产品是否能够使用未来版本的工件或接口？

• 可持续性：对环境的影响，例如能源效率、开关、节电模式、远程通信。

• 标准符合性：产品符合适用的标准、法规、法律或道德。

内部软件质量特征

这些特征不会被终端用户直接体验到，但是对一款成功的产品来说同等重要。

可支持性： 用户在使用过程遇到的问题能否获得技术支持？

• 标识符：是否易于识别产品的各个模块和版本，或者特定的错误信息？

• 诊断：是否可以了解有关客户情况的详细信息？

• 疑难解答：查明错误（如日志文件）并获得帮助是否容易？

• 调试：当需要时，你能观察软件的内部状态吗？

• 多功能性：能够以比最初设计的更多的方式使用产品

可测试性： 检查、测试产品容易吗？

• 可追溯性：产品以适当的级别和可用的格式记录操作。

• 可控性：独立设置状态、对象或变量的能力。

• 观察力：观察应该被测试的事物的能力。

• 可监控性：产品能提示它在做什么/如何做吗？

• 可隔离性：单独测试部分的能力。

• 稳定性：对软件的更改是可控的，而且不会太频繁。

• 自动化：是否有可以使用的公共或隐藏编程接口？

• 信息：测试人员学习需要学习的东西的能力。。。

• 可审核性：产品及其生成的产物是否可以验证？

可维护性： 产品能否用低成本来维护和扩展？

• 灵活性：能够根据客户的要求改变产品。

• 可扩展性：将来添加功能是否容易？

• 简单性：代码并不比需要的复杂，也不会影响测试的设计、执行和评估。

• 可读性：代码有充分的文档记录，易于阅读和理解。

• 透明性：理解底层结构容易吗？

• 模块化：代码被分成可管理的部分。

• 重构性：你对单元测试满意吗？

• 可分析性：发现缺陷或其他相关代码的原因的能力。

便携性： 是否允许将产品传输到不同的环境和语言？

• 可重用性：产品的某些部分可以在其他地方重用吗？

• 适应性：改变产品以支持不同的环境是否容易？

• 兼容性：产品是否遵循通用接口或官方标准？

• 国际化：产品易于翻译。

• 本地化：是否对产品的所有部分进行了调整，以满足目标文化/国家的需求？

• 用户界面的健壮性：翻译后的产品是否同样好看？

将测试想法融合

描述测试想法融合的过程是件很困难的事情。测试想法的融合涉及到大量的信息源，对重要性的感觉，以及一些创造性想法来提出巧妙的测试方法和有效的执行方法。

最简单的方法是拿着需求文档，重新定义里面的每个项目，并可以选择使用等价类添加一些细节。最好的方法是使用各种各样的信息源，并产生可测试的测试想法，这些想法很有可能是有效的。一个不可能的方法是以所有可能的方式组合所有重要信息。

相反，你应该使用每个重要的元素，以及你认为重要的每个组合。评审是有帮助的，实际的产品会邀请参加一些测试，而且测试的速度会引导你找到你所处环境中的最佳想法。白板思维图上的团队协作不需要花费太多时间。

我建议写下测试的想法，至少要有一个高等级的粒度，这样它们很容易用于讨论和计划。如果评审没有完成，或者软件已经可用，则在执行后将值得注意的部分连同结果一起写入会更快。

不要试图覆盖所有方面，因为你办不到。而是要确保有一个广度，并指望偶然性找到成功产品所需的信息。在测试执行过程中，当你看到实际可以使用该软件做什么时，一些测试想法就随之产生了。

当你有足够的测试想法时不要停止。再想一想，你可能会找到更好的方法，或者解决老问题的新方法。

使用的技术都是经典的技术：等价划分、边界值分析、状态模型、分类树、数据流，还可以直接说明要测试的内容或其他有用的东西。

出于培训的目的，各种分类测试是很好的，如基于风险的、基于规范的、领域测试等，但在我的实际工作中，在这些类型之间快速切换更为有效，并为不同的材料制定自己的方法。

尽管如此，这里有一个测试思路的替代分类：

持续更新的测试想法

持续更新的测试想法是不可能一次性达到完整的。只要有更多相关信息被披露，它们就会继续进行。一个很好的例子是质量特性，比如稳定性；你测试的越多，你对产品稳定性的了解就越多。你可能不只是在后台进行重要特性的测试，但作为补充，它非常强大，而且非常节省资源。

另一个例子是免费的持续进行的稳定性测试。测试过程中测试人员将相关的属性都抛诸脑后，但异常一旦出现就会被注意到，并且与相关人员沟通。

经典测试想法

经典测试想法处理的是特定的、可以被写成 “验证……” 格式的东西。它们可以是需求的镜像，或者其他测试人员知道的东西。

别误会，这些很重要。对于功能的核心部分，为了覆盖所有必须的测试内容，具有明确预期结果的经典测试设计技术可能是有必要的，因此你应该知道如何使用它们。对于功能测试，你可以关注独立的功能或者使用系统透视图。

为了便于评审和报告，请注意测试用例的粒度；与其使用十几个测试，不如使用一个测试 “验证对无效输入（空、空格、字符串、重音符号、Unicode、特殊 ASCII、长、错误分隔符）的适当处理”。在某些情况下，甚至可以使用 “验证是否满足显式需求”，并将重点放在更有趣的测试思想上。

还可以利用这个机会识别哪些测试更适合自动化，哪些测试最适合自动测试，以及工具辅助和手动测试。

组合测试想法

许多问题并不是孤立出现的（这就是为什么单元测试非常好，但远不是一个完整的解决方案），因此测试希望以不同的方式和顺序将特性、设置和数据一起使用。

场景测试是一条路要走，如果不值得找出最常见、最容易出错、最重要或最具代表性的是什么，那么成对测试就足够了（但是具有产品知识的测试人员可以立即告诉您哪些互操作性是不可忽视的）

组合测试思想使用许多测试元素在一起，因为我们认为它们可以相互影响，或者我们不知道。

非正统测试想法

需求通常是为了 “测试”（但通常的意思是 “验证”）而编写的，这很容易导致需求被量化，并且常常是契约式的，而不是描述真正的需求和愿望。

错过真正重要的东西的风险可以通过测试不一定必须的指向伪造假设的场景来减轻。“你是为数不多的几个在发货前详细检查完整产品的人之一”

非正统的测试思路是开放的，基于一些有趣的东西，但没有办法标定通过/失败的状态，更旨在调查和探索有用的信息。

有了创造力，你可以想出解决测试问题的独创方法。

可用性测试可以通过询问任何重度用户的想法来解决。

快速浏览十几种不同的设计，也许最能评价产品魅力。

如果有一百种选择，你可能想冒险，只随机看五种。

一个未知的区域可以被模糊地表达出来，集中在创造偶然性上。

这些对于获得反馈尤其重要，因为一个非正统的测试想法可以产生另外两个，更好的想法。这也是一个将他们视为无关紧要的人的机会。

可视化的测试想法

有些东西是无法用语言表达的。而且很多事情都能更有效地与图像进行交流。尝试使用测试的可视化表示，因为它们可以产生新的想法和理解。

示例：状态模型、架构图像、技术表示、测试元素关系、任何类型的激励图像。

和其他的一样，可视化的测试想法，可以转换成其他类型，变形成许多或者是最适合的。

是什么和怎么办？

大多数的测试想法可能会集中在测试什么上。有些还将说明如何测试它。这可以有很多好处，例如，如果你写你将使用 Xenu 的链接检查器，有人指出有另一个工具更适合这个测试目的。有时从一个测试想法到一个实际的测试可能是非常困难的，这使得测试执行者（可能是你自己）能够获得信任和机会

要知道 “什么” 和 “如何”，但要把它们作为一个整体来对待，因为这样会产生更有效和创新的测试，以及不同领域之间的许多协同作用。用一种整体的心态：在你细致入微的同时，你应该关注全局，关注大系统。

这些类别是人为的，只是用来更好地解释过程。当你知道的足够多的时候，忘掉它们，重新构建适合你、你的同事和你的公司想法的测试设计模型。当你学到更多的东西时，一定要改变并加入你的测试想法。复习你的考试想法。你的问题，假设和答案将会出现。

测试设计启发

设计测试时允许使用所有方法。使用任何信息源，任何偏差，并依赖于你的直觉，这可能是重要的测试。

如果这些经验法则似乎适用，也可以利用它们：

1. 所有的分析启发法都可以用作设计启发法。
2. ALAP（更可能的保持最新）—— 尽可能的保持测试的规范细节为最新。事情都会发生变换，你会从最新的信息中了解更多
3. 各样的半度量方式 —— “与其完美地进行一两种测试，不如在相当好的水平上进行更多不同类型的测试。”
4. 越快越好 —— 这样你就可以从产品中获得更多信息。
5. “把所有应该自动化的测试都实现自动化。”—至少完成一次测试后，你会更清楚这一点。
6. 不玩花活
   1. 使用简单的测试也能达到目标
   2. 你不必使用花哨的测试技术，特别是在不需要的时候
7. 复杂度：
   1. 复杂测试能够让你更有效率
   2. 在设计复杂的测试时不能太小心
8. 自由覆盖 —— 通过一次测试，就可以覆盖很多不同的内容。利用质量特征的持续性测试想法，将这些方法保留在你的意识深处，关注异常的发生。
9. 适当的粒度 - 考虑测试的详细级别，以提高可评审性。
10. 最具代表性–使用最常见、最容易出错、包罗万象、最重要的示例
11. 重要性原则 - 将大多数测试集中在主要目的上，但要寻找其他目的和可能的错误
12. 偶然性——如果测试能发现我们不知道的重要事情，那就更好了
13. 可以丢弃 —— 不要害怕丢弃你不再相信有相关性的测试
14. 当我感觉到它的时候我就知道了——试一下这个软件，你就会感觉到什么是重要的，什么是容易出错的，以及如何测试它。
15. 直觉——“当你在思考难以预测的事情并且信息很少的时候，相信你的直觉。”
16. 从软件测试中收获课程的五个例子 —— “在边界测试…测试每个错误消息…测试不同于程序员的配置…执行设置很烦人的测试…避免冗余测试。”
17. 与信息目标保持一致—测试是否可以针对不同的信息目标进行调整？
18. 良好的测试 —— 强大、有效、有价值、可信、可能、非冗余、激励、可执行、可维护、可重复、重要、易于评估、支持故障排除、适当复杂、负责任、性价比高、易于理解、能够实现偶然性。
19. 改变策略——如果你的测试没有揭示新的、有趣的信息，那么是时候改变策略了。
20. 用在别处？ —— 这个伟大的测试想法能否用与于领域的测试？
21. 谁能做到？–你可能会包含你无法执行的测试想法。
22. 多样性审查——如果审查者提供新的内容，请找一个想法更为不同的人。
23. 未读测试设计 —— 如果开发人员没有阅读你的高等级的测试设计，请询问他们原因。
24. 最喜欢的技巧 —— 你最好的测试设计技巧可能不是完美的匹配，但它可能会给你最好的结果。
25. 任何与探索性测试、基于经验的测试或错误猜测相关的技能都是有用的。
26. 元问题 —— 对于棘手的设计问题，您可以使用诸如 CIA Phoenix 清单之类的问题

测试价值

在某些时候，你需要评估、决定运行哪些测试。它可以在分析、综合测试想法或执行测试时完成或考虑。也许你会一直这样做，我想你会决定你认为最重要的测试。这并不神奇，但包括很多方面：风险、速度、机会、承诺、历史、偶然性、优良性。

你不会想花费太多时间来确定测试的优先级，相反，有一个称为 testworthy 的边界会很自然：

不考虑风险、需求、测试方法等方面，如果我们获取的信息值得我们花在收集上的时间，那么测试是有价值的。

Gerd Gigerenzer 在《适应性思维》中描述了他的理论（起源于 Herbert Simon），直觉是建立在启发式的基础上的，我们正在使用快速而节俭的决策树，以便在信息有限的复杂世界中做出正确的判断。

为了解释和分享推理，给你的直觉增加透明度；你可以尝试使用决策树进行测试分类：

问题的顺序和内容可能会多种多样。在这种情况下，我先检查速度，再检查重要性，因为我想有机会找到我们不知道的重要事情。另一方面，“相关” 的问题可能会去掉原本完美的测试，但这是可接受的。我们不能涵盖方方面面。

是否值得执行测试的工作也存在一个平衡点。

本文的目的是帮助测试人员在无尽的软件使用可能性中找到最值得测试的部分。

测试执行

有些测试设计最好留到测试执行时再做。当真的拿到软件的时候，结合细节你可以做出更好的决定，你也可以判断哪些变化和偏差是快速和富有成效的。你会发现一些你正在寻找的信息，还有一些你不知道你需要的信息。你将了解哪些方面容易出错，哪些方面可以快速测试，哪些方面我们希望了解更多，你实际可以使用软件做什么，这些方面是如何连接的，也许最重要的是：哪些方面可以变得更好。

将这些信息反馈到测试设计中，重新创建和重新安排测试，回溯那些比你最初认为的更重要的信息源。

在试图找出可能的问题时，还需要很多详细的变量，需要设计和执行额外的测试，以便生成一个真正好的问题报告。

自由度

探索性测试的现代定义涵盖了这一点：

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

如果测试是一个没完没了的抽样问题，你不需要任何限制因素。多样性需要自由，需要在一时冲动中抓住机会的能力。

有了高度的自由度，你可以根据需要更改测试环境；可以进行变化和偏差以最大化你的情况所需的多样性。你可以使用不受控制的环境和测试人员，因为他们可以提供你不知道你在寻找的信息。

测试执行启发

有很多测试执行的启发；以下是我认为与设计方面相关的：

1. 所有的分析启发式和设计启发式都可以用作执行启发式。
2. 基本的启发 —— 如果它存在，我想测试它。
3. 重要问题优先——先找出最重要的问题
4. 柔和的（？）开始——如果方便的话，首先看看大的功能工作是否正常。
5. 更宽泛的区分——如果 “这个” 可以或不可以，我们可以跳过 “那个”。
6. 背景复杂性——使用比需求更复杂的 “文档”。
7. 再做一件事——另外做一些容易出错的、大众的或者用户可能会做的事情。不要想太多，做点什么，看看会发生什么。
8. 死亡蜜蜂启发 - 如果我改变了一个数据文件，发现我正在测试的应用程序不再发生崩溃，下一步我要做的就是再次改变它，这样我就可以再次看到崩溃。
9. 隆隆作响——当产品做了奇怪的事情，一个大灾难可能会发生。
10. 慢慢挪动——以一种刻意过度精细的方式做某事
11. 用户错误——研究无意（典型）错误
12. 行动方法——成为一个 “真正” 的用户
13. 二分法——当有奇怪的事情发生时，去掉 “一半”，直到找到必要的成分。
14. 可翻转性启发——尝试从意外使用中获得价值。
15. 基本配置矩阵——确定跨越 “边界” 的几个平台
16. 并发测试执行——同时运行多个测试想法以获得新的交互和想法
17. 似曾相识的启发式方法——当遇到错误消息时，多重复一次（如果不完全相同，代码是可疑的）
18. 看看很多地方——测试结果可以通过几个地方来解释。
19. 其他地方是否存在问题——发现的问题是否存在于其他地方？
20. 直觉 - “相信你的直觉。尝试任何感觉有希望的测试”
21. 结对测试——协同测试执行激发新的更快的思考。
22. 测试辅助——有工具可以立刻帮助我吗？
23. 极性动态——在谨慎与快速、嬉戏与严肃、客观与主观等之间切换。
24. 现在——“我现在能做的最好的测试是什么？
25. 情绪——运用你的感官。
26. 新视角发现失败——看看新的东西；让别人看看你的东西。
27. 即兴表演
28. （不）确定性问题——总是有问题，但它们可能并不重要
29. 我可能用错了启发——如果我发现许多问题，可能是我的模型是错误的。

快速测试

用一些快速的，并不总是有效果的测试来刺激你的执行（这些测试来自 Kaner/Bach 等.)

1. 鞋子测试——找到一个输入字段，将光标移到它上，将鞋子放在键盘上，然后去吃午饭。
2. 边界测试——测试边界值因为边界的错误编码是一个常见的错误。
3. Whittaker 攻击
   1. 输入：强制错误消息、默认值、浏览数据、溢出缓冲区、查找交互、重复多次。
   2. 输出：强制不同、无效、属性更改、屏幕刷新。探索存储的数据和计算。填充或损坏文件系统；无效/不可访问的文件。
4. 干扰测试——取消、暂停、交换、中止、后退/下一步、竞争、删除、注销。
5. 跟踪最近的变化——意外的副作用。
6. 探索数据关系——利用依赖关系，跟踪数据，干扰，删除。
7. 变化之旅——尽可能在各个维度上变化
8. 复杂度之旅——查找最复杂的功能和数据，创建复杂的文件。
9. 示例数据之旅——尽可能使用任何示例数据。越复杂越好。
10. 持续使用 - 测试时，不要重置系统。打开窗口和文件。让磁盘和内存使用量增加。你希望随着时间的推移，这个系统会自己打结。
11. 调整 - 将某些参数设置为某个值，然后在以后的任何时间将该值重置为其他值，而不重置或重新创建包含的文档或数据结构。
12. Dog Pilling——一次运行更多进程；同时存在更多状态。
13. 减弱——当系统处于适当的状态时开始使用一个函数，然后将状态部分更改为不适当的状态。
14. 错误消息处理——使错误消息发生。重点测试错误被忽略后的情况。
15. 点击狂热——测试不仅仅是 “敲击键盘”，但这句话并非空穴来风。试着敲击键盘。试着到处点击。
16. 多个实例——同时运行应用程序的许多实例。打开相同的文件。
17. 功能交互——发现各个功能交互或共享数据的位置。寻找任何相互依赖的关系。浏览他们。给他们压力。
18. 便宜的工具！–了解如何使用 InCtrl5, Filemon, Regmon, AppVerifier, Perfmon, Task Manager, Threadhijacker, Zed Attack Proxy, Color Oracle（所有这些都是免费的）
19. 资源匮乏——逐渐降低内存和其他资源，直到产品优雅得降级或不优雅得崩溃。
20. 执行 “作者说”——查看联机帮助或用户手册，找到有关如何执行一些有趣活动的说明。做那些动作。然后即兴表演。
21. 疯狂配置——在安装产品之前或之后以非标准或非默认方式修改 O/S 配置。
22. 摸索——找到产品中产生大量数据或执行某些操作非常快的方面

解释

一切都是解释。测试的目的不是为了让设置通过或失败变得容易，这并不意味着什么。在寻找重要信息时，你应该保持开放和广泛。有时有必要在没有预期结果的情况下开始一项测试，或者手头只有陈旧的文档（甲骨文），更是利用你的判断力和好奇心来确定问题的细节或值得注意的信息，以及什么是重要的。通常你需要做后续的测试来找出最后的结果意味着什么。你可以看很多地方以避免解释错误。

你可以交流任何你认为对测试人员发现诸如错误、风险、问题、问题、工件、古董、测试、依赖性、问题、价值观、方法、想法、改进、解决方法、框架、连接等事情有价值的内容。

如果你有一把完美的钥匙，毫无疑问，那就把它当作你的神谕吧。

随机性

即使是最好的测试设计，你也不会发现产品的所有重要之处。但是，通过开放和好奇的测试执行，你可以利用软件测试中的偶然性。

如果你没有意外的经历，使用这个超级好的做法：

1. 对随机性保持开放——最重要的事情往往是在寻找其他东西时发现的。如果我们知道所有 bug 的确切位置，那么自动化或详细的测试脚本就足够了（或者我们根本就不必费心测试了？）所以一定要看整个屏幕，还有其他很多地方。奇怪的行为可能是不相关的，或者是非常重要信息的线索。测试总是需要抽样，而偶然性可以成为你的朋友和救星。

偶然性不是运气，但包含了运气。

终章

以上描述的测试设计阶段在实际中并不是线性完成的。可能它们涉及到各个方面，跨越了几个版本，并且随着测试结果的解释出现了许多变化和新想法。

这个过程看起来是这样的：

在执行探索性测试时，当考虑一个全新的想法时，最非正式的测试设计可能会在专家测试人员的头脑中以极快的速度发生；或者它可能是测试脚本/案例/场景的基础，这些脚本/案例/场景是事先仔细研究和设计的。好的软件测试使用许多不同的方法

跟随气味，看很多地方，用不同的视角，改变很多事情，很少的事情，倾听你的感受，使用你知道的数据，不要重新启动系统，让它简单，复杂，即兴！

覆盖率

写关于测试设计的内容却不提覆盖率是很可疑的。但是一个有代表性的覆盖率模型至少是非常困难的，而且如果不删除关于什么是重要的（这是我们应该追求的覆盖率）的信息，就不可能获得量化格式。例如，代码覆盖率，我们可以问，测试代码是否比产品是否有用更重要。

所提出的测试设计更能产生定性信息，即主观的、对重要内容敏感的信息，就像顾客与产品的关系一样。你可以报告什么是测试与否，以及你的重要发现，而不必提及覆盖率数字。

从测试的角度来看，覆盖模型有两个目的：

1. 识别待测试的东西
2. 决定什么时候测试完成

正如我们在前几章中所看到的，有许多模型和方法可用于确定要测试的内容。我怀疑将所有这些模型和其他模型塑造成多维覆盖模型或模型的模型是否有用。

至于 “何时停止” 的问题，我们可以从相反的角度来看待：

测试执行可以继续，直到找不到新的相关信息为止。

改变策略，或者停止；测试已经饱和。

如果我必须选择一个测试覆盖模型，我会尝试覆盖所有被认为重要的东西。

缺点

虽然我相信这本小书有很多有用的信息，但它远不是完美的。

这些是我知道的最重要的问题：

• 第一个雄心勃勃的测试设计启发集，它肯定可以改进
• 不适合所有人——太理论化，太过浓缩，与许多人无关
• 在许多情况下，通过/失败测试风格是预期/要求的，因此替代方法将不起作用
• 大量的重复工作，特别是分散的责任
• 一个全面的例子会使这些想法更加充实

结尾

测试人员应该摆脱仅限于需求、以验证为中心的测试用例的限制，并设计多种测试；您需要查看整个图片来查看重要的细节。

我并不是说测试就是真实的镜像，但我认为它们将有很好的机会找到关于用户和软件之间关系即将到来的现实的东西。

通过使测试设计透明，你就有了一个状态报告的种子。

你还应该努力争取参与的人的多样性。除了有一个混合的测试团队，这也意味着其他角色应该以不同的方式参与进来；不是因为他们不信任测试人员，而是因为他们都关心制作一个伟大的产品，所以很多人看到了更多。以同样的方式；您可以在项目的早期参与，并帮助收集/分析/理解需求。

我想我已经涵盖了我所知道的关于测试设计的最重要的事情。这不是一个完整的故事，只有一些部分与你相关。我真的希望每一个读到这里的人都至少找到了一些新的想法。如果你没有，我希望你自己写论文，寄给我。