Changes

:The Postman Testrunner Framework was born out of a need to test the API serving our mobile banking apps in a large, integrated test environment, over which we had have little control. :Our API platform acts as an aggregator of several core online banking systems (OLB's), each serving multiple financial institutions (FI's), and each with its own API data/interface contract. :The integrated environment was is used by hundreds of staff, across the company, and the data setup changes constantly change for the various testing needs. Testing here is never deterministic, it has to be opportunistic!, and needs to respond appropriately to any number of situations. :We To monitor the environment's health we needed a simple check of API functionality, capable of exercising all integration paths across the range of different OLB data interfaces, and FI/user configurations. It had to be flexible to run for a range of users, FI's, and OLB's, as well as for different deploy instances of our platform, and finally to handle the range of dynamic responses possible in such a fluid environment. :We To start with, we captured and observed the API calls from made by the mobile app (Using Fiddler, Burp Suite, and MITM Proxy) and designed tried to design a Postman solution that emulates to emulate the app's sequence of API callsbehaviour. :For To initiate a test user to be able to start using the application they need to check, we select the test environment that has an a platform instance of the platform, a code to select for the FI, a useragent for the device, and then enter the user's credentials (as well as selecting the type of device). Thereafter, the information required for subsequent scenarios must be obtained in preceding prior calls. For example, if you want to test a transfer scenario, you need to first obtain a list of their accounts. The :Our development teams had have been using Postman for over a year and had built up a collection with 100+ endpoints and requests, many . Many requests are furnished with helpful test scripts that extracted extract data from the responses and saved save them to the globalsPostman global/environment variables. The taskcollection is an organised into feature folders, and alphabetised to facilitate interactive functional testing of the platform API. The user must know the sequence of calls to make to start a session and then, meant we needed perform some feature testing. :This project tries to simply orchestrate the correct sequence of API requests in the collection to automate some common functional scenarios.fulfillx the feature test scenarios.