软件测试金字塔
在敏捷方法中，持续集成是其基石，持续集成的核心是自动化测试。下面这篇关于测试金字塔的文章，来自大师Martin Fowler。
测试金字塔的概念来自Mike Cohn，在他的书Succeeding With Agile中有详细描述：测试金字塔最底层是单元测试，然后是业务逻辑测试，最后是端到端的测试（GUI或CLI）。
在我的职业生涯中，很多次听到过自动化测试，自动化测试意味着端到端的通过界面完成的测试。完成这种自动化测试的工具一般是录制然后回放，初始使用很容易，不需要任何编码技能。
不过你使用一段时间后就会遇到很多麻烦，GUI的自动化测试运行速度都很慢导致版本发布速度下降，同时完成自动化测试的软件，一般都是商业软件需要license因此只能在特定的机器上部署，且不容易通过脚本集成。
GUI测试用例还很脆弱，如对系统的一些修正可能导致很多用例的失败，这时候你需要重新录制。你可以放弃录制的方法来解决这个问题，通过写GUI测试代码，但是这样效率非常低。就算你已经很精通了GUI测试代码的编写，端到端的GUI测试用例也很容易出现不可预期结果的问题－一些用例成功一些用例失败，因此，基于GUI的自动化测试是脆弱、耗时（包括用例维护和执行）的。所以测试金字塔要表达的是：底层应当有更多的单元测试和接口测试和逻辑测试，GUI测试用例能覆盖到主业务流程即可。
我们注意到测试金字塔中间这一层：服务。业务服务的测试，我称其为皮下测试，因为这一层就在用户界面GUI下面。服务测试可以完成很多端到端的功能测试而不需要像GUI自动化测试那样需要使用复杂的框架。如一个Web应用，你可能使用自己写的脚本测试端到端的逻辑，而GUI自动化你可能会使用Selenium这个工具。
测试金字塔发源与敏捷测试实践，使用测试金字塔原则很容易将你项目中的测试用例达到平衡的状态。在很多项目中都混淆了“端到端测试”，“UI测试”，“面向用户的测试”的概念，其实他们都是测试的不同角度。例如你有一个javascript开发的应用，那UI部分就需要用javascript的单元测试工具Jasmine完成大部分的UI功能测试；复杂的业务逻辑需要使用面向用户的表单（form）来测试，而不仅仅是底层的单元测试。
因此我通常将上层的测试称为“测试的第二防线”，如果你的一个上层测试用例执行失败，表现出来不仅仅是这个功能有问题，还说明你遗漏了这个地方的单元测试，因此你在修复功能之后，还需要补充相关的单元测试用例。