您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
用不同的测试模型来构建测试套件
 
作者:陈峻
  546  次浏览      4 次
 2022-5-31
 
编辑推荐:
本文介绍了经典的测试金字塔模型的构成、用途、以及各个层面的特点,也和你讨论了测试奖杯、测试矩阵模型的各自特点。
本文来自于51CTO ,由Linda编辑、推荐。

2009年,Mike Cohn在他的Succeeding with Agile 一书中用金字塔来比喻软件的测试模型。逐渐,该说法流传开来,如今它已成为了业界的行业标准。

总的说来,测试金字塔能够直观地表示出测试的标准化逻辑结构。它由如下三个不同的层次所组成:

金字塔的底部是单元测试。该单元实际上是一些小段的逻辑代码。它们可以是函数、类、甚至是类中的方法。单元测试仅会检查目标单元的行为,是否符合开发人员的预期。开发人员可以通过编写单元测试,在无需依赖任何其他组件、服务或UI的情况下,直接调用被测试代码,进而评估其输出。

金字塔的中间层是集成测试,Mike在他的书中也称为“服务测试”,其主要目的是测试系统的不同组件是如何协同工作的。例如,代码中的模型是否可以正确地与数据库交换数据,或者某个方法是否可以从API中检索到信息。同样,集成测试不需要UI的交互,便可以直接调用接口处的代码。

金字塔的顶层是端到端(end-to-end,E2E)测试,也称为UI测试,E2E是从最直观的角度进行测试,即通过运行应用程序,来查看其效果。当然,E2E测试并不一定需要人工去执行,而可以完全依靠自动化。E2E测试能够模拟出每个用户与应该交互的动作,例如:单击按钮、输入信息、以及捕获UI的显示内容等。

可见,这三种类型的测试会涉及到不同的范畴:

单元测试,只能在最基本的层面上发现逻辑错误。它们速度比较快,而且运行时所需的资源也比较少。

集成测试,主要验证应用服务和数据库,是否能与编写的代码和类进行良好的系统化协同。他们只能在两个或多个组件交互的接口处发现问题。

E2E测试,关注能否启动的完整应用程序。由于属于最全面的测试类型,因此它在运行时往往会耗费最多的计算资源和时间。

1.测试金字塔的复杂性

在了解了测试金字塔的基本测试层次后,让我们来讨论一下每种测试的复杂性。单元测试由于比较简单,因此易于编写和维护。虽然它们仅仅测试的是非常狭窄的代码部分,但是却经常被使用到。我们往往可以在几秒钟内运行数千个单元测试。

集成测试在复杂性、以及数量级上与单元测试差不多,毕竟我们只对待测应用程序的“边界”部分感兴趣。不过,与单元测试相比,集成测试需要更多的资源才能运行。

E2E测试则具有编写复杂、难以维护、需要大量资源、并且运行缓慢等特征。不过,由于我们可以通过各种E2E测试工具来覆盖更多的应用程序,因此我们需要执行的测试工作量并不大。

由金字塔的形状可知,每一层次的宽度会与该层的测试量成正比。也就是说,端到端的测试量相对较少、而集成测试的数量不及单元测试那么多、那么广。

如前所述,三类测试的复杂程度和代码库的覆盖率都是逐层增加的。下图展示了各种测试在编写、运行和维护方面的工作量比例。据此,您可以最大限度地利用更少的工作,找到更多的缺陷与错误。

2.如何给测试金字塔符能

在项目伊始时编写E2E测试往往极富挑战性。除非开发团队能够采用BDD等框架,并从一开始就着手编写验收测试(https://semaphoreci.com/blog/the-benefits-of-acceptance-testing),否则大多数E2E测试都将只能在基本原型、或最小可行产品就绪时,才能被编写。如下图所示,开发人员在整个开发过程中,也会逐步增加单元测试与集成测试的编写工作量。

让我们再来看看测试的效率。众所周知,缓慢的测试往往会拖慢生产环境所需的重要信息反馈。因此开发人员需要高效地运行三种测试套件,以稳定提升软件质量。

位于金字塔底部的单元测试具有最高的运行效率,因此开发人员往往乐于编写与使用。相反,鉴于复杂性,E2E测试的效率最低。一个大型的Web应用程序往往需要进行数千个单元测试、数百个集成测试、以及几十个E2E测试。而它们的用时,可以体现在下图中:

3.使用测试奖杯来测试前端

测试金字塔的历史可以追溯到2009年。随着技术的快速发展,人们在应对不同的开发需求时,也可能需要不同的测试模型。由Kent C. Dodds提出的测试奖杯(https://twitter.com/kentcdodds/status/960723172591992832)就是一种针对前端开发所构建的测试模型。

测试奖杯重排了优先级。它认为由于大多数现代UI都会依赖于各种后端组件,而且难以开展单独的测试,因此集成测试才是王道。

与金字塔相比,单元测试处于次要地位,而且可以被ESLint和JSHInt等静态测试工具所取代。它们通过扫描代码,便可发现诸如:使用了不安全的语句、或未遵守变量命名规则等潜在问题。

奖杯的顶端是E2E测试,它与在测试金字塔中的占比相似。

4.测试矩阵

在测试金字塔中,我们往往容易忽略测试结果可信度的问题。也就是说,唯一可以真正验证应用程序可行性的测试,只有E2E测试。通常,我们认为开发人员投入在测试上(如E2E测试)的精力越多,测试结果的可信度就越高。对此,Gleb Bahmutov和Roman Sandler提出了测试矩阵(https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead)作为规划测试相关策略时的工具。

如上图矩阵所示,开发人员精力的投入是从左到右增加的,而可信度是从下到上上升的。显然,最佳位置是在绿色区域。而大多数软件项目都是从低投入和低可信度的黄色区域开始的。

随着项目的成熟和新功能的添加,测试需求也会随之处于熵增的状态。倘若测试团队未能在测试方案上持续改进和维护,那么他们会很快滑到红色区域。

对此,我们应该如何以尽量少的投入,增加测试的可信度呢?我们需要定期重新评估如下五类与测试相关的方面:

安装:包括安装和设置测试框架所涉及的工作。

编写:涉及到为给定框架编写测试的复杂程度、以及开发人员的技能水平。

运行:包括运行测试套件的难度、以及CI/CD的性能。

调试:涉及到发生测试失败时,发现和修复问题难易程度。

维护:包含在项目的整个生命周期中,维护测试所耗费的精力。

在该模型中,我们往往需要在项目的开端,给予单元测试一定的投入。不过,一旦项目功能稳定下来,开发团队就需要通过添加更多的E2E测试、以及减少其他测试类别,来平衡组合测试。据此,测试有效性在稳步增加的同时,团队可以有条不紊地调整在不同类别上的投入。

5.谨防教条思维

由于速度、成本和维护问题,金字塔在一定程度上限制了我们尽早地开展E2E测试。当然,也有人认为:鉴于端到端测试更接近于用户的真实场景操作,团队可以通过应用提供的公共界面予以开展。因此,如果您更改了后台的实现,甚至更换了整个后端的话,那么E2E测试不应被推倒重来,而只需沿用原有的测试案例,进行测试微调便可。据此,其维护的工作量实际上也并非多得惊人。

当然,每个团队、每个项目、以及每个组织都是不同的。而且随着需求的变化,团队可能会需要通过重新决定或规范化测试套件,以灵活的方式停止现有的、或评估新的测试模型,按需进行调整,以达到多快好省的测试效果。

6.小结

历史悠久的测试金字塔模型,为整个测试领域树立了一个典型的通用模型,方便大家参考与交流。当然,随着新技术、新实践、以及新理念的出现,各种不同的改进模型也相继出现。它们各有专攻,服务于特定的开发领域。其中不乏服务于CI/CD管道的自动化测试套件。总之,您需要根据自己的实际项目,来选择最适合的测试套件。

 
   
546 次浏览       4
相关文章

微服务测试之单元测试
一篇图文带你了解白盒测试用例设计方法
全面的质量保障体系之回归测试策略
人工智能自动化测试探索
相关文档

自动化接口测试实践之路
jenkins持续集成测试
性能测试诊断分析与优化
性能测试实例
相关课程

持续集成测试最佳实践
自动化测试体系建设与最佳实践
测试架构的构建与应用实践
DevOps时代的测试技术与最佳实践

最新活动计划
企业架构师(业务应用-TOGAF)12-22[北京]
软件架构师-高级实践 12-25[北京]
需求分析师能力培养 12-26[北京]
基于SysML和EA系统分析设计 12-29[北京]
配置管理方案规划&实践 1-13[北京]
图数据库与知识图谱 2-25[北京]
 
最新文章
大数据平台测试
微服务架构下的测试之道
从零开始掌握微服务软件测试
如何进行测试需求分析:从接收需求到用例设计
python_selenium自动化测试框架
最新课程
测试需求分析与测试用例设计
性能测试方法与技术
自动化测试框架设计高级实践
接口自动化测试方法与工具
软件测试方法与实践(贯穿案例)
更多...   
成功案例
某支付企业 单元测试与重构培训
北京 用户体验、可用性测试与评估
某军工研究单位 自动化测试方法、案例与工具
知名消费金融公司 探索性测试与测试分析
北京 航天科工某子公司 软件测试架构师
更多...