Introduction Of API Testing
API Testing:
The API test is performed to check if the output from the first application/database is correct and well-structured and useful for another application. An API (application programming interface) is a set of procedures and functions that allow interaction between two components of a software application. API exams are the most challenging aspect of the QA exam because APIs are complex. This test contains protocols and standards that do not involve other types of testing.
Each URL is called a request, and the data sent back to you is called a response.
Here are some common reasons why you should test your APIs:
1. Ensuring that the API does what it is supposed to do.
2. Ensuring that the API can handle the load.
3. It helps to identify ways in which consumers can confuse things.
4. To ensure that APIs work on devices, browsers, and operating systems.
5. There may be costs due to system failure with API testing.
What are the types of API testing?
In this test, the following types of tests are performed:
Unit Testing: To test the functionality of an individual operation.
Functionality testing: To test the functionality of multiple unit tests when tested together.
Load testing: To test functionality and performance under load conditions.
Error detection: To detect errors such as exceptions and resource leaks.
Security Test: To test that the API is secure from any external threats.
UI testing: To test the functionality of the user interface as part of end-to-end integration tests to confirm UI functions.
Interoperability & WS Compliance Test: This type of test applies to SOAP APIs and is compatible with Web Services (WS) interoperability profiles. Compliance is tested to ensure that predefined criteria are met.
Penetration testing: To detect the vulnerability of any application from an attacker.
Fuzz testing: For testing by giving inputs in an attempt to crash the API.
Types of bugs found in API testing:
Following are the types of bugs found:
· Duplicate or missing functionality
· Improper messaging response
· Security, performance & security issues
· Reliability issues
· Error handling mechanism is incompatible
Things to know before you start API Testing:
Endpoint: Address where API is hosted on the Server.
HTTP methods: HTTP methods which are commonly used to communicate with Rest API’s are GET, POST, PUT, and DELETE
GET: The GET method is used to extract information from the given server using a given URI. While using the GET request, it should only extract data and should have no other effect on the data. No Payload/Body required
How to send input data in GET?
Using Query Parameters
POST: A POST request is used to send data to the server, for example, customer information, file upload, etc. using HTML forms.
How to send input data in POST?
Using Form Parameters /Body Payload
PUT: Replaces all current representations of the target resource with the uploaded content.
DELETE: Removes all current representations of the target resource given by a URI.
Resources: Resources represent API/Collection which can be accessed from the Server
google.com/maps
google.com/search
google.com/images
Path Parameters: Path parameters are variable parts of a URL path. They are typically used to point to a specific resource within a collection, such as a user identified by ID
https://www.google.com/Images/1123343 -
The forward-slash (/) character is used in the path portion of the URI to indicate a hierarchical relationship between resources. This link will redirect you to the given Particular image number.
https://www.google.com/docs/1123343
Query Parameters: Query Parameter is used to sort/filter the resources.
Query Parameters are identified with?”
https://amazon.com/orders?sort_by=2/20/2020
Headers/Cookies: Headers represent the meta-data associated with the API request and response. In layman terms, we were sending Additional details to API to process our request.
Example: Authorization details
Rest API:
REST determines how the API looks like. It stands for “Representational State Transfer”. It is a set of rules that developers follow when they create their API. One of these rules states that you should be able to get a piece of data (called a resource) when you link to a specific URL.
How to start with POSTMAN?
- Click on the Settings icon on the top right corner of Postman.
2. Click on ‘Add’ from the Manage Environments popup.
3. Add Environment name and variable details (here we specify the URL as a variable) to make our API scripts reusable across different environments.
4. Select the corresponding environment created from the select environment dropdown next to the settings icon.
5. Now, from our main URL, we can replace the API address with the variable created. For example: {{url}}/api/v1/employees [Same goes for all API requests].
How to create and maintain an automated API test case:
· Understand the project and its requirements.
· Read more about tools and then decide the perfect tool as per your project requirements.
Tools for API Testing and Automation:
There are several tools for testing APIs. When a tester comes to test an API, they must ask for its document, whether it is REST or SOAP API, or its web-based API to perform API testing.
· Ask for a dock
· Write functional or service level cases first
· Write integration tests
· When the API is stable enough and has passed most of the tests mentioned above, perform safety, performance, and load tests.
1. A simple API document contains all the information about the API, such as its request format, response, error codes, resource, mandatory parameters, optional parameters, and titles. The document can be managed on various tools like Swagger (https://swagger.io) which is open-source.
2. After that, try writing service-level cases for the API. For example, if M takes an API N parameter to get the required response to the mandatory parameters and others, then a test case is to try different combinations of parameters and verify the response. Another test can verify case titles and try to execute the API without going beyond authentication and verify the error code.
3. Next comes the step of integration testing, where you need to test the API and its dependent APIs or functions. It tests the API response, which is the data that must be returned to another API or method, and what happens if this API fails.
4. Once the API is stable and functional testing is almost complete, the tester will be able to perform load, safety, and performance tests.
API Automation:
We often need to automate test cases that are executed repeatedly, as in regression cases. Similarly, in the case of API testing, there may be some instances where we need to run before each release and automate those cases.
There are many tools for API automation that are very popular:
· SOUP UI (https://www.soapui.org)
· Katalon Studio (https://www.katalon.com)
· Postman (https://www.postman.com)
· Jmeter (https://jmeter.apache.org)
· Relax (https://www.nmr-relax.com/api/)
· CloudQA TruAPI (https://doc.cloudqa.io/TruAPI.html)
1. SOUP UI: This is a very popular tool for API testing. You can perform functional, load, security, and compatibility tests on your API using SoapUI.
2. Catalon Studio: Built on top of selenium and opium Catalon Studio is a free and powerful automated testing tool for web testing, API testing, and mobile testing.
3. Postman: Postman is free and helps you to be more efficient when working with APIs. It has all the capabilities to develop and test APIs.
4. JMeter: Although JMeter is mostly used for performance and load testing, it is also well used for API functional testing.
5. RestAssured: Rest-Assured is a Java-based library used to test RESTful web services. The library can be incorporated into an existing framework and its methods can be called directly to get the response in JSON format, and then perform the necessary actions.
SOAP:
SOAP or Simple Objects Access Protocol is a web communication protocol developed for Microsoft in 1998. Today, it is mostly used to expose web services and to transmit data via HTTP / HTTPS. But it is not limited to them. SOAP, unlike the REST model, only supports XML data formatting and strongly adheres to pre-set standards such as message structure, encoding set of rules, and assembly of policy requests and responses.
Built-in functionality to create web-based services allows SOAP to manage communications and make responses to language and platform-independent.
Most web data conversion is done through REST conversion, SOAP disappears anytime, because it is so authentic, in some cases allows for automation and is even more secure. Let’s look at the main SOAP features.
SOAP only works with XML
Web-streaming data is usually constructed in some way. The two most popular data formats are XML and JSON.
XML (or Extensible Markup Language) is a text format that sets the set of rules for converting messages into human and machine-readable records. XML is verbose because it aims to create a web document with all its formalities. JSON, on the other hand, has a loose structure that focuses on data. See the image below to get an idea.
SOAP vs REST:
The term Web API usually refers to two sides of a computer system that communicate over a network: the API services provided by the server, as well as the API provided by the client, such as a web browser.
The server-side component of the Web API is a programmatic interface to a defined request-response messaging system, commonly referred to as a web service. There are many design models for web services, but the two most dominant are SOAP and REST.
SOAP offers the following advantages compared to REST:
· Language, platform and transport-independent (REST requires HTTP usage)
· Distributed organization operates well within the environment (REST umes direct point-to-point communication)
· Standard
· WS * provides significant pre-build extensibility in the form of standards
· Built-in error management
· Automation when used with certain language products.
Use WSDL to describe the SOAP API
As SOAP and other web services have become ubiquitous, many tools, technologies, and standards have been created to support them. Among them is Web Services Description Language (WSDL), an XML format that describes how to call a web service. It defines the available activities and what input/output fields to expect.
Although not unique to SOAP, many implementations of the SOAP APIs combine WSDL with the XML scheme to provide a robust web service for exchanging messages using defined methods and field types. Since WSDL is machine-readable, a SOAP client can determine what operations are possible, what data is needed to complete the call, and then display the user with the required data.
WSDLs are also used to generate human-readable documentation for SOAP APIs. Developers can see method names and input to find out what is needed to call the SOAP API. Additionally, some programming language libraries and developer environments may use the WSDL file to assist programmers with the methods and syntax available when writing code.
Like SOAP, WSDL is suitable for most types of use, although the two technologies are often used together.
Let us see how this SOAP call is structured:
<? xml version = “1.0”?>
<Soap: Envelope xmlns: soap = “http://www.w3.org/2003/05/soap-envelope">
<Soap: Title>
</ Soap: Title>
<Soap: body>
<m: GetUser>
<m: UserId> 76576565546757 </m: UserId>
</m: GetUser>
</ Soap: Body>
</ Soap: Cover>
And the response is:
<? xml version = “1.0”?>
<Soap: Cover
xmlns: soap = “http://www.w3.org/2003/05/soap-envelope/"
soap: encodingStyle = “http://www.w3.org/2003/05/soap-encoding">
<Soap: body>
<m: GetUserResponse>
<m: Username> Tony Stark </m: Username>
</ m: GetUserResponse>
</ Soap: Body>
</ Soap: Cover>
Let’s look at the sample SOAP Request (You can test SOAP API using SOAP UI tool)
<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns=”http://webservices.somesystems.com/PrecisionEmail/1.0">
<soapenv:Header/>
<soapenv:Body>
<ns:RetrieveBatchStatusPrecisionEmailRequest>
<ns:Profile>sample</ns:Profile>
<ns:BatchName>Soap API test Sample</ns:BatchName>
<ns:TaskIdentifier>12</ns:TaskIdentifier>
</ns:RetrieveBatchStatusPrecisionEmailRequest>
</soapenv:Body>
</soapenv:Envelope>
Conclusion:
Programming interface comprises a lot of classes/capacities/methodology which speak to the business rationale layer. On the off chance that API isn’t tested appropriately, it might cause issues with the API application as well as in the calling application. It is a significant and compulsory test in the product life cycle.
