A GET request gets the information from the server. When you make the GET request on the server, then the server responds to the request. GET requests will not affect any data on the server. This means, there is no creation, updation, addition, or deletion of data on the server when you are making a GET request.
We will use the following URL for this Postman tutorial.
http://dummy.restapiexample.com/api/v1/employees
Implementation Steps
To create the first GET request in Postman, follow the following steps:
Create a Collection
Step 1: Create a Collection, click on Collections, and then click on the “+” plus button.
Step 2: Provide a name to the collection – “API Testing”.
Add a request to the Collection
Step 3: To create a new request, click on “Add a request”, if it is a new Collection. Otherwise, click on the 3 dots and select “Add request”.
Step 4: Once you create a new request, then you will get the following window:
Enter the details of request
Step 5: Enter the “name” in the request. Here, the name is “GET Demo”.
Step 5:Enter the “URL” in the address bar.
Step 6:Now, select the “GET” request from the list of request methods.
Send the Request
Step 7: Press the “Send” button.
Verify the Response
Step 8: Once you press the send button, you will get the response from the server. Make sure you have a proper internet connection; otherwise, you will not get a response.
Status
You can check the status code. Here, we got the status code 200, which means we got a successful response to the request.
Body
In the Body tab of the response box, we have multiple options to see the response in a different format.
Format Type
Each request has a defined response to it as defined by the Content-Type header. That response can be in any format. Such as in the above example, we have JSON code file.
Below are the various format type present in Postman.
XML
HTML
Text
Headers
Headers are the extra information that is transferred to the server or the client. In Postman, headers will show like key-value pairs under the headers tab. Click on the Headers link as shown in the below image:
We are done! Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!!
In this tutorial, we will integrate JMeter with Maven to support CI/CD.
Maven and jmeter-maven-plugin make it easy to integrate performance tests with CI/CD tools & technologies such as Jenkins/Jenkinsfiles or Azure/Azure pipelines and cloud build agents. It also helps to run your tests with different versions of JMeter.
Step 5 – Create a new directory src/test/jmeter and place JMeter Script in it
Create a new directory within src/test with the name jmeter.
Place the JMeter script(.jmx) file in src/test/jmeter. The steps to create a Test Plan in JMeter are mentioned at the end of the page.
Step 6 – Run JMeter Test with JMeter Maven Plugin
Go to your project directory and run the following command in the command line:
mvn clean verify
The test execution is displayed in the command line as shown below:
The test ran successfully! The results are located at /target/jmeter/reports. You will find an HTML report named “Index.html”:
Right-click on the Index.html and select Open In->Browser->Chrome (any browser of your wish).
This report provides the following metrics:
In the Dashboard of the report;
APDEX (Application Performance Index) table that computes for every transaction the APDEX based on configurable values for tolerated and satisfied thresholds
A request summary graph showing the Success and failed requests
A Statistics table providing in one table a summary of all metrics per transaction including 3 configurable percentiles:
An error table providing a summary of all errors and their proportion in the total requests
A Top 5 Errors by Sampler table providing for every Sampler (excluding Transaction Controller by default) the top 5 Errors:
You can see that there are a lot of other types of reports too. You should explore these reports.
Add Thread Group To add Thread Group: Right-click on the “Test Plan” and add a new thread group: Add -> Threads (Users) -> Thread Group
In the Thread Group control panel, enter Thread Properties as follows: We will take an example of row no 5
Number of Threads: 5 – Number of users connects to the target website Loop Count:Infinite – Number of times to execute testing Ramp-Up Period: 5 – It tells JMeter how long to delay before starting the next user. For example, if we have 5 users and a 5 -second Ramp-Up period, then the delay between starting users would be 1 second (5 seconds /5 users).
Duration – 2 sec
Step 2 – Adding JMeter elements
The JMeter element used here is HTTP Request Sampler. In HTTP Request Control Panel, the Path field indicates which URL request you want to send
2.1 Add HTTP Request Sampler To add: Right-click on Thread Group and select: Add -> Sampler -> HTTP Request
The below-mentioned are the values used in HTTP Request to perform the test
Name – HTTP POST Request Demo
Server Name or IP – reqres.in
Port – Blank
Method – POST
Path – /api/users
2.2 Add HTTP Head Manager
The Header Manager lets you add or override HTTP request headers like can add Accept-Encoding, Accept, Cache-Control
To add: Right-click on Thread Group and select: Add -> Config Element -> HTTP Read Manager
The below-mentioned are the values used in Http Request to perform the test Content-type = application/json
Step 3 – Adding Listeners to Test Plan
Listeners – They show the results of the test execution. They can show results in a different format such as a tree, table, graph, or log file We are adding the View Result Tree listener
View Result Tree – View Result Tree shows the results of the user request in basic HTML format To add: Right-click on Test Plan, Add -> Listener -> View Result Tree
Aggregate Report
It is almost the same as Summary Report except Aggregate Report gives a few more parameters like, “Median”, “90% Line”, “95% Line” and “99% Line”.
To add: Right Click on Thread Group > Add > Listener > Aggregate Report
Step 4 – Save the Test Plan
To Save: Click File Select -> Save Test Plan as ->Give the name of the Test Plan (POST_LoadDemo.jmx). It will be saved in .jmx format.
We are done! Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!!
Parameterization is a method that allows us to run a test plan several times with various sets of data. This aids in the development of a load test script that closely resembles real-world circumstances in which various users utilize different test data. Assume we need to do a load test on a search engine such as Bing. The initial step will be to document the search circumstance. To conduct an effective load test, we cannot just playback the script for 500 users. We should mimic 500 distinct users searching for 500 different items. We may utilize parameterization for this, with a CSV file containing 500 distinct search phrases. Now instead of the static search item that we had recorded in our script, we can include the search items from the CSV file dynamically.
Add Thread Group To add Thread Group: Right-click on the “Test Plan” and add a new thread group: Add -> Threads (Users) -> Thread Group
In the Thread Group control panel, enter Thread Properties as follows: We will take an example of row no 5
Number of Threads: 5 – Number of users connects to the target website Loop Count: 2 – Number of times to execute testing Ramp-Up Period: 5 – It tells JMeter how long to delay before starting the next user. For example, if we have 5 users and a 5 -second Ramp-Up period, then the delay between starting users would be 1 second (5 seconds /5 users).
Step 2 – Add HTTP Request Sampler
The JMeter element used here is HTTP Request Sampler. In HTTP Request Control Panel, the Path field indicates which URL request you want to send
Add HTTP Request Sampler To add: Right-click on Thread Group and select: Add -> Sampler -> HTTP Request
The below-mentioned are the values used in HTTP Request to perform the test
Name – Parameterized HTTP Request
Server Name or IP – reqres.in
Port –
Protocol – https
Method – POST
Path – /api/users
Here, we are parameterizing the test data for name and job attributes.
Step 3 – Add HTTP Head Manager
The Header Manager lets you add or override HTTP request headers like can add Accept-Encoding, Accept, Cache-Control
To add: Right-click on Thread Group and select: Add -> Config Element -> HTTP Read Manager
The below-mentioned are the values used in Http Request to perform the test Content-type = application/json
Below is the image once HTTP Header Manager is added to the Test Plan.
Step 4 – Add CSV Data Set Config
The ‘CSV Data Set Config’ element is used to read lines from a file and split them into variables. It is well suited to handle large numbers of variables and is also useful for testing with random and unique values.
To add: Right-click on Thread Group and select: Add -> Config Element -> CSV Data Set Config
Fill in the data in the required fields.
Let’s have a look at how the CSV Data Set is configured:
Filename: the path to the CSV file containing the data,
File Encoding: can be UTF-8 for example. The character encoding affects how the file is read,
Variable Names: comma-delimited list of names, should be an equal number of names than columns in CSV file. Example: name, job.
Ignore First Line: false by default, whenever to ignore the first line as a value (because it may contain the column names),
Delimiter: , by default, can be set to anything else. Suggestion: stick with the default one,
Allow Quoted Data: false by default, set to true if you have double quotes in CSV columns,
Recycle on EOF: true by default, should JMeter restart from the beginning when the End Of File is reached,
Stop Thread on EOF: stops the current thread gathering the value if EOF is reached,
Sharing Mode: defines how values are distributed among concurrent threads.
Below is the CSV file that has the data for the name and job attributes of the request.
Step 5 – Adding Listeners to Test Plan
Listeners – They show the results of the test execution. They can show results in a different format such as a tree, table, graph, or log file We are adding the View Result Tree listener
View Result Tree – View Result Tree shows the results of the user request in basic HTML format To add: Right-click on Test Plan, Add -> Listener -> View Result Tree
Note – Don’t use “View Results Tree” or “View Results in Table” listeners during the load test, use them only during the scripting phase to debug your scripts.
Aggregate Report
It is almost the same as Summary Report except Aggregate Report gives a few more parameters like, “Median”, “90% Line”, “95% Line” and “99% Line”.
To add: Right Click on Thread Group > Add > Listener > Aggregate Report
Step 6 – Save the Test Plan
To Save: Click File Select -> Save Test Plan as ->Give the name of the Test Plan. It will be saved in .jmx format.
Step 7 – Run the Test Plan
Click on the Green Triangle as shown at the top to run the test.
Step 8 – View the Execution Status
Click on View Result Tree to see the status of Run. A successful request will be of a Green colour in the Text Section.
We can see that Performance and Test2 are present in the CSV file. The script has to read the data from the file and passed it to the request.
Click on Response data and Response Header to view other information about Response.
Click on Aggregate Report Result to see the aggregated status of Run.
We are done! Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!!
Integrating JMeter with Jenkins is a powerful way to enhance CI/CD pipelines by automating performance testing. In this tutorial, we are going to learn how we can integrate JMeter with Jenkins.
Apache JMeter is a popular open-source testing tool. It is widely used for performance testing, load testing, and functional testing of web applications and other services. Jenkins is an open-source automation server. It can be used with these tools to automate the testing process easily.
A few of the main benefits of using JMeter with Jenkins are:
Unattended test execution for each system.
Build failure logs and recovery steps.
Secure and easy access to test reports of each build.
Automation of routine work.
Prerequisite
Apache JMeter is installed on the system : It will be used for creating and executing performance test scripts.
Jenkins is installed on the system. It is an open-source automation server. Jenkins will manage the build and deployment pipelines. It will also execute JMeter tests as part of the CI/CD process.
Implementation Steps
Step 1: Download the Performance Plugin
To generate a Performance Report in Jenkins, we need to download Performance Plugin. Please refer to this tutorial to install the plugin – How to install Plugins in Jenkins.
Step 2: Create a JMeter Script
It is advisable to have a JMeter Script built and tested that it is working locally. To know how to create a JMeter Script, please refer to this tutorial – How to send POST requests in JMeter.
Step 3: Create a new FreeStyle project
Give the Name of the project – JMeter_Demo
Click on the FreeStyle project.
Click on the OK button.
In the General section, enter the project description in the Description box.
Step 4: Source Code Management
Select Source Code Management as None if the project is locally present on the machine.
Step 5: Select Execute Windows batch command
In the Build Steps section, select Execute Windows batch command.
Use the below command to go to the path where the JMeter is placed in your system.
cd C:\Users\Vibha\Documents\Vibha\Automation\apache-jmeter-5.6\apache-jmeter-5.6\bin
jmeter -n -t C:\Users\Vibha\Documents\Vibha\Automation\apache-jmeter-5.6\apache-jmeter-5.6\bin\POST_Demo.jmx -l C:\Users\Vibha\Documents\Vibha\Automation\apache-jmeter-5.6\apache-jmeter-5.6\results\result1.jtl
In the above command, we are executing the JMeter Script – POST_Demo.jmx as well as generating a result1.jtl file in the folder results.
Step 6: Select “Publish Performance test result report” from “Post Build Actions”
Scroll down to ‘Post Build Actions’ and click on the ‘Add Post Build Actions’ drop-down list. Select “Publish Performance test result report.“.
Enter the Source data files as the path in workspace where the report will be saved .
Click on the Apply and Save buttons.
We have created a new project “JMeter_Demo” with the configuration to run the JMeter and also to generate JMeter Reports after execution using Jenkins.
Step 7: Execute the tests
Let’s execute it now by clicking on the “Build Now” button.
Right-click on Build Number (here in my case it is #1).
Click on Console Output to see the result.
Step 8: View the Performance Report
Once the execution is completed, we can see a link to view the ‘Performance Report’.
Click on the Performance Report. It displays the summary of the tests.
Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!! Cheers!!
In this tutorial, we will explain how to create a JMeter Test Plan for a Web Application.
Create a Web Test Plan in JMeter
Step 1 – Add Thread Group
Select Test Plan on the tree
Add Thread Group Right-click on Test Plan> Add > Threads
In the Thread Group control panel, enter Thread Properties as follows: We will take an example of row no 5
Number of Threads: 5 – Number of users connects to the target website Ramp-Up Period: 5 – It tells JMeter how long to delay before starting the next user. For example, if we have 5 users and a 5 -second Ramp-Up period, then the delay between starting users would be 1 second (5 seconds /5 users).
Loop Count: 2 – Number of times to execute testing
Step 2 – Adding JMeter elements
2.1 Add HTTP Request Defaults Here, we need to enter the URL of the testing site. Right-click on Thread Group> Add > Config Element > HTTP Request Defaults
2.2 Add HTTP Cookie Manager
The cookie policy should be set to Compatibility. Right-click on Thread Group > Add > Config Element > HTTP Cookie Manager
Below is the HTTP Cookie Manager added to the plan.
2.3 Add the Simple Controller
A simple controller is used as a container for the request. We add the login and home page under the simple Controller. Right-click on Thread Group > Add > Logic Controller > Simple Controller
2.4 Add HTTP Request Sampler
It is used for HTTP page requests. Right-click on Simple Controller> Add >Sampler> HTTP Request
The below-mentioned are the values used in HTTP Request to perform the test
Name – Index Page
Server Name or IP – Blank
Port – Blank
Method – GET
Path – /index.html
2.5 Add Response Assertion
Add the Assertion method to verify the Index page. Right-click on Index Page (HTTP request) > Add > Assertions > Response Assertion
Add text to verify the Index Page
2.6 Add Second HTTP Request Sampler
It is used for HTTP page requests for the Change page. Right-click on Simple Controller> Add >Sampler> HTTP Request
The below-mentioned are the values used in HTTP Request to perform the test
Name – Change Page
Server Name or IP – Blank
Port – Blank
Method – GET
Path – /changes.html
2.7 Add Second Response Assertion
Add the Assertion method to verify the Change page. Right-click on Index Page (HTTP request) > Add > Assertions > Response Assertion
Add text to verify the Changes Page
Step 3 – Adding Listeners to Test Plan
Listeners – They show the results of the test execution. They can show results in a different format such as a tree, table, graph, or log file We are adding the View Result Tree listener
View Result Tree – View Result Tree shows the results of the user request in basic HTML format Right-click on Test Plan, Add -> Listener -> View Result Tree
Aggregate Report
It is almost the same as Summary Report except Aggregate Report gives a few more parameters like, “Median”, “90% Line”, “95% Line” and “99% Line”.
Right Click on Thread Group > Add > Listener > Aggregate Report
Step 4 – Save the Test Plan
To Save: Click File Select -> Save Test Plan as ->Give the name of the Test Plan. It will be saved in .jmx format.
Step 5 – Run the Test Plan
Click on the Green Triangle as shown at the top to run the test.
Step 6 – View the Execution Status
Click on View Result Tree to see the status of Run. A successful request will be of a Green in the Text Section.
Click on Response data and Response Header to view other information about Response.
Click on Aggregate Report Result to see the aggregated status of Run.
We are done! Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!!
GitLab automatically enables CI/CD pipelines for new projects. It’s just a matter of adding a new configuration file called .gitlab-ci.yml to your code repository with instructions for GitLab on what to run. So simply create the following basic workflow in your main repository directory and commit it:
The Serenity tests run on a headless browser in the pipeline.
What is a headless browser?
A headless browser is a web browser that operates without a graphical user interface (GUI). It is typically used for automated testing, web scraping, and server-side rendering of web pages. While traditional web browsers like Chrome, Firefox, or Safari have a visible interface for users to interact with, headless browsers work in the background and don’t display the web content visually.
Why do we use Headless browser for executing tests in CI/CD pipeline?
Headless browsers provide a consistent and controlled environment for running tests. They eliminate the variability introduced by different operating systems, browser versions, or screen resolutions, ensuring that tests produce consistent and reliable results across different environments.
Headless browsers can often execute tasks faster than their graphical counterparts. They don’t need to render and display web content, which can significantly reduce the execution time for automated tests or other web-related tasks, contributing to faster feedback in the CI/CD pipeline.
In the below example, our tests are in headless mode.
WebDriverManager.chromedriver().setup();
ChromeOptions ops = new ChromeOptions().setHeadless(true);
ops.addArguments("--remote-allow-origins=*");
driver = new ChromeDriver(ops);
To know, how to create a blank new project in GitLab, please refer tothis tutorial.
Step 2 – Push the project from local repository to Gitlab Repository
To know, how to push the changes in GitLab, please refer to this tutorial.
Step 3 – Create a .gitlab-ci.yml file in the project in GitLab
There are many ways to create a new file in GitLab. One of the ways is to create a file as shown in the below image.
It is a YAML file where you configure specific instructions for GitLab CI/CD. In the .gitlab-ci.yml, we can define:
The scripts you want to run.
Other configuration files and templates you want to include.
Dependencies and caches.
The commands you want to run in sequence and those you want to run in parallel.
The location to deploy your application to.
Whether you want to run the scripts automatically or trigger any of them manually.
Below is a sample example to run the Cucumber tests in the GitLab pipeline.
image: markhobson/maven-chrome
stages:
- test
variables:
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
test:
stage: test
allow_failure: true
# Run the tests
script:
- echo "Executing BDD scenarios with maven"
- mvn clean test
# Store artifacts
artifacts:
when: always
name: "Cucumber Report"
paths:
- target/*
expire_in: 24 h
Image – markhobson/maven-chrome is used in this test. It is a docker image for Java automated UI tests.
Pipeline configuration begins with jobs. Jobs are the most fundamental element of a .gitlab-ci.yml file.
Jobs are:
Defined with constraints stating under what conditions they should be executed.
Top-level elements with an arbitrary name must contain at least the script clause.
Not limited in how many can be defined.
Jobs can output an archive of files and directories. This output is known as a job artifact. The expire_in keyword determines how long GitLab keeps the job artifacts. Here, it shows 24 hrs to retain the artifacts.
Step 4 – Run the tests in the GitLab pipeline
Now, when a new change is committed, a pipeline kicks off and it runs all the tests.
Step 5 – Check the status of the pipeline
Once the Status of the pipeline changes to either failed or passed.. that means the tests are already executed.
As you can see the Status is passed, it’s green colour. This means all the tests present in the test suite are executed and passed. If any test fails in the test suite, the final execution status will be brown. The reason for the brown colour is we have mentioned allow_failure: true.
Below shows the execution status report in the GitLab pipeline.
As I have added an artifact also in the .gitalb-ci.yml, which is highlighted in the image. This artifact creates a folder with the name “Cucumber_Report”and the reports in this folder come from the path /target/site. This artifact gives us the option to download the reports or browse the report. This report will be available for 24 hours only as mentioned in the gitlab-ci.yml.
Step 5 – Download the report
Once, will click on the download button, it will download “Cucumber_Report.zip”. Unzip the folder and it looks like something as shown below:
Example of Overview Features
Example of Overview Tags
Example of Overview Steps
Congratulations. This tutorial has explained the steps to run Cucumber tests in GitLab CI/CD. Happy Learning!!
JMeter supports dashboard report generation to get graphs and statistics from a test plan. In this tutorial, we will explain how to generate JMeter HTML Report.
The dashboard generator is a modular extension of JMeter. Its default behaviour is to read and process samples from CSV files to generate HTML files containing graph views. It can generate the report at the end of a load test or on demand.
Add Thread Group To add Thread Group: Right-click on the “Test Plan” and add a new thread group: Add -> Threads (Users) -> Thread Group
In the Thread Group control panel, enter Thread Properties as follows: We will take an example of row no 5
Number of Threads: 5 – Number of users connects to the target website Loop Count: 5 – Number of times to execute testing Ramp-Up Period: 5 – It tells JMeter how long to delay before starting the next user. For example, if we have 5 users and a 5 -second Ramp-Up period, then the delay between starting users would be 1 second (5 seconds /5 users).
Step 2 – Adding JMeter elements
The JMeter element used here is HTTP Request Sampler. In HTTP Request Control Panel, the Path field indicates which URL request you want to send
2.1 Add HTTP Request Sampler To add: Right-click on Thread Group and select: Add -> Sampler -> HTTP Request
The below-mentioned are the values used in HTTP Request to perform the test
Name – HTTP POST Request Demo
Server Name or IP – reqres.in
Port – Blank
Method – POST
Path – /api/users
2.2 Add HTTP Head Manager
The Header Manager lets you add or override HTTP request headers like can add Accept-Encoding, Accept, Cache-Control
To add: Right-click on Thread Group and select: Add -> Config Element -> HTTP Read Manager
The below-mentioned are the values used in Http Request to perform the test Content-type = application/json accept – application/json
Step 3 – Adding Listeners to Test Plan
Listeners – They show the results of the test execution. They can show results in a different format such as a tree, table, graph, or log file We are adding the View Result Tree listener
View Result Tree – View Result Tree shows the results of the user request in basic HTML format To add: Right-click on Test Plan, Add -> Listener -> View Result Tree
Aggregate Report
It is almost the same as Summary Report except Aggregate Report gives a few more parameters like, “Median”, “90% Line”, “95% Line” and “99% Line”.
To add: Right Click on Thread Group > Add > Listener > Aggregate Report
Step 4 – Save the Test Plan
To Save: Click File Select -> Save Test Plan as ->Give the name of the Test Plan. It will be saved in .jmx format.
The below image shows that the test is saved in Documents with the name POST_Load.jmx.
Report Generation after load test
Step 5 – Run the Test Plan from Command Line
Open the command prompt and go into JMeter’s bin folder.
cd C:\Users\Vibha\Documents\apache-jmeter-5.6\apache-jmeter-5.6\bin
Below is the detail about the commands used in the execution.
-n: This specifies JMeter is to run in cli mode
-t: [name of JMX file that contains the Test Plan]
-l: [name of JTL file to log sample results to]
–e: generate report dashboard after load test
-o: output folder where to generate the report dashboard after the load test. The folder must not exist or be empty
The test execution is displayed in the command line as shown below:
The result1.csv is saved as mentioned in the above command in the JMeterResult folder present in Documents:
Go to the Report Folder. You can find the generated HTML files in the given report path.
This report provides the following metrics:
In the Dashboard of the report;
APDEX (Application Performance Index) table that computes for every transaction the APDEX based on configurable values for tolerated and satisfied thresholds
A request summary graph showing the Success and failed requests
A Statistics table providing in one table a summary of all metrics per transaction including 3 configurable percentiles:
An error table providing a summary of all errors and their proportion in the total requests
A Top 5 Errors by Sampler table providing for every Sampler (excluding Transaction Controller by default) the top 5 Errors:
You can see that there are a lot of other types of reports too. You should explore these reports.
Generation from an existing sample CSV log file
Imagine, we have run the tests from JMeter GUI. Mention the path where we want to save the result file in the Filename option of one of the listeners.
Run the tests, and we can see that the result is generated.
In this tutorial, we will explain how to run tests in JMeter in non-GUI mode (Command Line mode).
Why execute tests in non-GUI mode?
The JMeterGUI’s inability to handle huge loads and excessive resource consumption risks overloading the server, which would give you inaccurate test results information. Additionally, the less load you can generate throughout your tests, the more resource-intensive the server is.
Create a Test Plan in JMeter by following the below-mentioned steps
Step 1 – Add Thread Group
Select Test Plan on the tree
Add Thread Group To add Thread Group: Right-click on the “Test Plan” and add a new thread group: Add -> Threads (Users) -> Thread Group
In the Thread Group control panel, enter Thread Properties as follows: We will take an example of row no 5
Number of Threads: 5 – Number of users connects to the target website Loop Count: 5 – Number of times to execute testing Ramp-Up Period: 5 – It tells JMeter how long to delay before starting the next user. For example, if we have 5 users and a 5 -second Ramp-Up period, then the delay between starting users would be 1 second (5 seconds /5 users).
Step 2 – Adding JMeter elements
The JMeter element used here is HTTP Request Sampler. In HTTP Request Control Panel, the Path field indicates which URL request you want to send
2.1 Add HTTP Request Sampler To add: Right-click on Thread Group and select: Add -> Sampler -> HTTP Request
The below-mentioned are the values used in HTTP Request to perform the test
Name – HTTP POST Request Demo
Server Name or IP – reqres.in
Port – Blank
Method – POST
Path – /api/users
2.2 Add HTTP Head Manager
The Header Manager lets you add or override HTTP request headers like can add Accept-Encoding, Accept, Cache-Control
To add: Right-click on Thread Group and select: Add -> Config Element -> HTTP Read Manager
The below-mentioned are the values used in Http Request to perform the test Content-type = application/json accept – application/json
Step 3 – Adding Listeners to Test Plan
Listeners – They show the results of the test execution. They can show results in a different format such as a tree, table, graph, or log file We are adding the View Result Tree listener
View Result Tree – View Result Tree shows the results of the user request in basic HTML format To add: Right-click on Test Plan, Add -> Listener -> View Result Tree
Aggregate Report
It is almost the same as Summary Report except Aggregate Report gives a few more parameters like, “Median”, “90% Line”, “95% Line” and “99% Line”.
To add: Right Click on Thread Group > Add > Listener > Aggregate Report
Step 4 – Save the Test Plan
To Save: Click File Select -> Save Test Plan as ->Give the name of the Test Plan. It will be saved in .jmx format.
The below image shows that the test is saved in Documents with the name POST_Load.jmx.
Step 5 – Run the Test Plan from Command Line
Open the command prompt and go into JMeter’s bin folder.
cd C:\Users\Vibha\Documents\apache-jmeter-5.6\apache-jmeter-5.6\bin
GitLab automatically enables CI/CD pipelines for new projects. It’s just a matter of adding a new configuration file called .gitlab-ci.yml to your code repository with instructions for GitLab on what to run. So simply create the following basic workflow in your main repository directory and commit it.
Step 3 – Create a .gitlab-ci.yml file in the project in GitLab
There are many ways to create a new file in GitLab. One of the ways is to create a file as shown in the below image.
It is a YAML file where you configure specific instructions for GitLab CI/CD. In the.gitlab-ci.yml, we can define:
The scripts you want to run.
Other configuration files and templates you want to include.
Dependencies and caches.
The commands you want to run in sequence and those you want to run in parallel.
The location to deploy your application to.
Whether you want to run the scripts automatically or trigger any of them manually.
Below is a sample example to run the Gradle tests in the GitLab pipeline.
image : gradle:7.1.0-jdk11
stages:
- test
variables:
GRADLE_OPTS: "-Dorg.gradle.daemon=false"
test:
stage: test
allow_failure: true
# Run the tests
script:
- echo "Executing BDD scenarios with Gradle"
- gradle clean test
- gradle reports
# Store artifacts
artifacts:
when: always
name: "Gradle Report"
paths:
- lib/target/site/serenity/*
expire_in: 24 h
Image – gradle:7.1.0-jdk11 is used in this test. It is a docker image for Gradle with Java 11 installed in it.
Pipeline configuration begins with jobs. Jobs are the most fundamental element of a .gitlab-ci.yml file.
Jobs are:
Defined with constraints stating under what conditions they should be executed.
Top-level elements with an arbitrary name and must contain at least the script clause.
Not limited in how many can be defined.
Jobs can output an archive of files and directories. This output is known as a job artifact. The expire_in keyword determines how long GitLab keeps the job artifacts. Here, it shows 24 hrs to retain the artifacts.
Step 4 – View GitLab Pipeline
Now, when a new change is committed, a pipeline kicks off and it runs all the tests. To view the pipeline, go to the left panel and click on the Build option. There are a number of sub-options in the Build option, click on the Pipelines.
Step 5 – Run the tests in the GitLab pipeline
The below image shows that the tests are running in the GitLab pipeline.
Step 6 – Check the status of the pipeline
Once the Status of the pipeline changes to either failed or passed, that means the tests are already executed.
As you can see, the Status is passed, its green colour. This means all the tests present in the test suite are executed and passed. If any test fails in the test suite, the final execution status will be brown. The reason for the brown colour is we have mentioned allow_failure: true.
Below shows the execution status report in the GitLab pipeline.
As I have added an artifact also in the .gitalb-ci.yml, which is highlighted in the image. This artifact creates a folder with the name “Serenity_Report”and the reports in this folder come from the path /target/site. This artifact gives us the option to download the reports or browse the report. This report will be available for 24 hours only as mentioned in the gitlab-ci.yml.
Step 7 – Download the report
Once, will click on the download button, it will download “Gradle_Report.zip”. Unzip the folder and it looks like something as shown below:
Example of Index.html
Example of Serenity Summary Report
Congratulations. This tutorial has explained the steps to run Serenity tests in GitLab CI/CD. Happy Learning!!
GitLab automatically enables CI/CD pipelines for new projects. It’s just a matter of adding a new configuration file called .gitlab-ci.yml to your code repository with instructions for GitLab on what to run. So simply create the following basic workflow in your main repository directory and commit it:
By default, GitLab will have CI/CD pipelines and Auto DevOps enabled for all projects. What this means is that, when you push code to the repository, GitLab will automatically trigger the pipeline.
Step 3 – Create a .gitlab-ci.yml file in the project in GitLab
There are many ways to create a new file in GitLab. One of the ways is to create a file as shown in the below image. I have already created .gitlab-ci.yml in the project, which can be seen in the image.
It is a YAML file where you configure specific instructions for GitLab CI/CD. In the.gitlab-ci.yml, we can define:
The scripts you want to run.
Other configuration files and templates you want to include.
Dependencies and caches.
The commands you want to run in sequence and those you want to run in parallel.
The location to deploy your application to.
Whether you want to run the scripts automatically or trigger any of them manually.
Below is a sample example to run the SpringBoot project (Maven) in the GitLab pipeline.
image: maven:3.8.5-openjdk-17
stages:
- test
variables:
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
test:
stage: test
allow_failure: true
# Run the tests
script:
- echo "Executing SpringBoot scenarios with maven"
- mvn clean test site
# Store artifacts
artifacts:
when: always
name: "SpringBoot Report"
paths:
- target/site/*
expire_in: 24 h
Image – maven:3.8.5-openjdk-17 is used in this test. It is a docker image for Maven and have Java 17 installed in it.
Pipeline configuration begins with jobs. Jobs are the most fundamental element of a .gitlab-ci.yml file.
Jobs are:
Defined with constraints stating under what conditions they should be executed.
Top-level elements with an arbitrary name and must contain at least the script clause.
Not limited in how many can be defined.
Jobs can output an archive of files and directories. This output is known as a job artifact. The expire_in keyword determines how long GitLab keeps the job artifacts. Here, it shows 24 hrs to retain the artifacts.
Step 4 – View GitLab Pipeline
Now, when a new change is committed, a pipeline kicks off and it runs all the tests. To view the pipeline, go to the left panel and click on the Build option. There are a number of sub-options in the Build option, click on the Pipelines.
Step 5 – Run the tests in the GitLab pipeline
The below image shows that the tests are running in the GitLab pipeline.
Step 6 – Manually run the tests in the GitLab pipeline
Whenever there is a new change committed, the pipeline runs automatically. Imagine the scenario when we need to run the pipeline without any new change. This can be done by clicking on the button “Run pipeline”.
Step 7 – Check the status of the pipeline
Once the Status of the pipeline changes to either failed or passed, that means the tests are already executed.
As you can see, the Status is passed, its green colour. This means all the tests present in the test suite are executed and passed. If any test fails in the test suite, the final execution status will be brown. The reason for the brown colour is we have mentioned allow_failure: true.
Below shows the execution status report in the GitLab pipeline.
As I have added an artifact also in the .gitalb-ci.yml, which is highlighted in the image. This artifact creates a folder with the name “Serenity_Report”and the reports in this folder come from the path /target/site. This artifact gives us the option to download the reports or browse the report. This report will be available for 24 hours only as mentioned in the gitlab-ci.yml.
Step 8 – Download the report
Once, will click on the download button, it will download “SpringBoot_Report.zip”. Unzip the folder and it looks like something as shown below:
Example of SureFire-Report.html
Example of Project Summary Report
Congratulations. This tutorial has explained the steps to run Serenity tests in GitLab CI/CD. Happy Learning!!