Postman Testrunner Framework

Overview

The Postman Testrunner Framework was born out of a need to be able to test the API used by a mobile banking app in an integrated test environment over which we did not have control. The API servers (platform) acts as an aggregator for a number of different core online banking systems (OLB's), each one of which servicing many financial institutions (FI's). We needed a simple check of API functionality covering the key user scenarios capable of being run with different user credentials, different FI's, from different OLB's , from different test environments. We essentially need to be able to emulate the flow 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. The task, then, meant we needed to simply orchestrate the correct sequence of API requests to 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.

Postman Object Model

classes in Code lib

Settings & Variables

orthogonal syntax cascading over riding values

TFS

powershell script variables builds

- base
- Fi's
- time schedule

build agents

PTFWeb

Dashboards of results