什么是探索式测试

什么是探索式测试

探索式测试（Exploratory Testing）是一种自由的软件测试风格，强调测试人员同时展开测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。考虑到它所具备的即兴发挥、快速实验、动态调整等特征，其思维方法可以追溯到软件开发的最初岁月。

作为一个技术术语，“探索式测试”是测试专家Cem Kaner博士在1983年提出的，并受到了语境驱动测试学派（Context Driven Testing School[1]）的支持。Cem Kaner、James Bach和Bret Pettichord合著的《软件测试经验与教训》[Kaner01]对语境驱动测试和探索式测试做了精要且深刻的论述。测试专家James A. Whittaker曾是Cem Kaner在佛罗里达工学院（Florida Institute of Technology）的同事，后来担任过微软测试架构师和Google测试总监。基于在微软的工作经历，他撰写了《探索式软件测试》一书[2]，进一步扩展了探索式测试的测试方法。

探索式测试有丰富的内涵，Cem Kaner用如下文字定义了探索式测试的核心。

探索式测试是一种软件测试风格（Style），它强调独立测试人员（Individual Tester）的个人自由和职责（Personal Freedom and Responsibility），为了持续优化其工作的价值（Value），将测试相关学习（Test-related Learning）、测试设计、测试执行和测试结果分析作为相互支持的活动，在整个项目过程中并行地执行[Kaner08]。

不妨将这段定义分成三个部分进行讨论。

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

在这种测试风格的指导下，涌现出了一批支持探索式测试的测试技术。例如，James A. Whittaker在《探索式软件测试》中提出了一套基于系统化错误猜测和测试隐喻的“漫游测试”技术（该测试设计方法将在第3章和第4章中介绍），丰富了探索式测试的手段。又例如，Jonathan Bach和James Bach发明了基于测程的测试管理（Session-Based Test Management）[3]，显著地提高了探索式测试在测试组织、汇报、交流和度量上的能力（该测试管理方法将在第8章中介绍）。再例如，开发工具Microsoft Visual Studio 2010开始支持手工测试和探索式缺陷（Exploratory Bug）[4]，虽然相关功能略显单薄，但是它体现了软件行业对探索式测试的认可，也表明探索式测试辅助工具和自动化将获得更多的重视与发展（第6章将介绍Visual Studio 2010的相关功能）。

因此，笔者认为术语“探索式测试”[5]有两层含义。

第一，其内涵是一种软件测试风格和思考方法，不拘泥于具体的测试技术；第二，其外延是一批在这种思考方法指导下发展出来的测试技术，包括测试设计方法、测试管理方法、测试辅助工具等。为了避免混淆，本书使用“探索式测试”指代探索式测试风格和思考方法，使用特定的测试方法名指代具体的测试技术。

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

测试人员是软件企业的知识工人（Knowledge Worker）。管理大师Peter Drucker认为知识工人必须管理自己。一方面，他建议知识工人自己确立工作目标（根据项目情况去做当前最有价值的工作），通过持续创新、持续学习、持续交流来优化其生产效率和产出质量。另一方面，他建议企业信任员工，给予充分的授权，并将他们视为企业的资产加以持续投资[Drucker99]。这两方面可以视为探索式测试对于员工与企业的潜在要求。

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

n  测试学习：学习任何可以指导测试的知识，可能要学习的内容包括行业背景、领域知识、技术平台、测试技术、产品缺陷、项目风险等。

n  测试设计：安排测试计划，拟定测试策略，开发测试想法，制作测试支持材料。

n  测试执行：执行测试并收集结果。测试可以手工执行，也可以自动执行。

n  测试结果分析：分析并解读从测试中学到的知识，可能的活动包括判定测试是否通过、理解产品实现、发掘风险区域、评估测试方法是否有效等。

在现实的软件项目中，穷举测试是不可行的。任何测试都是采样测试，都存在投入测试资源却不能发现缺陷的风险。随着项目的发展，测试的风险也在持续变化。对此，探索式测试人员会在项目过程中，随时收集并判读测试情报，优化测试决策和设计，并将它们立即应用于测试执行，通过分析测试结果来评估开发状态和测试风险。这样的循环有助于最大化测试价值，并降低软件项目的风险。

 

 

 

 

 

本文节选自《探索式测试实践之路》一书

史亮，高翔著

电子工业出版社出版

 

[1] www.context-driven-testing.com

[2] http://book.douban.com/subject/4818689/

[3] http://www.satisfice.com/sbtm/

[4] http://msdn.microsoft.com/en-us/library/dd380763.aspx

[5] Exploratory Testing通常被翻译为“探索式测试”或“探索性测试”。本书的作者们选择“探索式测试”是因为这个术语强调了Exploratory Testing是一种测试风格和思考方式，符合该术语的核心思想。此外，“探索式测试”在字面上与现有的测试术语（如功能性测试、安全性测试、兼容性测试等）有更大的差异，表明它是一种可以应用于任何测试活动的测试方式。

 

本文出自 “博文视点官方博客” 博客，请务必保留此出处http://bvbroadview.blog.51cto.com/3227029/1005892