Introduction 简介

这篇文章描述了如何利用多样的信息来源的方法来进行有野心的系统测试。
在我第X次感觉到，现有的测试设计技术并没有捕捉到我10年来测试同一个产品套件的方式之后，我开始深入研究它。这产生了我和我同事们一起学习到的广泛思想的一个概况。
我将描述测试策略的整体合并、测试分析、测试设计、测试执行；它们在理论上可以分割且可以融入实际的活动中。这并不是关于某个独立测试用例的细节，测试设计也可以是俏皮话、章程或者你脑中的一个心理模型。它是跟处理错综复杂的事务、提升你的技能和在过程中学习有关。
我想要强调测试的结果；一个广阔的采样空间，使得你具备意外发现珍奇事务的能力和实现重要领域的真正饱和度。这可能更适合于关注所有重要问题的手工系统测试者、并想要发现比通过\失败指定需求更多的质量信息。
这是我和其他很多人一直在使用的测试设计方法。

The Essence 精华\本质

从多样的来源中学习，产生关联的测试元素，合成值得测试的测试点，并带着意外发现的能力去执行
软件测试人员可以遵循社会科学基础理论的思想；我们应该使用与主题相关的各种信息来源（需求、说明书、技术原型、工具箱、模型、系统、质量目标、质量属性、测试技术、测试观点、跟其他人的对话、风险、可能性）；我们应该把各种事务聚集在一起，运用创造力，创造一个由许多看起来对测试很重要的想法组成的理论，并同时考虑结果。
我鼓励测试人员去使用比需求更多的东西，去理解结合各种不同类型事物的需要，去同时兼顾全局和细节。这篇文章是给有野心的项目，甚至可能横跨多个发布版本。但是当各种资源很少、或者你非常肯定你用的技术是最好的情况下，不适用。
这可能看起来很重，但是人类有着非常显著的容量。

image.png
这些活动依赖于测试人员的技能，这个技能跟随时间成长，在最好的情况下跟随着大量的产品和项目环境知识；并在产生和分享你自己的经验法则、你自己的测试设计启发中加速成长。

Grounded Theory 基础/扎根理论

我看见一个散漫的科学理论，被用在社会科学上，作为一个定性的、彻底的现象分析。
科学家们仔细检查这个主题，收集了很多资料、代码文件和备忘录中的观念，把它们结合成分类，从而形成了一个理论。
像传统的自然科学一样，一开始没有假设，而且跟我的软件测试非常类似；如果我们认为我们马上就知道了所有重要问题的话会很危险。他们承认我们在处理一个采样问题，意外发现珍奇事务的本领是你的一个优势。基础理论的产生是直到没有新的、改变的信息被发现；这个理论已经饱和了。
我认为这是软件测试的一个很好的匹配，尤其是它强调研究者必须使用他的创造力。
在借用其他领域的观点时，你需要考虑是否有一些软件测试的特定方面会导致观点不合适。基础理论是一种研究方法，去尝试证明事务，而且其他人应该能够得出相同的结论。它经常使用人们的访谈，而不是测试。
我没有尝试去将基础理论应用到软件测试上，这是一个对我测试设计实际的描述灵感。

Test Design Theory 测试设计理论

跟传统的测试用例设计聚焦不一样的是，这种测试设计围绕于测试策略、测试分析、测试设计和测试执行，但并不强调把这些活动分割。跟随一个更整体的分析，你将同时得到交流和各种在你思维中的事务有趣地结合，这些活动相互告知。
它不能适用于任何的测试策略，但最好的是在一开始不要去定义测试策略，宁愿让多种不同的测试策略观点和结果相互融合。
一个匹配的高水平测试策略应该是：
我们在构建现成的软件，且它花费了相当多的钱。客户期望在他们的数据、环境和他们的需求下使用产品，我们希望避免补丁和其他导致图像丢失的问题。我们也希望你帮助开发加速，创造更容易得到的果实。
在你学习的时候，低水平的测试策略会很自然的聚集在一起。但你应该检查明确的需求，执行特许或者自由形式的探索性测试。
测试分析是测试文献中一个非常明显未经阐述的领域。我猜测是因为传统\正式的测试根本不需要测试分析，需要被测试的内容已经完全地描述在了需求文档上，也是因为“大部分已经发行的测试技术都是基于单元\组件测试”。然而这是不幸的，因为更重要的测试决策在你选择哪些测试元素来考虑、测试到什么程度的时；在你尝试找出调查领域的好方法和从用户角度来设计方法，找出软件的重要元素时已经决定了。同时探索性测试的本质大部分也是关于这个，比起检查，我对测试更有兴趣。
基于多样的信息来源找出聪明的方式来测试，是测试设计中最令我着迷的一部分。
我对设计测试用例并不感兴趣，让我更感兴趣的是设计测试点，至少是比测试用例高一个等级。实际的执行细节通常是测试人员可信任的，预期结果并不是必要的，我们经常可以看到我们找到的，和报告任何值得注意的内容。
跟很多现有的测试设计技术相反，我的关注点在于找出相关联的来源，分析他们，选择策略和技术，而不是设计测试用例的细节。
我正在写的在一定程度上跟错误推断和基于经验测试相似，但是更相似的是探索性测试（承认现有的软件、测试结果应该用来指导接下来的测试，如果有帮助的话）。如果你在非常多的信息来源中找寻知识，你会聚焦在学习，而这正是探索性测试最关键的部分。
也许这篇文章只是探索性测试核心领域的另一个呈现，但同时，这种测试设计可以被同样用在照稿子测试、希望看起来比需求和说明书文档更长远的测试上。

What is important 什么是重要的

我们知道完全的测试是不可能的，因为即使你为了所有质量属性执行所有代码和功能，你也不会获得所有用户数据、需要、环境和用户感受的所有可能。这意味着我们在处理一个采样问题，因此我们想主要针对重要事项来进行抽样。
测试设计应该提出测试思路，在执行时（有或没有意外发现）将涵盖大部分重要事项（这时候需求文档可以是一个好的开始）。然而这非常困难，因为对于软件来说有非常多的重要事项，这就是为什么“测试是一个极具创造力和智力挑战的任务”。
我相信在特定的情况下，你要么知道或者不知道什么是重要的。所以基本策略应该是去学习，因为接下来大部分时候你会知道。
你理解重要内容的能力会随着时间发展，但是会由于好奇和合作而加速。如果你从事于一个产品很长时间，那么把通过学习产品有用的不同方式当成你的优势，这是一段很长和有意思的学习旅程。领域知识有助于获得测试人员的思维模式，最终用户联系人让概念充实，想象去构思可行的场景和新的联系，批判思维去发现漏洞，用技术学习可以和应该做的事情。
我们可以将测试看成无穷尽的领域，有一个需求盒子和软件土豆：

image.png

带着关于软件的基础知识和它的上下文，你可以完成捕获重要事项的变奏曲。
理解重要性需要价值判断，传统上，太多定量的自然科学被放到了测试上。计算机不擅长判断什么是重要的，但人类擅长。

Software Testing Inspiration 软件测试启发

人们常说，为了可以非常好地测试产品你需要考虑很多除了明确需求之外的东西，这是对的。
最重要的原因是，在测试的时候，我们对产品知道得比完成前更多，而且测试人员会关注不同级别的细节。另外一个原因是，需求一直都是不完整的（他们不是全能的神写的，隐式需求是无止境的），有些东西必须在你理解之前去尝试，而且你并不想花太多的资源在写需求上。
我们也应该问问自己，测试是在尝试解决什么样的问题？我认为很多情况下更应该是这样的：
我们知道我们正在构建的产品会有问题。我们需要你的帮助来保证发行的产品在被用户使用时时不会有失败，并且能令用户满意的帮助他们完成任务。
而不是：
我们必须确保实际的产品能满足需求文档中的描述
多样信息来源的洞察力通常伴随着“其他信息”的一些例子，例如：有关用户需求的一些东西、阅读代码的需要、软件运行技术的知识或者对指定环境下质量特性的认知。
在10-11页，有一个完整的列表，可以被用来当作“建立你自己的检查清单时候的检查清单”。所有事情不总是相关联的，但是我推荐花一分钟的时间在每个种类上。考虑什么是重要的，决定哪些信息来源去深入挖掘。你获取到的信息可以马上给你好的测试点，可以指向重要事项，甚至是指导你测试设计上的相关细节。在很多情况下，整体的融合会让我们知道什么是重要的。
通过使用多样的信息来源，包括实际的产品和用户需求，你的测试将与现实建立更好的联系，并将成为基础。

Using Many Models 使用多模型

对软件应该完成的内容来说需求是个重要模型，但会比需求文档中的内容复杂很多。你应该去挑战需求，并用其他资源尝试去找出重要的隐藏点。
如果有各种类型的说明书（概念上的，技术的，功能上的，设计上的），它们是非常有价值的输入。你也可以通过说明书来找出其他功能，在这种情况下，测试规范可能会是最有趣的。
实际的代码也是一个模型，你可以通过阅读它获益，或者让阅读过的人给你讲解。对旧的、新的、不稳定的、未读过的、评估过的代码采取特殊的考虑。
从用户的角度来帮助模拟功能。
而最好的模型是实际的软件，你能真实的看到他做了些什么。你将会理解各个不同的模块是怎样相互影响的。在使用软件的时候，你总是会给它建立一个心理模型，即使你自己都没有意识到。
你有的心理模型并不一定需要去表达出来。这样是可以的。问你的朋友他们是怎么设想一年的，有些人并不会这么做，但仍然会对它表达的意思有一个很好的理解。你的组合测试和测试结果为你的测试空间建模，并且对所有测试模型来说，你应该同时关注内部和外部。
对其他人的模型保持开放心态，测试人员不是完美的，会跟其他任何人一样犯错误。

The Product & The Project 产品和项目

在你工作于一个产品的很多发行版本时，总是会有很多历史和很好的机会，所以你会有很多以前的运行数据可以使用。
你是否为你位置上经常发生的bug建立了错误类型目录？
你是否可以为你的bug和支撑资料打上标签，以便他们可以重新用作测试灵感？
你是怎样在早期的时候发现了重要的问题？又是怎样让一些问题逃脱了？
用户是怎样不使用你的软件尝试去解决他们的问题的？
你是否有将市场营销资料当作重要区域的指南？
你是否有在网络上搜索真实使用数据和问题？
你有也可以获取到非常多关于功能的信息和相关联的风险。你是项目的一部分、过程的一部分，你知道所有不同的产出物。
你有测试执行的上下文环境来指导你的测试设计：
什么时候你可以开始做什么？你有多少时间？
测试人员的背景和特长是什么？
有哪些内容会被其他人测试到？
这次你需要去尝试哪些新的测试类型？
你是否为经常发生的各种意外情况做好了准备？
你可能会需要一个不确定的开放式的计划来应对变化。
如果你足够幸运，有或者可以去建立一个指向重要事情的质量目标。
或许会有一些信息目标可以用一种好的方式引导你的测试活动。

People&Skills 人员&技能

在你团队和相关干系人中有很多的知识，当你有机会的时候去问问细节。赢得开发人员的尊重，在你寻找缺陷时你将获得非正式的内部技巧。
关于用户需求、常识、感受、障碍，你知道哪些？
对于用户、团队和其他感兴趣的团体来说什么是有价值的？
为了寻找出哪些内容应该被测试，你应该运用你自己和同事的技能：
调查：探索和学习
分析思维：模型细节和宏图，遵循路径
批判思维：看到问题、风险和可能性
创造力：拓宽测试范围、形成新的想法，横向思考
测试之眼：想要看到错误，关注多种类型，关注很多地方，经常查看，聚焦于重要事项，以其他人的眼光来看

More Inspiration 更多的灵感

知道很多产品实际和潜在的用途非常有益，抓住拜访或者跟用户谈话的所有机会，找出需要支持的经验，学习真正的需求：用户在尝试解决什么样的问题？
你能否使用产品内在的真实，吃自己的狗粮，喝自己的香槟？使用实际应用的产品去完成有价值的事情是我最喜欢的测试灵感。
你可以用软件产品、内部工具也包括模拟工具的形式来查看竞争者，相似的功能是怎么被执行的在他们被计算机化之前？
为了去理解商业需求、逻辑、信息、知识、标准、法律，你可以尝试跟商业专家结对测试。
知道这些技术意味着你知道软件应该怎样运行以及什么是重要的。理解怎么样去的执行测试且高效地去执行也非常关键。使用你首要的平台进行私人工作是一种捷径，因为知道相关的工具是必要的。
如果你懂得很多现有的测试理论，你可以使用很多不同的技术/途径，并有更高的机会找出重要信息。经典的测试设计技术可能在很多时候不合适（除了等价类划分一直在使用），但是在合适的场景下非常强大。
从通用的测试点比如快速测试、探索、助记符、启发式、质量特征中获取灵感，或者小技巧、攻击、检查清单和其他从书、网站、表格、博客、课程、文章、会议、谈话中的获取的信息。
不要在你的产品中使用任何没考虑过它是否重要、是否相关联的测试点，你可以随着时间创建你自己的测试点触发清单，非常简单的转化成在你实际产品中富有成果的测试。

Double work？ 双倍工作？

这可能会有争论，使用广泛的测试灵感的工作量会双倍于基于需求分析。这在一定程度上确实如此，如果需求文档的附录有着更多关于属性、特性、和一些他们收集的积极信息，会花费得少一些。
与此同时，测试以需求从来没做到的方式进入细节。在任何情况下，需求都不会规定每个和所有动作的响应时间，但是如果允许或者被告知的情况下，手工的测试人员每次都会隐式地评估特定性能。
为了去做一个好的工作，测试人员（和开发人员）需要理解真正的需求（不是文档），这会需要一些双重工作，但是也会产生由多样性带来的更丰富的、集合的理解。
此外，在做这个练习的时候，测试人员将需要使用的获得一整串资源在评估有趣的测试执行时。

37 sources of test idea 37种测试思路的资源

我们推荐在各种各样的信息来源中持续收集测试思路。
考虑以下点，思考价值、风险、机会，找到覆盖重要内容的捷径：

• 1、能力：第一个也是明显的测试思路用来思考产品本应该做的内容。需求、例子和其他说明书、或者实际软件的功能清单是一个好的开始。但也应该尝试去找出隐藏需求、文档种没有但是用户期望的东西。并对不需要的东西保持警惕。
• 2、失效模式：软件可能在很多方面失效。所以问“假设”问题，以产生测试思路，揭示内部/外部、预期/意外、（非）故意、现实/挑衅故障的处理。挑战系统容错能力；任何对象\组件都有可能失败。
• 3、模型：一个状态模型帮助识别关于状态、转换和路径的测试思路；一个系统架构图展示了哪些内容可以被测试，而且可以突出交互；一个视觉模型更容易沟通，而且建模活动经常会带来理解和新的思路。多而丰富的模型给测试带来好的思路。
• 4、数据：通过识别故意的和非故意的数据，你有了一个对测试思路的好的开始：通过应用跟随简单和棘手的数据、在内外边界、挑战数据类型和格式、使用CRUD(Create\Read\Update\Delete)、利用依赖关系、观察很多地方的数据。
• 5、环境：没有一个软件是孤岛，所以环境兼容性（硬件、操作系统、应用、配置、语言）是一个重要的测试问题，但也需要去研究你产品周围的活动。通过理解整个大的系统，你会获得可靠的测试思路，这些思路在单独考虑功能时是牵强的。
• 6、白盒：通过将测试人员的破坏性思维放置在开发人员的架构、设计、代码视角上，你可以挑战假设，也可以找到容易修复的错误。重点注意你通过黑盒角度可能不理解的结果和路径。代码覆盖不是没有价值的，它可以找出还没有被测试的内容。
• 7、产品历史：旧问题非常可能在新的系统中出现，搜索你的bug/支撑系统或者建立一个错误目录，记录严重错误和根本原因分析。将旧版本软件用作灵感和oracle。
• 8、流言：经常会有关于质量和问题的谈论，有一些会使产品和组织收到损害。将流言本身当作测试思路，消灭流言或者证明流言是你的责任。
• 9、实际软件：通过跟软件交互，你会获得关于软件中容易出错、有联系的、有意思的测试思路。如果你可以吃自己的狗粮（委婉说法：喝自己的香槟），你会处于一个更好的位置去理解对软件来说什么是重要的。如果质量是某些人的价值，那个人是我的话会非常好。
• 10、技术：通过知道软件内部运用的技术，你可以发现有可能会错的区域和事情；理解可能性和安全方面；什么时候去改变哪个参数；你可以完成正确的变奏曲，且和开发讨论技术细节。
• 11、竞争者：通过观察相似问题的不同解决方案，你可以获得最直接的测试思路，同时也可以了解最终用户感兴趣的特征。总会存在被启发到的内部解决方案（例如excel表格），也总会存在对相似目标的相似解决方案。你是否可以从竞争对手的支持、FAQ和其他资料中获取有洞察力的测试思路呢？
• 12、意图：产品的总体目标会给你测试思路的目标。问几个额外的原因？去找出真正的目标。这些可以给你最广泛的好的开始，来快速找到非常重要的问题。
• 13、经营目标：公司最重要的目标是什么？（以及部门细分）是否存在一些需求否定了这些目标？你是否知道大局、产品愿景和价值驱动因素？
• 14、产品形象：产品设计的行为和特征有可能是明确或不明确的，存在于生产或者消费软件的人的思想或围城中。如果你知道并且可以展示出对产品形象的威胁，你将有能力写出令人信服的问题报告。例如指出对营销材料的违背。
• 15、商业知识：如果你知道软件的目的和它运营的环境，你可以理解它是否会对用户提供价值。如果你获取不到这些知识，去跟知道这些需求、逻辑和环境的人合作。
• 16、法律问题：你是否需要考虑合同、罚款或者其他法律义务？在法律问题上，对公司来说什么是成本最高的？你有律师给你一些必须避免的提示吗？
• 17、创意思路：所有产品都是独一无二的，并且需要一些以前从没见过的测试思路。尝试使用横向思维（例如Edward De Bono的6个思维帽、挑衅操作、反面、随机激励、Google护目镜）来产生有创意的测试思路。隐喻和类比是让你开始新方向的好方法。
• 18、内部收集：使用或者创建在你环境中通常都很重要的事项列表，有些人称它为质量\测试模式，其他则有特定产品的快速测试。
• 19、你：你是一个用户。你可能是一个利益相关人。你很重要。充分你用你在经验、技能、知识和对问题的熟悉度上的优势。运用你的主观和感受去理解重要事情，并且不要忘记你的弱点和盲点。
• 20、项目背景：项目的原因正在推动着许多的决策，并且以前（类似）项目的历史非常值得去了解，以便进行有效的测试。
• 21、信息目标：理解测试工作的明确和隐含目的至关重要。如果您无法获得它们，请创建自己的质量目标，以引导任何功能的测试想法。
• 22、项目风险：项目中一些困难的事情可以通过测试来解决。你想要了解开发人员遇到问题的公，基于风险来调整需要最先缓解的部分去调整测试计划。
• 23、不仅仅你自己的测试思路、日志和结果可以用在后续的测试中，也可以去尝试其他项目的测试结果、Beta测试报告、可用性评估、第三方测试结果等等。你希望在状态报告中回答哪些问题呢？
• 24、债务：在我们采取捷径的时候会带来债务的持续增长，这可能是项目债务、管理债务、技术债务、测试债务或者其他任何你想要称之为的债务。如果团队在持续追踪债务清单上的内容，你可以跟进这些条目映射一组测试思路。
• 25、会话：你从其他人获取的非正式的信息，可能会包含比说明书上更重要的内容。很多人可以帮助你进行测试设计，有一些人可以更好的判断重要性。你可以从题外话中获取到什么呢？如果开发人员知道你可以找出有意思的东西，他们会给你提供软件中可疑的东西的内部信息。一组给开发人员的问题可能是一句天真的“你觉得我们应该测什么？”或者“你代码中的哪那部分你觉得应该做得更好？”
• 26、上下文分析：在现在的情况下，有什么且会怎样影响你正则测试的东西？你知道市场规律和项目驱动吗？是否存在任何事情的改变会导致需要新的测试方式？什么内容被其他人测试了？项目和它的人员有哪些力量和弱点？
• 27、众多的交付物：有很多东西可以用来测试：可执行的东西，安装装置，程序接口，扩展，代码和注解，文件属性，帮助说明，其他文档，发布说明，自述文件，市场，培训资料，样品等等。所有这些都可能包含你可以用来当作测试灵感的信息。
• 28、工具：如果有些事情可以很快完成，去尝试它是一个好主意。工具不仅仅是达到目的的手段，他们也可以被用来当作探索的起点。
• 29、质量特征：对成功的项目来说，质量特征一直是重要的，尽管OK区域可以容易的到达，或困难但关键。我们的定义包括能力、可靠性、可用性、感染力、安全性、性能、IT能力、兼容性、可支持性、易测性、可维护性、可移植性和其他的副类别。这当中的很多都可以持续的在你脑中作为测试思路，自由执行，但做好鉴别违规的准备。
• 30、产品恐惧：关系人非常担心的事情比风险更有力量，它们不需要优先次序，它们需要测试。典型的难以验证，但有用的测试恐惧是：图片丢失，错误的决策，损害，人们不想要这个热软件。不同的人有不同的恐惧；找出最重要的。
• 31：有用的场景：用户想要用软件完成或者体验一些事情，因此建立模拟产品行为顺序的各种方式的测试，而不是单独的功能。你了解的可靠的使用模式越多，你执行的测试就更实际。还可以尝试古怪的肥皂剧测试来拓宽测试覆盖范围。
• 32、领域信息：除了关于用户故障，环境，需要和感受外，你还可以花些时间在错误和成功模式下去理解客户。访问最终用户、售前人员、销售人员，市场顾问、支持人员，或者更好的是，在这里工作一段时间。
• 33、用户：考虑各种不同类型的用户（你认识的人，角色模型），不同的需求，不同的感受和不同的场景。找出他们喜欢和不喜欢的，他们接下来会对你的软件做的事情。在测试实验室中设置场景，将测试人员分配角色来扮演不同的用户，从中触发哪些测试想法？最好的当然是未经过滤的直接来自用户的信息，使用它们的语境。记住两个相似用户关于相同领域的想法可能会非常不一样。
• 34、公共收集：利用通用或指定的bug清单，代码错误，或者测试思路。在你为你的场景下建立合适你自己的检查清单时，尝试这些：

• 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、标准：挖掘相关的商业标准、法律和章程。阅读和理解用户界面标准，安全规则，政策。有些文章描述了即使符合标准也可以打破某些东西，你能否包括他们的测试想法？
• 36：参考文献：各种各样的参考资料是测试灵感的一个好的来源，例如地理产品的地图集。
  各种通用知识很容易取得，维基百科可以足以快速了解统计方法。
• 37、搜索：使用Google和其他方法是一个好的方法来搜索你正在寻找的内容和你不知道你需求的内容（意外发现）

Analysis 分析

测试设计分析部分要处理的问题是：我们应该测试什么？这包括鉴别和细化各种不同来源的信息资源，还有找出什么是\可能是重要内容的艺术。
我想要详细说一下，测试人员将产品信息分解为用于测试的元素的本能。它可以是需求细节、跟用户谈话的思考、一个网站的特色口号，这个列表跟前面章节的一样长。
Kaner把这叫做学习，Michael Bolton (and James Bach) 则使用因素分解——“因素分解是分析对象、事件或模型以确定构成它的元素的过程”。
爱德华·德博诺有通用的横向思维技术分割，明确的包括了创造性：

• 一个不是尝试找出情况的真正组成部分，而是尝试去创造零部件。
  在软件测试中，这个概念并不仅仅包含数学上的因素分解，它分析并找到构成整体的确切组件。
  在测试中，我们为了找出产品的重要信息，则宁愿去寻找一些包含了我们想要去测试的东西的有用元素。我们有可能创造了一些不公平的人工分类，因为他们会帮助我们。如果一个使用场景包括Firefox 3.6。我们可能添加所有我们任务有关联或者有测试价值的其他浏览器和平台。我们会字段地考虑浏览器设置。
  我们会添加一些我们知道或我们认为自己知道的东西；利用我们对重要事项的理解，获取元素来合成有用的测试思路。我们也将寻找很多解决方案，重要的不是构成原始信息来源的因素，而是你想要有用的测试元素，即使他们相互矛盾也没有任何关系。
  不要仅仅聚焦在重要事项上，也要关注那些可能是重要的、或可能产生其他重要信息的事项上。你想要创造有测试价值的测试，典型的例子可以是这种测试：你不知道它是否重要，但是你需要的确认它。

Analysis Heuristics 分析启发式