In this blog, I will provide insight on the Test Approach should be considered, Best practsies to follow and Tools should be used for API Testing.
Test Approach -
To outline the approach of testing, we must know the scope of API testing as it will help us to know what to test, what should be to the focus area of the Testing etc. Now most of you have questions, how to get the scope of API Testing.
We should go through the Project documents, Design discussions, Requirement documents, working sessions etc as that will help us to outline the scope of API Testing. Below targeting questions must be asked in those discussion meeting as it will effectively identify the scope.
What are the Endpoint URLs need to use for API Testing?
Sample Requests and Response.
Response Codes.
Error handling/Messages.
Field to Field Mappings.
Authentication type and Parameters.
Expected Behavior.
Response Time.
Best Practices to Follow -
Start with API smoke and sanity testing.
Make sure to perform “negative” testing
Use a comprehensive API testing tool.
Mock missing APIs and components.
Don’t neglect security tests.
When defining test cases, group them by category.
Consider every potential API input combination to ensure complete test coverage.
Automate tests to produce better, more trustworthy results.
Keep good level of documentation.
Tools can be used for API Testing -
SoapUI
Apigee
Swagger UI
Postman
Ready API
Rest Assured
Testim
Here we have completed the blog series on API Testing, next series of blogs will be on Security Testing.
Bonus - Glossary for API
Authentication: Who is allowed to log in? Authentication means verifying the identity of a user or device before allowing access to a resource.
Authorization: What can a specific authenticated user do? Authorization refers to the set of permission rules that check for levels of access and allow actions for authenticated users.
Stateful Auth: The server maintains a record of the current authentication status of a user. The server ‘state’ reflects exactly who is logged in to a resource at any given time and only provides access to those users. Stateful auth uses sessions and cookies to keep track of user state.
Session: A defined period of time when a user is logged in to a resource. Generally short, measured in hours. Begins when a user is authenticated and ends either based on a pre-set timeout or when the user logs out.
Cookie: An HTTP header containing data about the user and session. Cookies can be used for data collection and personalization - in those cases, users must be notified and allowed to opt-out. Cookies used for auth purposes do NOT require separate notification, as user permission is implied by the authentication process. However, session cookies also contain very little information about who the user is and should be deleted immediately at the end of a session, so there is less potential for abuse than with other cookie types.
Session-based Auth: In session-based authentication with a cookie, once a user is authenticated, a `Set-Cookie` HTTP header is used to assign a session cookie. That cookie is stored on the server-side. Each action the user takes with the resource, in the form of an HTTP request, includes a `Cookie` header. So long as the cookie value is active on the resource server, the user may continue to access the resource. When the user logs out or time expires, the cookie is deleted from the resource server and the session ends. When the user logs in again, a new cookie will be generated and a brand-new session will be initiated. This approach places more demands on the resource server and storage but makes it more difficult for credentials to be stolen or misused.
Stateless Auth: In stateless auth, the server does not maintain a record of authentication status. Instead, the responsibility rests with the user or a third-party auth service. Since the resource server does not maintain any record of who is currently using the resource, stateless auth relies on headers and tokens.
Basic Authorization Header: An HTTP header used to pass a string value (e.g., an encrypted password or API key) to a resource.
Token: A small data object provided to a client/user by an authorization server. The basic structure of an authorization token is a Header, which defines the token type and encryption algorithm, a Payload, which includes JSON-format data about the user and token expiry, and a Signature, which is an encrypted value that ensures the token hasn’t been modified.
Token Exchange: Two round-trip data transactions:
First, a client application sends credentials (e.g. username/password, biometrics, or a device ID and secret) to an authentication server. If credentials are valid, the auth server returns a token to the client.
Second, the client application sends the token to the application server. If the token is valid, the application returns the resources that token is allowed to access.
JSON Web Token/JWT: (pronounced ‘jot’) An open standard format for authentication tokens. Allows more data to be contained than a simple authorization header, including encoded expiration and customizable encryption algorithms.
Token-based Auth: Unlike session-based stateful auth, token-based auth separates resources from the auth process. The user retains control over the token, and the resource simply verifies that the token is valid. The resource has rules for validating tokens, which can include a blacklist of expired or blocked tokens. Tokens can remain valid for long periods of time, and are often sent to users along with a renewal token, so they can be reused many times. This reduces the storage burden on the resource but has more vulnerabilities from misused tokens.
Single Sign-On/SSO: Authorization servers that take a single set of user credentials to provide tokens for multiple applications and resources. In general, SSO works with stateless auth, because a third party coordinates credentials and authentication, not the resource itself. SSO - and stateless auth practices as a whole - are best used in high-trust environments.
Security Assertion Markup Language/SAML: An XML-based markup language. An older but still widely-used authentication protocol and token format. We’ll talk more about SAML in the next post in this series!
OAuth2: An open standard for authorization that uses a centralized authentication mechanism to coordinate tokens between different applications. NOT an authentication protocol. We’ll talk about OAuth more in our next post, as well.
Comments