by Hannah Rivera | Jul 14, 2024 | API Testing, Blog |
API testing is a critical aspect of software testing as APIs serve as the communication channels between different software components, allowing them to interact and exchange data. API testing not only involves validating the functionality, but also the performance, security, and reliability of APIs to ensure they meet the intended requirements and perform as expected. Ensuring that you’ve got complete coverage can be a challenge and that is why we have prepared this comprehensive API Testing Checklist based on our experience in delivering software testing services to our clients. Before we head to the checklist, let’s understand the criticality of API testing and the prerequisites you’ll need to follow the checks as well.
What Makes API Testing Crucial?
Although we gave you a brief overview of the API testing’s importance in the introduction, it would be better if you understand it in detail to ensure you can modify our API Testing checklist as per your varying requirements.
Functionality Validation:
API testing ensures that APIs function correctly and perform the intended operations. It verifies that the API endpoints return the expected responses, handle different scenarios, and adhere to the defined specifications and requirements.
Integration Testing:
APIs serve as the interfaces between different software components. API testing helps validate the integration of these components, ensuring smooth communication and data exchange between them. It helps identify any issues or inconsistencies in the integration process.
Performance and Scalability:
APIs often handle a significant volume of requests and need to perform efficiently and scale seamlessly. So you’ll have to assess the API’s response time, addition, and resource utilization under different payload conditions. It helps identify bottlenecks, optimize performance, and ensure scalability.
Security and Reliability:
APIs are also potential entry points for security vulnerabilities and attacks. That is why it is critical to maintain their security by identifying vulnerabilities like injection attacks, cross-site scripting (XSS), and authentication/authorization flaws. It helps ensure that APIs are secure, protect sensitive data, and follow industry best practices.
Version Compatibility:
APIs evolve in time with new versions introducing changes and improvements. So it is important to validate the compatibility between different API versions and ensures backward compatibility. It ensures that existing integrations and applications continue to function correctly when API versions are updated.
Error Handling and Exception Management:
APIs should handle errors and exceptions gracefully, returning meaningful error messages and appropriate status codes. API testing verifies that error handling mechanisms are in place and that the API responds appropriately to different error scenarios.
Pre-requisites for API Testing
Even with the API testing checklist in hand, you will not be able to perform the testing directly as there are a few prerequisites that have to be done from your end. So let’s see what those prerequisites are,
Understanding API Documentation:
Familiarize yourself with the API documentation available such as Swagger to understand the details about endpoints, parameters, expected responses, etc. This will play a crucial role in making changes to our API Testing checklist to align with your needs.
Setting Up the Test Environment:
Next up, you’ll need to ensure you have the test environment to do the tests. If a test environment isn’t available, make sure to set it up or reach out to the concerned team to get it done.
Identifying Test Data:
The next part is having test data to cover valid and invalid scenarios, edge cases, and boundary values. Establish a systematic approach for efficient test data management, encompassing the storage and organization of test data sets for reuse and maintenance.
Test Automation:
Test the APIs manually to conduct exploratory and feature testing. But to speed up the process, you can focus on implementing test automation to execute the repetitive tests and save time. You can use tools such as Postman, Rest Assured, or other tools mentioned below based on your preference.
Tools for API testing:
Since both manual and automation testing is required, choose the right API testing tools for your needs. Here’s a list of tools commonly used for API testing in both:
Manual API Testing Tools
- Postman
- Swagger UI
- cURL
- Insomnia
- SoapUI
Automation Testing Tools
- Postman (Automation)
- RestAssured in Java
- Requests In Python
- Karate DSL
- Fiddler
By addressing these prerequisites, you lay a foundation for a well-prepared environment with the right resources to execute the API testing checklist effectively.
Key Definitions
If you’ve already worked with APIs, you’ll be familiar with these terms. But if you’re just getting started, it is important that you are aware of these definitions to understand the checklist with ease.
Endpoints: It is a specified location within an API that accepts requests and returns responses.
Payload: The term “payload” denotes the information or data transmitted by the client in a request to the server, or the information provided by the server in response to a request.
Request: It is a question or a demand made by the user to a computer, asking for specific information or action.
Response: The answer or action taken by the receiving computer in response to the request.
Query parameters: They are provided at the end of the URL and are used to filter, and sort the data given by the API.
Key-value pairs: In key-value pairs, you’ll find a colon separating them, for example, “key”: “value” and the key remains static, serving as a consistent identifier.
API Testing Checklist
Now that we have seen the fundamentals, let’s head directly to the API testing checklist. We have categorized the checklist to help you understand and perform these checks with ease.
API Version
We start our API testing checklist with API version validation and it is the process of ensuring that an API behaves appropriately and consistently across different versions. APIs are frequently updated, with new versions being published to add features, repair issues, or enhance performance. However, these upgrades can occasionally introduce changes that alter the API’s behavior.
In API version validation, testers typically perform the following tasks:
- Testing forward compatibility: Check if older clients can still work with newer versions of the API. This ensures that new features added in the newer version do not break existing clients.
- Regression testing: Re-run existing test cases against the new version of the API to ensure that the core functionality remains intact and that new changes have not introduced any regressions.
Response Status code
The status code is an essential part of API responses as it indicates the success or failure of a request. Verifying the expected status code ensures that the API is functioning correctly and returning the appropriate status codes for different scenarios.
Example: If we expect a successful response, we will verify that the API returns a status code of 200 (Success). On the other hand, if we expect an error response, we would check for status codes like 400 (Bad Request) or 500 (Internal Server Error). Let’s take a deeper look at these responses in our API testing checklist now.
2xx Success Responses:
These codes confirm that the client’s request was successfully received.
- 200 OK: Signifying a successful request, the server returns the requested data.
- 201 Created: The server successfully processed the request, resulting in the creation of a new resource.
- 204 No Content: Although the request succeeded, the server does not provide any data in response.
4xx Client Error Responses:
These codes signify issues with the client’s request, such as mistyped URLs or invalid credentials. Prominent examples are:
- 400 Bad Request: The request is incorrect or invalid.
- 401 Unauthorized: The client lacks authorization to access the requested resource.
- 403 Forbidden: Although authenticated, the client lacks authorization to access the requested resource.
- 404 Not Found: The requested resource is not present on the server.
5xx Server Error Responses:
These codes reveal that the server encountered an error while attempting to fulfill the client’s request. Examples include:
- 500 Internal Server Error: A generic code indicating an unexpected condition preventing the server from fulfilling the request.
- 502 Bad Gateway error: It occurs when a gateway or proxy server receives an incorrect answer from an upstream server.
- 503 Service Unavailable: Issued when the server is temporarily unable to handle the request, often during high-traffic periods or maintenance.
Presence of JSON Elements
Next point in our API testing checklist is about JSON elements as API responses often include JSON data, which consists of key-value pairs. It is important to ensure that all the required JSON elements, or keys, are present in the response. This helps validate the response’s completeness and ensures that the expected data is returned.
Example: Suppose we expect an API response to include the following JSON elements: “name”, “age”, and “email”. We would verify that these elements are present in the response and contain the expected values.
Data Types for Response Values
API responses can contain data of different types, such as strings, numbers, booleans, or arrays. Validating the data types for response values ensures that the API returns the expected data types, which helps in maintaining data integrity and consistency.
Example: If we expect a response value to be a number, we will verify that the API returns a numeric value and not a string or any other data type.
Value Formats
Similar to the data type we saw previously in our API testing checklist, some API responses may include specific value formats, such as dates in the format MM/DD/YYYY. Validating value formats ensures that the API returns data in the expected format, which is important for compatibility and consistency with other systems or processes.
Example: If we expect a date value in the format MM/DD/YYYY, we have to verify that the API response follows this format and does not return dates in any other format such as DD/MM/YYYY or DD/MM/YY, etc.
Invalid Request Headers
When testing an API, it is important to verify how it handles invalid requests. Let’s start this part of our API testing checklist with invalid request headers by checking whether the API returns appropriate error messages when invalid or incorrect headers are provided.
Example: Suppose the API expects a valid access token in the “Authorization” header like this:
Authorization: Bearer <valid_access_token>
Now, during testing, you might intentionally introduce an invalid header, such as:
Authorization: Bearer <invalid_access_token>
Testing with this invalid header helps ensure that the API responds appropriately to unauthorized requests. The API should return a specific HTTP status code (e.g., 401 Unauthorized) and provide a clear error message, indicating that the provided access token is invalid or missing.
Invalid Request Body
Now that we have seen how invalid request headers should be managed, let’s check how invalid request bodies should be handled in our API testing checklist. When you send a request to an API, the request body often contains data in a specific format (e.g., JSON or XML). If the data in the request body is not well-formed or does not contain the mandatory fields, the API should respond with an appropriate error message.
Example: Consider an API that expects a JSON request body for creating a new user. The expected format might look like this:
{
"username": "john_doe",
"email": "[email protected]",
"password": "secure password"
}
Now, during testing, you intentionally send a request with an invalid key:
{
"username": "john_doe",
"email": "[email protected]",
"invalid_field": "securepassword"
}
In this example, the “invalid_field” is not expected in the API’s request body. The API should detect this issue and respond with an appropriate error message.
Header Parameter Limit
APIs often have certain limits or restrictions on header parameters, such as maximum character limits. To ensure that the API handles such scenarios correctly, we can test by hitting the API with more than the expected limit for a header parameter and verify the response.
Example: Suppose you have an API that expects a “Content-Length” header indicating the size of the request payload. The API may have a specified limit on the size of the payload it can accept, and exceeding this limit could lead to issues or security vulnerabilities.
The expected header might look like this:
Now, during testing, you intentionally send a request with a “Content-Length” header exceeding the expected limit:
In this case, you are testing the API’s ability to handle oversized headers. The API should detect that the request header exceeds the defined limit and respond appropriately.
Invalid Header Parameter
Similar to sending header parameters beyond the defined limited, we have also included a check in our API testing checklist to see how an API handles invalid header parameters. It is important for maintaining security and data integrity. By sending invalid header parameters, we can ensure that the API rejects or handles them appropriately.
Example: If an API expects a header parameter called “X-API-Key”, we can test by sending an invalid or non-existent header parameter, such as “X-Invalid-Header: value”, and check if the API returns an error or handles it correctly.
Invalid Authorization Header Value
Authorization headers are often used to authenticate and authorize API requests. Testing with invalid authorization header values helps in verifying that the API rejects unauthorized requests and returns appropriate error messages.
Example: If an API expects an authorization header with a valid token, we can test by sending an invalid or expired token and check if the API returns an error indicating invalid authorization.
Valid Content-type values in the Request Header
Verifying an API request with valid Content-Type values in the request header involves testing how the API correctly processes different content types. The Content-Type header informs the server about the media type of the resource being sent or requested.
Example: Suppose you have an API endpoint for creating a new resource, and it accepts data in JSON or XML format. The valid Content-Type values might include:
JSON Content-Type:
POST /api/resources
Headers:
Content-Type: application/json
Request payload:
{
"name": "New Resource",
"description": "A description of the new resource"
}
XML Content-Type:
POST /api/resources
Headers:
Content-Type: application/xml
Request payload:
<resource>
<name>New Resource</name>
<description>A description of the new resource</description>
</resource>
Without Authorization Header Parameter
Similar to checking invalid header parameters previously in our API testing checklist, it is important to test how an API handles requests without the required authorization header parameter. This helps ensure that the API enforces proper authentication and authorization.
Example: If an API requires an authorization header parameter, we can test by sending a request without the authorization header and check if the API returns an error indicating the missing authorization.
Expired Authorization Token
When dealing with authorization tokens, it is important to test how the API handles expired tokens. By sending an expired token and hitting the API endpoint, we can verify that the API rejects the request and returns an appropriate error message.
Example: Consider an API that requires an “Authorization” header with a valid and non-expired access token for authentication. A valid authorization header might look like this.
Authorization: Bearer valid_access_token
Now, during testing, you intentionally send a request with an expired access token:
Authorization: Bearer expired_access_token
In this example, the API should detect the expired authorization token and respond with an appropriate error message. The expected behavior might include an HTTP status code, such as 401 Unauthorized, and a response body with a clear error message
Pagination
As pagination is a common technique used in APIs to retrieve data in chunks or pages, we have included a check for them in our API testing checklist. When testing pagination, it is important to verify whether the API returns the expected amount of data based on the specified data count limit for pagination.
Example: Suppose we want to retrieve 10 items per page using pagination. We would hit the API with the appropriate parameters and verify that the response contains exactly 10 items.
Valid Query Path Parameters
When verifying the response for an API endpoint with all the valid query path parameters, you are essentially checking how the API processes and responds to correctly formatted query parameters. We will also check for invalid query path parameters next in our API testing checklist. Let’s consider an example now:
Example: Suppose you have an API endpoint for retrieving information about a user, and it accepts several query parameters:
Query parameters:
- userId (required): The ID of the user.
- includeDetails (optional): A boolean parameter to include additional details.
A valid API request with all the valid query path parameters might look like this:
GET /api/users?userId=123&includeDetails=true
In this example:
- userId is a required parameter, and it is set to 123.
- includeDetails is an optional parameter, and it is set to true.
- The expected response from the API should include the relevant information based on the provided parameters i.e. userId: 123.
{
"userId": 123,
"username": "john_doe",
"email": "[email protected]",
"details": {
// Additional details based on the includeDetails parameter
"age": 30,
"location": "City"
}
}
Invalid Query Path Parameter
Testing with invalid query path parameters helps in ensuring that the API handles such scenarios correctly and returns meaningful error messages.
Example: If an API endpoint expects a query path parameter called “id”, we can test by providing an invalid or non-existent value for this parameter and check if the API returns an error indicating the invalid parameter.
Special Characters in Query Path Parameter
The next check with regard to query path parameters in our API testing checklist is with special characters as it can sometimes cause issues or unexpected behavior in APIs. By testing with special characters in query path parameters, we can ensure that the API handles them correctly and returns the expected response.
Example: If an API expects a query path parameter called “name”, we can test by providing a value with special characters, such as “John&Doe”, and check if the API handles it properly.
Request Payload
Request payloads often contain data that is required for the API to process the request correctly. By verifying that all the required fields are present in the request payload, we can ensure that the API receives the necessary data.
Example: Suppose an API requires a request payload with fields like “name”, “email”, and “password”. We would verify that all these fields are present in the request payload before sending the API request.
Without a Request Payload
Similar to other checks in our API testing checklist, we should also test an API request without a request payload involves testing how the API handles scenarios where no data is provided in the request body.
Example: Suppose you have an API endpoint for creating a new user, and it requires certain fields in the request payload. But you didn’t provide any request body, the API should handle this scenario gracefully and respond appropriately. The expected response might include an HTTP status code, such as 400 Bad Request, and a response body with an error message indicating that the request payload is missing or malformed.
Without a Required Field in the Request Payload
To ensure data integrity and completeness, APIs often require certain fields in the request payload. By testing without a required field in the request payload, we can verify that the API returns the expected error message or response.
Example: If an API requires a request payload with a field called “email”, we can test by sending a request without the “email” field and check if the API returns an error indicating the missing field.
Invalid Data Types in the Request Payload
Next up in the set of request payload checks in our API testing checklist is to test with invalid data types in the request payload. APIs often have specific data type requirements for request payloads and so we have to ensure that the API handles them correctly and returns meaningful error messages even with invalid inputs.
Example: If an API expects a numeric field in the request payload, we can test by sending a string value instead and check if the API returns an error indicating the invalid data type.
Request Payload Length
Similar to other limitations seen in our API testing checklist, APIs also have limitations on the number of characters or the maximum length allowed for certain fields in the request payload. By testing with values exceeding these limits, we can ensure that the API handles them correctly and returns the expected response.
Example: If an API expects a field called “description” with a maximum limit of 100 characters, we can test by sending a value with more than 100 characters and check if the API returns an error indicating the exceeded limit.
Null Value in the Request Payload
Some APIs may allow certain fields to have null values in the request payload. By testing with null values for these fields, we can ensure that the API handles them correctly and returns the expected response.
Example: If an API expects a field called “address” in the request payload, we can test by sending a null value for this field and check if the API handles it properly.
Special Character in the Request Payload
Special characters can sometimes cause issues or unexpected behavior in APIs. By testing with special characters in fields of the request payload, we can ensure that the API handles them correctly and returns the expected response.
Example: If an API expects a field called “Contact” in the request payload, we can test by sending a value with special characters, such as “998877665$”, and check if the API handles it properly.
Valid Key-value Pair in the Query String Parameter
Next in our API testing checklist, we’re going to see a sequence of checks with the Query string parameters that are used to provide additional information to the API endpoint. By testing with valid key-value pairs in the query string parameters, we can ensure that the API correctly processes and returns the expected response based on the provided parameters.
Example: Suppose we have an API endpoint that expects query string parameters like “category” and “sort”. We can test by providing valid values for these parameters, such as “category=books” and “sort=price”, and verify that the API returns the appropriate response.
Invalid Key-value Pair in the Query String Parameter
Testing with invalid key-value pairs in the query string parameters helps ensure that the API handles such scenarios correctly and returns meaningful error messages.
Example: If an API endpoint expects a query string parameter called “page”, we can test by providing an invalid or non-existent key-value pair, such as “invalidKey=value”, and check if the API returns an error indicating the invalid parameter.
Different Data Types in the Query String Parameter
APIs may have specific data type requirements for query string parameters. By testing with different data types in the query string parameters, we can ensure that the API handles them correctly and returns meaningful error messages.
Example: If an API expects a query string parameter called “count” with a numeric data type, we can test by providing values of different data types as shown below,
"GET /api/products?count=10" (valid)
"GET /api/products?count=somestring" (invalid),
It should return the appropriate error code or message when it is an invalid parameter.
Valid Date Format Key-value pair in the Query String Parameter
The final check with the query string parameters in our API testing checklist is with the valid date format. Some APIs may require specific date formats in the query string parameters. By testing with valid date formats, we can ensure that the API correctly processes and returns the expected response based on the provided date.
Example: If an API expects a query string parameter called “date” in the format “YYYY-MM-DD”, we can test by providing a value like
"GET /api/products?date=2024-02-16"
We can ensure it returns the appropriate response message or code.
Server Request Per Second Configuration
We’re now moving towards the performance part of our API testing checklist. To test the performance and rate-limiting capabilities of an API, we can hit the API multiple times within a short period to exceed the configured request per second limit. This helps verify that the API enforces the rate limit and returns the expected response or error message.
Example: If an API has a rate limit of 10 requests per second, we can test by sending more than 10 requests within a second and check if the API returns an error indicating the exceeded limit. It could respond with an error code, such as 429 Too Many Requests, indicating that the rate limit has been exceeded.
Concurrent Rate Limit
Similar to testing the rate limit per second, we can also test the allowed concurrent rate limit of an API by sending multiple concurrent requests. This helps in verifying that the API handles concurrent requests correctly and returns the expected response or error message.
Example: If an API allows a maximum of 100 concurrent requests, we can test by sending 100 or more concurrent requests and check if the API handles them properly.
Expected Responses:
- If the concurrent rate limit is not exceeded, all requests ( more than 100) should receive successful responses.
- If the concurrent rate limit is exceeded, the API should respond in a controlled manner, possibly by returning an error response indicating that the concurrent rate limit has been surpassed.
Uploads and Downloads
If an API supports file uploads and downloads, it is important to test this functionality to ensure that the API handles the file transfer correctly. By uploading and downloading files, we can verify that the API correctly processes and returns the expected files. We will further break this point in our API testing checklist.
File Uploads
Check File Type and Size:
- Verify that the API checks the file type and size during the upload process.
- Test with various file types, including both allowed and disallowed types, and files exceeding the maximum size.
Validate File Name and Content:
- Verify that the API sanitizes and validates the file name to prevent any potential security issues.
- Check if the API validates the content of the uploaded file to ensure it matches the expected format (e.g., for image uploads).
Handle Concurrent Uploads:
- Test the API’s behavior when multiple users attempt to upload files simultaneously.
- Check if the API maintains proper concurrency control and prevents race conditions during file uploads.
Test Timeout and Large Files:
- Verify that the API gracefully handles long upload times and does not time out prematurely.
- Test the API’s behavior with very large files to ensure it can handle the load without crashing.
Authentication and Authorization:
- Make sure that file uploads are only done by authorized users.
- Verify that the API enforces proper authentication and authorization checks before processing file uploads.
File Downloads:
Check Access Controls:
- Test if the API correctly enforces access controls for file downloads. Unauthorized users should not be able to access sensitive files.
- Verify that the API checks user permissions before allowing file downloads.
Test Download Speed and Efficiency:
- Assess the download speed and efficiency by downloading various file sizes.
- Ensure that the API efficiently streams large files and does not consume excessive resources.
Secure File Transmission:
- Ensure that file downloads are conducted over secure connections (HTTPS) to prevent man-in-the-middle attacks.
- Verify that the API supports secure protocols for file transmission.
Specific Time Zone in the Request Payload
The Accept-Timezone header allows the client to specify the desired timezone for the API response. By testing with specific timezone values in the Accept-Timezone header, we can ensure that the API correctly processes and returns the response in the specified timezone.
Example: If an API supports the Accept-Timezone header, we can test by setting the header value to a specific timezone, such as “Accept-Timezone: America/New_York”, and verify that the API returns the response in the specified timezone.
Managing SSL/TLS Certificates
SSL/TLS certificates are essential for securing API communications over HTTPS and that is why we have added it to our API testing checklist. By testing the API with different SSL/TLS certificates, including valid, expired, or self-signed certificates, we can ensure that the API handles them correctly and returns the expected HTTP status codes.
Example: If an API requires a valid SSL/TLS certificate, we can test by accessing the API with a self-signed or expired certificate and verify that the API returns an appropriate error indicating the certificate issue.
Server log Information
The final point of our API testing checklist is to monitor server logs as it is crucial for debugging and troubleshooting API issues. By testing the API and checking the server logs, we can ensure that the API requests are logged correctly and provide valuable information for diagnosing any errors or unexpected behavior.
Example: After making API requests, we can access the server logs and verify that the relevant information, such as the request method, path, and response status, is logged correctly.
Conclusion
We hope our comprehensive API testing checklist will ease your API testing process to give great coverage. By following this checklist and testing each item, we can ensure that the API functions correctly, handles various scenarios, and returns the expected responses. Testing systematically and thoroughly helps in identifying and fixing any issues, ensuring the reliability and quality of the API. Remember to adapt the checklist based on the specific requirements and functionalities of the API you would like to test.
by Chris Adams | Mar 15, 2024 | API Testing, Blog |
Postman is one of the most popular API testing tools and it can perform both manual and automated API testing. So it is a great choice for beginners who are just getting started with API testing to take the first step with manual testing and gradually move towards automation testing. Moreover, Postman has recently introduced Postbot which is an AI assistant within Postman that can make your testing process easier. But in this blog, our primary focus will be on Postman API Automation Testing. Before we get started, let’s list out all the reasons that make Postman a great choice.
Why use Postman for API Automation?
Being a leading automation testing company, we have used many tools for API automation testing and have found Postman to be a great choice due to the below-listed reasons. It actually streamlines the process of API automation by providing a unified platform for designing, testing, and monitoring APIs, thus improving the efficiency and reliability of API development and maintenance.
User-Friendly Interface: Postman offers an intuitive and user-friendly interface, simplifying API work for developers and testers, without requiring extensive coding.
Testing Capabilities: Postman allows you to easily create and execute automated tests for your APIs, including functional, regression, and load testing. You can define test scripts using JavaScript, which offers flexibility and power in crafting test scenarios.
Collections: Postman allows you to organize your API requests into collections, making managing and sharing them with your team easier. Collections can be exported/imported, facilitating collaboration and version control.
Environment Variables: Postman lets you define environment variables, which can be used to parameterize your requests and make them more dynamic. This is particularly useful for testing different environments (e.g., development, staging, production) with the same set of requests.
Pre-request and Post-request Scripts: Postman enables you to run scripts before and after sending requests, allowing you to set up test conditions, manipulate data, or perform cleanup actions.
Integration with Continuous Integration (CI) Tools: Postman can be integrated with CI/CD pipelines, enabling automated testing as part of your development workflow. This ensures that API changes are thoroughly tested before deployment.
Monitoring and Reporting: Postman offers features for monitoring APIs in production, including real-time monitoring, performance testing, and generating reports on API health and performance.
Extensive Documentation: Postman provides comprehensive documentation and resources, including tutorials, examples, and community support, making it easier for users to get started and troubleshoot issues.
Postman API Automation Testing
To ensure you understand the automation testing process without any doubts, we have used a sample scenario where we use all 4 CRUD operations. We have also explained how to run a collection on the whole and generate reports as well.
Create a Collection & Requests
A collection and subsequent requests have to be created first by following the below steps before we get started with Postman API Automation Testing.
- First up, launch Postman and click on the ‘Create Collection’ button and give a name to the collection eg: API Demo.
- Now we have to add requests to the collection we created by clicking the three dots in the top right corner.
- Click on ‘Add request’, enter the name of the request, and click the Save button to create a (POST) request named “Create User”.
- Similarly, create a few more requests “Get user details”(GET), “Update user details”(PUT), and “Delete User”(DELETE).
- After creating the collection with CRUD operations, we have to add a URL and request content for each operation.
Create User
In the “Create User” request, select the POST request method and enter the URL you want to test. In our blog, we have used https://gorest.co.in/public/v2/users. An authentication token has to be added for the above-mentioned API. It can be done so by clicking on the collection name ‘API Demo’ to view the below screen.
Click on the ‘Authorization’ tab, select the type as Bearer token, and place your token value in the token field
In Body, select raw, select JSON format, and enter the following request body:
Request Body:
{
"name": "QA Test",
"gender": "Male",
"email": "[email protected]",
"status": "active"
}
Now we have to add the test scripts as shown below to verify the response results by clicking the ‘Tests’ tab.
Test Script:
pm.test("validate status code", function ()
{
pm.response.to.have.status(201);
});
pm.test("Validate response data", function()
{
var data = pm.response.json();
pm.expect(data.name).to.equal("QA Test");
pm.expect(data.email).to.equal("[email protected]");
pm.expect(data.gender).to.equal("male");
});
Once you click on the “Send” button, you will see the response body for the above-mentioned scripts. You can then validate the response with the expectations and click the “Save” button to save the request.
Get User Details
In the Get user details request, we have to construct the URL using global variables by adding BaseURL and UserID. Global variables serve as general-purpose variables and should be used sparingly, primarily for rapid prototyping needs. They are accessible to all requests within the Postman environment, regardless of the collection they belong to.
To get particular user details, we may need to pass the User ID as a variable, in Postman it is known as “Globals”.
You can create variables by selecting Environments – > Globals as shown below,
Now when we select the GET request method and URL as “{{BASE_URL}}/{{USERID}}”, the values will be fetched from global variables. As seen previously in our Postman API Automation testing blog, we have to write test scripts for response body validation in the tests tab as shown below.
Test Script:
pm.test("validate status code", function ()
{
pm.response.to.have.status(200);
});
pm.test("Validate response data", function()
{
var data = pm.response.json();
var userID = pm.globals.get("USERID")
pm.expect(data.id).to.equal(parseInt(userID)); // Parse userID to integer for comparison
});
After verifying all the details once, click on the Send button will see the response body for the above-mentioned scripts.
Update User Details
Let’s see how we can validate the details that have been updated. In our example, let’s update the username from QA Test to “QA Test001”. In the Update user details request, select the PUT request method and enter the URL as “{{BASE_URL}}/{{USERID}}”
We will update the username to, in the request body update the value, and send the request as mentioned below
Request Body:
{
"name": "QA Test 001",
"gender": "Male",
"email": "[email protected]",
"status": "active"
}
Test Script:
Write a script to validate if the updated username is reflected in the response body
pm.test("validate status code", function () {
pm.response.to.have.status(200);
});
pm.test("Validate response data", function() {
var data = pm.response.json();
pm.expect(data.name).to.equal("QA Test 001");
});
Click on the “Send” button and you will be able to see the updated response body
Delete User
So far in our Postman API automation testing tutorial, we have created the user, validated the response, got user information, and validated the response again. Now it’s time to delete the user.
In the Delete User request, select the DELETE request method, for the URL we have the BaseURl and userId already saved in our collection variables, let’s use it directly for the delete user request
Test Script:
pm.test("status code is 204", function ()
{
pm.response.to.have.status(204);
});
Please note that no response body will be displayed for delete requests. So we just have to verify the status code above and click the Send button
Collection Runner
We have seen how to run individual requests so far and will be focusing on how to execute a specific collection directly in our Postman API automation testing tutorial. Postman offers a built-in feature known as the Collection Runner within the Postman interface for this very purpose. You can click on the three dots next to your collection and select “Run Collection” to initiate the process.
Postman’s API automation testing also supports scheduling features that allow you to automate the execution of collections at specific times or intervals. Here’s a brief overview:
Setting Up a Schedule: You can create a schedule by navigating to the collection runner, selecting the collection you want to schedule, and then clicking on the “Schedule Runs” button. From there, you can configure the schedule according to your requirements.
Configuring Schedule Parameters: Postman allows you to specify parameters such as the frequency of runs (e.g., daily, hourly), start date and time, and time zone. You can also choose to run the entire collection or select specific folders or requests within the collection.
Monitoring Scheduled Runs: Once a schedule is set up, you can monitor the status of scheduled runs from the Postman dashboard. You’ll be able to see information such as the last run time, the next scheduled run time, and any run failures or errors.
You can also run it manually by clicking on the ‘Run Manually’ option
Once the tests have been executed for the collection, you will be able to see the results as shown below.
Newman CLI Reporting
As we have seen how to perform all the required tests, let’s see how we can create effective reports in Postman using Newman. Newman is a CLI tool that enables running collections directly from the command line interface. It can be achieved if it’s integrated into a CI/CD pipeline remotely or executed locally on your CLI. You can download Newman from NPM.
After installation, you’ll have to export both your collection and global variables. Let’s see how to do that in our Postman API Automation testing tutorial.
Navigate to the directory where the collection is exported in your CLI and execute the below command
newman run collection name.json --globals global variable name.json --env-var "token=YOUR_BEARER_TOKEN"
Once you execute the above command, you will be able to see a report as shown below.
Newman HTML Reporting
If you would like to generate HTML reports, we’ve got that covered as well in our Postman API Automation testing tutorial. First, you’ll have to complete all the prerequisites listed below.
Pre-Requisites:
All you have to do is add the ‘-r’ flag followed by ‘htmlextra’ in the CLI command when executing a collection in Postman. Upon completion of the test run, an HTML file will be automatically generated within the Newman folder in the corresponding directory.
CLI Command:
newman run collection name.json --globals global variable name.json --env-var "token=YOUR_BEARER_TOKEN" -r cli,htmlextra
Benefits of API Automation Testing
Automating API tests offers numerous advantages beyond manual testing, enhancing developer workflows and facilitating rapid iteration. So the benefits we’ve discussed are not specific to Postman API automation testing as they apply to API automation on the whole.
Integration with UI Testing:
Combining UI testing with API automation addresses the frontend-backend interplay common in modern applications. This integration ensures comprehensive testing coverage, validating both the frontend and backend operations seamlessly.
Handling Data Complexity:
APIs interact with diverse data types, and API automation excels in managing this complexity effortlessly. Automated testing tools adeptly navigate through different data structures, meticulously validating inputs and outputs, irrespective of the format—be it JSON, XML, or others.
Early Issue Detection:
API automation facilitates rapid identification of problems and issues early in the development lifecycle. By automating API endpoint testing, developers streamline the debugging process, saving significant time by detecting issues before they escalate.
Integration with CI/CD Pipelines:
API automation seamlessly integrates into CI/CD pipelines, ensuring thorough testing of each code change before deployment. Automating the CI/CD process accelerates development cycles, promotes continuous delivery, and enhances the overall software release procedure.
Data-Driven Testing:
API automation enables teams to conduct data-driven testing effectively. By adjusting inputs and evaluating associated outputs, testing scenarios can be varied, ensuring consistent API performance across various circumstances.
Simulation of Realistic Scenarios:
API automation facilitates the realistic simulation of scenarios encountered in live environments. This provides valuable insights into API behavior under different loads and situations, encompassing scalability, performance, and stress testing.
Best Practices of API Test Automation
In order to achieve all the said benefits, you’ll have to follow the best practices when implementing Postman API automation testing.
Early and Continuous Testing: Initiate API testing in the development lifecycle’s early stages and sustain it throughout, facilitating prompt issue detection and mitigation, thus reducing development costs.
Diverse Test Case Design: Craft test cases encompassing a variety of input combinations to thoroughly assess API functionality, including valid and invalid inputs, edge cases, and boundary conditions.
Assertion-Based Response Verification: Employ assertions to validate API responses against expected outcomes, scrutinizing aspects such as response codes, timing, data integrity, and other critical parameters.
Effective Test Data Management: Efficiently manage test data by leveraging techniques like data-driven testing, parameterization, and data generation, ensuring comprehensive test coverage and minimizing reliance on manual data setup.
Robust Security Testing: Given the susceptibility of APIs to security breaches, prioritize security testing to evaluate authentication, authorization, encryption, input validation, and defenses against common vulnerabilities.
Performance and Scalability Monitoring: Conduct load and stress testing to assess API performance under anticipated high traffic and concurrent requests, monitoring metrics like response times, throughput, and resource utilization to identify and address performance bottlenecks.
Conclusion:
Now that we have reached the end of our tutorial, we hope you have a clear understanding of how to achieve Postman API Automation Testing. To sum it all up, Postman is a great choice as it requires minimum code to perform automation testing, supports scheduled test executions, and Newman integration for seamless reporting. We as a software testing company have found great value in using Postman and hope you will be able to as well.
by Mollie Brown | Jan 25, 2023 | API Testing, Blog |
To be a complete tester, it is very important for you to know how to perform Automated API testing. It enables you to test the business logic of an application early on even before the UI is ready. There are many aspects to API testing, but it generally involves making requests to one or more API endpoints and validating the response for various reasons. And Rest Assured is a great option for API Test Automation as it offers a lot of methods that can be used to fetch data from almost every part of the request or response for our testing. So in this Rest Assured Tutorial, we will be focusing on how to easily achieve API Test Automation using Rest Assured. We have also included a sample program to make it easier for you to understand the core concepts.
What is Rest Assured?
Rest-Assured is a Java-based library for testing RESTful Web Services. Accessing REST web services can be made easier by using this library, which behaves like a headless client.
As stated earlier, it is possible to create highly customizable HTTP requests to send to a Restful server. So you can use Rest Assured to send a wide range of request combinations to test the different combinations of the core business logic.
You can also use Rest Assured to validate HTTP responses received from the server. For example, we can verify the Status code, Status message, Headers, and Body of the response.
How to Perform API Test Automation using Rest Assured?
Create a Maven Project
The first of the two prerequisite steps to start API Test automation with Rest assured would be to create a Maven project by following the specified steps
File->New-> Project -> Maven Archetype -> Project_Name -> Create
Add the Rest Assured dependency to your POM file
Now that you have created your Maven project, you must add the below-specified dependency to your POM.xml file.
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>4.4.0</version>
<scope>test</scope>
</dependency>
Make a detailed HTTP request
The next step in performing API test automation using Rest Assured is to create a detailed HTTP request URI that contains the unique address of the request.
Components of an HTTP Request
URI:
The URI is composed of the Base, Resource, Query, and Path.
Header:
An HTTP header is a meta-data attached to a request or response. So it is additional information sent with a request or response between a client and a server to serve a particular purpose such as authentication, caching, or sending messages.
Body:
Users send information to the server via the body which can be in the Payload, String, or File format.
Commands:
With the REST interface, the four basic operations are crucial to achieve API Test Automation using Rest Assured. The 4 basic operations Create, Read, Update, and Delete (CRUD) are performed via the POST, GET, and PUT methods.
GET: To retrieve or read the server’s data.
POST: It is used to add a resource to the server.
PUT: To update an existing record completely.
PATCH: If only a partial update has to be made to an existing record.
DELETE: Deletes a resource from a server.
Send the request over the network
You will be able to send the payload to the request body using a String or a JSON object. You can also send the JSON file as the payload to the request body.
Verifying the received Response
Based on the response code you receive, you will be able to identify the status of the request. There are several status codes that you’ll have to know, but we have listed the most important ones below.
200 – When the request is a success
201 – Request succeeded and has created the resource
400 – Server couldn’t process the request due to a client error
429 – When someone has sent too many requests
404 – When the requested page is not available
Example Program:
In this example for API Test Automation using Rest Assured, we will be adding an employee’s details to the server and verifying if the data was updated correctly.
package cap.utilities;
import com.fasterxml.jackson.core.JsonProcessingException;
import io.restassured.RestAssured;
import io.restassured.response.Response;
import io.restassured.specification.RequestSpecification;
import org.json.JSONObject;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
public class APIUtil {
private static Map<String, Set<?>> dataMapForTestCaseDetails = new HashMap<>();
public static void main(String[] args) throws JsonProcessingException {
try {
RestAssured.baseURI = "https://reqres.in/";
String strURITokenForPost = "api/users";
RequestSpecification request = RestAssured.given();
JSONObject requestParams = new JSONObject();// JSON Object Creation
requestParams.put("name", "John"); // Adding the information as key-value pair in the JSON
requestParams.put("job", "tester");
request.body(requestParams);
request.header("Content-Type", "application/json");
Response response = request.post(strURITokenForPost); // here we are hitting the uri
System.out.println("\n Status Code: " + response.getStatusCode()); // Response status code is printed here
System.out.println("---> Response JSON Body: " + response.getBody().asString());
} catch (
Exception ex) {
System.out.println("WARNING: " + ex.getMessage() + " In API Util class file.");
}
}
}
Output
Code Explanation:
To make it even easier, we have explained the important parts of the sample code we have mentioned to perform API Test Automation using Rest Assured.
- Though we can add other details such as authentication, caching, and so on, we have mentioned only the content type in the header part.
- We have mentioned our base URI, base path, and given() to get the reference of the request specification
- We have created a JSON object and added the information (Name & Job) in the key-value pair and passed it into the body.
- Next, the request is hit with a post command which is used to add information to the server.
- Finally, we got the status code as 201 as the script passed. If the script had failed, it would have thrown an exception.
Conclusion
We hope you are now clear on how to perform API Test Automation using Rest Assured. Being a leading API Testing Services company, we have used various other tools such as SoapUI, Postman, and so on. We have also written numerous in-depth blogs about API testing as well. So make sure to go through our entire collection and subscribe to our newsletter to not miss out on any of our latest blogs.
by Charlotte Johnson | Dec 7, 2022 | API Testing, Blog |
API testing is an integral part of the complete testing process as it will help you identify bugs and issues at different layers of your application. So choosing the right API testing tool is crucial as it can help you reduce testing time and increase testing efficiency. Being an experienced API testing company, we have used a wide range of API testing tools. Though Rest Assured is a Java library and not a standalone tool, it is one of the widely used tools for API testing along with Postman. So in this blog, we will be comparing Postman vs Rest Assured as they are widely used by many in the testing community. There is no one size fits all solution when it comes to choosing the right testing tools. With that being said, let’s find out which tool will suit you the best.
Postman
Many might have a misconception that Postman is used only to perform manual API testing. But Postman does have automation testing capabilities as well. According to recent reports, Postman has crossed the incredible milestone of having more than 20 Million registered users. This is an incredible feat considering that Postman initially launched in 2012 as a Google Chrome extension.
Rest Assured
Rest Assured is a Java-based library that can be used to perform automation testing on REST APIs and services. The libraries based on the Rest Assured library can also validate the server’s HTTP responses. Though Rest Assured isn’t as popular as Postman, it is still a great API testing library.
Now that we have been introduced to both options, let’s take a closer look at the difference between the two in our Postman vs Rest Assured section.
Postman vs Rest Assured: Key Highlights
| Features | Postman | Rest Assured |
| Types | Best suited for exploratory, manual, and automation Testing. | A Java library for performing Automated API Testing. |
| Pricing | A limited open-source version & an advanced Propeitory version. | Open-source |
| Scripting Language | Supports only JavaScript. | It has support for Java, . Net, Python, Ruby, etc |
| API Response Time | It is faster in comparison. | It is slower in comparison. |
| Code Reusability | Requests have to be copied from one collection to another manually. | Can be done with ease as it is a Java client. |
| Integration | Less scope for integration | More scope for integration |
| Customized Reports | Does Not allow us to customize Reports | We can customize reports for rest assured. |
| Parallel Execution | Harder to Achieve | Easier to Achieve |
| Designing a Data-Driven framework | Limited with only one data file for each collection | No Limitations at all |
Postman vs Rest Assured: In-Depth
Now that we have seen the key differences, let’s taker a deeper dive into the critical aspects you’ll have to consider.
Though Postman does offer a free version that can be used, there are a lot of limitations that come along with it. But in contrast, Rest Assured is a completely free open-source option with all the features you’ll need to perform effective API Testing. So if you are looking for an open-source option and will be scaling your test suite with time, you can skip the Postman vs Rest Assured comparison and go straight ahead with Rest Assured. But if cost alone isn’t the only deciding factor, you can consider the below points as well.
Code Reusability
As Rest Assured is using Java client, we can easily make reuse the methods depending on our testing needs instead of writing new methods every time. Whereas, Postman doesn’t provide the option of reusing pre-written scripts. So if you are choosing between Postman and Rest Assured for a large project or will be scaling your testing in the future, Rest Assured would be the right choice.
Ease of Use
As mentioned earlier in our Postman vs Rest Assured blog, Postman is the actual tool, and Rest assured is a Java library. So Postman has a great user interface that you can access easily by logging through a browser; making it very simple and easy to use. You also wouldn’t need to know how to work with an IDE to get things done.
Though Rest Assured uses Given/When/Then test annotations to simplify your tests and make them easy to understand even for non-technical people, the lack of a GUI does make Postman more user-friendly.
End-to-End Testing
Let’s take an example where you have to test if the data received from the web has been processed by the API and stored in the database as expected. In such end-to-end testing scenarios, opting to use Rest Assured would be the better way to go. You can add other third-party applications such as Jenkins with Rest Assured for CI/CD Integration as it is a framework. So with the help of dependencies, we can easily cover that part. Whereas Postman has less support for such integration.
But if you’re primarily looking to debug or perform manual exploratory testing, Postman is still a great option thanks to its great UI. Though automation is possible with Postman, the scale at which it can be done is a major factor to consider in this Postman vs Rest Assured comparison.
General Tips for Making the Right Choice
According to us, the major differences when comparing Postman vs Rest Assured arise from the fact that one is a tool and the other is a framework. If you are still unable to pick the right choice, here are a few tips that can help you arrive at the right decision.
- Analyze your requirements thoroughly and list them all.
- Define the dealbreaker aspects before analyzing other attributes.
- Sort your requirements based on priority.
- See which tool satisfies most of your needs, by using the above-discussed points.
Conclusion:
As in the case of most tool comparisons, the answer is not an easy this or that solution due to the numerous factors involved while choosing the right API testing tool. We hope our Postman vs Rest Assured comparisons have helped you understand the pros and cons of both these tools. In our years of delivering API testing services to different clients across the globe, we have used both Postman and Rest Assured based on the needs of the project. We recommend you do the same when it comes to choosing between Postman and Rest Assured. For more such insightful content, make sure to subscribe to our newsletter to not miss out on any of our latest updates.
by Mollie Brown | Jun 30, 2022 | API Testing, Blog |
API testing has become increasingly important as cloud apps and interconnectivity platforms have grown in popularity. In fact, many of the services we use on a daily basis rely on hundreds of interlinked APIs. So even if any one of the APIs fails, the service will cease to function. That is why it is extremely important to perform API testing without fail. If you are looking to learn what API testing is and how to do it, you’re at the right place. We will also be covering the different types of bugs and challenges of API testing in this API testing tutorial. But before that, let’s brush up on the basics by seeing what an API is and what it does.
What is an API?
API (Application Programming Interface) is a computing interface that allows two different software systems to communicate with each other and share data. Let’s take a look at a real-time example to better understand the functionality of an API. Let’s assume that you are in a restaurant and that you have decided what to order from their menu. Though you have made a choice, the food will reach you only if your order is received in the kitchen and that is made possible with the help of a waiter who takes your order. So in this scenario, your order is the request, the kitchen is the server, and the waiter is the API.
As shown in the figure, a Web API can also be defined as “a communication interface between a client computer and a webserver.”
Web Services vs Web API:
If you are aware of what Web Services are, you might feel that both Web Services and Web APIs serve the same purpose. Though Web Services (like Web API) are services that allow one computer to communicate with another. However, the main distinction between API and Web Services is that Web Services make use of a network. So let’s take a look at the key differences between the two
| S. No | Web Services | Web API |
| 1 | Web Services Are Software Components That Convey Specific Data/Information, Send Or Post Data, Or Update Data Using Web Protocols Such As HTTP And XML | APIs Are A Piece Of Software That Lets Two Separate Apps Or Machines Communicate With Each Other Without The Need For Human Intervention. |
| 2 | A Web Service Is A Type Of Network Communication Between Two Machines. Eg. Netflix | A Web API Is An Interface Between Two Independent Applications. |
| 3 | Web Services Are Generally Developed In XML (Extensible Markup Language), Which Increases Their Security. | Web APIs Frequently Employ JSON (JavaScript Object Notation), Which Makes Them Easier To Use. |
| 4 | Web Services Require A Network To Function. | The Functioning Of A Web API Does Not Always Require A Network. |
| 5 | Web Service Is A Subset Of Web API. For Example, Web Services Are Based Only On Three Utilizations: SOAP, REST, And XML-RPC. | Web APIs Are The More Advanced Version Or Superset Of Web Services. For Example, The Web API Supports All Three Kinds Of Web Services, But It Also Supports Alternative Styles Such As JSON – RPC. |
| 6 | In Most Cases, It Communicates Through The HTTP Protocol. It Also Communicates Through SOAP, REST, And XML-RPC. | It Uses Any Communication Protocol Such As HTTP/HTTPS To Start The Interaction Between The Applications. |
| 7 | It Doesn’t Have A Comprehensive Set Of Requirements, And It Can’t Always Do All Of The Functions That A WEB API Can. | An API Is A Collection Of Rules And Criteria That Are Followed To Make Interaction Easier. |
What is API Testing?
Given the purpose, API testing can be termed as the process of evaluating a set of application programming interfaces (APIs) individually or as part of an integration test to see if they meet the expected functionality, reliability, performance, and security requirements.
What makes it different from other types of testing?
- API testing is different from the regular type of testing as it is a black-box type of testing that doesn’t have a Graphical User Interface (GUI).
- As there is no GUI, you will not employ the conventional input and output mechanisms such as keyboard, mouse, monitor, and so on for your API testing.
- API testing would require you to use software to make the API calls, receive the output, and record the feedback as well.
- Since there is no GUI, there is no focus on the look and feel of the app. Rather, it only focuses on the business logic layer of the software’s architecture.
How to do API Testing?
Now that we have seen how API testing differs from the other types of testing, let’s explore the different stages of API testing in this API testing tutorial.
Understanding API Requirements:
Understanding the requirements is the number one step in all types of testing. And when it comes to API testing, it would be helpful if the testers understand the application’s workflow and how it is expected to perform. This step helps the tester define the verification approach as API testing is all about the responses from the database.
Checking the output status:
There is a response code or the response status code in API testing for checking the output status. It enables the tester to know if a test case has passed or failed with ease. So here’s the list of the different types of response codes and their meanings.
- 1xx (Informative): The request has been received and is being handled.
- 2xx (Successful): The request was received, comprehended, and accepted successfully.
- 3xx (Redirection): More action is required to complete the request.
- 4xx (Client Error): The request has incorrect syntax or is unable to be fulfilled.
- 5xx (Server Error): A seemingly valid request is not fulfilled by the server.
Organizing the API:
A testing project could contain dozens, if not hundreds, of APIs to be tested. For better test management, testers are strongly advised to classify them into categories. It is also critical to organize and size an API’s data, feedback, and goals in order to deliver an API that is easy to use and does not overload consumers.
Test Cases for API Testing
Positive test cases:
- Check whether the API takes the provided inputs and provides the desired output as defined in the requirement.
- Check the answer status code in the output status as mentioned in the previous part of this API testing tutorial.
- Provide an input by filling just the bare minimum of the required fields and by also filling all the fields.
Negative test cases:
- When the expected output does not exist, make sure the API responds appropriately.
- Conduct an input validation test.
- Use different levels of authorization to test the API’s behavior.
Automating the tool:
Using automation as much as feasible and as early as possible in the API testing process is very crucial as it can save a lot of time. It also makes it possible to save the test execution history. Since API testing is considered black-box testing, automation should be used extensively in order to maximize test coverage. It should also be conducted at an early stage of the SDLC.
API Testing Tools:
When running an API test, developers may either design their own framework or utilize one of several ready-to-use API testing solutions. API testing tools provide user-friendly interfaces with low coding requirements, making it possible for less-experienced engineers to deploy tests. So next up in our API testing tutorial, we’re going to take a look at the most useful API testing tools. Being a pioneer API testing Service provider, we always prefer to use open-source tools and have suggested the same here too.
SoapUI:
SoapUI is one of the world’s most popular API testing tools that is designed to verify API functioning in both SOAP & REST APIs and web services as well. It is a great choice if you’re looking for an easy-to-use and fast tool to build & run automated functional, regression, and load tests.
Apache JMeter:
The Apache JMeter is a great open-source option that can be used to perform load testing for your API and see how well it performs at different load conditions. Though it was initially developed with the focus of testing web applications, its scope of usage has now widened.
Apigee:
Apigee is an API development and management platform that can be used as an API performance testing tool as well. It has an intuitive UI that works well for both technical and non-technical users. But what makes Apigee great is that it provides security, rate limiting, analytics, and so on by fronting the backend service with a proxy layer.
REST Assured:
As the name suggests, REST Assured is an API Testing tool that can be employed to test REST APIs. Like Apache, REST Assured is also a Java-specific tool and its biggest advantage is that it supports Behavior-Driven Development (BDD) syntaxes.
Swagger UI:
Swagger UI is also an open-source program that allows users to see and interact with the API’s resources without requiring any implementation logic. It simplifies the testing process by generating a web page that lists the APIs that have been used.
Postman:
It is an end-to-end solution that enables users to perform API testing , verification, and automation. You can quickly explore, debug, & test your APIs and even design complicated API requests in HTTP, REST, SOAP, GraphQL, & WebSockets.
Katalon:
Katalon is a great choice if you are looking to improve your test coverage. It is also highly dependable as it follows the Data-Driven test approach. Despite being an open-source tool, it can be used in projects of all sizes all thanks to its productivity-focused features and user-friendly UI.
Types of Bugs in API Testing
It goes without saying that any type of testing would reveal the numerous bugs in a product. So we are now going to see the most commonly found bugs in our API testing tutorial to help you get an idea of what to expect when performing those steps.
- Fails to effectively handle the incorrect conditions.
- Overlooking the flags that have never been used before.
- Duplicated or missing functionality.
- It faces issues with Reliability Connecting to API and receiving a response is difficult.
- Security Concerns
- Bugs that arise due to multithreading.
- Performance issues such as API response time.
- Incorrect errors/warnings being sent out.
- Inability to handle valid argument values.
- The data in the response isn’t organised properly (JSON or XML).
Challenges of API Testing
Like every other type of software testing, API testing also has its own share of challenges.
1. When it comes to Web API testing, the 3 most common issues are parameter combinations, parameter selection, and call sequencing.
2. Since it is a black-box type of testing, the lack of a GUI makes it impossible to provide input values during the testing process.
3. API testing is also a little difficult for testers to validate and verify the results in a separate system.
4. The necessity to test the exception handling function is also a challenge.
Conclusion:
Since the business logic layer is represented by a set of classes, functions, and methods in an API, it goes without saying that API testing plays a very crucial part in ensuring a product’s success. And you will need to use the correct testing methodology and tools to ensure the best results. We hope this API testing tutorial has provided you with a systematic approach and a lot of useful insights about API testing as well. Being a top Quality assurance company, we will be posting more insightful content in the future and highly recommend you to subscribe to our newsletter to make the most of it.
by admin | Oct 27, 2021 | API Testing, Blog, Latest Post |
Postman is one of the most popular software testing tools which is used for API testing. Postman is widely used by both software testers and developers for testing as it is easy to integrate with Continuous Integration (CI) & Continuous Development Pipelines. Postman sends an API request to the webserver and receives the response. As one of the leading QA companies, we have been doing our manual Rest API testing using Postman whenever it was deemed necessary. So if you are someone who is looking for a complete guide that explains everything from what is REST API to how it works to how it can be manually tested using Postman, you will definitely find this blog useful.
API (Application Programming Interface)
An API is a set of defined rules that enables computers or applications to communicate with one another. APIs sit between an application and the webserver and acts as an intermediary that processes data transfer between systems.
What is REST API?
- REST API (Representational State Transfer Application Program Interface) is an architectural style that allows the software to communicate with other software on the same device or over a network.
- REST APIs communicate via HTTP requests to perform standard database functions like creating, reading, updating, and even deleting records (also known as CRUD) within a resource.
Why REST API?
These are the major reasons as to why we choose REST API over the other options. REST API is
1. Easy to Learn & Implement
2. Easy to Build & Maintain
3. Scalable
4. Cacheable
5. Flexible and Portable
How does REST APIs work?
As stated earlier, REST APIs use HTTP requests for their communication. HTTP works as a request-response protocol between a client and server and enables client-to-server communication. For example, your web browser can be considered as the client, and the application on the computer that hosts the website can be termed as the server. So if your browser (client) submits an HTTP request to the server, the server will return a response that contains the status information of the request and the requested content if any were requested.
Common HTTP methods (CRUD commands) used in REST API:
Most of these commands have very straightforward names that make them self-explanatory. So once you have been introduced to them, it will be very easy for you to remember.
- GET – The GET method can be used to extract information from the given server using a given URI. It is worth noting that when you use the GET request, it should only extract the data and not have any other effect on the data. So no Payload/Body is required.
- POST – As the name suggests, a POST request is used to send data to the server. Data like customer information, files, and so on can be sent using HTML forms.
- PUT – Using PUT, you will be able to replace all the current representations of the target resource with the uploaded content.
- DELETE – It can be used to remove all the current representations of the target resource given by a URI.
There are other CRUD commands like patch, copy, and so on as well. So once you are thorough with these basics, you can explore them.
API Contract
We have seen the basics of REST API that you will need to know. There are also a few basics of Postman that you should be familiar with. But before we can move forward, we have to explore a few aspects of the API contract as you’d have to know the following information to perform manual REST API testing using Postman.
Endpoint:
It is the address where the API is hosted on the Server. An End Point Request URL can be constructed as below
Base URL/resource/(Query/Path)Parameters
Resources:
They represent the API/Collection that can be accessed from the Server. We have listed a few common examples below to help you understand better.
- Google.com/maps
- google.com/search
- google.com/images
Here maps, search and images are the resources of Google.com which is the Base URL.
Path Parameters:
Path parameters are the variable parts of a URL path. They are generally used to point to a specific resource within a collection in the same way how a user is identified by ID.
Example for Path Parameters:
- https://www.google.com/Images/1123343
- https://www.google.com/docs/1123343
- https://amazon.com/orders/112
Here 1123343, and 112 are the parameters
Query Parameters:
Query Parameters are primarily used to sort or filter the resources. They can be identified with ”?” (A Question Mark). You’ll be able to identify them once you see a few examples.
- https://amazon.com/orders?sort_by=07/09/2021
- https://www.google.com/search?q=newyork&oq=newyork&aqs=chrome..69i57j0l7.2501j0j7&sourceid=chrome&ie=UTF-8
Here orders and search are your resources and they are sorted and filtered by the query parameter that is followed by the “?”.
Headers/Cookies:
Headers represent the meta-data associated with the API request and its response. In layman’s terms, it will be used to send additional details to the API for processing our request. An example of it would be the authorization details.
Sample API Contract for Basic CRUD commands:
Apart from these values, we would also have to know about the HTTP method in use, the body, content types of the parameter and response (either Application or JSON), and also the response value. You will get a clear idea of these aspects when we see a few examples.
1. Request to Log in – Successful
Parameters
Base URL: https://reqres.in
Request : /api/login
Request Type: POST
Body :
Parameter Content Type: application/json
Responses:
Response Content Type: application/json
Response Code : 200
Description : OK
Response Value :
{
"token": "QpwL5tke4Pnpja7X4"
}
2. Request to Get a List of Users
Parameters
Base URL: https://reqres.in
Request: /api/users
Request Type: GET
Responses:
Response Content Type: application/json
Response Code : 200
Description : OK
Response Value :
{
"page": 1,
"per_page": 6,
"total": 12,
"total_pages": 2,
"data": [
{
"id": 1,
"email": "[email protected]",
"first_name": "George",
"last_name": "Bluth",
"avatar": "https://reqres.in/img/faces/1-image.jpg"
},
{
"id": 2,
"email": "[email protected]",
"first_name": "Janet",
"last_name": "Weaver",
"avatar": "https://reqres.in/img/faces/2-image.jpg"
},
{
"id": 3,
"email": "[email protected]",
"first_name": "Emma",
"last_name": "Wong",
"avatar": "https://reqres.in/img/faces/3-image.jpg"
},
{
"id": 4,
"email": "[email protected]",
"first_name": "Eve",
"last_name": "Holt",
"avatar": "https://reqres.in/img/faces/4-image.jpg"
},
{
"id": 5,
"email": "[email protected]",
"first_name": "Charles",
"last_name": "Morris",
"avatar": "https://reqres.in/img/faces/5-image.jpg"
},
{
"id": 6,
"email": "[email protected]",
"first_name": "Tracey",
"last_name": "Ramos",
"avatar": "https://reqres.in/img/faces/6-image.jpg"
}
],
"support": {
"url": "https://reqres.in/#support-heading",
"text": "To keep ReqRes free, contributions towards server costs are appreciated!"
}
}
3. Request to update user Information
Parameters
Base URL: https://reqres.in
Request : /api/users/{{User_ID}}
User_ID=2
Request Type: PUT
Body :
{
"name": "morpheus",
"job": "zion resident"
}
Parameter Content Type: application/json
Responses:
Response Content Type: application/json
Response Code : 200
Description : OK
Response Value :
{
"name": "morpheus",
"job": "zion resident",
"updatedAt": "2021-10-05T19:20:33.979Z"
}
4. Request to Get a List of Users
Parameters
Base URL: https://reqres.in
Request : /api/users/{{User_ID}}
User_ID=2
Request Type: DELETE
Responses:
Response Content Type: application/json
Response Code : 204
Description : OK
Response Value :[]
Now that we have fully covered all the prerequisites when it comes to REST API, let’s see why we use test REST APIs and explore a few other prerequisites that will be required to perform Rest API testing using Postman.
Why Postman tool?
Postman is a simple GUI for sending HTTP requests and viewing its responses. It is built upon an extensive set of power tools, which are incredibly easy to use. Postman helps you perform a variety of functions and has a lot of useful functionalities as well.
- Since Postman is accessible from anywhere, you have to just install it into the device and access it by logging into the account.
- Your test suites will be more organized as Postman allows users to build collections for their API calls. Every set can create multiple requests and subfolders.
- Using Postman, you’ll be able to test checkpoints with the verification of the successful HTTP response status that will be added to every API call.
- Automation Testing becomes easier as several iterations of the tests can be performed by using the Collection Runner or Newman. So you can save a lot of time when performing repetitive tests.
- As Postman makes it easy to create environments, you can design multiple environments and reduce the replication of tests as you’ll be able to use the same collection for a different setting.
- The postman console helps to track what data is being retrieved makes it possible to effectively debug the tests.
- The scope for collaboration is also high as you can import or export your collections & environments and share those files. You can also use a direct connection to share the collections.
- Postman supports continuous integration as well.
- You can use Postman by either downloading & installing their application or use their web version. It is a good option to have as both offer great performance.
How to create API requests in Postman
Learning how to create API requests is an integral part of learning how to perform manual REST API Testing using Postman. You will need to know more about the following 2 features to create an API request.
Workspace in Postman:
Postman Workspaces acts as a common working area where you can group your API projects together and use API builder to define APIs or generate API elements. So they are helpful in organizing your API work better and collaborating with your teammates as well. Now let’s see how to create one.
Creating a Workspace in Postman:
Click on the Workspace dropdown in the header -> New Workspace -> WorkSpaceName (Type any workspace name you wish) -> Create Workspace.
Collections in Postman:
- Postman Collections are Executable API Descriptions Postman’s collection folders make it easy to keep your API requests and elements organized.
- Generate Collections from API schemas Generate a collection from an API schema to view and edit each request.
Creating Collections in Postman:
Click on File -> New -> Collection -> CollectionName (Assign a Collection Name as you wish)
OR
Click Collection -> Create Collection Icon (+) -> CollectionName (Enter a Collection Name of your wish)
For testing the CRUD commands, we are going to use the information which is present in the above mention API contract.
Testing POST Request to Log in – Successful:
To make a POST request, click on the More option icon (…) -> Add Request -> Login User
1. From the Dropdown select POST
2. In the “Enter request URL” text box, type the following (URL): https://reqres.in/api/login
3. Click on Body Tab, select the ‘Raw’ radio button, and then the JSON format from the dropdown list.
4. In the text box, paste the Login Credentials:
5. Click on the Send button
6. You should be able to see the below response:
7. Also, make sure to check for the correct status code here. In this case, you should get: ‘Status: 200’ as shown in the image below.
Testing GET Request to Get the List of Users:
To make a GET request, you have to click on the More options icon (…) -> Add Request -> Request to Get List of Users (Assign any requested name you wish)
1. From the Dropdown list, select GET
2. Type the mentioned URL (https://reqres.in/api/users) in the “Enter request URL” text box.
3. Click on the Send button.
4. You’ll be able to see the below response:
5. Once again, check for the status code and see if it is ‘Status: 200’.
Testing PUT Request to update user Information:
Same as above, you have to click on the More option Icon(…) ->Add Request -> Request to Update user Information (Enter any request name of your choice)
1. Click on ‘PUT’ from the dropdown list.
2. In the “Enter request URL” text box that appears, type this URL: https://reqres.in/api/users/2
3. Click on the ‘Body’ Tab, select the ‘Raw’ radio button, and then choose the JSON format from the dropdown.
4. Paste the Login Credentials in the text box:
{
"name": "morpheus",
"job": "zion resident"
}
5. Click on the ‘Send’ button
6. You will see the below response:
7. Check if the status is shown as ‘200 OK’.
Testing DELETE Request to Remove Users from Database
Click on the More option Icon (…) -> Add Request -> Request to Get the list of Users (Enter any request name you wish)
1. From the Dropdown list of options, select ‘DELETE’.
2. Type this URL https://reqres.in/api/users in the “Enter request URL” text box.
3. Click on the ‘Send’ button
4. Check is you see the below response:
5. Check if ‘Status: 200 OK’ is visible as shown in the image below.
Conclusion:
It is evident that the steps we saw for each request were almost identical to each other. So by now, you should have no trouble in performing Rest API testing using Postman in an effective way to ensure high quality. As a leading manual testing services provider, we have often used Postman for our manual testing projects. But Postman can also be used for automation testing with the help of Test scripts.
