关于史亮探索性测试小节

作为一个技术术语，“探索式测试”是测试专家Cem Kaner博士在1983年提出的，并受到了语境驱动测试思想的指导。目前，影响力最大的定义是Cem Kaner的论述：

探索式测试是一种软件测试风格，它强调独立测试人员的个人自由和职责，为了持续优化其工作的价值，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，在整个项目过程中并行地执行。

该定义包含三个方面的内容。

第一，探索式测试是一种软件测试风格，而不是一种具体的软件测试技术（如等价类划分、边界值分析等）。作为一种思维方法，探索式测试强调依据当前语境选择合适的测试技术，而不局限于特定的测试技术。测试人员可以在探索式测试中使用任何一种测试技术，也可以将探索式风格应用于任何测试活动。

第二，探索式测试强调独立测试人员的自由和责任。测试人员应该为个人和团队负责，调动所有能量，发挥人的灵活性，在整体上持续优化个人和团队的产出。

第三，探索式测试建议在整个项目过程中，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，并行地执行。实际上，人脑难以并行地执行多项任务。探索式测试旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代，以不断收集反馈、调整测试、优化价值。

探索式测试的核心优势是有助于“学习”。此处的学习是指学（获取知识）与习（应用知识）的持续过程。

对于测试人员，软件测试是一个持续学习并实践的过程。他的学习范围包括：行业知识、用户角色、软件产品、计算平台、编程技能、测试技术、程序缺陷、项目环境等。

开发工具Microsoft Visual Studio 2010开始支持手工测试和探索式缺陷，Visual Studio 2012进一步增强了对探索式测试的支持，这体现了软件行业对探索式测试的认可，也表明探索式测试辅助工具和自动化将获得更多的重视与发展。

测试专家Jonathan Bach和James Bach提出的基于测程的测试管理（Session-Based Test Management，简称SBTM）。

人们研究探索式测试是为了“更好的软件测试”，探索式测试的发展应该针对软件测试所面临的使命与挑战。我认为以下几个方面会持续受到关注。

● 测试人员的教育。所有高效的测试都依赖于测试人员的测试技能和行业知识。在知识爆炸、行业高速发展的今天，如何培训测试新、如何培养测试专家、如何传承经验教训，将变得比以往更重要。探索式测试有助于测试人员的快速学习，在此领域会有更重要的作用。

● 测试建模。为了更好的测试，测试人员需要建立产品的模型，根据模型选择测试策略，并根据测试反馈，动态地调整模型。虽然，工业界和学术界已经积累了一批模型，但是仍存在许多重要的问题值得研究。例如：在开发技术高速发展的情况下，如何分析新的平台、技术或产品，以高效地构建测试对象的模型 ；在测试资源有限、测试对象复杂的情况下，如何根据模型和其他信息选择测试策略；能否将分离的模型有机地组合起来，使得不同粒度的测试模型（模块级的模型、子系统级的模型、系统级的模型、通用架构的模型）可以相互关联、彼此支持；能否建立测试策略的框架，使测试人员能够更全面地思考，并组合运用多种测试策略。

● 测试自动化。近10年来，在测试驱动开发的推动下，自动化单元测试得到了长足的发展。但是，软件系统的复杂性要求更智能、更全面的测试，这使得测试自动化存在巨大的创新空间。而云计算技术的出现，使得测试人员很容易（在短期内）获得几十台甚至上百台（虚拟）计算机。如何开发新的自动化测试以充分利用这些计算机，不但是具有挑战的测试任务，也蕴含着巨大的机会。

第一，建议阅读我与高翔合著的《探索式测试实践之路》。这本书介绍了探索式测试专家们的理论与方法，传达了正确的观念，回答了常见的疑问。阅读此书，有助于读者了解探索式测试全貌。对此，探索式测试专家James Bach给予了肯定：“此书是第一本总结了探索式测已发表工作的著作”。

第二，您不需要成为测试专家，才能开始探索式测试。探索式测试的核心实践是“学习”，即获取知识与应用知识的持续过程。在此过程中，测试人员不但更加深入地理解产品，也更深刻地理解测试思想和测试技术。在学习探索式测试的道路上，动手实践并积极反思总是优于等待观望。任何一种方法都需要练习才能纯熟，实战是迈向成熟的第一步。

第三，您不需要领导批准，才能开始探索式测试。也许您的团队要求详细记录测试设计，但这不妨碍您广泛地收集信息，通过简短的探索式测试或头脑风暴，产生多样化的测试策略和测试用例。也许您的团队要求测试执行遵循脚本，但您总是可以在测试执行中引入新的变化，并根据新发现，即席设计测试用例，来触发更多的变化。

　　我的工作要求我编写自动化测试用例来测试系统。所谓自动化是指，测试的建立(set up)、执行(execution)、检查(verification)和拆卸(tear down)是无人值守的。这些测试用例被加入到每日测试(daily test)中，以测试每日构建(daily build)所生成的当日构建。这篇短文旨在总结我的测试实践，介绍如何用一种探索式的方法来开发测试用例，权当抛砖引玉。

　　在介绍具体的方法之前，需要明确自动化测试用例开发的目标。

　　1. 迅速找出重要的程序问题[Cem01]。

　　2. 测试应该有助于提高质量[Gerard07]

　　3. 测试应该易于编写和维护[Gerard07]。

　　测试用例开发不是线性的过程，需要不停的尝试，需要根据新的情况制定新的方向和策略。虽然本文用列表的方式介绍我的方法，但是在真实的测试过程中，它们是交错且迭代的。

　　1. 选择或开发一个适合的测试框架。测试框架提供了测试领域的可复用解决方案，使得测试人员可以专注于业务领域。

　　2. 收集并理解规格说明。

　　3. 开发基本测试用例。基本测试用例用于检查系统的主要功能和常见场景。它们应该包括正面用例和负面用例，同时从快乐路径(happy path)和异常路径(exception path)来检查被测试软件。

　　4. 阅读被测试软件的源代码。阅读源代码的主要目的有二。

第一、找出高风险的模块。

第二、找出潜在的程序缺陷。(是否可由开发作Code review来作？)

　　5. 困惑是一种测试工具[Cem01]。软件开发从来都不缺乏困惑：阅读规格说明，会觉得莫名其妙；阅读源代码，会觉得匪夷所思；阅读测试结果，会觉得不可思议；阅读错误报告，会觉得不知所云。困惑是指南针，它指出了在规格说明、用户文档、实现、测试中的缺陷。

　　6. 增加测试用例来记录对软件的理解。软件测试是一个学习的过程，随着测试的展开，对被测试软件的理解也会更加深入和全面。基本测试用例是一个很好的起点，随后测试应该在广度和深度上继续发展。

　　7. 利用测试覆盖率来增强测试用例集。运行代码覆盖率分析工具，查看测试没有覆盖哪些语句块，然后补充测试用例，以求100%的语句块覆盖。

对于测试覆盖率

① 100% 语句块覆盖需要被测试代码有较好的可测试性(testability)和可观的自动化测试投入。在许多情况下，是难以实现的。

　　② 分支覆盖是比语句块覆盖更好的覆盖率方法，它可以揭示出更多的可执行路径。

　　③ 测试覆盖率只能避免最差情况，而不能说明测试的质量足够了。(现在有啥好的测试覆盖率工具？)

　　8. 重构测试代码。随着测试用例越来越多，测试方法(test method)、测试夹具(test fixture)、断言(assertion)、测试辅助(test utility)也越来越多。[Gerard07]提供了一批重构手法和模式，是很好的起点。

　　测试用例的设计是一个迭代的过程，需要在测试过程中不断地收集信息并调整策略。在许多情况下，本文介绍的测试用例开发方法和手工执行的探索式测试(Exploratory Testing)很像（探索式测试并不一定是手工测试）。其关键是用自动化测试用例来记录探索过程中的重要发现。

　　Reference

　　[Cem01] Cem Kaner, James Bach , Bret Pettichord, Lessons Learned in Software Testing, Wiley, 2001.

　　[Brian07] Brian Chess, Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.

　　[Gerard07] Gerard Meszaros, xUnit Test Patterns: Refactoring Test Code, Addison-Wesley, 2007.

　　[Michael07] Michael Feathers, Working Effectively with Legacy Code, Addison-Wesley, 2007.

　　探索式测试（exploratory testing）是一种自由的软件测试风格，强调测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。考虑到它所具备的即兴发挥、快速实验、随时调整等特征，其思维方法可以追溯到软件开发的最初岁月。作为一个特定的技术术语，它是由测试专家Cem Kaner博士在1983年提出的，并受到语境驱动的软件测试学派（context driven testing school）的支持。测试专家James A. Whittaker曾是Cem Kaner在佛罗里达工学院（Florida Institute of Technology）的同事，后来担任过微软测试架构师和Google测试总监。基于在微软的工作经历和积累，他撰写了《Exploratory Software Testing》一书，进一步扩展了探索式测试的概念和方法。

　　探索式测试有丰富的内涵，Kaner博士用一页幻灯片的篇幅介绍了探索式测试的核心。

　　首先，探索式测试是一种软件测试风格（style），而不是一种具体的软件测试技术（如等价类划分、边界值分析、组合测试等）。作为一种思维方法，探索式测试强调依据当前语境（context）选择合适的测试技术，而不局限于特定的测试技术。虽然James A. Whittaker将他的书命名为《探索式软件测试》，该书所提出的方法集仍旧属于软件测试技术（基于系统化错误猜测和测试隐喻），而不代表整个探索式测试。Whittaker的工作是很有意义的，本文指出它不是探索式测试的全部，是为了强调：当你和别人讨论”探索式测试“时，你们得达成共识。你们是在讨论一种思考方法，还是在讨论这种思考方法指导下的测试技术。

　　然后，探索式测试强调独立测试人员（individual tester）的个人自由和责任（personal freedom and responsibility），其目的是为了持续优化其工作的价值（value）。测试人员应该为个人和团队负责，调动所有能量，发挥人的灵活性，在整体上持续优化个人和团队的产出。这段描述和精益生产（lean production）、敏捷软件开发的理念高度一致，这也是探索式测试受到敏捷团队欢迎的原因之一。

　　最后，探索测试建议在整个项目过程中（throughout the project），将测试相关学习（test-related learning）、测试设计（test design）、测试执行（test execution）和测试结果解读（test result interpretation）作为相互支持的活动（mutually supportive activities），并行地（parallel）执行。实际上，人脑难以并行地执行多项任务。探索式测试旨在将测试学习、测试设计、测试执行和测试分析做为一个循环快速地迭代，在较短的时间内（如1个小时）完成多次循环，以不断收集反馈、调整测试、优化价值。该思路再次与敏捷软件开发小步快跑、持续反馈的理念不谋而合。

　　探索式测试与即兴测试（ad-hoc testing）有何区别？

　　探索式测试与即兴测试的都强调”即兴发挥“，利用直觉和经验，快速地试验被测试应用，并不停地调整测试策略开发大师Andy Hunt在《Pragmatic Thinking and Learning》中指出，直觉是非显性知识的代名词，是大脑富（Rich）模式的杰出能力。如果我们只使用大脑的线性模式（语言可表达的显性知识、逻辑思维），而漠视富模式的能量，我们将浪费自身的巨大潜力。

　　然而人是不完美的，某些直觉可能是认知偏见或错误。这就引出了探索式测试与即兴测试的关键不同：探索式测试是带着”反思“的学习和优化过程。在探索式测试中，测试人员不断地提出假设，用测试去检验假设，通过解读测试结果来证实或推翻假设。在这个过程中，测试人员不断完善头脑中被测试应用的模型，然后利用模型、技能、经验去驱动进一步的测试。相比即兴测试不注重测试计划和设计，探索式测试在不停地优化测试模型和测试设计。因为测试设计和测试执行的切换速度很快，许多人误以为探索式测试没有测试计划和设计。实际上，这些活动是被切分到细微的时间片中，并被反复执行。如何实施探索式测试？

　　探索式测试是一种测试风格，它鼓励测试人员依据当前语境选择合适的测试实施方法。我个人认为SMART原则为探索式测试提供了一些很好的建议。

　　● Specific（具体的）：测试需要一个具体的目标。

　　● Measurable（可度量的）：有明确的度量可以评估目标是否达成。

　　● Achievable（可实现的）：当前的目标应该是可实现的。这潜在地要求将一个大的目标分解为多个小目标，每个小目标也是具体的、可度量的。此外，跟踪小目标的完成情况也提供了整体进度的可度量性。

　　● Relevant（相关的）：目标要切合当前语境，符合团队利益，且不忘企业愿景（vision）。

　　● Time-boxed（有时间限制的）：为每个目标设定一个合理的最后期限。这是帮助测试人员在固定的时间窗口（time window）中排除不相关干扰、专注工作。

　　依据SMART原则，测试人员可按如下描述逐步展开探索式测试。

　　1、首先，测试人员制定测试计划。他分析被测试应用，确立若干个具体的测试任务，每个任务针对一个可能的风险。

　　2、然后，他将测试任务分解为一系列子任务，每个子任务都有明确的退出条件和时间限制。

　　3、在短暂的测试计划之后，测试人员根据优先级选择一个小任务，在一个固定的时间窗口中执行探索式测试。我建议时间窗口的长度是50分钟，因为这是人脑可以专注工作的极限时间。再这段时间里，他设计测试，执行测试，评估测试结果，获得知识，然后为了获得新知再设计测试。

　　4、在时间窗口结束后，测试人员应该适当休息，放松思维。

　　5、随后，他会反思当前的测试进展，并优化测试计划。也许他会为当前任务追加一个时间窗口；也许他会再增加一个新的任务以弥补当前测试计划的不足；也许他会精简一些任务以反映他对测试对象的最新认知。

　　6、这时，他会更有自信地开始新一轮探索式测试。

　　再次重申，以上只是一种可能的探索式测试实施方法。负责任的测试人员一定会选择他自己的方式展开测试，因为只有作为领域专家的他，才能做出最符合语境的决策。当然，集合整个团队的能量，进行伙伴评审、头脑风暴、结对测试等活动，有助于产生更好的测试结果。

探索是为了学习

对于测试人员，软件测试是一个持续学习并实践的过程。他需要学习的内容可能包括：

　　→ 行业知识：为什么需要这个软件？软件如何帮助使用它的人和团体去获得行业优势？

　　→ 用户角色：目标用户是谁？他们有什么特点，有什么期望？软件如何帮助他们去获得个人成就？

　　→ 软件产品：产品是一种解决方案。它解决了行业和用户所面临的问题吗？

　　→ 计算平台：只有深刻理解软件所依赖的计算平台（如操作系统、中间件、网络协议等），才能更好地测试。

　　→ 开发技能：理解项目所使用的具体技术，知晓典型的技术缺陷，具备测试开发能力。

　　→ 测试方法：针对当前项目，选择合适的测试方法，并能够熟练地应用。

　　→ 程序缺陷：研究当前（和相关）项目的缺陷，提炼错误模式（Pattern），制定缓解或预防方案。

　　→ 开发团队：语境（context）决定策略和实践。在一起工作的人，是所有项目语境中最重要的组成部分。

敏捷大师Andy Hunt在《Pragmatic Thinking and Learning》中指出“一种高效的学习环境应该允许你安全地做三件事情：探索、创造和应用”。

　　Cem Kaner所言：

　　探索式测试强调测试者的自由和责任，为了持续优化其工作的价值，将测试相关学习、测试设计、测试执行和测试结果解读，作为相互支持的活动，在整个项目过程中并行地执行。

　　Exploratory software testing emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work, by treating test-related learning, test design, test execution and test result interpretation as mutually supportive activities that run in parallel throughout the project.

　　探索式测试在本质上鼓励测试人员去自由地探索、创造和应用。

　　→ 《软件测试经验与教训》：“探索是带着使命在某个空间中有目的的漫游，但没有预先确定的路线。探索包括不断学习和实践”。

　　→ 在探索式测试中，测试者创造出一切有助于学习和实践的数据和工具。

　　→ 探索式测试者持续应用他所学到的知识。

　　→ 探索式测试是一项富有智力挑战的活动，充满了乐趣。

　　为了鼓励自由的探索，我们需要“安全的”环境。

　　→ 测试者应该拥有独立且隔离的测试环境，他的测试活动所照成的破坏性后果不会影响团队的其他成员。

　　→ 当测试者破坏了他的测试环境，他可以快速地创建新测试环境。

　　→ 在测试中使用产品数据甚至产品系统是有很有帮助的。

　　→ 测试环境中内建丰富的开发、测试、调试、监控工具。

　　最后，值得强调的是，所谓“探索”和“学习”都是隐喻（metaphor）。它们是指南针，不是规程手册。Steve McConnell在《代码大全》中用了整整第2章来讨论“用隐喻来更充分地理解软件开发”，很值得一读。通过丰富的案例和分析，他很好地论述了隐喻的威力和范围。

　　与其说一个软件隐喻是一张路线图，还不如说它是一盏探照灯。它不会告诉你到哪里去寻找答案，而是告诉你该如何寻找答案。隐喻的作用更像启发性方法，而不是算法。

　　A software metaphor is more like a searchlight than a road map. It doesn't tell you where to find the answer; it tells you how to look for it. A metaphor serves more as a heuristic than it does as an algorithm.

　　以上幻灯片来自Doug Hoffman和Cem Kaner的报告“Exploratory Test Automation”。他们列举了典型的测试任务，并强调这只是测试人员日常工作的一部分。

　　● 分析产品和它的风险

　　● 开发测试策略

　　● 设计测试用例

　　● 执行测试用例（测试用例的首次运行通常是手动执行）

　　● 评估测试结果（包括错误分析和调试）

　　● 管理测试环境

　　● 测试结果管理与追踪

　　● 回归测试

　　如果自动化能促成测试使命的完成，就利用自动化。评估利用自动化是否成功的标准，是看它多大程度上帮助测试人员完成自己的使命。（摘自《软件测试经验与教训》第5章“测试自动化”）

　　在探索式测试中，探索式测试自动化（exploratory test automation）是帮助测试人员完成探索式测试使命的开发与测试活动。Doug和Cem认为：

　　探索式测试自动化是计算机辅助测试，它支持学习被测试软件质量的新信息。

　　Exploratory test automation is computer-assisted testing that supports learning of new information about the quality of the software under test.

探索式测试自动化的要点。

　　1、探索式测试自动化强调计算机辅助（computer-assisted），而不是自动化测试（automated testing）。

　　2、探索式测试自动化的一个重要目标是学习。

　　3、学习的目的是获得新知。测试专家Rex Black 在《Pragmatic Software Testing》提到了一条测试设计原则，很有启发性：“你应该设计测试用例以便你能从每个测试用例中学习到一些你还不知道的东西。当你从测试中学到了什么时，你应该感到高兴”。

　　著名的Web调试工具Fiddler也体现了探索式测试自动化的思想。其作者Eric Lawrence在IEBlog上描述了它的诞生：

　　在我加入Internet Explorer团队之前，我工作于Microsoft Office Online网站。当处理大规模流量时，我们面临一些性能挑战，它们迫使我深入挖掘HTTP性能的深入细节。我的努力最终产生两个成果：Microsoft Fiddler和网络性能优化的最佳实践的文档。

　　Before I joined the Internet Explorer team, I worked on the Microsoft Office Online website. Handling massive amounts of traffic, we faced some performance challenges that forced me to dig into the guts of HTTP performance. The output of that effort was twofold: Microsoft Fiddler, and documentation of some best practices for web performance optimization.

　　可见Fiddler的原始需求是性能测试的结果分析和问题调试。为了更好地理解系统（包括服务器、客户端、网络、HTTP协议），更快速地定位问题，Eric用Fiddler捕获网络通讯的细节，并以友好的方式显示。当工具完成了枯燥、琐碎、繁杂、海量的任务，开发者能够利用他们的头脑去解决来自现实世界的难题。

　　在结束本文之前，我想再回顾一下我的观点。

　　1、情景（context）是非常重要的。要依据当前情景，选择合适的测试任务。要根据测试任务，思考合适的测试自动化方法。

　　2、测试自动化不但包括自动执行测试用例，还包括计算机辅助的测试分析、手工测试、错误调试等活动。

　　3、学习是软件测试的核心活动之一。测试自动化应该更好地支持测试学习。

　　盖特伍德的单肩包提示我们自问：

　　1、测试自动化的投入产出比如何？是那些投入最多的测试在创造最多的价值吗？

　　2、我们遵循了“要事第一”（First Thing First）的原则吗？我们的主要精力是投入在最有价值的事情上吗？

　　3、现有的流程、框架、基础设施中，有哪些部分不是必须的？能用更轻量的方法替代吗？

　　对于搜索用户，自动建议（AutoSuggest）是一项贴心的设计。但是对于测试工程师，这不是一项容易测试的功能。

　　1、手工探索式测试无法保证测试抽样可以覆盖用户输入。与必应搜索庞大的用户输入相比，手工测试的覆盖率接近于零。传统的等价类划分等测试抽样方法，对于如此海量的、无规则的输入，也无可奈何。

　　2、传统的自动化测试遇到的困难是无法构建测试Oracle。自动建议的核心实现是基于海量数据的人工智能算法。算法的输出受到多个因素的影响，如当前用户的查询、近期的相似查询、自动拼写更正、关键词过滤（如去除色情内容）等。对于特定的输入，很难构造自动建议的“预期结果”。

　　面对困难，Harry的测试思路是构造启发式测试Oracle（Heuristic Test Oracles）。所谓启发式Oracle，就是使用规则对测试结果进行一致性检查。开始时，Harry的规则非常简单：

　　自动建议的结果应该以输入字符串为作为缀。

　　Autosuggestions should have the input string as their prefix.

　　Harry编写了一个简单的测试程序。它从必应的服务端日志中获得真实用户的查询，调用自动建议的Web Service API，以获得这些查询的自动建议结果，最后利用上述规则对结果进行检查。

　　很快，测试程序发现了不满足规则的案例。当输入是“nestb”，自动建议返回“bestbuy.com”（百思买，财富500强消费电子零售商）。这是自动建议的拼写更正（Spelling Correction）功能，它将用户的“疑似错误输入”，纠正为一个最可能的结果。该行为是可接受的。于是，Harry将规则修正为：

　　自动建议的结果应该以输入字符串的合理近似作为前缀。

　　Autosuggestions should have a reasonable approximation of the input string as their prefix.

　　虽然不知道Harry的具体做法，我能想到若干“合理近似”的判定方法。

　　1、将单词看作向量，计算向量之间的距离。距离小于指定阈值的单词对，可以认为相互“近似”。

　　2、查询Office Word的拼写更正字典，获得指定单词的所有拼写更正建议。这些建议可以视为单词的“合理近似”。

　　3、调用必应的搜索API，获得搜索结果。搜索结果中的高亮关键词可以视作查询的“合理近似”。

　　Harry利用修正后的规则又发现了一些违规的案例。如输入“dond”，自动建议返回“nbc.com”。也许这符合某些文化上的约定，但值得进一步调查。再例如，输入“federal trust bank”，自动建议返回“floridalottery.com”。这个建议应该是错误的，需要开发者去调查哪里出了问题。在这个过程中，启发式Oracle更像一个过滤器，它处理海量的数据，过滤出需要测试者人工审查的潜在错误案例。

　　通过持续运行测试程序，Harry获得了以下成果。

　　1、测试运行了7天，覆盖了2200万个用户查询。

　　2、发现了1万个有问题的建议结果。

　　3、在建议词条数据库中，发现了1.9万个从未被返回的建议词条。它们应该被剔除。

　　当然，真实的测试过程比上述描述要复杂一些。但是，它们都拥有相同的核心：从简单的测试Oracle开始，利用测试反馈持续完善Oracle。Harry将这种迭代式的测试开发过程称作涌现式测试（Emergent Testing）。

　　行车路线的长度与A到B的直线距离没有数量级的差距。

　　这里需要对在线地图的实现稍作说明。在线地图的实现可以大致分为两层：绘制地图的Web UI和提供地图数据的Web Service API。API能够返回指定邮政编码的经纬度坐标。因此，利用其返回值，就可以算出两点间的直线距离。对于行车路线，API返回的是一系列点的坐标值，Web UI将行车路线路线绘制为贯穿这些点的曲线。计算临近两点间的距离，将结果累加，就可以得到行车路线的长度。因此，上述规则的实现并不复杂。

肥皂剧测试（Soap Opera Testing）是Hans Buwalda（CTO， LogiGear Corporation）提出的系统级功能测试方法。其特征和方法对于基于情景（Scenario）的探索式测试很有启发性，是探索式测试者值得研究的工具。本文将简介肥皂剧测试的基本方法和特征，详细论述请参考Hans的原文。

　　四大特征

　　Hans用 一句话归纳了肥皂剧测试的特征：

　　Try  to  write  scenarios  that are (1) based on real life, (2) exaggerated, and (3) condensed into a limited number of events.

　　其要点与电视中的肥皂剧如出一辙：源于真实生活、浓缩、夸张，（同时要充满乐趣）。

　　1. 源于真实生活（based on real life）

　　软件要能帮助客户解决实际问题，特别是复杂的现实世界中的困难问题。《项目百态》指出：“很多项目没有真正成功，只因为缺少一个人专门负责确保最终的业务流程——从用户的角度看来——尽量顺利地开展。”

　　2. 夸张（exaggerated）

　　肥皂剧测试用戏剧性的问题拷问软件，看它如何应对。这与James Whittaker在《探索式软件测试》中提出的“学究测试法”（Intellectual Tour）和“傲慢的美国佬测试法”（Arrogant American Tour）有些相似。

　　3. 浓缩（condensed）

　　肥皂剧测试同时展开多个复杂的情况，看软件如何处理。肥皂剧往往展开多个支线情节，相互交织，彼此推动，测试情景也可以如此。此外，浓缩的情节可以在较短的时间内测试多个功能，提高了测试效率。

　　4. 乐趣（fun）

　　乐趣是高效软件测试的核心因素之一。软件测试是高水平的智力活动，需要测试者全神贯注，以思考力决定成败。因此，Hans强调编写测试用例一定要充满乐趣。

此外，好的测试情节不但容易理解，而且能够激发审阅者、测试者的灵感，让他们发展出更好的支线和细节。

　　肥皂剧测试与探索式测试

　　探索式测试强调测试将测试设计与测试执行作为相互支持的活动并行地执行（详见Cem Kaner的定义），但是并不排斥单独的测试设计阶段。Cem Kaner说，测试有两个极端：完全的即兴测试（毫无计划）和绝对的计划测试（编写细致入微的测试计划，且严格遵循），大多数测试者都位于两极之间，有些人更靠近即兴的一端，有些人更靠近计划的一端。注重实效的测试者会根据当前项目的特征，动态地调整自己的位置。

基于测程的软件测试管理

为了使探索式测试满足软件开发团队对可管理性的要求，Jonathan Bach和James Bach提出了基于测程的测试管理（Session-Based Test Management，简称SBTM）[Bach2000]。本文将介绍SBTM的概念与方法。

　　Session的翻译：测程

　　在翻译Session时，我遇到了困难，因为现有的中文表达难以传递出SBTM中Session的两层含义：

　　● Session是一段不受打扰的测试时间（通常是90分钟），是测试管理的最小单元。

　　● 一系列Session相互支持，有机地组合在一起，周密地测试了整个产品。

　　在如此语境下，Session的同义词是Term（学期、会期）、Period（时段、课时）、Semester（学期），但是直接使用这些同义词的中译并不适当。进过反复考虑，我将Session翻译为“测程”，原因有三点：

　　● 用专用术语“测程”指代SBTM的Session，与Session的其他含义或中译（如“会话”）做明显的区分，这有利于快速、清晰地传达语义。

　　● “测程”表达出Session的基本语义：一段专注于测试的过程。

　　● “测程”与“课程”有相似的词汇结构，暗示了一系列测程组合在一起研究了整个产品，正如课程通过一系列课时讨论了一个完整的领域。

　　如幻灯片的标题和右侧的图画所示，SBTM的重要特征是将测试过程分解为一组测程，从而提高整个测试项目的可说明性（Accountability）。为此，一个测程包含四个要点：主题（Charter）、时间盒（Time Box）、可评审的结果（Reviewable Results）和简报（Debriefing）[Bach2004]。

　　主题（Charter）是一个测程需要完成的任务。该任务应该是清晰且具体的，可以在90分钟的时间内完成，并提供有价值的简报。主题通常用一段简练的文字描述，其内容可以是测试一个功能、检查一个风险、测试一组用户情景（User Scenario）等。以下是两个实例[Michael2007]：

　　● Create a test coverage outline and risk list for DecideRight. （为产品DecideRight生成测试覆盖大纲和风险列表）

　　● Explore a decision created with QuickBuild – the wizard that guides the user through the options， criteria， and weights needed to calculate the best decision. （探索QuickBuild如何产生一个决策——用户向导应该引导用户使用选项、标准和权重来计算最佳决策）

　　时间盒（Time Box）是一段不受打扰的测试时间，其长度一般在60~120分钟，以90分钟较为常见。在此期间，测试人员不回答问题、不回复邮件、不应答即时消息，只专注地实施测试。从工程师的角度，时间盒使测试人员能排除干扰，全力应对测试的智力挑战。从测试团队的角度，固定且专属的时间盒使得测试规划和进度追踪变得更容易。

　　可评审的结果（Reviewable Results）是测程的产出，常见的形式是测程表（Session Sheet），其内容可以包括：

　　● 主题（Charter）

　　● 测试人员

　　● 测试所覆盖的区域

　　● 测试设计和测试发现

　　● 测试所发现的缺陷（Bugs）

　　● 测试所发现的问题（Issues）

　　● 测试所使用的数据文件

　　● 测试活动的时间统计：在产品安装、测试设计与执行、缺陷调查与报告、非测试活动中各花费了多少时间。

　　简报（Debriefing）通过面对面的交流将测试情况传递给测试领导。在一天的测程结束后，测试人员向测试领导当面汇报测试情况。领导查看测程表，提出一些问题，测试人员解释测试结果，并回答疑问。测试领导也可以召开小组会议，让测试人员轮流报告当天的测试结果，使测试团队对当前产品的质量形成较完整的认识。

　　近年来，出现了更多的SBTM支持工具[Carvalho2011]，能够支持更富表现力的测程表。例如，RapidReporter可以方便的生成CSV和HTML格式的测程表，CSV格式便于进一步地自动处理，HTML格式则支持较复杂的排版和屏幕截图。

　　

SBTM是动态管理

　　由以上论述不难看出，SBTM与敏捷开发宣言[Agile01]是高度一致的。在原则上，他们都认同：

　　● 个体和互动高于流程和工具

　　● 响应变化高于遵循计划

　　在实践上，他们都认可：

　　● 围绕被激励起来的个人来构建项目。提供他们所需的环境和支持，并且信任他们能够完成工作。

　　● 在团队内部，最有效率与效果的传递信息的方法，就是面对面的交流。

　　可见，SBTM和敏捷开发虽然来自于不同的专家、实践和社区，但是他们拥有相似的核心，其思想和方法可以相互借鉴与补充。

　　SBTM是管理框架

　　测试专家Paul Carvalho指出SBTM一个管理框架（Management Framework），其基本元素是：设定清晰的主题、固定长度且不受打扰的工作时间、产生可检查的结果、利用评审和简报来驱动未来的Session [Carvalho2010]。该框架的合理名词也许不是Session-Based Test Management，而是Session-Based Task Management。个人或团队可以用它管理各种类型的（创造性）活动，如编程、写作、锻炼身体、整理房间等。

　　从这个角度，SBTM与SMART 原则（Specific, Measurable, Achievable, Relevant, Time-boxed）和番茄工作法有异曲同工之妙。

　　● Specific（具体的）：一个测程需要一个具体的主题，一个番茄钟需要一个具体的目标。

　　● Measurable（可度量的）：测程产出测程表以反映测试进展。番茄钟关注当前任务是否完成，并收集过程指标。

　　● Achievable（可实现的）：对于测程和番茄钟，主题和目标应该是可实现的。这潜在地要求将一个大目标分解为多个小目标，且每个小目标也是具体的、可度量的、可实现的。而且，追踪小目标的完成情况提供了整体进度的可度量性。

　　● Relevant（相关的）：测程要为测试项目服务，要切合当前情况，并优化产品价值。番茄钟要针对最重要的任务，以实现自我承诺。

　　● Time-box（有时间限制的）：测程和番茄钟都提供了一个固定的时间段以一心一意的工作。

　　测程表（Session Sheet）

　　传统上，测程表是一个文本文件，拥有固定的格式。这样，测试领导可以用一个文本处理程序从多个测程表中提取信息，形成聚合的测试报告。测试人员也可以用程序读取测程表，将其中的缺陷记录自动提交到缺陷管理系统。Michael Bolton曾经分享过两个测程表的实例[Bolton2007]。

　　● 测程表记录了一些任务分解（Task Breakdown）数据，如在测试设计和执行（Test Design and Execution）、缺陷调查和汇报（Bug Investigation and Reporting）、测程建立（Session Setup）等活动上花费的时间。这些数据配合简报有助于测试领导估算测试速度、评估测试效率。

　　● 测程表拥有固定的格式，该实例用特殊符号“#”标记了文本处理程序可以提取的数据。测试人员只要遵循简单的格式，就可以产生易于自动分析的测程表。一个简单的文本处理程序（或脚本）能够批量地处理测程表，产生测试报告和图表，并完成自动化任务（如提交缺陷记录到缺陷管理系统）。

　　● 测程表列举了测试所使用的数据文件（Data Files），为测试数据复用提供了基础。

　　● 测程表的核心是测试笔记（Test Notes），它简略地叙述了测试故事（Testing Story）：为什么测试，如何测试，为什么认为我们的测试是足够好的。

　　● 测程表记录了缺陷（Bugs）和问题（Issues），它们不但是测程的直接产出，还是规划未来测试的参考资料。

番茄钟，是指把任务分解成半小时左右，集中精力工作25分钟后休息5分钟，如此视作种一个“番茄”。哪怕工作没有完成，也要定时休息，然后再进入下一个番茄时间。收获4个“番茄”后，能休息15至30分钟。

[1]

提早几分钟到办公室，把一天的工作任务划分若干个 “番茄钟”，规定好每个“番茄钟”内要完成的小目标，然后尽量心无旁骛地工作，这种“番茄工作法”的流程，也被称为拖延症“自救攻略”之一。

2背景

如果想培养自己强烈的时间管理意愿和意识，养成坚定的自我管理行为，想从此克服惰性，就可以利用番茄钟的理论来提升自己充分利用时间的能力。

番茄钟是根据一个叫Staffan Noeteberg的瑞典人所写的番茄工作法理论进行开发的一款方便、实用的日程管理软件。

番茄工作法的原理：比如说25分钟为一个番茄钟，中间不能中断；如何预估和执行；在两个番茄钟之间如何休息；每天如何整理番茄钟的完成情况以及一些心得等等。

当“拖延症”渐渐成为一种办公室“慢性病”，一些白领开始种“番茄”以对抗顽疾。

3特点

番茄工作法的设定是考虑到，对庞大任务的恐惧和抗拒是导致拖延的重要原因，把注意力集中在“当下”，能帮助人更好地集中精力、摆脱过去失败的阴影和对“万一任务完不成”的焦虑。

4效果

一家外企从事财务工作的白领，曾是一个深度“拖延症”患者，通过“种”番茄，以坚持每天上班时间至少收获10个“番茄”，来敦促自己完成日常财会工作。自我诊断拖延程度有所减轻、工作效率大大提高。

参考资料

1．  巧用“番茄钟”自制职场拖延症  ．化工招聘网 [引用日期2012-10-29]