语境驱动测试7原则

本文系《探索式测试实践之路》第1.2节，简要的讨论了“语境驱动测试”（Context Driven Testing）的7条原则。所引用文献的详细信息可以在这里找到。

 

探索式测试的奠基人和积极实践者Cem Kaner和James Bach都支持语境驱动测试[Kaner12]。语境驱动测试的7条基本原则对于正确理解并应用探索式测试具有重要意义，本节将予以简单讨论。

 

原则1：任何实践的价值都取决于其语境（Context）。

这条原则几乎是不言自明的。中国人很早之前就有相似的认识，“南橘北枳”（语出《晏子春秋》，其成书于战国，后经西汉刘向整理）指相同的种子在不同的环境中会结出不同的果实。因此古人建议“因地制宜”（语出《吴越春秋》，成书于东汉），即根据当地的具体情况，采用合适的措施。

然而，软件开发者往往会在无意中忘记这条原则。开发团队会照搬以往的经验，却不考虑经验可能已经过时；会不假思索地采用他人建议的开发方法，却不怀疑南橘北枳的可能；会按照高层的指示亦步亦趋，却不思索指令是否合理。更糟糕的是，在感觉到情况不妙后，却将错就错，不思变更。因此，开发团队需要频繁地反思其开发实践是否符合当前的语境，并做出相应调整。

 

原则2：在特定语境下存在好的实践，但不存在最佳实践。

这条原则看似有些武断，毕竟软件研发已经沉淀出一批公认的实践方法，它们是现代软件开发必不可少的核心实践。但是，细细一想便会发现这些方法也需要因地制宜。“持续集成”是公认的最佳实践，但是不同的团队往往有不同的集成频率。对于小型项目，一次签入（Check-in）会触发一次完整的构建；对于大型项目，开发团队可能每天做一次完整构建；对于超大型项目，做一次完整的构建可能需要几天甚至更长的时间。不同的构建频率和构建代价自然会导致不同的签入策略和测试方法。虽然都在实施“持续集成”，但是不同的团队会设计出不同的流程和方法。

对于测试工作者，这条原则表示任何一种测试方法（包括探索式测试）都不是无条件的最佳选择。测试人员始终要评估当前情况，寻找适合当前语境的测试风格和技术。

 

原则3：人，在一起工作的人，是项目语境中最重要的部分。

这条原则强调了软件开发的社会学因素。软件开发专家Tom DeMarco和Tim Lister指出：“本质上，我们工作中的主要问题，与其说是技术问题，不如说是社会学问题”[DeMacro99]。而社会学因素的根源是“软件开发是一个创造与沟通的协作游戏（Game也可以翻译为“博弈”。本书将其翻译为“游戏”是为了突出软件开发的乐趣、协作、沟通与互助。软件开发团队的对手不是团队成员，而是亟待解决的问题）”[Cockburn07]。在创造与沟通的过程中，一定是个体和他们的交互（Individuals and Interactions）起主要作用。

在软件测试中，以下观点反映了人的重要性。

• 软件开发是具有挑战性的智力活动，开发人员（包括测试人员）的责任感、技能、状态将强烈影响软件实现和代码质量。因此，招聘、培训、挽留高水平开发人员是软件企业最重要的工作之一。
• 软件开发是一种创造与沟通的游戏。软件企业应该营造一种开放、协作的工作环境，使得开发人员能够自如地去思考、去发明、去创造。
• 软件测试的核心任务是寻找并传递信息。在寻找信息的过程中，测试人员的能力和相互协作的水平将在很大程度上决定信息的数量和质量。
• 软件测试提供信息服务。服务就意味着有客户，测试人员是否成功，主要取决于是否很好地满足了客户的要求和最佳利益[Kaner01]。也就是说，测试人员的重要任务是理解客户，并与他们展开有效的交流。

以上观点只涉及该庞大主题的一小部分。笔者建议读者去阅读此领域的经典书籍（请参考本书附录中的“推荐阅读”）以获得更多见解。

 

原则4：项目的发展往往难以预料。

在一些语境中，项目的发展是可以预料的。图1.1摘自Steve McConnell所著的《软件估算》，它显示了（对项目范围、代价、功能的）估算值是如何随着项目的进展变得准确的[McConnell06]。随着时间的推移，项目的不确定性逐渐降低，当项目即将结束时，开发团队能够准确预期项目的结局。但是，图1.1也提示了在项目的开始阶段，项目的不确定性非常高。在初始概念（Initial Concept）阶段建立的估算值可能是实际值的4倍。

该原则并不是一个悲观的见解，相反它体现了一种实事求是的态度和对软件风险的成熟认知。探索式测试有助于快速获得信息，从而降低软件项目的不确定性。成功的测试团队在整个项目过程中会结合广度优先探索和深度优先探索，在特定的时间选择适合的方法，从而更明智地利用测试资源。

 

图1.1 根据日历时间得到的不确定性锥（Cone of Uncertainty）

 

原则5：产品是一种解决方案。如果问题没有被解决，它就是无用的（Doesn’t Work）。

成功的软件必须帮助用户解决现实世界中的问题，辅助他们获得成功。在极端情况下，一个符合规格说明且没有技术缺陷的软件会遭遇失败，因为它没有解决用户的问题，甚至阻碍用户解决问题。图1.1显示，在需求完成（Requirements Complete）时，不确定的范围会大幅缩小。但是，如果需求存在重大缺陷，甚至初始概念就是错误的，那么稳定的开发过程只会“稳定地”产生失败的产品。

这一原则要求测试工作者用软件用户的视角考察整个产品，从显式规格说明（不完整、模糊、包含错误的项目文档）和隐式规格说明（包括竞争对手产品、相关产品、已发布版本、电子邮件讨论、口头讨论、论坛反馈、博客文章、领域专著、测试经验等）中，挖掘、推导、发现需求。这是探索式测试人员需要掌握的探索技能。

 

原则6：好的软件测试是一个具有挑战性的智力过程。

这又是一条不言自明的原则，相信本书的读者也会认同该原则。虽然您可能会质疑本书的一些观点，但是您的阅读已经说明软件测试的挑战性和复杂性需要认真研究与思考。

这条原则的推论是枯燥、机械、无成就感的测试过程不是好的软件测试。这样的过程压抑了测试人员的创造性，分散了他们的注意力，降低了他们的智力水平。然而，本书的作者们也必须承认，我们在日常工作中也时常会感到枯燥、单调、缺乏创造力。对此，笔者的基本观点是：第一，测试人员应该以合乎要求的质量完成自己的工作，这是测试人员必须履行的职责；第二，应该将单调的工作视为改进的信号，通过改变工作内容和流程，将更多的时间用于具有挑战性的工作。探索式测试、技术创新和测试自动化是笔者的常用工具。

 

原则7：只有通过判断和技能，并在整个项目过程中协同练习（Exercise Cooperatively）它们，我们才能在正确的时间做正确的事，以有效地测试我们的产品。

软件测试领域的一些文献似乎在暗示，只要严格遵循“优秀”的测试过程或模板，就可以使普通的测试人员成为测试专家，并获得理想的测试结果。这种观点是不正确的，因为只有高素质的测试人员才能根据语境设计出合适的流程、计划、策略和用例，而这些才是有效测试的基础。

那么该如何培养高素质的测试人员呢？Cem Kaner指出：“测试过程的一个重要成果，是更好、更聪明的测试人员。”[Kaner01]优秀的测试人员具备高超的技能，而这种技能只能通过持续的学习和实践才能获得。而且在一个合作与分享的环境中，测试人员可以学得更快、练得更好。