Staff
470
edits
Changes
→Overview
==Overview==
:The Postman Testrunner Framework was born out of a need to be able to test the our API used by a serving our mobile banking app apps, in an a large pan-company integrated test environment , over which we did not have had little control. The :Our API servers server(s) (platform) acts as an aggregator for of a number of different core online banking systems (OLB's), each one of which servicing serving many financial institutions (FI's), and each with its own API data/interface contract. :We needed a simple check of API functionality covering , capable of exercising all integration paths across the key user scenarios capable range of being run with different OLB data interfaces, and FI/user credentialsconfigurations. To do this, it had to be flexible so that it could run for a range of users, different FI's, from different and OLB's , from as well as via different test environmentsinstances of our platform. We essentially need to be able to emulate :Using network capturing tools (Fiddler, Burp Suite, MITM Proxy) we traced the API calls from mobile app and designed a Postman solution that emulates the flow app's sequence of API calls . for a variety of users as they would have been made by the application.
For a test user to be able to start using the application they need to select the test environment that has an instance of the platform, a code to select the FI, and the user's credentials (as well as selecting the type of device). Thereafter, the information required must be obtained in preceding calls. For example, if you want to test a transfer scenario, you need to first obtain a list of their accounts.
The development teams had been using Postman for over a year and had built up a collection with 100+ endpoints and requests, many with test scripts that extracted data from the responses and saved them to the globals.
