Martin Fowler 分层测试概念博文分享

在我们测试工作中，常常遇到这样的问题：开发与测试团队分属不同的不同（部门隔离、沟通不畅），质量职责划分不清（出现bug往往都是测试人员背锅），需求的不确定和易变性（需求不断变化导致代码不停更新、产品重构等），项目时间紧（互联网项目的需求对上线时间有更严格的要求）...测试团队必须纠结这样一个问题：如果在质量保证与上线时间之间找平衡，我们一方面需要尽可能的希望找出产品的“所有”bug，一方面又要保证需求能如期上线，对于一个测试团队来说，直观上只有两种方法来解决这个问题：扩充我们的测试队伍（人多力量大嘛），然而，一味的扩大队伍就意味着项目成本的增加，所有我们只能追求通过各种自动化测试方法来提高测试效率。
　　自动化测试，大家的第一反应是这样：写好一个脚本，然后每次运行脚本就把人工测试要做的所有事情全做了...这只是我们的一个理想，理想是美好的，现实却很骨感。自动化测试不是万能的，这里面还存在很多问题，其中最重要的一个问题就是：对于大多数团队的测试人员来说，往往只有黑盒测试环节在咱们的全面掌控下，在这样的前提下，大多数自动化测试工程师们都在对UI层面的测试做自动化，而UI是易变的，我们想通过在这里做自动化实现“全面”的覆盖是不可能的，看下下面这篇博文，也许能为你的自动化测试平台设计提供一些灵感：

TestPyramid

马丁福勒

2012年5月1日

 

测试金字塔是一种思考不同类型自动化测试的方式，应该用来创建一个平衡的投资组合。它的基本点是你应该有更多的低级UnitTests比通过GUI运行的高级 BroadStackTests。

 

对于我职业生涯的大部分时间来说，测试自动化意味着通过用户界面驱动应用程序的测试。这些工具通常会提供记录与应用程序交互的功能，然后允许您回放该交互，检查应用程序是否返回相同的结果。这种方法最初效果很好。记录测试很容易，测试可以由不懂编程的人记录。

但这种方法很快就会遇到麻烦，成为一个 冰淇淋锥。像这样通过用户界面进行测试很慢，增加了构建时间。通常它需要为测试自动化软件安装许可证，这意味着它只能在特定的机器上完成。通常情况下，这些操作不容易在“无头”模式下运行，由脚本监控以放入适当的部署管道。

最重要的是这种测试非常脆弱。对系统的改进很容易导致大量这样的测试结束，然后必须重新记录。您可以通过放弃记录回放工具来减少这个问题，但这会使测试更难写。 [1]即使在编写它们的良好实践中，端到端测试也更容易出现非确定性问题，这可能会削弱对它们的信任。简而言之，通过用户界面进行端到端测试的操作是：易碎，写入成本高，运行耗时。所以金字塔认为你应该通过单元测试进行更多的自动化测试，而不是通过传统的基于GUI的测试。[2]

金字塔还提出了一个中间测试层，它通过应用程序的服务层来执行，我称之为 SubcutaneousTests。这些可以提供端到端测试的许多优点，但避免了处理UI框架的复杂性。在Web应用程序中，这将对应于通过API层进行测试，而金字塔的顶部UI部分将对应于使用像Selenium或Sahi 这样的测试。

测试金字塔在敏捷测试圈中出现了很多，尽管其核心信息是健全的，但关于构建一个平衡良好的测试组合还有很多话要说。一个常见的问题是团队混淆了端到端测试，UI测试和面向客户的测试的概念。这些都是正交特性。例如，一个丰富的JavaScript UI应该使用像Jasmine这样的JavaScript单元测试来测试其大部分UI行为。一套复杂的业务规则可能会以面向客户的形式捕获测试，但是可以像单元测试一样在相关模块上运行。

我一直认为高级测试是第二道防线测试。如果您在高级测试中失败，不仅仅是您的功能代码中存在错误，还会丢失或错误的单元测试。因此，我建议在修复由高级测试暴露的错误之前，您应该使用单元测试复制该错误。然后单元测试可以确保错误不会消失。

笔记

1： 记录回放工具对于任何类型的自动化来说几乎总是一个坏主意，因为它们抵制可变性并阻碍有用的抽象。它们只有作为一种工具才能生成脚本片段，然后您可以使用Twist 或Emacs的方式将其编辑为适当的编程语言。

2： 金字塔是基于这样的假设：与更集中的测试（如单元测试）相比，宽泛测试的代价昂贵，缓慢且脆弱。虽然这通常是正确的，但也有例外。如果我的高水平测试是快速，可靠和便宜的修改 - 那么不需要低级测试。

我们可以根据这个测试金字塔，把自动化测试也分层来做，这样就能更好的保证我们的测试质量和效率啦。