一文说尽测试金字塔的这20年

自动化测试 (AT) 并不是保护项目质量的盔甲骑士。但它是保护项目质量的一种方法。结构合理的自动化策略可确保成本效益、减轻团队负担并提高测试准确性。而测试金字塔可能是启动自动化测试的一种好方法。测试金字塔是一个框架,指导了各种测试类型在开发过程中的分布。您可以使用这个模型来组织或完善您的自动化测试。

1 测试金字塔概述

在探讨金字塔的实际应用之前,让我们先回顾一下其结构背后的逻辑。

1.1 原始测试金字塔:单元-集成-UI

测试金字塔提供了一个有组织的测试层次结构。它反映了每个层次的测试位置和数量。分为三层:

  1. 单元测试。

  2. 集成测试。

  3. 用户界面 (UI) 测试

它们代表不同的测试目标和关注领域。金字塔的形状强调了每个层级所需的测试的 “数量”:

  1. 首先进行单元测试,因为它们执行起来简单快速。您可以为它们分配很多资源,并发现后期可能更难修复的较小问题。

  2. 集成测试更为复杂且相对较慢。您应该减少这些测试的数量,但要针对相关方面进行测试。

  3. 用户界面测试是最复杂、最难运行的。只需进行少量测试,并优先考虑对用户至关重要的元素。

1.1.1 基础层:单元测试

单元测试是测试金字塔的基础层,用于检查独立的软件组件。它们的目的是验证代码的正确性和性能。将如此大量的工作投入到单元测试中,并不是为了达到100%的覆盖率,而是为了避免日后举步维艰。

想一想,当您在尽早发现许多小错误时,更大的问题就不太可能出现。金字塔的递减形式精确地体现了这种方法。

然而,并不意味着要全力进行单元测试。为了提高生产效率,单元测试并不需要检查每个元素,它们只需要执行大量的代码。换句话说,单元测试的目的是:

  • 针对单个代码单元进行测试。

  • 快速执行。

  • 提供一致的结果。

  • 具有可预测的结果。

为了确保上述目标,您可以采取以下措施:

  1. 使用描述性的测试名称。

  2. 一次只测试一个功能。

  3. 编写小而专注的测试。

  4. 检查边缘情况和边界条件。

  5. 使用”预置-执行-断言”(Arrange-Act-Assert)模式。

  6. 避免使用if-else和switch-case语句。

  7. 使用针对测试目的的断言。

  8. 测试正向和负向场景。

  9. 避免重复编写测试代码。

  10. 保持测试代码的更新。

*预置-执行-断言模式:

  1. 预置—设置前置条件和输入。

  2. 执行—执行操作。

  3. 断言—验证结果。

1.1.2 中间层:集成测试

集成测试评估内部或外部系统之间的交互和数据交换。它们验证各种元素能否顺利通信。

金字塔将集成测试放在中间较小的一层。由于集成测试比单元测试更复杂,因此不应该有太多的集成测试。相反,可以通过以下方法提高集成测试的效率:

  • 确定测试内容和原因。

  • 准备包括测试数据、验收标准和测试方法在内的测试计划。

  • 定期测试。

  • 监控结果,防止出错。

您还可以关注一些集成场景中的重点内容。例如:

  • 用户将新产品添加到购物车。在这种情况下,您应优先确认应用程序在与电子商务数据库通信时,能正确反映更新内容。

  • 客户尝试使用错误的凭据登录。在这种情况下,您需要评估错误处理,以防止出现可用性或安全问题。

  • 消费者尝试支付其购买的商品。相应地,您需要评估多个服务的交互,重点关注支付、库存和运输等方面。

1.1.2 顶层: UI 测试

位于金字塔顶层的是UI测试。它们专注于用户视角,确保消费者价值。这些测试模拟用户交互,以验证UI行为的正确性。

它们占据了金字塔的顶层(最小的一层),这是因为它们在执行上具有一定的困难:

  • 它们处理复杂的Web组件和场景。

  • 应用程序的界面经常变化,这意味着UI测试需要经常返工。

  • UI测试是最难维护的测试类型,等等。

因此,通过减少处理关键用户流程的UI测试数量,您可以开发出高质量的应用程序,并节省时间和精力。以下是一些关于如何最大化利用这些测试的要点:

  1. 创建清晰且具有描述性的测试名称。

  2. 使用页面对象模型(POM)来表示用户界面交互和元素。

  3. 依靠数据工厂或生成方法,尽量减少测试数据依赖性。

  4. 实施测试自动化框架,简化脚本编写。

  5. 对UI测试进行参数化,以涵盖具有不同输入的场景。

  6. 实施数据清理程序。

  7. 审查和重构测试,使其保持最新状态。

  8. 监控测试结果,发现潜在的应用程序问题。

  9. 对测试代码使用版本控制,以便更好地协作。

  10. 实施同组评审,提高测试质量。

2 测试金字塔的迭代

测试金字塔并没有长期保持不变。它的迭代似乎是为了适应不断发展的测试领域。每个版本都对原始形式进行了调整,升级了被认为不切实际的方面。

让我们来讨论一下四个主要的改动,解释其中的变化。

2.1 单元 – 集成 — E2E

为什么现在顶层变成了端到端(E2E)测试呢?因为UI经常变化。频繁的变化会导致更多的测试,从而增加资源消耗。通过顶部的E2E测试,质量保证工程师可以检查不受视觉变化影响的面向用户的方面。因此,您可以进行深入的应用程序分析,并避免额外的工作。

E2E测试检查完整的工作流程,从开始(如用户注册)到结束(如接收到购买的商品)。它复制真实的用户交互,确保顺利的用户体验。因此,与UI不同,E2E测试提供了应用程序在真实场景中的整体视角。

2.2 单元 – 集成 – UI & API – 手工 & 探索

这个模型将API添加到中间层,因为并不总是需要UI测试。例如,您的应用程序可能没有Web用户界面或过于复杂。鉴于UI测试容易出错,您可以用 API 来代替。它们能提供适当的覆盖范围,而无需投入太多资源或做太多妥协。

探索性和手工测试位于顶层。为什么呢?因为它们优先考虑以用户为中心,并且可以发现一些遗漏的问题。例如,自动化测试对于可用性或可访问性不会有太大作用。但是手工和探索性测试却能让你更接近卓越。

2.3 单元 – 集成 – 契约 (API) – UI – E2E – 验收

在软件开发过程中,将任务分配给不同的团队是很常见的。因此,您需要确保单独创建的模块之间没有矛盾。契约测试正是着眼于这一点。该附加层可确保自主开发的部件之间的一致性。

UI测试和 E2E 测试因其范围而被分开。在某种程度上,这种划分可以让你进行选择。还记得之前的两种模型是如何添加 API 和 E2E(基本上允许跳过UI)的吗?通过这种迭代,您就可以根据项目需要调整测试结构。

验收测试验证系统是否符合业务和用户的期望。它们提供了对软件功能和价值的平衡视角。因此,现在验收测试占据了顶层,成为连接高层和低层测试(E2E 和单元测试)的纽带。

2.4 单元 – 验收 – 集成 – 监控 & 告警 – 冒烟 – 手工

在此迭代中,验收测试下降到金字塔的下部。它们将验证您正在构建正确的产品。而且您越早确保这一点,就越好。实际上,早期的验收测试就像是集成测试前的门禁。如果你已经进行了全面的单元测试,验收测试将对其进行验证,您就可以放心地继续进行其他测试。

监控和告警可以主动的发现问题。通过这些,您可以及时跟踪和解决问题,然后再进行更复杂的评估。

冒烟测试可以快速验证系统功能,强调关键用户路径。它们是非侵入性的,并且数量有限。因此,在开发早期实施有益于测试阶段和最终产品。

自动化测试以预期结果为基础,手工测试则更注重探索,以从中获得最大价值。脱离脚本可以让您充分研究系统。这一层并不重要,但它可以表明用户在实际使用中是如何与应用程序交互的。

3 实践中的测试金字塔

提到上一节,你可能会问:”为什么金字塔会发生这样的变化?这个问题的答案在于对测试过程的不切实际的看法。例如,它的原始形式没有考虑到不同项目的独特需求。

接下来,我们将从该模型的优点入手,再来谈谈它的局限性。

3.1 优点
  • 金字塔的层次结构有助于团队组织测试工作。

  • 鼓励测试的平衡分布,使测试覆盖范围均衡。

  • 单元测试的快速执行使开发人员能够迅速获得有关其代码的反馈。

  • 频繁运行单元测试和集成测试有助于及早发现问题,最大限度地减少错误堆积。

  • 单元测试的弹性和简单性意味着减少维护和有针对性的工作。

3.2 缺点
  • 测试金字塔夸大了单元测试的价值。虽然单元测试必不可少,但过度强调单元测试可能会导致测试覆盖率的差距。

  • 该模型还将UI测试置于首位。但它们更加脆弱,经常会在变更时出现问题。

  • 对技术方面的关注并没有抓住消费者的视角。现实世界的场景和用户行为需要更复杂的方法。

  • 金字塔忽略了通过手工去测试易用性的价值。

  • 过分简化了测试过程,可能不适用于某些项目。

4 取得合适的平衡

您可能找不到金字塔的实际应用。但它的原则可以为您提供指导。因此,更重要的是平衡测试和方法,以满足您的测试需求。

  • 确定应用程序中需要广泛测试的区域,并将精力集中在这些区域上。

  • 优先考虑具有更高缺陷检测价值的测试。例如,如果复杂的测试对整体质量贡献不大,则应避免使用它们。

  • 识别高风险点,例如重要功能或安全性,并将测试集中在这些方面。

  • 保持较快的反馈,以防止技术债务。

  • 使用以用户为中心的方法去做自动化测试,例如可用性测试和 beta 测试。这样,您将获得积极的用户体验。

最重要的是,要考虑项目的独特性。根据这些特点调整测试策略。例如,您的团队可能更擅长一些特定的方法,在这种情况下,让他们做他们最擅长的事情,以最大限度地提高测试价值。

5 测试金字塔的演化

那么,如果您可以弯曲和扩展测试金字塔,为什么它仍然存在?很简单,它仍然有效。您可以根据其原始形状构建您的测试,并利用由此产生的模型。

5.1 菱形

在菱形测试模型中,测试体积发生了变化。它将大部分精力分配给集成层,试图平衡工作量和功能。

该模型优先考虑集成测试,因为它们可以保障关键的业务功能。单元测试和E2E测试的工作量大致相同—足够覆盖基本要素(并稍微多一些),但不会过多地陷入其中。

菱形模型最适合系统集成最重要的项目,例如数据转换、API和数据库。

5.2 冰淇淋甜筒

冰淇淋甜筒测试模型是一个倒金字塔,顶部有一个勺子。它是唯一突出手工测试的模型。该模型强调了最终用户体验的重要性,提倡以用户为中心的测试。

由于该模型鼓励采用用户视角,因此它认为单元测试最无用。它鼓励您只测试必需的部分,并在用户体验方面全力以赴。

冰淇淋甜筒测试模型适合以用户满意度和可用性为重点的项目。它还非常适合传统系统、原型、MVP 和需要依赖手工方式去做质量保证的小型项目。

5.3 奖杯

奖杯测试模型是一种全面的测试方法。它致力于优化测试所投入的资源以及对产品的价值。

最底层是静态测试,用于捕捉代码中的拼写错误。它们的成本足够低廉,可实时运行,并能消除基本错误。有了它们,应用程序就有了一个稳定的基础。

与菱形模型一样,奖杯模型也更重视集成测试。您不需要进行很多测试来发现真正的问题,而且它们的速度足够快,可以覆盖更大的代码块。

奖杯模型在成本和收益之间实现了良好的平衡。它非常灵活,适合各种项目,例如具有敏捷/DevOps 环境、复杂业务逻辑和需求不断变化的项目。

5.4 螃蟹

螃蟹测试模型引入了一种横向测试方法。它更喜欢并行的测试层次,而不是层级结构。螃蟹模型将组件、API和单元测试视为同等重要。它们支撑着主要部分—功能和视觉化的E2E 测试。

该模型促进测试工作的合理分工,以更快地发现问题。它还能激励开发人员和质量保证工程师通力合作,确保更好的质量。因为进行了视觉化的 E2E 测试,所以螃蟹模型是唯一认识到 “美观 “对用户的重要性的模型。

敏捷性高、并行测试多的项目可以从螃蟹测试模型中受益。它也非常适合用户体验至上的产品。

6 使用测试金字塔的最佳实践

您大老远跑来,不会就是为了找一堆测试金字塔的替代方案吧?别担心。正如我们之前提到的,原始模型在敏捷中也有很多用途(我们稍后会讨论)。现在,让我们来看看如何让金字塔为您服务。

6.1 采用基于风险的方法

对高风险区域进行全面的单元测试和集成测试。。例如,您希望确保关键功能或经常变动的代码的稳定性。而对像静态内容或次要功能这样的元素,只需进行少量测试或手工测试即可。

将自动化工作放在最重要的地方。

6.2 避免重复测试

不同级别的测试不应检查相同的组件。考虑一个E2E 测试,去执行单元或集成测试已涵盖的功能。您会在同一件事上花费两次时间和资源。

结构化您的测试和测试数据,以防止重复。

6.3 编写整洁的测试代码

保持测试代码简洁易懂,这样更容易发现和解决问题。您还会发现详细的测试名称和描述会减少混淆。

遵循编码规范,避免测试代码出现不必要的复杂性。

6.4 搭建快速反馈的部署流水线

搭建部署流程,以便在代码更改时自动运行测试。通过快速测试迭代,您可以更快地发现并解决错误。

应用持续集成/交付实践,简化测试和部署。

6.5 保持测试环境的一致性

维护一个与生产环境相似的测试环境。因此,要密切关注配置和软件依赖性。使用相同的数据也有助于获得一致的结果。

自动化设置和清理操作,最大限度地减少可变性。

6.6 重构优化测试

优先考虑定期重构和优化测试代码。随着应用程序的发展,您可能需要修改对应的测试用例。定期审查和更新将使它们保持相关性和准确性。

定期修改和删除多余或过时的测试。

7 敏捷中的测试金字塔

你可能会认为金字塔缺乏灵活性,与敏捷恰恰相反。但是,Mike Cohn实际上是为了支持敏捷方法而创建了这个模型。因此,测试金字塔的概念实际上增强了敏捷方法,下面是它的原因。

7.1 更好的时间管理—提高团队生产力

敏捷团队依靠高效的时间管理而蓬勃发展。而金字塔为测试工作的分配提供了一个清晰的框架。这种优化节省了时间,提高了团队的工作效率。

7.2 测试驱动开发 (TDD) – 更好的代码质量

TDD 是敏捷开发的天然伴侣。在编写代码之前编写测试,可以提高代码质量,避免回归。金字塔对单元测试的关注与这种方法不谋而合。

7.3 清晰的结构 – 更容易确定优先级

测试金字塔提供了一种基于风险的测试方法。它可以让团队根据不同测试类型的相关风险来确定测试的优先级。高风险区域会受到更多关注,而附加功能则会得到较少的校验。

7.4 自动化路线图 – 减少 QA 费用

敏捷的迭代本质意味着频繁的测试。这对持续改进非常有益,但对预算来说可能不太友好。金字塔模型暗示了通过自动化来实现成本效益。该模型清楚地列出了需要自动化的内容—以避免对资金或团队造成压力 - 需要大量时间和精力的测试。

7.5 早期缺陷检测— 缩短上市时间

测试金字塔的结构有助于及早发现缺陷。它还鼓励在开发过程中保持软件的稳定性。有了快速的问题修补和系统一致性,您就更有可能更快地交付产品。您还可以迅速适应不断变化的用户期望。 在敏捷中使用测试金字塔的最大好处是您可以构建它。通过添加新的层级和重组僵化的形式,自己的需求量身定制金字塔,并最大限度地发挥其整体价值。

8 总结

测试金字塔是一个特殊的概念。当然,它并不完美。但是,为了更好地服务于质量保证工程师,有那么多专家参与了这一理念的提出和开发,这令人鼓舞。您可以使用原始金字塔来更好地组织您的测试。您还可以对其进行修改,以适应您的项目需求。

最后: 下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保证100%免费】

在这里插入图片描述

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。在这里插入图片描述

在这里插入图片描述

 行动吧,在路上总比一直观望的要好,未来的你肯定会感谢现在拼搏的自己!如果想学习提升找不到资料,没人答疑解惑时,请及时加入群:1150305204,里面有各种测试开发资料和技术可以一起交流哦。

你可能感兴趣的:(功能测试,测试工具,自动化测试,程序员,python)