Staff
470
edits
Changes
→Overview
:To start with, we captured and observed the API calls made by the mobile app (Using Fiddler, Burp Suite, and MITM Proxy) and tried to design a Postman solution to emulate the app's behaviour.
:To initiate a check, we select a platform instance, a code for the FI, a useragent for the device, and then enter the user's credentials. Thereafter, the information required for subsequent scenarios must be obtained in prior calls. For example, to test a transfer scenario, you need to first obtain a list of their accounts.
:Our development teams have been using Postman for over a year and built up a collection with 100+ endpoints and requests. Many requests are furnished with helpful test scripts that extract data from the responses response, and save saves them to the Postman global/environment variables. The collection is an organised into feature folders, and alphabetised to facilitate interactive functional testing of the platform API. The user However, the developer/test analyst must know the sequence of calls to make to start a session , and then they can perform some feature testing. :This collection is actively maintained and versioned with pull requests and reviews in a Git repo. It is a wonderful resource and this project tries to leverage it's value by trying to orchestrate the correct sequence of API requests in the collection to automate some common functional (API) scenarios.
fulfillx the feature test scenarios.
Finally, we need to handle different responses. We may receive different success or failure codes, but also we may receive information that makes the feature incapable of being executed, eg, if the feature is switched off for the FI, or a user isn't configured to permit it.
