• 0
  • 0
分享
  • 前端页面的性能测试——软件测试圈
  • 北极 2022-12-15 15:05:28 字数 2360 阅读 1812 收藏 0

介绍

随着 Web 应用的空前发展,前端业务逐渐复杂,为了处理这些复杂业务,前后端分离,出现了专门应对这种分离架构的应用开发框架,比如 Angular,React,Vue 等,从而也导致 Web 应用的复杂度大大增加,并出现了 SPA(Single Page web Application)。同时随着越来越多的用户使用移动设备访问 Web 应用,Web 应用也需要支持一些性能并不是很好的移动设备。所以为了度量和测试 Web 应用是不是在高复杂度的情况下,页面性能能满足用户的需求,我们需要对前端页面系统进行性能测试。

前端页面性能测试本质上和本地应用性能测试类似,其性能和运行应用的设备的性能强相关,即运行被测系统的硬件性能越强,性能也越强。所以测试前端页面性能需要找到一个固定配置的硬件来测试其性能基线,然后通过这个基线推测或者计算其他硬件配置下的性能情况。在项目开发的过程中持续对一个固定配置的硬件进行性能测试,也可以判断性能在开发过程中的趋势,从而第一时间发现性能问题。而测试性能基线,一般是选用最为普通和常规的配置,而不能选用最为流行的高性能配置,不然得到的基线很容易让测试人员有一种页面性能很高的误解。

前端页面性能一般都是有专业的性能工具来测试,比如免费的 WebPageTest、PageSpeed Insights、SiteSpeed 等,这些工具都能检测前端页面的各种性能指标,但是这些工具要么只提供基于在线服务,导致安全性无法保证;要么安装和配置比较复杂或者无法自动执行,导致很难和持续构建流水线集成。Google 开发的免费的 Lighthouse,很好地解决了以上的问题。

Lighthouse

Lighthouse 是 Google 开发的一款分析 Web 应用和 Web 页面性能的工具。除了性能,它还可以分析 Web 页面的 Accessibility,各种页面最佳实践(Best Practices),SEO 以及 Progressive Web App 的能力,对它们打分,并展示出每一项基础项目的数据和结果,如下图:

1.png

其中对于性能的分数,它是根据 6 个不同的性能指标计算而得到的,如下图:

2.png

而这 6 个性能指标又来源于 Chrome DevTool 中的 Performance,点击上图中的“View Original Trace”可以跳转到 Performance,见下图:

3.png

所以,Lighthouse 中的 Performance 所计算的分数是真实性能分数,通过这个分数可以了解到这个页面整体的性能情况。

Lighthouse 除了支持通过 Chrome DevTool 和 Chrome Extension 的手动方式使用以外,还可以通过 Node CLI 和 Node Module 的方式来使用。这种方式特别适合在集成流水线中,以持续测试前端页面的性能,并检测页面性能随着开发而产生的变化趋势,从而尽早发现前端页面的性能问题。

Cypress和Lighthouse

实施前端页面的自动化性能测试的最好方式,就是将它嵌入 Web App 的功能或者端对端自动化测试过程中,当功能和端对端自动化测试执行的过程中就执行了自动化性能测试。Cypress 是当前最为流行的 Web 自动化测试框架之一,它有一款插件 Cypress-Audit 就很好地集成了 Lighthouse 的功能。它能在 Cypress 的自动化测试运行过程中,针对每张测试过的页面生成 Lighthouse 的性能分数,并展示在 Cypress 的测试报告中。

而且我们还可以针对这些分数做断言,当某个页面的分数低于某个阈值的时候,持续构建流水线就会中断,从而通知开发人员或者测试人员对其进行性能分析,发现可能存在的性能问题。首先需要在 Cypress 的自动化测试代码中,配置这 6 个性能指标的阈值,比如配置 First Contentful Paint 的阈值时间为 1000 毫秒,配置代码如下:

cy.lighthouse({
    performance: 50,
    “first-contentful-paint”: 1000,
    accessibility: 50,
    “best-practices”: 50,
    seo: 50,
    pwa: 50,
});

这样在执行 Cypress 自动化测试的过程中,某个页面的指标不满足配置好的阈值,比如 First Contentful Paint 的时间超过了 1000 毫秒,测试就会失败,其测试报告如下图:

4.png

我们可以手动使用 Chrome 浏览器中的 LightHouse 和 Performance DevTools 去分析其性能问题,并通过优化将这个 First Contentful Paint 的时间降到 1000 毫秒以下,其测试就会通过。或者通过分析得知无法提高这个指标,将阈值时间改到 2000 毫米,测试也会通过。

总结

前端页面的性能往往容易被忽视,但是如果存在性能问题,就算后端服务器性能再好,用户的体验也是极差的。并且随着现在富前端和大前端的流行,前端系统越来越复杂,性能问题也越来越多。所以及时发现并修复性能问题是非常重要的,特别是对于关注用户体验的Web系统。如果能自动化前端页面的性能测试,并将其集成到持续流水线中,则可以持续关注前端页面的性能,在第一时间发现其性能问题,并以最低的成本修复这些问题,节约后期的修复成本,最终实现持续的前端页面性能测试。


作者:刘冉

原文链接:https://insights.thoughtworks.cn/frontend-web-pages-performance-testing/

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   “测试”一词最初是指“用于测定贵金属的小容器”。这意味着测试是一种确定黄金或白银质量的方法。它也用于精炼有价值的合金,如锡。  后来,该术语在其他领域被采用,如今,在教育,医学或软件开发等环境中经常会发现它。然而,它的本质并没有改变:测试被用来提炼最终价值。  我们在软件开发中使用测试来确保代码按预期工作。测试可以是手动的,也可以是自动的。手动测试类似于汽车制造商撞车,以验证它们在道路上是否安全。它可以工作,但经常这样做太昂贵了,所以它通常在生产周期结束时完成。这种方法的问题在于,在此阶段发现的问题可能会将产品的发布延迟数月。  自动化软件测试具有完全不同的成本结构。有一个初始反转和定期维...
            0 0 576
            分享
          • 之前做过一个项目,我们公司内部测试完功能之后,还会拿着项目去竞标,在这个过程中,举办方会拿我们的软件找一些专业的公司做检测,其中有一项就是安全漏洞扫描。其实扫描出来的漏洞,用户平时使用中基本很小的概率碰到,但是举办方会拿着这个说事,要求必须整改。这些安全漏洞中最常见的是csrf跨站攻击,修改起来其实也不是特别麻烦,那我们主要就看下平时测试的时候应该怎么注意才能避免这个问题。【csrf攻击的原理】:用户登录浏览器,打开网页A,输入登录信息并操作网站,在未退出登录的情况下,另外开启一个tabB,访问网站进行操作,由于A的登录信息(cookie)已经存储在浏览器中,此时网页B接收到用户请求后,如果是...
            1 1 11217
            分享
          • 距离17年下半年高项考试已过去将近1个月时间,回想起准备考试的日子仍历历在目,现如今吸引眼球的东西太多,需要我们花精力处理的纷杂事情也堆满了难能可贵的休息日,电视剧里跌宕起伏的剧情,奔波于陪孩子补课的路上等诸如此类,以至于每周拿出半天时间去阅读去学习都是极其奢侈的事情,不知大家是否也深有同感,所以如何能够既省时又省力的通过考试,是我们准备考试前都应该了解清楚的事情,俗话说"不打无准备之仗,方能立于不败之地"说的就是这个道理。1. 备考选择我们都知道要想通过考试的决定性因素是分数,我们只要把握住考点以及每年常考和必考内容通过考试基本上没有什么问题,掌握这些考点的过程...
            0 0 988
            分享
          •   一、判定表  1.使用场景:  当多个输入条件之间存在逻辑关系,需要组合测试时,使用判定表法进行分析  2.相关概念  (1)条件桩:输入条件,如工资薪制,错误程度  (2)条件项:输入条件的取值,如年薪制、月薪制  (3)动作桩:输出结果项,如扣款比例,扣款金额,实发工资  (4)动作项:输出每个项的具体值  3.使用步骤  (1)需求分析,得到条件桩和条件项,以及动作桩  (2)确定组合数量(条件项乘积)  (3)得到判定表  (4)导出测试用例,原则,一列是一条测试用例  案例1:  工资发放系统  条件桩:工资薪制  条件项:年薪制,月薪制,季薪制  案例2:  有一个处理单价为5...
            4 4 2443
            分享
          • 摘要:通过比较生产和测试代码版本之间的多个API响应来进行测试的方法非常有效,可以在一个版本一个版本地生成所需的结果。但是,需要改进和改变,以满足不断变化的需要。对于大多数(若不是所有)技术解决方案来说都是如此;“边际效用递减定律”的经济学原理也适用于软件。一种最初引入时让利益相关者兴奋不已的技术解决方案可能很快就会过时。需要修改或新的解决方案来匹配不断发展的期望。概述通过比较生产和测试代码版本之间的多个API响应来进行测试的方法非常有效,可以在一个版本一个版本地生成所需的结果。但是,需要改进和改变,以满足不断变化的需要。对于大多数(如果不是所有)技术解决方案来说都是如此;“边际效用递减定律”...
            1 0 584
            分享
      • 51testing软件测试圈微信