https://www.jianshu.com/p/3bea28840a74
2012年5月1日，Martin Fowler在他的博客（https://martinfowler.com/bliki/TestPyramid.html）上发表了著名的自动化测试金字塔。
Martin认为，基于用户接口（如UI）的自动化测试运行慢、效率低、维护开销大。因此自动化测试应该投入更多的精力在单元（Unit）和接口（Service）层，这样不仅自动化测试效率更高，还可以更早发现质量问题，提升系统质量。这个自动化测试金字塔后来被国内技术人员广泛引用，成了实际意义上的标准。
但是这个自动化测试金字塔模型也一直饱受争议，其中争议最多的点在于UT（Unit Test ，单元测试）。Martin提出测试金字塔模型的时间是2012年，那时敏捷已经非常流行。敏捷以快速响应变化著称，代码自然也会频繁变化。传统意义下的UT，需要开发者针对代码函数进行各种覆盖测试，投入非常大，且UT一般和代码强关联，一旦代码发生了变化，UT大概率也就失败了。所以几乎没有开发者喜欢做UT，即便有很多公司会强制要求UT覆盖率，但是执行效果也不尽人意。所以真实情况是，很多团队UT都做得很弱。很多团队真实的自动化测试分层，更像一颗钉子。
国内外测试行业有很多对自动化测试分层模型的探讨，很多模型都非常有趣，例如Kent提出的奖杯模型，还有蜂巢模型等。
2021年6月2日，Martin在他的博客上深入讨论了各种形式的自动化测试分层，以及他对单元测试、集成测试的理解（https://martinfowler.com/articles/2021-test-shapes.html），其中几个观点很值得我们讨论回味。
观点1 自动化测试分层，代表的是我们在各种测试类型上花费的精力，代表我们应该如何去平衡单元测试和其他测试的投入。金字塔模型认为，需要将大部分测试精力放在单元测试中，而奖杯或者蜂巢模型代表我们应该把大部分测试精力放在集成测试（关注接口）。
观点2 单元测试和集成测试的定义一直都相当模糊，很多开发者和测试者都并不真正清楚这两者之间的区别是什么。Martin是这样阐述的：以大型瀑布式软件开发为例，开发者会独立研究编写大量代码，无论这部分代码有多大，只要开发者可以相对独立地编写、调试而不受到其他开发者的影响，就可以将其看成一个单元，对应的测试就是单元测试。测试完成后，开发者提交代码，将自己的代码和其他开发者的代码进行集成，然后自己测试集成后的代码的功能是否正确，这就是集成测试。Martin认为单元测试和集成测试的关键区别在于，单元测试是独立测试我们的代码，而集成测试是测试我们写的代码如何和别人的代码一起正常工作（The key distinction is that the unit tests test my/our code in isolation while integration tests how our code works with code developed separately）。
集成测试是更偏向于Sociable Tests的测试，而单元测试更倾向于Solitary Tests，这两者之间并没有那么明显的界限。
Martin的观点给了我们一些如何在实际项目中解决“UT难”问题的启发。
我们可以把单元测试理解为，由开发者进行的，验证自己写的代码的功能是否正确的测试。换句话说，单元测试不一定非是一个函数一个函数地进行测试，也可以是针对功能的测试，重点在于这个测试是由开发者站在代码实现的角度，验证自身代码实现正确性的测试。与之类似，集成测试也是由开发者进行的，只不过其是站在代码实现的角度，验证自己写的代码和其他开发者写的代码是否可以正常工作。
无论是单元测试还是集成测试，都需要解决测试时模块间的依赖问题（Test Double），开发者可以根据情况选择合适的测试风格和方法，如Stub或者Mock。从这个角度来说，单元测试和集成测试并没有本质的区别，都是开发者测试。
Test Double：为保证测试代码可以顺利进行而编写的各种依赖。
Stub：桩，在被测对象需要调用其他功能代码时，提供所需功能存在的假象（被测对象：“我需要你。”Stub：“我在，我一直默默存在。”）来解除依赖，保证被测对象顺利执行。
Mock：Mock会对预期进行编程，形成被调用后预期的规范。如果Mock收到一个不期望的调用，可以抛出异常（断言）。
我们可以把自动化测试的底层作为开发者测试层，在这个层次里我们完全可以模糊单元测试和集成测试的边界，只要开发者可以快速确认自己实现的正确性就行。
很多时候系统还会提供外部接口，如Restful、CLI（命令行）等。这些接口一般也会提供给最终用户使用。建议测试者可以针对外部接口和UI界面接口进行自动化测试。这样就可从开发者和测试者的角度，对自动化测试分层模型进行重新定义，
摘取自刘琛梅老师的《测试架构师修炼之道：从测试工程师到测试架构师 第2版》