Smart Testing

我发现，许多测试人员和测试经理将测试自动化等同于测试用例自动化执行。在他们的词汇中，“自动化”是“测试自动化”的缩写，而“测试自动化”就是自动地运行被测试对象、检查测试结果并生成测试报告。

如果仅仅运行计算机可执行的测试用例就可以保证软件质量，那么测试人员的生活将轻松许多。但是，在绝大多数项目中，测试者都必须完成一系列任务来提供优质的测试服务。

以上幻灯片来自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》提到了一条测试设计原则，很有启发性：“你应该设计测试用例以便你能从每个测试用例中学习到一些你还不知道的东西。当你从测试中学到了什么时，你应该感到高兴”。

下图是一个探索式测试自动化的实例。它是我开发的测试工具，以图形化的方式来展示指定时间段中所有任务（Job）的耗时：横轴是时间轴，每一个矩形对应一个任务，矩形越宽说明任务耗时越长，相同颜色的矩形对应同一种任务。

通过该工具，我可以立即理解被测试系统在产品环境或测试环境的工作负载。在特定时间窗口中，执行了哪些任务，哪些任务耗时最长，哪些任务数目最多，哪类任务在并发执行，哪类任务在串行执行，哪些时段系统繁忙，哪些时段系统空闲——这些信息界皆一目了然。虽然该工具不执行任何测试，但是它可以帮助我分析被测试系统，发掘可能的性能风险，为测试策略选择提供信息。

著名的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. 学习是软件测试的核心活动之一。测试自动化应该更好地支持测试学习。

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

• 行业知识：为什么需要这个软件？软件如何帮助使用它的人和团体去获得行业优势？
• 用户角色：目标用户是谁？他们有什么特点，有什么期望？软件如何帮助他们去获得个人成就？
• 软件产品：产品是一种解决方案。它解决了行业和用户所面临的问题吗？
• 计算平台：只有深刻理解软件所依赖的计算平台（如操作系统、中间件、网络协议等），才能更好地测试。
• 开发技能：理解项目所使用的具体技术，知晓典型的技术缺陷，具备测试开发能力。
• 测试方法：针对当前项目，选择合适的测试方法，并能够熟练地应用。
• 程序缺陷：研究当前（和相关）项目的缺陷，提炼错误模式（Pattern），制定缓解或预防方案。
• 开发团队：语境（context）决定策略和实践。在一起工作的人，是所有项目语境中最重要的组成部分。

测试者不需要在项目之初就掌握所有知识，他可以通过每天的工作去逐步理解用户、项目、技术和团队。更重要的是，他要在每天的工作中实践所学内容：规划测试方案，创建并执行测试用例，分析测试结果，编写测试报告。实践就是练习，是“学”的自然延伸。知行合一才构成“学习”的完整内核。

如果学习非常重要，那么如何才能高效地学习呢？敏捷大师Andy Hunt在《Pragmatic Thinking and Learning》中指出“一种高效的学习环境应该允许你安全地做三件事情：探索、创造和应用”。

探索就是在陌生的环境中玩（play）。你需要自由地探索才能学习。我们不仅仅接受信息，而是亲自探索和构建思维模型。

玩引入了一种新奇的感觉，也就是乐趣。用一种好玩的方式学习新资料或者解决问题，可以让这个过程变得更让人享受，也让学习变得更容易。为了更好地学习，请更好的玩。

你需要自由地创造——不介意自己的创造没有成功。通过构造来学习，而不是通过学习来构造。（这是“原型”、“曳光弹”、持续集成等方法获得成功的原因之一）

你需要在日常实践中应用到你学到的东西。你持续使用和实践的技能会（在脑皮层竞争中）占据统治地位，大脑会为它们提供更多方便。

这种探索应该相对没有风险，因为你肯定不想因担心害怕而止住探索的脚步。（安全有助于）更好地利用反馈，让失败也变得有意义。

虽然Andy讨论的是广义的学习与探索，但是他的话解释了探索式测试的成功之道。正如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.

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

• 《软件测试经验与教训》：“探索是带着使命在某个空间中有目的的漫游，但没有预先确定的路线。探索包括不断学习和实践”。
• 在探索式测试中，测试者创造出一切有助于学习和实践的数据和工具。它们包括输入数据、结果检查脚本、数据分析报告、业务流程图表等。
• 探索式测试者持续应用他所学到的知识。所谓“学而时习之，不亦说乎”，探索式测试将学习与应用作为相互支持的活动逐步展开，为测试者的知识提升提供了平滑的学习曲线。
• 探索式测试是一项富有智力挑战的活动，充满了乐趣。如果你没有感到智力的快感，那么一定是哪里做错了。

此外，Andy也指出，为了鼓励自由的探索，我们需要“安全的”环境。

• 测试者应该拥有独立且隔离的测试环境，他的测试活动所照成的破坏性后果不会影响团队的其他成员。
• 当测试者破坏了他的测试环境，他可以快速地创建新测试环境。虚拟化技术可以提供多样的软、硬件和网络配置。版本管理系统、自动化构建和全自动安装有助于部署特定版本的软件。
• 在测试中使用产品数据甚至产品系统是有很有帮助的。这时，应该将测试环境置于某种沙箱（sand-box）中，使测试导致的产品崩溃或数据损坏不会被沙箱以外的系统所感知。
• 测试环境中内建丰富的开发、测试、调试、监控工具。它们是探索所必需的指南针、GPS、电筒、绳索、背包和帐篷。有经验的探险家不会空手上路。

最后，值得强调的是，所谓“探索”和“学习”都是隐喻（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.