学习探索式测试的问与答(5)

　　寻找缺陷：发现或收集软件的缺陷。

　　提炼模式：分析出缺陷的根本原因，编写一个模式，用它捕获相似的缺陷。一个模式是一个结构化的攻击手段，它包含如下内容。

　　何时实施该攻击?

　　该攻击会捕获何种错误(Fault)?

　　利用该攻击如何识别软件失败(Failures)?

　　如何实施攻击?

　　样例和分析。

　　开发自动化工具：识别出攻击过程中机械的部分，编写一个工具去自动化模式的应用。此处的测试自动化不是自动地执行测试用例，而是提供计算机辅助功能，其目的是让计算机完成高负荷运算，让人专注于富有智力挑战的任务。

　　按照James的方法实施软件测试，测试团队可以积累一批有益的模式和测试辅助工具。这可以帮助团队更有效地测试现在和未来的项目。

　　问：探索式测试能用于测试自动化吗?

　　答：本书第6章将讨论探索式测试与测试自动化。这里简单陈述一下笔者的观点。

　　测试自动化可以大致分为测试用例自动执行(Automated Test Execution)和计算机辅助测试(Computer-Assisted Testing)。

　　对于测试用例自动执行，探索式测试可以提供一批适合自动执行的测试用例。

　　对于计算机辅助测试，探索式测试要求人尽其才(自由发挥测试者的智能)和物尽其用(充分利用计算机的性能)，利用计算机强大的计算能力去帮助测试人员完成测试使命。

　　许多复杂的测试自动化应该以探索式的风格来构造。对于困难的测试，应该先构建简单的测试代码，将其投入测试，利用测试反馈来改进测试代码。然后，将改进后的测试代码投入测试实践，分析测试反馈，再优化测试代码。所谓探索式测试自动化，就是将学习、设计、实现、评估纳入迭代开发，以逐步提高测试自动化和产品的质量。

　　问：探索式测试与敏捷测试有何关系?

　　答：探索式测试在本质上是敏捷的，且可以很好地应用于敏捷项目。

　　2001年，17位软件专家在美国犹他州雪鸟(Snowbird)城集会，缔结敏捷联盟，并发表敏捷宣言。与会者之一Brian Marick具有深厚的测试背景，因此软件测试社区对敏捷宣言亦有贡献。

　　敏捷软件开发宣言[Agile01]

　　我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：

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

　　工作的软件高于详尽的文档

　　客户合作高于合同谈判

　　响应变化高于遵循计划

　　也就是说，尽管右项有其价值，我们更重视左项的价值。

　　语境驱动测试的基本原则“任何实践的价值都取决于其语境”和“人，在一起工作的人，是项目语境中最重要的部分”，与敏捷宣言的首条价值观“个体和互动高于流程和工具”不谋而合。高效的探索式测试不但需要优秀的测试人员，也要求测试人员、开发人员、客户和项目关系人紧密协作、频繁互动。

　　在思想层面，探索式测试要求测试人员不断地研究产品，通过应对、激励、拥抱变化来驱动对问题空间的积极探索。这不但符合敏捷价值观，也可以应用于其他类型的测试项目。敏捷测试专家Lisa Crispin和Janet Gregory指出：“敏捷测试可以发生在敏捷项目之外。例如探索式测试，无论它是否应用于敏捷项目，其本质是敏捷的。通过测试逐渐学习产品，并让所学信息指导测试实践，这无疑符合敏捷价值观：工作的软件和响应变化。”[Crispin09]

　　在实践层面，探索式测试是评价产品的面向业务测试的主要手段[Crispin09]。在用户故事和测试策略的指导下，测试人员会模拟真实用户去测试系统。当一部分代码被签入，一部分用户故事被实现后，测试人员就会探索新的区域，并逐步完善测试模型和测试策略。随着测试人员对产品的了解，探索式测试不但可以弥补自动化测试的不足，还可以揭示出更有效的自动化测试区域，为自动化测试设计添砖加瓦。此外，探索式测试能够发掘新情景(Scenario)，而这些情景往往会演变成新的用户故事，从而在需求层面提高产品质量。

　　从术语的历史看，“探索式测试”(Exploratory Testing，Cem Kaner提出于1983年)的历史比“敏捷软件开发”(Agile Software Development，敏捷宣言缔结于2001年)更悠久。它们都是在描述已经长期存在但是没有得到合适命名的思想及实践：Cem Kaner用“探索式测试”来描述一种已经长期存在的测试思维，敏捷宣言的缔造者们用“敏捷”来描述他们对软件开发的共识。虽然这些思想来自不同的头脑、实践和社区，但是它们拥有相似的核心，并可以相互借鉴与补充。

原文转自：http://www.ltesting.net