我想知道是否还有其他人实施和执行了测试金字塔准则，如果这样做，是如何做到的。特别是，我如何说服开发人员在其工作中维护和实施单元/集成测试？
#1 楼
我绝对使用测试金字塔作为我的``指导''工具之一。我经常在演讲和演示中将它与4个敏捷测试象限结合起来。
/>
正如Niels所说，这更多的是指导原则，而不是具体的实现方式。
我通过以下方式介绍并鼓励这样做：
在向开发人员和QE工程师介绍我们的质量实践时进行介绍
在书评中重新审视它，因为我们经历了Lisa Crispin和Janet Gregory进行的敏捷测试
将其用于指导我们的测试工作，以便在sprint审查期间查看故障单并指向
我谈论了我工作过的几家公司，这些公司有数千个单元测试，然后有几十个UI功能测试
在讨论模拟和存根时会参考它，以便人们可以看到何时在更高级别的UI功能规范中实际测试了数据库访问。
我认为您可以通过以下方法说服开发人员在其工作中维护和实施单元/集成测试：
通过让您知道是否破坏东西来确保人们知道自动化测试如何增加价值
确保对数据库和其他依赖项进行存根以便进行单元测试，以便它们能够快速运行-每秒执行许多测试，而不是每次测试花费几秒钟
，如果可以进行测试，可以查看最近可以避免的错误
谈论没有单元测试的变化系统的感觉和压力与具有防止意外更改的测试的联系
强调测试套件运行完整套件应该少于10分钟
#2 楼
测试金字塔不是您要实现的东西，而是更多的指南，显示了如何分散测试工作。同时，它也应该成为防止使用敏捷反模式“冰淇淋测试锥”的指南。您可以使用代码分析工具（例如SonarQube）来监控趋势。这些工具甚至可以拒绝请求或发送警报。
您可以从最低35％的测试覆盖率入手，这迫使每个人在至少对代码进行一次测试。稍后您可以说新代码一定不能使其低于35％。将来的几个月中，您可以将百分比提升到65％或更高。 Xp团队的目标是覆盖率达到85％至100％。对于遗留代码库，这是您可以实现的梦想，设置切合实际的目标。同样要记住测试是目标，而不是覆盖范围。
关注趋势而不是确切的数字。新代码不应降低当前代码覆盖率的统计数据，该数字应该总是增加。在dojo会话中，我们使用TDD技术使开发人员熟悉单元测试和编写好的测试。每次迭代，我们进行一个1.5小时的会话。同时，我们每次观看和讨论UncleBob的CleanCode视频，其中一些还专注于TTD和代码测试能力。这是耗时的，但是大多数开发人员没有空闲时间在工作之外学习。我真的认为开发人员应该增加每次迭代的时间，并学习如何制作可测试和可维护的代码。
其他来源：
http://www.duncannisbet.co .uk / test-automation-basics-levels-pyramids-quadrants
https://www.pluralsight.com/courses/the-coding-dojo