性能测试回归测试_自动网站性能回归测试

性能测试回归测试

by Adam Henson

亚当·汉森(Adam Henson)

如何使用Foo自动执行网站性能回归测试 (How to automate website performance regression testing with Foo)

使用部署后步骤自动执行连续交付工作流程中的性能回归测试 (Using a post deploy step to automate performance regression testing in a continuous delivery workflow)

In another post I went over how to analyze website performance using Lighthouse, and specifically how we can automate performance monitoring with Foo. In this post I’m going to demonstrate how we can step it up a notch by regression testing performance… automagically ?.

在另一篇文章中，我介绍了如何使用Lighthouse分析网站性能 ，特别是如何使用Foo自动执行性能监控。 在这篇文章中，我将演示如何通过回归测试性能……自动地将其提升一个等级。

什么是回归测试？ (What is Regression Testing?)

Regression Testing is a type of software testing to confirm that a recent program or code change has not adversely affected existing features. Adhering to best practice could include the below.

回归测试是一种软件测试，用于确认最近的程序或代码更改未对现有功能造成不利影响。 遵循最佳做法可能包括以下内容。

• Maintain a Strict Testing Schedule: Always maintain a continual testing schedule throughout the entire software development life cycle. Not only will this quickly force the team to adapt to a frequent testing regimen, it will also ensure the finished product is as well-tested as possible.

  维护严格的测试计划 ：在整个软件开发生命周期中始终保持连续的测试计划。 这不仅将Swift迫使团队适应频繁的测试方案，还将确保最终产品经过尽可能好的测试。

• Use Test Management Software: Unless your current software project is a simple self-developed side project, chances are you’ll have such an abundance of tests that tracking each will be well beyond the capabilities of a single individual or a spreadsheet. Thankfully, there are many different test management tools on the market designed to simplify the process of creating, managing, tracking, and reporting on all the tests in your entire testing suite.

  使用测试管理软件 ：除非您当前的软件项目是一个简单的自行开发的副项目，否则您将拥有大量的测试，因此跟踪每个测试的能力将远远超出单个人或电子表格的能力。 幸运的是，市场上有许多不同的测试管理工具旨在简化整个测试套件中所有测试的创建，管理，跟踪和报告过程。

• Categorize Your Tests: Imagine a test suite of hundreds or thousands of tests that are merely identified by a single name or id field. How on Earth would anyone ever sort through that massive list in order to identify tests that are related? The solution is to categorize tests into smaller groups based on whatever criteria is appropriate for your team. Most test management tools will provide the means of categorizing or tagging tests, which will make it easier for everyone on the team to identify and reference a certain type of test.

  分类测试 ：想象一个包含数百或数千个测试的测试套件，这些测试仅由一个name或id字段id 。 在地球上，任何人将如何对大量列表进行排序以识别相关测试？ 解决方案是根据适合您团队的任何标准将测试分类为较小的组。 大多数测试管理工具将提供对测试进行分类或标记的方法，这将使团队中的每个人都更容易识别和引用特定类型的测试。

• Prioritize Tests Based on Customer Needs: One useful way to prioritize tests is to consider the needs of the customer or user. Consider how a given test case impacts the end user’s experience or the customer’s business requirements.

  根据客户需求对测试进行优先级排序：对测试进行优先级排序的一种有用方法是考虑客户或用户的需求。 考虑给定的测试用例如何影响最终用户的体验或客户的业务需求。

Check out this article for more info: “Regression Testing: What It Is and How to Use It”

请查看本文以获取更多信息：“ 回归测试：它是什么以及如何使用它 ”

“网站性能”实际上是什么意思？ (What Does “Website Performance” Actually Mean?)

Load times vary dramatically from user to user, depending on their device capabilities and network conditions. Traditional performance metrics like load time or DOMContentLoaded time are extremely unreliable since when they occur may or may not correspond to when the user thinks the app is loaded.

加载时间因用户而异，具体取决于他们的设备功能和网络状况。 传统的性能指标(例如加载时间或DOMContentLoaded时间)极其不可靠，因为它们发生的时间可能与用户认为已加载应用程序的时间相对应，也可能不相对应。

~ User-centric Performance Metrics | Web Fundamentals | Google Developers

〜以用户为中心的性能指标| 网页基础知识| Google开发人员

Nowadays, life cycle of a web page load can be thought of more granularly. We can think of website performance metrics as being “user-centric”. When a user goes to a web page, they’re typically looking for visual feedback to reassure them everything is working as expected.

如今，可以更精细地考虑网页加载的生命周期。 我们可以将网站效果指标视为“以用户为中心”。 当用户转到网页时，他们通常是在寻找视觉反馈，以确保他们一切正常。

The metrics below represent important points of the page load life cycle. Each answers questions about the user experience.

以下指标代表页面加载生命周期的重要点。 每个回答有关用户体验的问题。

• First Contentful Paint: Is it happening? Did the navigation start successfully? Has the server responded?

  第一个内容丰富的油漆 ：正在发生吗？ 导航是否成功启动？ 服务器响应了吗？

• First Meaningful Paint: Is it useful? Has enough content rendered that users can engage with it?

  首先有意义的绘画 ：有用吗？ 是否渲染了足够的内容以使用户可以参与其中？

• Time to Interactive: Is it usable? Can users interact with the page, or is it still busy loading?

  互动时间 ：可以使用吗？ 用户可以与页面进行交互，还是仍在忙于加载？

• Long Tasks (absence of): Is it delightful? Are the interactions smooth and natural, free of lag and jank?

  长任务(不存在) ：令人愉快吗？ 交互是否顺畅自然，没有滞后和颠簸？

We can run performance audits manually or programmatically using tools like Lighthouse to provide values to metrics similar to the above. We can use a Lighthouse integration like Foo to automatically monitor website performance over time. In the example below you can see Twitter’s performance degrade and correlate it to an exact day and time! What if we could pinpoint this to an exact release? In the next section I explain how to do this.

我们可以使用Lighthouse之类的工具手动或以编程方式运行绩效审核，以为与上述类似的指标提供价值 。 我们可以使用像Foo这样的Lighthouse集成 来自动监控网站的性能 。 在下面的示例中，您可以看到Twitter的性能下降并将其与确切的日期和时间相关联！ 如果我们可以确定确切的版本怎么办？ 在下一节中，我将说明如何执行此操作。

我们如何自动回归测试性能？ (How Can we Regression Test Performance Automatically?)

We can accomplish automatic performance tests integrated as a post deploy step in a continuous delivery pipeline. We can do this by creating a free account with Foo and utilizing its public REST API. Follow the steps below.

我们可以完成自动性能测试，作为连续交付管道中的部署后步骤进行集成。 为此，我们可以使用Foo创建一个免费帐户并利用其公共REST API。 请按照以下步骤操作。

1. Create a free account with Foo. Verify your email by clicking on the link sent.

   使用Foo创建一个免费帐户 。 通过单击发送的链接来验证您的电子邮件。

2. Create a page on Foo where you can add the URL to the page you want to performance test.

   在Foo上创建一个页面 ，您可以在其中将URL添加到要进行性能测试的页面。

3. Click on the list item for your page from the screen above. This will direct you to the dashboard reflecting your page.
   在上方的屏幕上，单击页面的列表项。 这会将您定向到反映您的页面的仪表板。
4. Obtain the page API token by scrolling to the bottom of the page above.
   滚动到上面页面的底部，获取页面API令牌。

5. Trigger a test run by requesting the endpoint as detailed in Foo’s API documentation. A curl command would look something like curl -X POST "https://www.foo.software/api/v1/queue/items" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"pages\": \"pagetoken1,pagetoken2\", \"tag\": \"My Tag\" }".

   通过请求端点来触发测试运行，如Foo的API文档中所述 。 curl命令看起来像curl -X POST "https://www.foo.software/api/v1/queue/items" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"pages\": \"pagetoken1,pagetoken2\", \"tag\": \"My Tag\" }" 。

6. Add the above command as a post deploy step in your CD pipeline. You can find a full example in GitHub. Below a circleci snippet that actually defines this step.

   将以上命令作为CD管道中的部署后步骤添加。 您可以在GitHub中找到完整的示例 。 在实际上定义此步骤的circleci片段下方。

From the example linked above our pipeline steps run on every commit to our master branch.

从上面链接的示例中，我们的流水线步骤在对master分支的每次提交上运行。

And voilà we are now deploying a release on every commit to master and running a performance audit on it automatically ⭐!

而且，我们现在每次对master提交都部署一个发行版，并自动对其进行性能审核⭐！

结论 (Conclusion)

Foo provides many features to monitor and analyze performance. In this post we took a look into how we can utilize it to run Lighthouse performance regression testing automatically. Below are other features — most of which are free!

Foo提供了许多功能来监视和分析性能 。 在这篇文章中，我们研究了如何利用它来自动运行Lighthouse性能回归测试。 以下是其他功能-其中大多数是免费的 ！

• Automatic performance audits, a timeline visualization and detailed views of results.
  自动绩效审核，时间线可视化和结果的详细视图。
• Email, Slack, an PagerDuty notifications when performance has dropped, improved or become “back to normal”.
  当性能下降，提高或恢复“正常”时，通过电子邮件，Slack和PagerDuty通知。
• Automatic health check pings and notifications.
  自动运行状况检查ping和通知。

翻译自: https://www.freecodecamp.org/news/automatic-website-performance-regression-testing-4e30e6bf5cd/

性能测试回归测试