书评与访谈：Fifty Quick Ideas to Improve Your Tests-InfoQ

“ Fifty Quick Ideas to Improve Your Tests ”作者是 Gojko Adzic，David Evans 和 Tom Roden，这本书为跨职能团队实施迭代交付提供了建议，这些建议可以用来管理和改进他们的测试活动。

InfoQ 有幸采访了 Adzic，Evans 和 Roden，谈及了他们为什么写这本书，量化质量是如何支持测试的，当测试大型和复杂系统时平衡信任级别，为什么自动化手动测试几乎总是一个坏主意，和在测试环境中使用生产度量指标，如何减少或避免重复的测试代码，以及 50 个快速创意系列中即将出版的书刊。

InfoQ：你们为什么写这本书？

Adzic：在与许多不同团队共事的过程中，我们总是能够看到不同的团队发生类似的问题。尽管每个团队都是独一无二的，都有他们自己的一套约束，但是基本问题的解决方案往往都是一样的。例如，当自动化测试涉及到数据库操作时，在数据库事务内调整 test runner 执行测试，需要立即处理大量的我们不断与新客户看了一遍又一遍的问题。有些问题在我们的周围已经存在一段时间了，但是由于某些原因，人们很少知道它们，因此从外在的角度来看，我们希望帮助人们增强对此问题的意识。从内在的角度来看，写这本书最终迫使我们坐下来，分类和阐明这些创意，使我们更快地解决那些容易复发的、可解决的问题，处理更多有趣的挑战。

Evans：在我们的职业生涯中，我们都曾经与测试有过密切的联系。我们已经探讨其它一些会影响软件质量的有趣的因素，从围绕自动化测试非常技术性的问题，到更人文的问题，比如识别真正的价值。本书几乎是回归基本面——包含了某些我们已经说过和指导过很长时间的东西，其它的只有通过观察测试和以一种新的眼光进行测试才能逐渐理解。当我们写前一本的时候，“ 50 Quick Ideas to Improve Your User Stories ”，有很多我们希望写进去的故事都跟测试有关，所以我们觉得这个主题应该有自己的书。

Roden:过去的几年，我们帮助团队完成了许多测试挑战，所以我们觉得将我们的经历汇集成一个工具包的形式为从业者服务，肯定是一个不错的主意。我们发现自己在处理类似的问题时用的都是类似的方法，书中的许多创意都是些我们在不同的情况、领域和技术上经常使用的创意——我们认为这将会使它们广泛适用于很多的团队。书中有很多可以用来解决具体问题的创意，提高测试效果和价值的小窍门，还有很多创意试图为测试提供备选方法。我们希望这种混合的组合使人们在使用和参考这些创意的时候，觉得这是一本有趣的书。

InfoQ：本书针对的观众是哪些？

Adzic：这本书是为迭代交付系统内的跨职能团队设计的，他们经常需要在测试中有效的合作，和在艰难时间压力下交付他们的产品。鉴于这一情况，本书主要有益于拥有测试基础的开发人员和测试人员——在书中我们没有覆盖基础知识，而是直接跳到改进创意。在我们之前一本有关用户故事的“Fifty Quick Ideas”书中，这种格式看起来很受欢迎。书中有很多好的基础资源，但是没有覆盖那么多的高级主题。

书中有很多涉及探索性测试的创意，设计良好的检查，提高自动化测试和管理大型测试套件，我们希望不论在什么环境下，都有一些有趣的指标能够帮助几乎所有的团队从事软件产品。

Roden：正如 Gojko 所言，尽管我希望书中有些东西能够帮助寻找创意的任何人改进他们的测试，但是本书的主要受众是拥有一定技能的迭代交付团队。有些创意能够快速实施和掌握，但是其它的则相对更复杂一点。

Evans：是的，这些都是“快速的创意”，但是不是“简单的创意”。这本书绝对不适合初学者。我希望这本书可以帮助测试人员识别和向别人阐明为什么他们的行业需要技巧和思想。我同样希望这本书可以帮助测试以外的其他人理解，为了更好地完成测试我们需要弄清楚哪些事情。

InfoQ：书中有个创意跟量化质量有关。多年来，我一直在尝试这件事，并且对量化质量如何帮助所需质量获得更好的、共同的理解有着丰富的经验。您能否详细说明量化质量是如何支持测试的？

Roden：好的质量在旁观者心中就像美景一样。这种与生俱来的主观性会导致人们对什么是好的质量，哪些属性可以代表好的质量，有着不同的理解。

因此为了彻底认识质量就必须对质量进行量化和可视化。这需要考虑不同的层次。在故事或者特征层次，我们以验收标准的形式量化目标质量，在产品层次，我们同样可以对质量进行全盘考虑。目前，许多团队使用验收标准对故事质量进行量化和可视化，但是有时不同的标准也会引起歧义，比如‘必须尽快’和‘必须可靠’，这些可能会在解决方案的适用性里留下巨大的潜在的错误隐患。

我们发现在特征和产品层次量化质量非常有用。这样在讨论特征验收标准时会有一个明确的目标，同样，对于讨论更高层次的可视化质量，包括其中的特征和指导测试，也有一个明确的目标。

Adzic：它有助于在墙上描绘一个大家都能看到的目标。许多团队都会遭受错位问题的困扰，许多团队成员会被指责吹毛求疵和减缓交付，而其他人也会因为交付太快和不关心质量而受到指责。除非这些人对什么是质量有个统一的定义，不然任何有关改进质量的讨论都是主观的，最后都会成为一家之言。如果有个全局统一的目标，不管它是什么，都会使得实际工作的开展和决定哪些事情需要更多的工作或者这项工作是否已经够完美变得更加容易。

Evans：众所周知，Tom Gilb 非常善于争辩，尤其是在如果你尽力去做，那么质量的任何方面都是可以量化的这个问题上。他说，“量化，即使没有后续计量，也是清晰思维和良好沟通的有效帮手”。我很喜欢这个创意，尤其是它将量化（能够将总量表现出来）与计量（在某个时间点上寻找一个总量的实际指标）进行了分离。

我们已经多次听到善意的利益相关者谈论良好质量的重要性，但是，正如 Gojko 所言，问题起源于那些负责交付和评估良好质量的人，对实践中的质量意味着什么没有一个统一的标准，进而导致每个人都对结果感到失望。

InfoQ：另一个创意是记录信任边界。您能否解释一下，在测试大型复杂系统时，为什么它对平衡信任级别很重要？

Adzic：当多个团队共同实现同一个软件片段时，会有很多机会使信息遗漏在团队界限的缝隙中。虽然这是一件很悲观的事情，但是如今对许多组织来说，这就是现实。与来自其他团队的成员相比，在同一个团队内的成员对彼此拥有更高级别的信任，和更高密度的沟通。当两个团队依赖彼此交付时，常常没有明确定义跨团队问题和影响的责任，人们会对另外一组的工作进行大量的假设。这会导致团队之间大量重复的工作，例如，其中一个团队会测试另外一个团队已经完全解除风险的特征。它也同样会导致很多不合理的信任，难题中一个小片段的一个问题就会导致层叠效应，并给团队造成很多问题。如果没有一个明确的统一，一个团队内不同的人在处理相互依赖的工作时可能会采取不同的方法。

记录信任边界这种创意，帮助同一团队中的人们就他们最少应该信任别人到什么程度，才能在内部互相协调工作达成一致意见。一方面，如果团队中其他人了解潜在的问题，人们就不会盲目地相信工作中的依赖，迫不及待地进行操作。相反，如果团队认为他们可以互相信任，人们就不用浪费时间去测试组件周围的边界情况。

记录信任边界还能给其它目的提供帮助：他们能够帮助将问题划分为意料之中（可以通过自动测试检查到）和意料之外（与当前信任边界不一致）。团队可以将他们大部分的自动测试投资用于消除意料之中的集成问题，并且可以尝试违反信任边界，执行探索性测试，寻找意料之外的问题。如果违反了记录在案信任边界，就需要重新审视围绕之前的边界进行的大量的假设。

Evans：我想 Gojko 已经回答了我想表达的内容了。

Roden:哈哈哈哈，永远不要让 Gojko 第一个回答问题 :-)

InfoQ：“将例子与反例进行对比”这种创意解释了，测试人员如何能够提出某个新的功能不适用的情景，他们可以考虑在这种情景下进行测试。您能够给出一些你共事过的团队使用这种窍门的案例？

Adzic： 反例也可以是有效的案例，并且反例经常发生，它们只是不是人人关注的完整的幸福之路。我相信 David 对这方面的关注更多一点，但是反例使主要的例子更加的清晰，因为它与重要的东西形成对比。一些谈论幸福案例的例子，就像在浅色的背景下使用白色的文本——很难迅速掌握。添加良好的反例就像将背景颜色改成黑色，从而使得白色文本更加清晰。

Evans：确实是这样的，通过例子与反例的对比，前景与背景的对比，使我们对我们尝试测试和理解的内容有一个更加清晰的认识。反例不是不应该发生的情景，但是有效的情景处在被测试行为的‘边缘’。

最近我曾经与这样的一个团队共事过，当使用某种类型的付款卡和事务类型时，我们需要添加手续费。我们有许多例子，它们显示了正确的计算，和不同情况下费用的显示。但是显示没有费用适用时发生了什么这样的案例同样的重要。费用适用或不适用，报表布局、付款摘要信息、email 和 SMS 收据是不一样的。与“有费用”案例相比，“无费用”案例就是反例。

Roden:我一直很喜欢 David 推举的案例与反例中的光和影的比喻。这个创意清晰地表达了，你不需要使用一大堆的案例来说明测试中的行为，事实上，恰恰相反。每一小组反例比大量的混杂了关键行为的测试案例提供了更好的对比。补充测试也很好，但是在验收时请考虑保留这些为数极少的反例，并将它们作为关键案例。

InfoQ：您在书中提到，自动化手动测试几乎总是一个坏创意。您能解释一下这是为什么吗？

Evans：这是一个相当常见的综合征：组织或者团队开展自动化测试，并将其作为节省测试执行时间的一种方式，尤其是如果他们需要运行一大套人工回归套件，但是结果却发现比之前的情况还要糟糕。低级的方法是做一些类似记录与回放现有的自动化测试的事情。这么做仅仅是创造了各种新问题，并且任何节省执行时间的自动化很快被越来越多的维护负担侵蚀。

Adzic：手动测试是从优化人类工作的角度来考量的。人们可以处理少量的前后矛盾的事物而不会引起太多的麻烦，当地形与地图不一样时，他们可以更好地利用他们的判断力。但是人们并不擅长处理重复繁琐和缓慢的任务。这就是为什么良好的手动测试常常被写为指导指南，而不是处方。即使是那些在野外讨厌的、机械的手动测试也是从优化人类工作的角度编写的，使得这样一个简单、艰苦的设置可以在许多情况下重复利用。

另一方面，机器确实擅长重复困难的、枯燥的任务。计算机电脑能够很轻松地以完全相同的方式重复建立客户的信用账户 500 次。但是机器非常不善于处理少量的前后矛盾的事物。因此这样一种可能会影响 500 种相互依赖情况的简单的设置，是个非常糟糕的创意。中间的某一项发生问题都会中断成百的测试，并且很难理解、排除和维护这些发生故障的测试。

因为这两种不同的情况，仅仅自动化执行一些为人类设计的任务就变得没有意义。而将团队从从头重写这类测试代码，和优化无人值守的、重复的执行约束中解放出来，可以更好地发挥他们的价值。

Roden:通过完全遵循人工测试脚本中的每一步实现自动化测试，将会导致测试非常的脆弱、冗长、和难以阅读。人工测试脚本常常可以在数十个测试步骤内编写完，使得任何没有假设产品或者领域知识的人都可以执行它们。但是这种长度常常意味着失去了测试的目的，被埋藏在所有步骤的某个地方。所以，以同样的方式自动化将会很快地扭曲测试的目的（或者在自动化中失去了目的和测试错误的事情）。人们在后来添加新的测试时，他们将不会知道他们添加的东西是否已经覆盖了，会不会导致重复和浪费。

此外，当这些测试被中断时，如果测试的目的不明确，那么同样不能够确定测试或者系统是否有故障。测试的这种属性常常是关闭的或者至少是因为高昂的维护成本仅仅是手动运行它们。

当 UI 自动化工具是社交礼仪必需品时，直接自动化手工脚本是实现自动检查，展示用户验收的常见方式。Gojko 提到的会中断了大量测试的设置，同时可以用来保持测试的独立性，使编写速度更快，但是确实提供了糟糕的反馈。在现代化的自动化测试框架中，没有必要为了验收测试以这种方式编写测试代码，或者在测试自动化环境中过分使用 UI。

InfoQ：您能否给出在测试环境中使用生产度量指标的案例吗？这么做的好处是什么？

Evans：测试是一种行为，其收集证据帮助我们预测未来。就像他们说的，过去的表现并不一定是未来回报的指标，但是实际的生产度量指标跟任何测试数据一样，都是未来回报有效证据的来源。在精确复制生产环境中的硬件、网络连接、数据量等成本可能过高的情况下，这种策略能够带来最大收益。不好的一面是你只能搜索后视镜，所以如果在陷入绝境时预测行为，或者如果还没有被推到系统的极限，认识系统的极限所在时，它就不是那么有用。

此外，监控生产度量指标给你一个更深入地理解不同指标之间关系的机会。我记得一个案例，一个网站的性能暂时低于规定的阈值，这促进呼吁性能的提升转变，但是当分析完同时期的所有的统计数据后，并没有充分的证据表明这种性能的下降会对用户流量和销售带来负面的影响，所以昂贵的性能改进计划被放弃了。如果单独基于性能测试数据做决定，那么他们可能已经招致不必要的成本和过度的优化。

Roden:最近我共事过的几个团队，他们已经一直在使用监控生产指标，以通知进一步测试投资。这不仅是尝试建立某种环境，这种环境具有组件的完整补充和类似生产的系统规模。曾经有一次，发布后的一到两天，内存阈值被打破，可以看到内存远远高于之前的数值。监控响应速度允许团队运行一系列新的测试，用来分析特定组件，和用于提出一个修复而不必撤销整个发布或者让产品流行起来（go pop）。在每次发布前，使用一系列关键监控措施可以允许一定速度的响应，这种响应使其比执行大型测试的设备、人员和时间成本更具成本效益。

另一个例子是 A-B 测试，虽然这不是新的测试，但是在‘精益创业’时代，它已经越来越流行。细分的用户群和产品的不同部分为在可控的情况下执行小测试和评估用户行为提供了平台。这比在不同的产品版本中组织和执行 alpha 或 beta 测试更加的快速和具有成本效益。它同样消除了对实验室中的行为是否是自然环境下真实行为的模仿的怀疑。

Adzic：很多横切关注点没有经过测试生成一个准确的结果。例如，诸如某个 web 网站主页的加载速度，或者处理信用卡交易所花的时间等方面。它们经过测试生成足够好的结果。即使在较短的时间内它们小幅回落到预期区间之外，也不是一个大问题。随着短迭代交付，团队有机会显著地减少降低风险等方面的成本。

随着大批量的发布，测试网页加载通常涉及在类似生产环境的硬件中部署应用，并让性能测试专家反复推敲。无论是类似生产环境的硬件还是性能测试专家往往都是稀缺资源，被多个团队共享，所以他们为自己在交付中创造了一个巨大的瓶颈。

随着频繁的迭代交付，风险来源被严重破坏，以至于风险不是太高。但是它们往往随时间恶化。所以与等待稀缺资源得到缓解，在交付中引入瓶颈相比，团队可以选择在实际环境中推进变更，并监控差异，如果需要可以计划在下次迭代中调整。

InfoQ：重复的测试代码会导致测试套件的维护问题。您有什么建议可以用来减少重复的代码，或者甚至防止重复代码的生成？

Evans：如果你的前提假设是，你所有的测试代码都跟生产代码的标准是一样的，并且团队认为集体测试所有权（collective test ownership）跟集体代码所有权（collective code ownership）一样重要，那么重复代码的异味应该由团队快速发现并处理。与设计你的系统一样花同样的心思设计你的测试基础设施，这样可以鼓舞诸如关注点的理想分离，代码重用，单一职责等事情。因为更多的测试增加了对可重用工具的需求，导致可重用工具将从一次性项目中进化出来。为共同测试数据设置服务的数据生成器就是一个常见的案例。早期的测试可能会创建新账户，例如，在它们的设置中生成账户。随着越来越多的测试需要建立账户，这个功能就会被提取到一个账户生成器工具中。

Adzic：许多团队会忽略测试自动化代码，把它们视为自己代码库中的二等公民。理由是，客户不会看到它编码，所以对于它是由 quick hacks 组成这种事是没有问题的。但是，这是一个错误的前提。

对于通过测试自动化支持实践迭代交付的团队而言，测试代码占据了他们代码库的绝大部分。例如，在 MindMup，我们拥有的测试代码几乎是面向客户代码的两倍还多。仅仅因为它没有面向客户，就忽略良好的编码和设计实践是一件愚蠢的事情。

管理大型代码库和减少重复代码这些的技术是已经为世人所熟知，人们只需要将它们应用到测试自动化代码，以及面向客户的代码。测试自动化不应该委托给那些几乎不知道如何写代码的人，它必须由那些知道如何设计良好的、复杂的软件的人来完成。

Roden:跟生产代码一样，测试自动化代码也需要相同的维护。它决定了利用这种维护你可以容易地创建和修复测试。

我记得一个具体的例子，发生在 Gojko 和我曾经工作过的地方。为了进入一个事务，从最初的一个或者两个自动化方法，到很快从五个团队开发产品过程中出现了 15-20 种不同的方式方法。编写新测试的开发人员并不知道那些进入方法的区别，最终选择了不合适的方法或者只是编写新的方法。这导致要么剩下的测试是脆弱的或者测试没有覆盖他们希望覆盖的风险。调试测试很快变得越来越辛苦，同时维护成本迅速上升。

我们通过优化一组小的模板事务，创建使用示例库，推进更广泛的所有权，和交流新增的和更改的自动化模式改进它。我们还必须重构一系列能够适应的测试，但是随着时间推移，早早地支付成本要比慢慢地越来越多的地支付成本（因激起众怒而招致灭顶之灾）好。

通过定期交流，集体所有权，样本的使用模式和重复使用，深思熟路的测试代码可以避免重复的测试代码——非常像你解决生产代码的方式……

InfoQ：这是 50 个快速创意系列已经出版的第二本书。关于这个系列任何即将出版的新书，您能透露一下预览内容吗？

Adzic：下一本正在准备中的新书是 Tom 和 Ben 关于改进你的回顾的新书。

Roden:目前，Ben Williams 和我正在准备第三本书，跟回顾有关。我们设计的创意范围更加的广泛，总的来说跟持续改进有关，但是回顾概念仍然是一个很好的致力于改进的体现。

Evans：我们跟作者一样，都很喜欢“50 个快速创意”的格式，看上去我们的读者也很喜欢，所以我们打算将这个系列继续下去。对于系列的下一本我们并没有具体的计划（回顾之后），但是我们一直在收集不同事物的创意。有些创意围绕着活文档，并没有被列入测试书中，所以，也许将来的某个时候我们会尝试一下那个主题。

关于本书作者

Gojko Adzic是战略软件交付顾问，他与多个具有上进心的团队合作，帮助他们改进软件产品和过程的质量。Gojko 获得了 2012 年度 Jolt 最佳图书奖，由同行投票，作为 2011 年度最具影响力的敏捷测试专业人士，并且他的博客获得 2010 年度英国敏捷最佳网络刊物奖。如果你想联系 Gojko，可以给他写邮件 gojko@neuri.com，或者访问他的网页 gojko.net。

David Evans是一位顾问，教练和培训师，专门从事敏捷质量领域。David 帮助组织改进战略过程，指导团队进行有效的敏捷实践。他是一位很受欢迎的会议发言人，并且在国际期刊上已经发表了数篇文章。你可以通过邮件 david.evans@neuri.com 联系 DAvid，或者在 Twitter 上 @DavidEvans66。

Tom Roden是一位软件交付教练、顾问，以及质量保证的狂热支持者，帮助团队和人们做出必要的改进以获得成长，并且学会适应他们的环境所要求的各种变革。Tom 的专长是敏捷指导，测试和转型。你可以通过电子邮件 tom.roden@neuri.com 联系 Tom，或者在 Twitter 上 @tommroden。