Send your request Join Sii

Best practices in performance testing programming in the context of k6 encompass a range of techniques and approaches that aid in efficient, reliable, and effective performance testing of applications. Additionally, these best practices aim to demonstrate how to create test scenarios that are easy to build and maintain.

Simplifying test scenarios

Up until now, we have focused on creating simple test scenarios. However, even with the reuse of many elements within a scenario, there is potential for further simplification.

To achieve this, we will utilize the httpx module based on the k6 API. This module changes the approach to creating test scenarios, making them more intuitive and easier to maintain. It is considered one of the many good practices in k6.

The core of using the httpx module is the creation of a user session. This approach is reminiscent of that used in tools like JMeter. On the session object, we can define fields such as the base URL or headers, which will be included in every subsequent request. Furthermore, it’s possible to define global settings, such as the timeout duration in case of no application response.

Let’s take a look at an example test scenario.

An example test scenario
Fig. 1 An example test scenario

In the above example, we no longer need to define headers or the full application URL each time.

Covering HTTP requests for static resources

Another interesting practice is covering HTTP requests for static resources. Static files often change on a webpage, which can lead to cumbersome test scenario edits with every change. Therefore, we will create a utils directory to house our helper functions. Next, we’ll place a file named helper.js with the following content in this directory:

Contents of the helper.js file
Fig. 2 Contents of the helper.js file

The above file contains two functions. The first one is already familiar to us and is responsible for pausing the execution of the script. The second function, on the other hand, is used to extract all requests related to static resources on the page, and then it sends a GET request to each of them. This function could be expanded to include proper tagging and checking whether the domain belongs to those of interest.

Moreover, we could add the ability to perform six simultaneous asynchronous calls to static resources at once. This would make our tests even more closely resemble browser behavior.

Creating a test suit

Based on the knowledge gained throughout the series, let’s try to create two test scenarios that will be based on the Sii application. Let’s assume we want to cover the following simplified test scenarios:

  1. Scenario named search-article.js – responsible for searching for articles on the page and then accessing the one of interest:
Step numberTest stepExpected outcome
1User navigates to the homepageUser is on the homepage
2User searches for 1 of the 5 pre-defined articlesThe searched article is displayed to user
3User clicks on the searched articleThe article’s name is displayed to the user

Implementation in k6:

Scenario implementation in k6
Fig. 3 Scenario implementation in k6
  1. Scenario named search-training.js – this scenario searches for a training of interest:
Step numberTest stepExpected outcome
1User navigates to the homepageUser is on the homepage
2User goes to the “Szkolenia” (Trainings) sectionUser is in the “Szkolenia” section
3User navigates to the training searchUser is in the training search section
4User searches for a training named “Zostań Analitykiem Biznesowym”The offer for the training is displayed

Implementation in k6:

Scenario implementation in k6
Fig. 4 Scenario implementation in k6

Scenario Configurations

In the previous sections, we discussed various types of executors used in k6. This is important because if we wanted to change the type of executor, we would need to edit the code inside the scenario. Another option is duplicating the same test scenario.

Both of these solutions are cumbersome to maintain in the long run and impractical. Therefore, different test configurations are used, which can be universally applied to each scenario. Let’s take a look at two configurations:

  1. smoke.json – a configuration responsible for a single run of the scenario.
Configuration of smoke.json
Fig. 5 Configuration of smoke.json
  1. load.json – target configuration that increases the load along with the test duration:
Configuration of load.json
Fig. 6 Configuration of load.json

Defining custom commands

The final stage involves defining commands to run the target scenarios. We will utilize the familiar mechanism from the package.json configuration file that we have already encountered.

Defining custom commands
Fig. 7 Defining custom commands

We have defined four commands, where the first ones are responsible for running two tests with a single iteration configuration. In the latter ones, the execution is for the load testing configuration.

One aspect that could be improved is dynamically defining the number of virtual users used in the second configuration scenario. This enhancement would make the configurations even more versatile for each scenario. After all, the appropriate load for the first scenario is likely to differ from that of the second scenario. This could be achieved using environment variables.

Summary

In the sixth article of our series, we discussed best practices for writing performance test scenarios in k6. We created sample test scenarios and configured them to enhance the versatility of our testing framework.

Our journey with k6 is far from over – we can continue developing the framework and tailor it to our needs to ensure the quality and reliability of our applications. In the next part, we will delve into using Grafana, InfluxDB, and Docker.

***

If you haven’t had a chance to read the articles in the series yet, you can find them here:

In addition, I encourage you to check out the project’s Repository.

5/5 ( votes: 2)
Rating:
5/5 ( votes: 2)
Author
Avatar
Grzegorz Piechnik

Performance Test Engineer z udokumentowanym doświadczeniem w branży bankowej, giełdowej i streamingowej. Jego praca skupiona jest głównie na pełnej automatyzacji procesów wydajnościowych oraz zarządzaniu obserwowalnością w systemach. Poza pracą prowadzi bloga dotyczącego CyberSecurity, Devops i wydajności aplikacji oraz zajmuje się rozwojem narzędzi open source. Ponadto edukuje, szkoli i wprowadza nowe osoby do branży IT

Leave a comment

Your email address will not be published. Required fields are marked *

You might also like

More articles

Don't miss out

Subscribe to our blog and receive information about the latest posts.

Get an offer

If you have any questions or would like to learn more about our offer, feel free to contact us.

Send your request Send your request

Natalia Competency Center Director

Get an offer

Join Sii

Find the job that's right for you. Check out open positions and apply.

Apply Apply

Paweł Process Owner

Join Sii

SUBMIT

Ta treść jest dostępna tylko w jednej wersji językowej.
Nastąpi przekierowanie do strony głównej.

Czy chcesz opuścić tę stronę?