接
探索式测试的问与答（1） 既然学习非常重要，那么如何才能高效地学习呢？软件专家Andrew Hunt指出：“一种高效的学习环境应该允许你安全地做三件事情：探索、创造和应用。”Andrew的解释如下：
探索就是在陌生的环境中玩（Play）。你需要自由地探索才能学习。我们不仅仅接受信息，而是亲自探索和构建思维模型。玩引入了一种新奇的感觉，也就是 乐趣。用一种好玩的方式学习新资料或者解决问题，可以让这个过程变得更让人享受，也让学习变得更容易。为了更好地学习，请更好地玩。
你需要自由地创造--不介意自己的创造没有成功。通过构造来学习，而不是通过学习来构造。这是“原型”、“曳光弹” 、持续集成等方法获得成功的原因之一。
你需要在日常实践中应用到你学到的东西。你持续使用和实践的技能会在脑皮层竞争中占据统治地位，大脑会为它们提供更多方便。
这种探索应该相对没有风险，因为你肯定不想因担心害怕而止住探索的脚步。安全有助于更好地利用反馈，让失败也变得有意义。
虽然Andrew讨论的是广义的学习与探索，但是他的话解释了探索式测试的成功之道：探索式测试在本质上鼓励测试人员去自由地探索、创造和应用。
探索是带着使命在某个空间中有目的的漫游，但没有预先确定的路线。探索包括不断学习和实践。
探索式测试者持续应用他所学到的知识。所谓“学而时习之，不亦说乎”，探索式测试将学习与应用作为相互支持的活动逐步展开，为测试者的知识提升提供了平滑的学习曲线。
探索式测试有助于测试人员在合适的时间学习合适的内容，并立即应用，以获得真实反馈。这提高了学习效率和效果，并降低了浪费测试资源的风险。
在探索式测试中，测试者创造出一切有助于学习和实践的数据和工具。它们包括测试输入数据、结果检查脚本、数据分析报告和业务流程图表等。
探索式测试是一项富有智力挑战的活动，充满了乐趣。
问：“学习”有助于独立测试人员更好地工作与发展。从测试团队和开发组织的角度看，探索式测试能够提供什么帮助？
答：探索式测试有助于“机动性”，该特性在现在比以往任何时候都更重要。
随着互联网与Web应用席卷全球，软件竞争比以往更加激烈。开发组织不仅要减少缺陷，还要跟踪不断变化的用户需求和市场需求，在紧迫的时间约束下交付赢得用户的产品。这要求软件企业在业务、研发、营销等方面均保持高机动性。其中，探索式测试可以在以下方面为产品研发提供帮助。
首先，探索式测试将许多测试决策置于更合理的时机，从而避免了浪费。在Web应用等高竞争性领域中，开发组织面临模糊且持续变更的用户需求。更重要的 是，他们必须在一切明朗之前着手行动，因为交付的时机将在很大程度上决定市场的反应，此外真实的用户反馈将有助于下一次更准确地交付。面对高变动性的开发 过程，测试人员需要将测试设计合理地分配到整个开发周期，根据当前的开发进度和真实的测试反馈，做出恰当的测试决策。这有助于避免在信息不充分的情况下做 出错误的决定，从而导致严重的浪费和返工。
其次，探索式测试不停地根据实际情况，调整测试计划，优化测试策略，因此能够更有针对性地测 试，从而更快速地稳定（Stabilize）产品。探索式测试和语境驱动测试建议，测试人员总是自问：“我现在可以测试什么？应该如何测试？”这有助于测 试人员更动态地审视被测试产品和测试策略，并运用多样化的手段去探索产品。随着对业务领域的认识不断深入，随着逐渐了解产品的设计和弱点，随着对测试技术 和工具的更加熟悉，测试人员会不断调整测试策略，使得在整个产品开发过程中，重要错误的发现率都保持在比较高的水平[Kaner01]。而及时地发现重要 错误能够帮助开发组织降低风险、快速推进。
测试需要探索，而探索要要大量的思考。积极思考的探索式测试是具有挑战性的智力过程，常常需要以不确定的顺序反复实施钻研、尝试、迂回、调整、评估等活动。好的探索式测试不会使测试更简单，但是它会使测试更有效，从而在测试速度和缺陷发现上获得更多的回报。
问：探索式测试是否只适用于功能性测试？
答：作为一种测试风格，探索式测试可应用于各种类型的测试。
以安全测试为 例，请想象一下黑客是如何攻破软件产品的。他们的基本方法是“错误猜测”：通过分析已知的安全缺陷，抽象出可利用的缺陷模型，然后开发出相应的缺陷挖掘工 具。这些工具可以是黑盒工具，通过持续地输入攻击数据来发现缺陷；也可以是白盒工具，通过扫描（开源）源代码来识别漏洞。他们运行工具，分析输出中的蛛丝 马迹，一旦发现疑似缺陷，便深入探索。整个攻击过程常常需要广泛扫描、深入挖掘、迂回前进、反复尝试。从安全测试的角度看，黑客都是探索式测试的绝顶高 手。
相比安全测试只需“断其一指”，性能测试需 要建立被测试产品的性能模型，并考察它在不同负载下的性能指标，因此需要更多的预先设计。然而性能测试的关键内容：用户的行为模式、充足的高质量测试数据 和完整的性能监测指标（特别是面向业务的性能指标），是难以仅通过一次测试设计便可以获得的。性能测试工程师需要与开发团队紧密协作，通过阅读、研究、实 验等手段来探索性能测试模型和技术，并逐步挖掘用户行为、制造测试数据及建立性能指标。
问：在功能实现之前，探索式测试是不是无用武之地？ 答：对于探索式测试有一个误解，那就是探索式测试只通过运行测试以获得知识。实际上，探索式测试者能够也必须通过其他手段探索被测试软件。
语境驱动测试认为：产品是一种解决方案，它必须解决现实世界中的问题。因此，探索式测试者必须从项目关系人（包括软件用户、项目投资人和开发团 队等）的视角考察整个产品，研究显式规格说明和隐式规格说明，从而发现软件在概念、需求、设计、实现等层面上的缺陷。值得强调的是，测试人员应该主动探究 隐式规格说明，从而拓宽探索的范围。以下是一些常见的隐式规格说明。
竞争产品。竞争产品不一定是软件，例如笔记软件的竞争者就包括纸质笔记本和铅笔。
相关产品。软件套装（如Microsoft Office）中的软件往往相互补充、相互约束。
同一软件的已发布版本。向前兼容可能是非常重要的约束。
口头讨论、采访、闲聊。
电子邮件、会议记录、采访记录。
用户反馈：电话支持记录、论坛讨论、Beta测试反馈。
技术反馈：软件提交的崩溃信息、错误消息。
第三方评论：杂志文章、博客文章、社交网络反馈。
技术标准。所有软件都建立在一系列技术标准之上，某些标准会对测试产生重要影响。
法律法规。法律可能对软件有强制性约束。
领域专著。测试财会软件需要学习相关著作，以掌握财会知识。
测试人员经验。
Cem Kaner拥有法律学位，对语言文字非常敏感。他认为积极阅读（Active Reading）是探索式测试者需要具备的技能。积极阅读是一个内涵丰富的主题，广受好评的经典书籍包括《如何阅读一本书》 、《探索需求》 和《你的灯亮着吗？》 。
此外，在功能实现之前，可以通过小组讨论、头脑风暴等方式发掘测试策略和测试思路。针对一个开发中的功能，测试人员可以邀请几个同事，组织一个 测试研讨会。在会议上，大家自由发言，提出自己的测试策略，通过脑力震荡相互启发，从而获得一批观点各异、视角不同的测试策略。会后，测试负责人对这些相 对粗糙的测试思路进行整理，将完善后的结果写入测试计划。
问：如何评估探索式测试的测试效果？
答：评估探索式测试结果的前提是测试记录。
探索式测试者常常在一个固定的时间窗口内（60~120分钟），根据预设的测试目标，对软件进行Z探索式测试。这样的测试活动被称为测程（Session）。
测程类似于科学实验。一次科学实验大致可以分为以下三个阶段。
（1）实验设计：确定实验目标。科学实验的常见目的是假设检验，那么此次的假设是什么？
（2）实验记录：执行实验步骤，并记录实验所发现的点点滴滴。
（3）实验分析：分析实验数据，总结实验结果，为下一次实验提供目标和假设。
相应地，一次测程包含如下三个阶段。
（1）测试计划：明确测试目标。测试是获得信息的过程，那么此次测试要获得什么信息？
（2）测试执行：设计并执行测试用例，记录测试所发现的点点滴滴。
（3）测试分析：分析并总结测试所发现的信息，为下一次测试提供目标。
详细的实验记录是科学实验的基本要求之一。同理，详略适当的测试记录也是测试执行的自然结果，是测试评估的基本要求。通常，测试记录可以包含如下内容。
测试目标：本次测试要提供什么信息？
测试范围：本次测试覆盖了哪些功能、模块、用户情景？
测试策略：本次测试使用了何种测试方法？
缺陷列表。
在测试过程中发现的疑问，它们值得进一步探索。
可以复用的测试资源：被测试软件配置、测试数据和测试脚本等。
测程的耗时。
测程的时间分配：在测试设计与执行、缺陷调查与报告、测程的启动与结束和非测试活动上各花费了多少时间。
测试记录可以转化为测试备忘录，供今后的测程参考。测试记录也可以提炼为测试报告，反映当前项目的进展。更重要的是，测试记录是测试评审的素 材。基于测试记录，测试团队可以开发出符合项目语境的评估方法，对测程进行专家评审和定量度量。这有助于度量探索式测试结果，并提出改进方案。
问：探索式测试只适合测试专家，不适合测试新手？
答：“探索式测试不适合测试新手”是一种似是而非的说法。第一，所有高效的测试都依赖于测试人员的测试技能 和行业知识。测试专家能够准确地选择测试策略、有效地运用测试方法，因此测试效果更佳。第二，测试新手采用任何测试方法，都需要指导和帮助。这有助于他们 充分利用方法的优点，并避免方法的潜在陷阱。可见，更有意义的问题是：如何帮助测试新手尽快地掌握测试方法，尽快地成长为测试专家？
从个人发展的角度看，探索式测试有助于测试新手快速学习。探索式测试将学习与应用作为相互支持的活动逐步展开，为测试人员的技能提升提供了平滑 的学习曲线。此外，并行地进行测试学习、测试设计、测试执行和测试评估为测试人员的成长提供了持续、及时、有效的反馈，这有助于他主动学习和快速调整。
从企业发展的角度看，测试团队应该积极帮助测试新手成长。可以采用的方法包括：为他安排工作导师、评审其测试文档、评审其测试记录、在测程中安 排测试专家与他结对测试、定期进行一对一的会谈等。这些活动会消耗测试团队的人力资源，但是它们是帮助新员工成长最快速、最有效、最廉价的方法。
Peter Drucker指出：知识工人的创造性（Productivity）要求他们被视为企业的资产（Asset）而不是开销（Cost）。培养高水平测试人员是测试团队和测试领导不可回避的职责。
问：有什么工具可以支持探索式测试？
答：本书第5章将讨论探索式测试的工具。这里强调两个基本观点。
第一，作为一种测试风格，探索式测试可以使用任何开发和测试工具。探索式测试者应该根据语境选择合适的工具，去完成自己的使命。
第二，软件测试存在大量的创新空间，测试人员应该勇于开发自己的探索式测试工具。
测试专家James A. Whittaker提出过一种测试工具构建方法，值得测试人员参考。
（1）寻找缺陷：发现或收集软件的缺陷。
（2）提炼模式：分析出缺陷的根本原因，编写一个模式，用它捕获相似的缺陷。一个模式是一个结构化的攻击手段，它包含如下内容。
何时实施该攻击？
该攻击会捕获何种错误（Fault）？
利用该攻击如何识别软件失败（Failures）？
如何实施攻击？
样例和分析。
（3）开发自动化工具：识别出攻击过程中机械的部分，编写一个工具去自动化模式的应用。此处的测试自动化不是自动地执行测试用例，而是提供计算机辅助功能，其目的是让计算机完成高负荷运算，让人专注于富有智力挑战的任务。
按照James的方法实施软件测试，测试团队可以积累一批有益的模式和测试辅助工具。这可以帮助团队更有效地测试现在和未来的项目。
问：探索式测试能用于测试自动化吗？
答：本书第6章将讨论探索式测试与测试自动化。这里简单陈述一下笔者的观点。
测试自动化可以大致分为测试用例自动执行（Automated Test Execution）和计算机辅助测试（Computer-Assisted Testing）。
对于测试用例自动执行，探索式测试可以提供一批适合自动执行的测试用例。
对于计算机辅助测试，探索式测试要求人尽其才（自由发挥测试者的智能）和物尽其用（充分利用计算机的性能），利用计算机强大的计算能力去帮助测试人员完成测试使命。
许多复杂的测试自动化应该以探索式的风格来构造。对于困难的测试，应该先构建简单的测试代码，将其投入测试，利用测试反馈来改进测试代码。然 后，将改进后的测试代码投入测试实践，分析测试反馈，再优化测试代码。所谓探索式测试自动化，就是将学习、设计、实现、评估纳入迭代开发，以逐步提高测试 自动化和产品的质量。
问：探索式测试与敏捷测试有何关系？
答：探索式测试在本质上是敏捷的，且可以很好地应用于敏捷项目。
2001年，17位软件专家在美国犹他州雪鸟（Snowbird）城集会，缔结敏捷联盟，并发表敏捷宣言。与会者之一Brian Marick具有深厚的测试背景，因此软件测试社区对敏捷宣言亦有贡献。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
语境驱动测试的基本原则“任何实践的价值都取决于其语境”和“人，在一起工作的人，是项目语境中最重要的部分”，与敏捷宣言的首条价值观“个体 和互动高于流程和工具”不谋而合。高效的探索式测试不但需要优秀的测试人员，也要求测试人员、开发人员、客户和项目关系人紧密协作、频繁互动。
在思想层面，探索式测试要求测试人员不断地研究产品，通过应对、激励、拥抱变化来驱动对问题空间的积极探索。这不但符合敏捷价值观，也可以应用 于其他类型的测试项目。敏捷测试专家Lisa Crispin和Janet Gregory指出：“敏捷测试可以发生在敏捷项目之外。例如探索式测试，无论它是否应用于敏捷项目，其本质是敏捷的。通过测试逐渐学习产品，并让所学信 息指导测试实践，这无疑符合敏捷价值观：工作的软件和响应变化。”
在实践层面，探索式测试是评价产品的面向业务测试的主要手段。在用户故事和测试策略的指导下，测试人员会模拟真实用户去测试系统。当一部分代码 被签入，一部分用户故事被实现后，测试人员就会探索新的区域，并逐步完善测试模型和测试策略。随着测试人员对产品的了解，探索式测试不但可以弥补自动化测 试的不足，还可以揭示出更有效的自动化测试区域，为自动化测试设计添砖加瓦。此外，探索式测试能够发掘新情景（Scenario），而这些情景往往会演变 成新的用户故事，从而在需求层面提高产品质量。
从术语的历史看，“探索式测试”（Exploratory Testing，Cem Kaner提出于1983年）的历史比“敏捷软件开发”（Agile Software Development，敏捷宣言缔结于2001年）更悠久。它们都是在描述已经长期存在但是没有得到合适命名的思想及实践：Cem Kaner用“探索式测试”来描述一种已经长期存在的测试思维，敏捷宣言的缔造者们用“敏捷”来描述他们对软件开发的共识。虽然这些思想来自不同的头脑、 实践和社区，但是它们拥有相似的核心，并可以相互借鉴与补充。