参考链接： Python中的NZEC错误
三角形的故事
它可能被称为“测试自动化金字塔”，但在大多数情况下看起来都像三角形一样可怕。如果使用吉萨大金字塔的尺寸和本文中讨论的数学方程式，您将最终对测试金字塔的每一层的作用和依赖性以及建立牢固基础的重要性有更深入的了解。
通过将自动测试金字塔视为一个三角形，我们可以使用几何和三角元素查找每个级别的大小。为了弄清楚这一点，我们首先将金字塔分解成3个独立的三角形。我们将确定每个三角形的面积，然后使用切片技术确定每个级别的大小。
我们需要做的第一步是使用来自吉萨大金字塔的这些尺寸来找到三角形的总面积：
使用这些尺寸，我们可以找到组成金字塔一侧的三角形的总面积。
面积=½（230 * 147）≈16905
从顶部（UI级别）开始，我们可以找出每个级别的大小以及它所占整个金字塔的百分比。
用户界面级别
将大金字塔的高度平均分为3个部分，这意味着我们的顶部UI层高49米。现在，我们可以使用一些三角函数和勾股定理来查找该三角形的区域，以查看所涉及的数学细节。
通过数学运算，我们发现金字塔的UI层的面积为1909.4，约占金字塔总数的11％。
服务级别
使用相同的过程找到中间层的面积，我们发现金字塔的服务层为5726.76，约占金字塔总数的33％。
单位等级
为了找到单位层的面积，我们从测试金字塔的总面积中减去服务和UI层的总面积
16905-5726.76-1909.4 = 9268.84
金字塔的单位层约占金字塔总数的56％。
考虑更多层
您可能会发现一些测试金字塔有3层以上。为了了解更多层如何影响UI测试应该在您的测试策略中表示的数量。对4个和5个相等的图层使用相同的数学过程的结果如下：
由于F层的不同三角形类型之间始终只有很小的变化，因此基于基于大金字塔的三角形的四舍五入结果得出结论似乎很安全。
实施金字塔百分比
人们了解金字塔的顶部和底部。我们可以同意什么是单元测试，而我们大多数可以同意什么是UI或端到端测试。
中间部分是测试类型和所引用测试的基础定义上肯定有更多差异的地方。如果我们将3层，4层和5层测试自动化金字塔的数字合并为单位，UI和介于两者之间的东西的三个范围，我们可以开始看到一个有用的指标。
单元测试有很多好处；它是众所周知的测试自动化工作的基础。数字证明了这一点，表明36-55％的测试自动化应该在单元级别。
但是，数字还突出表明，“胶粘中心”（即许多人通常不确定的服务水平）应该是测试自动化的33-60％。该数量大致等于或可能大于单元测试水平。
对于UI级别，这剩下4-11％的测试自动化。如果UI级别占测试自动化的4-11％，并且这些数字告诉我们，单元和服务级别测试的大小通常相等，则基于测试金字塔的测试自动化的合理分布将大致为：
将其付诸实践时，这些百分比实际代表什么？对于我们一直使用的三角形，单位长度以米为单位，面积为平方米。什么是测试自动化有用的单位？
数量
我敢打赌，“测试的数量”就是您的想法。这可能是大多数人在看测试自动化金字塔时所想到的。即使不进行所有数学运算，您也可以从视觉上得出这样的想法：随着您在金字塔中向上移动，测试次数应该越来越少。
从技术上讲，这意味着每添加100个测试，您应该有大约45-48个单元测试，45-48个服务测试以及4-11个UI /端到端测试。考虑一下。这如何适合您的思维模式或团队中的当前实践？
在UI级别看到过度测试是很常见的。实际上，这可能是人们实际引用测试自动化金字塔的主要原因之一。我们知道UI测试很昂贵，而且通常很脆弱或易碎。数字还突出显示，很有可能在单元级别进行过度测试，而在服务级别进行过度测试。
在单元级别进行过度测试甚至更加容易。单元测试便宜，快速且可靠。许多团队经常追求代码覆盖率指标。发生这种情况时，您可能不会感觉到在单元级别进行过度测试的问题，直到问题可能变得更大为止。过去需要几秒钟或几分钟才能完成的构建，最多要花费30分钟，一个小时甚至更长的时间。当小的更改或重构导致花费大量时间更新失败的测试时，它也可能使开发人员感到沮丧。
单元测试的质量与UI级别的测试一样重要。像Goldilocks和“三只熊”一样，我们希望测试不要太大也不要太小，而恰恰是正确的。将更多的精力放在金字塔中间的测试上可以帮助实现这一目标。
Time
除了数量之外，一个相当恒定的话题是应该花多少时间进行自动化。
而不是测试数量，相反，如果测试自动化金字塔能够启发团队在各个级别上花费时间来编写和维护自动化，该怎么办？
对于给定的每周40小时工作时间，这将花费大约18个小时来编写和维护单元级别测试，大约花费18个小时来编写和维护服务级别测试，并且如果有足够的数字，大约需要花费4个小时来编写和维护UI级别测试。
一开始听起来可能有点不对劲。但是，良好的开发实践将在添加，固定和重构代码时引起相当一致的注意力和时间，以专门用于添加和维护测试。开发人员花费少于一半的时间参加单元测试和一些服务层测试听起来很合理。
假设团队中的QA或测试人员负责服务层测试和UI测试的某些部分，那么大约有四分之一到三分之一的时间专门用于自动化。这可能很低，尤其是在团队不熟悉自动化或项目刚刚开始并且需要构建一些框架或基础结构的情况下。一旦建立起来，那段时间就变得很合理了。
通过将更多的精力放在服务层频谱的高端测试上，并仅引入少数几个端到端UI自动化测试，您将获得一组更健壮和可靠的测试。这种关注减少了支持和维护更高级别测试所需的时间，因为更多的测试成为无法承受的负担。时间限制有助于指导我们仅允许在UI级别添加表征业务关键功能的测试。
编写自动化可以提高生产率。必须花费比这些数字所显示的更多的时间可能表明存在着一些更深层次的问题。
在应用程序或代码库变得难以测试的情况下，团队应承担的某些技术债务吗？测试基础架构是否存在缺陷，导致测试不可靠？在某些级别上测试太多了，和/或在其他级别上测试太少了吗？
这可能是各种各样的问题，但是如果感觉需要花费大量时间在自动化上，则表明该团队可能需要退后一步。抓住机会，以团队的形式聚在一起，询问为什么需要那么多时间，然后承认并希望制定解决任何问题的计划。
Effort
与其专注于一个特定的指标（例如多少测试或花费多少时间用于测试自动化），不如让我们从冲刺计划中抽出一页，看看这些数字类似于在敏捷项目评估中使用故事点的方式。
故事点是一种无单位的度量，用于了解事物的相对大小。查看测试金字塔时，您会对此有所了解。将顶层分配为任意大小，然后估计与此相对的其他各个级别的大小。
通过将测试金字塔中的这些数字用作团队应为自动化所进行的预期工作的启发，我们正在与如何估算功能工作保持一致。这并不是邀请您开始单独估算自动化工作，而与功能工作分开进行。在估算工作量时，您希望将任何自动化工作都包括在估算中。取而代之的是，我们拥有的一种方法可以比较应该在自动化上共同花费多少精力，这与团队已经在评估工作的标准方式直接一致。
重要的是要记住将每个测试级别视为一个较大的整体的一部分，其中每一层都充当其之上级别的基础。较低级别的不稳定和缺陷将破坏整个测试策略的完整性。我们完成的数学为相对比较提供了一个起点，因此您可以开始就团队中各个角色的测试策略进行更深入的讨论。
TeamCity VS Jenkins：选择正确的CI / CD工具
持续集成（CI）
如何在Chrome浏览器中运行Selenium？
使用Pytest创建一个Python测试自动化项目
Python中的用户定义异常与NZEC错误
分享，点赞，在看，
都在这儿,点我不香吗？
