测试金字塔理论被广泛应用于计划和实施敏捷软件开发所倡导的测试自动化，并且取得了令人瞩目的成就。本文尝试从产品开发的角度出发，结合Kent Beck最近提出的3X模型和近年来迅速发展的自动化测试技术，提出并讨论一种新的测试层级动态平衡观：三明治模型。同时，为了应对端到端测试在实践中面临的种种挑战，设计并实现了一种面向用户旅程的端到端自动化测试框架——雪鸮。实际项目经验表明，雪鸮能够显著提升端到端测试的可维护性，减少不确定性影响，帮助开发人员更快定位和修复问题，对特定时期的产品开发活动更具吸引力。

背景

测试金字塔

按照自动化测试的层级，从下至上依次为单元测试、集成测试和端到端测试，尽量保持数量较多的低层单元测试，以及相对较少的高层端到端测试，这就是测试金字塔理论。随着敏捷软件开发的日益普及，测试金字塔逐渐为人所知，进而得到广泛应用。Mike Cohn、 Martin Fowler以及 Mike Wacker等先后对测试金字塔进行了很好的诠释和发展，其主要观点如下：

测试层级越高，运行效率就越低，进而延缓持续交付的构建-反馈循环。
测试层级越高，开发复杂度就越高，如果团队能力受限，交付进度就会受到影响。
端到端测试更容易遇到测试结果的不确定性问题，按照Martin Fowler的说法，这种结果不确定性的测试毫无意义。
测试层级越低，测试的代码隔离性越强，越能帮助开发人员快速定位和修复问题。

3X模型

2016年起，敏捷和TDD先驱Kent Beck开始在个人Facebook主页撰写系列文章，阐述产品开发的三个阶段——Explore、Expand和Extract，以及在不同阶段中产品与工程实践之间的关系问题，即3X模型。近二十年软硬件技术的飞速发展，使得软件开发活动面临敏捷早期从未遇到的市场变革，而根据在Facebook工作的经历，Kent Beck把产品开发总结为三个阶段：

探索（Explore），此时的产品开发仍处于非常初期的阶段，仍然需要花费大量时间寻找产品和市场的适配点，也是收益最低的阶段。
扩张（Expand），一旦产品拥有助推器（通常意味着已经找到了市场的适配点），市场需求就会呈现指数级上升，产品本身也需要具备足够的伸缩性以满足这些需求，由此收益也会快速上升。
提取（Extract），当位于该阶段时，公司通常希望最大化产品收益。但此时收益的增幅会小于扩张阶段。

（3X）

Kent Beck认为，如果以产品是否成功作为衡量依据，那么引入自动化测试在探索阶段的作用就不大，甚至会延缓产品接受市场反馈循环的速度，对产品的最终成功毫无用处，还不如不引入；当位于扩张阶段时，市场一方面要求产品更高的伸缩性，另一方面也开始要求产品保证一致的行为（例如质量需求），那么此时就该引入自动化测试来保证产品的行为一致性；当产品最终处于提取阶段时，任何改动都应以不牺牲现有行为为前提，否则由此引发的损失可能远高于改动带来的收益，此时自动化测试就扮演了非常重要的角色。

测试工具爆炸式增长和综合技能学习曲线陡升

根据SoftwareQATest网站的历史数据，2010年记录的测试工具有440个，共划分为12个大类。这个数字到2017年已经变为560个，共15个大类，且其中有340个在2010年之后才出现。也就是说，平均每年就有50个新的测试工具诞生。

面对测试工具的爆炸式增长，一方面所支持的测试类型更加完善，更加有利于在产品开发过程中保证产品的一致性；另一方面也导致针对多种测试工具组合的综合技能学习曲线不断上升。在实践中，团队也往往对如何定义相关测试的覆盖范围感到不知所措，难以真正发挥测试工具的效用，也很难对产品最终成功作出应有的贡献。

从金字塔到三明治

作为敏捷在特定时期的产物，测试金字塔并不失其合理性，甚至还对自动化测试起到了重要推广作用。但是，随着行业整体技术能力的不断提升，市场需求和竞争日趋激烈，在项目中具体实施测试金字塔时往往遭遇困难，即便借助外力强推，其质量和效果也难以度量。

此外，随着软件设计和开发技术的不断发展，低层单元测试的传统测试技术和落地，因前、后端技术栈的多样化而大相径庭；同时，在经历过覆盖率之争，如何确保单元测试的规范和有效，也成为工程质量管理的一大挑战；高层的端到端测试则基本不受技术栈频繁更替的影响，随着不同载体上driver类技术的不断成熟，其开发复杂度反而逐渐降低。

这里讨论一种新的测试层级分配策略，我们称之为三明治模型 。如下图所示，该模型允许对不同测试层级的占比进行动态调整，说明了倒金字塔形、沙漏形以及金字塔形分配对特定产品开发阶段的积极作用。

（Sandwich）

产品开发的自动化测试策略

根据3X模型，在探索初期往往选择避开自动化测试。一旦进入扩张期，产品的可伸缩性和行为一致性就成为共同目标，但此时也常会发生大的代码重构甚至重写，如果沿用测试金字塔，无论补充缺失的单元测试，还是只对新模块写单元测试，都既损害了产品的快速伸缩能力，也无法保证面向用户的产品行为一致性。因此，如果在探索后期先引入高层的端到端测试，覆盖主要用户旅程，那么扩张期内所产生的一系列改动都能够受到端到端测试的保障。

需要注意的是，用户旅程在产品即将结束探索期时通常会趋于稳定，在扩张期出现颠覆性变化的概率会逐渐减少，端到端测试的增长率会逐步下降。

除此以外，随着扩张期内不断产生的模块重构和服务化，团队还应增加单元测试和集成测试的占比。其中，单元测试应确保覆盖分支场景（可以在CI中引入基于模块的覆盖率检测）；集成测试和某些团队实践的验收测试，则需进一步覆盖集成条件和验收条件（在story sign-off和code review时验收）。

许多新兴的测试技术和工具擅长各自场景下的验收测试，但更重要的仍是识别产品阶段和当前需求，以满足收益最大化。

（Sandwich-3x）

由此我们认为，随着产品开发的演进，测试层级的分配应参考三明治模型，动态调整层级占比，更加重视运营和市场反馈，致力于真正帮助产品走向成功。

端到端测试的机遇和挑战

与其他测试层级相比，端到端测试技术的发展程度相对滞后。一方面，作为其基础的driver工具要在相应载体成熟一段时间之后才能趋于稳定，web、mobile无不如是。另一方面，端到端测试偏向黑盒测试，更加侧重描述用户交互和业务功能，寻求硬核技术突破的难度较高，于是较少受开发人员青睐。但是，由于端到端测试更接近真实用户，其在特定产品开发活动中的性价比较高，有一定的发展潜力。

然而，当前实践中的端到端测试，普遍存在如下问题：

低可维护性。一般实践并不对测试代码质量作特别要求，而这点在端到端测试就体现得更糟。因为其涉及数据、载体、交互、功能、参照（oracle）等远比单元测试复杂的broad stack。虽然也有Page Object等模式的广泛应用，但仍难以应对快速变化。
低运行效率。如果拿单次端到端测试与单元测试相比，前者的运行效率肯定更低。因此只一味增加端到端测试肯定会损害构建-反馈循环，进而影响持续交付。
高不确定性。同样因为broad stack的问题，端到端测试有更高的几率产生不确定测试，表现为测试结果呈随机性成功／失败，进一步降低运行效率，使得真正的问题很容易被掩盖，团队也逐渐丧失对端到端测试的信心。
难以定位问题根因。端到端测试结果很难触及代码级别的错误，这就需要额外人工恢复测试环境并尝试进行问题重现。其中所涉及的数据重建、用户交互等会耗费可观的成本。

方法

为了解决传统端到端测试遇到的种种挑战，本文设计了一种面向用户旅程的端到端自动化测试框架——雪鸮（snowy_owl），通过用户旅程优先、数据分离、业务复用和状态持久化等方法，显著提高了端到端测试的可维护性，降低不确定性的影响，并且能够帮助团队成员快速定位问题。

用户旅程驱动

端到端测试应尽量贴近用户，从用户旅程出发能保证这一点。在雪鸮中，用户旅程使用被称作play books的若干yaml格式的文件进行组织，例如下列目录结构：

play_books/
  core_journey.yml
  external_integration.yml
  online_payment.yml

其中每个play book由若干plots所组成，plot用于表示用户旅程中的“情节”单位，其基本特征如下：

单一plot可以作为端到端测试独立运行，例如发送一条tweet的情节：

SnowyOwl::Plots.write 'send a plain text tweet' do
  visit '/login'  
  page.fill_in 'username', with: 'username'
  page.fill_in 'password', with: 'password'
  page.find('a', text: 'Sign In').click
  # verify already login?
  page.find('a', text: 'Home').click
  # verify already on home page?
  page.fill_in 'textarea', with: 'Hello World'
  page.find('a', text: 'Send').click
  # verify already sent?
end

单一plot应是紧密关联的一组用户交互，并且具备体现一个较小业务价值的测试参照。
plot可以被play book引用任意次从而组成用户旅程，play book同时定义了所引用plots之间的顺序关系，基本语法如下所示：

---
- plot_name: send a plain text tweet
  digest: 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
  parent: d6b0d82cea4269b51572b8fab43adcee9fc3cf9a

其中plot_name表示情节的标题，digest和parent分别表示当前情节引用在整个端到端测试过程中的唯一标识和前序情节标识，初期开发人员可以通过各个情节的引用顺序定义用户旅程，大多数情况下digest和parent将由系统自动生成并维护。

整个play books集合将是一个以plots为基础组成的森林结构，而端到端测试的执行顺序则是针对其中每棵树进行深度遍历。

通用业务复用

由于plot本身必须是一个独立可运行的端到端测试，那么plots之间通常会共享一部分交互操作，例如用户登录。雪鸮允许把高度可复用的交互代码进行二次抽取，称作determination：

SnowyOwl::Determinations.determine('user login') do |name, user_profile|
  # return if already login
  visit '/login'  
  page.fill_in 'username', with: user_profile[:username]
  page.fill_in 'password', with: user_profile[:password]
  page.find('a', text: 'Sign In').click
  # verify already login?
end

这样，plot的代码就可以简化成:

SnowyOwl::Plots.write 'send a plain text tweet' do
  determine_user_login({username: 'username', password: 'password'})
  page.find('a', text: 'Home').click
  # verify already on home page?
  page.fill_in 'textarea', with: 'Hello World'
  page.find('a', text: 'Send').click
  # verify already sent?
end

这里应注意Determination和Page Object的区别。看似使用Page Object可以达到相同的目的，但是后者与Page这一概念强绑定。而Determination更加侧重描述业务本身，更符合对用户旅程的描述，因此比Page Object在plot中更具适用性。当然，在描述更低层的组件交互时，Page Object仍然是最佳选择。

测试数据分离

合理的数据设计对描绘用户旅程非常重要，雪鸮对测试逻辑和数据进行了进一步分离。例如用户基本数据（profile），同样是使用yaml文件进行表示：

data/
  tweets/
    plain_text.yml
  users/
    plain_user.yml

那么在plot的实现中，就可以使用同名对象方法替代字面值：

SnowyOwl::Plots.write 'send a plain text tweet' do
  determine_user_login({username: plain_user.username, password: plain_user.password})
  page.find('a', text: 'Home').click
  # verify already on home page?
  page.fill_in 'textarea', with: plain_text.value
  page.find('a', text: 'Send').click
  # verify already sent?
end

情节状态持久化

雪鸮的另一个重要功能是情节状态的持久化和场景复原。为了启用情节状态持久化，开发人员需要自己实现一个持久化脚本，例如对当前数据库进行dump，并按照雪鸮提供的持久化接口把dump文件存储至指定位置。

当端到端测试运行每进入一个新的情节之前，系统会自动执行持久化脚本。也就是说，雪鸮支持保存每个情节的前置运行状态。

当端到端测试需要从特定的情节重新开始运行时，雪鸮同样会提供一个恢复接口，通过用户自定义的数据恢复脚本把指定位置的dump文件恢复至当前系统。

该功能有两处消费场景：

由于broad stack的问题，端到端测试不确定性的技术因素一般较为复杂。实际经验表明，测试的随机失败率越低，就越难以定位和修复问题，而通过不断改进测试代码的方式消除这种不确定性的成本较高，效果也不好。但是，可以尽量消除不确定性带来的影响。例如，不确定测试导致的测试失败，通常会导致额外人工验证时间，完全可以选择让系统自动重试失败的测试。另一方面，重试会造成测试运行效率降低，特别是针对端到端测试。当一轮端到端测试结束后，雪鸮只会自动重试失败的情节测试，同时利用该情节对应的数据dump文件保证场景一致性，这就减少了重试整个端到端测试带来的运行效率下降问题。
当团队成员发现端到端测试失败，通常需要在本地复现该问题。而借助测试dump文件，可以直接运行指定plot测试，从而避免额外的人工设置数据和交互操作，加快问题定位和解决。

实践

雪鸮在笔者所在的项目有超过6个月的应用时间。该项目在产品开发方面长期陷入困境，例如过程中同时兼具了3X每个阶段的特点，不仅缺少清晰的产品主线，还背负了接棒遗留系统的包袱。这种状况对工程质量管理提出了更大挑战。

项目采用雪鸮对已有端到端测试进行了重构，生成了一个核心用户旅程和三个涉及外部系统集成的重要用户旅程，包含24个plots，9个determinations，使端到端测试实现了长期稳定运行。在本地相同软硬件环境下，不确定性导致的随机失败从原有10%降低至1%以内，部署至云环境并采用headless模式后，连续15天测试失败记录为零，运行效率的损失可以忽略不计。同时，当用户旅程产生新分支时，可以引入新的情节测试节点，并且根据业务需求将其加入现有play book树，从而实现端到端测试的快速维护。

持续集成与常态化运行

项目完整的端到端测试的平均运行时间保持在19分钟左右，为了不影响现有持续集成节奏，CI每30分钟自动更新代码并运行端到端测试，结果在dashboard同步显示，一旦发生测试失败，第一优先级查找失败原因并尝试在本地复现和修复。

常态化运行端到端测试的另一个好处是，能够以低成本的方式实现24小时监控系统各个组件的功能正确性，有助于更早发现问题：一次，产品即将上线的支付功能发生异常，查看CI记录发现端到端测试在晚上9:15左右出现了首次告警。通过及时沟通，确认是海外团队在当时擅自改动了支付网关的一个配置，造成服务不可用的问题，并迅速解决。

结论与展望

Kent Beck的3X模型，提出了从不同产品开发阶段看待工程实践的新视角。而敏捷一贯推崇的TDD等实践，更多体现在个人技术专长（Expertise）方面，与产品是否成功并无必然联系。然而，程序员的专业主义（Professionalism）的确同时涵盖了技术专长和产品成功两个方面，二者相辅相成。因此，如何通过平衡众多因素并最终提高整体专业性，这才是软件工程面临的经典问题。本文给出的测试三明治模型，目的就是帮助思考产品开发过程中测试层级间的平衡问题。

为了应对现有端到端测试面临的挑战，本文设计并实现了一种新的面向用户旅程的端到端测试框架，通过职责隔离、业务复用和状态持久化等手段，构建了易于维护且更加有效的端到端测试。同时，基于上述方法构建的测试代码，更易于和自动化测试的其他研究领域相结合，在诸如测试数据构建、用例生成、随机测试和测试参照增强等方向有进一步的应用潜力。

更多精彩洞见，请关注微信公众号：思特沃克

WeChat Sina Weibo Evernote Pocket Instapaper Email LinkedIn Pinterest