TestPyramid（测试金字塔）

这篇文章是对https://martinfowler.com/bliki/TestPyramid.html的翻译，不准确的地方，希望可以在大家的帮助下完善。

测试金字塔是一种思考方式，不同类型的自动化测试投入不同的精力，从而达到一个最佳平衡。其核心观点是底层单元测试应多于依赖GUI的高层的端到端测试。

在我的职业生涯中，测试自动化的大部分意味着通过驱动用户界面来驱动应用程序的测试。这些工具会记录测试过程，并且可以通过回放测试过程来检查应用程序返回的结果。这种方法最初效果很好，也可以由不懂编程的人进行操作。

但是这种自动化测试很快就会遇到麻烦，像一个冰淇淋。UI测试的时候需要对硬件进行授权，意味着只能在特定的机器上进行测试，也增加了构建时间。通常这种测试可以通过脚本部署到合适的环境中，并在后台运行。

最重要的是，这种测试非常脆弱。对系统迭代之后通常会造成测试失效，必须重新录制。当然，我们可以放弃使用这种脚本录制工具，自己动手编写测试用例。但是即使测试编程能力不错，也会遇到不确定性问题。不确定性问题往往会让我们对自动化测试丧失信心。 总之，基于UI的自动化测试易失效，编写成本高，运行时间长。因此，金字塔认为，应该把更多的精力放在单元测试，而不是基于传统的GUI测试。

金字塔认为应该进行与应用程序的中间层测试，即：SubcutaneousTests。这种测试保存了端到端的诸多优势又可以避免UI框架的许多复杂性，在web应用程序中，这相当于API测试，而在金字塔顶部的UI测试部分则相当于selenium（一种测试框架）中的sahi（元素定位）。

在敏捷开测试开发圈中，测试金字塔是一个合理的测试组合。在实际中常见的问题是团队将端对端的测试，UI测试和面向客户的测试混为一谈。例如，像js的界面应该使用jasmine这样的单元测试。负责的业务规则的应该采用面向客户的表单进行测试，也需要像单元测试一样在独立的模块进行测试。

高级测试是测试体系的第二道防线，如果在高级测试上失败，不仅说明功能上有Bug，还证明在单元测试上做的不足够好。因此无论何时都应该添加单元测试。

总结：

这篇文章讲了应该合理的使用单元测试，UI测试，服务测试。需要花更多的精力在单元测试上面。另外讲了UI测试的脆弱性，不建议使用脚本录制回放的方法进行UI测试。也可以通过各个框架对应的单元测试来减少问题。