Bureaucrat, staff, administrator
491
edits
Changes
m
→Overview
work in progress ...
==text from ScratchPad==
The latest project that I've enjoyed working on has been to learn how to use Postman and to develop a framework that allows us to use an existing Postman collection, and apply it to a new business need. Our existing API automation suite is closely tied to a particular data set only available in a mocked environment. However, the business also needed to be able run some form of automation suite in integrated environments. It was decided that we would use Postman to create solutions for performing the positive and alternate test flows in the integrated test environments. I started on a personal project to see if I could leverage the extensive Postman collection we already had for the functional testing of the API. I was pleased that I was able to create a framework that allowed us to store and easily switch between different settings for users, financial institutions and environments. This eliminated the close association the existing automation suite had with the mocked data set. I was then able to create a mechanism by which we could use an external data file to specify the API calls necessary to perform a list of use-case scenarios as individual user sessions. Incidentally, we also were able to implement a simple mechanism for code reuse that was lacking from Postman. This simple proof of concept was able to extended by other team members to add reporting customised to our needs, and able able to be run periodically from our TFS build server. We now have a dashboard of test results spanning many environments and many clients' particular configurations. Our initial implementation was added to one Postman collection, but recently another team was able to take the framework and apply it to their collection as well, which showed the benefit of designing the framework in a manner that allowed it to be retrofitted to any collection, a goal of what I was attempting to achieve. I'm sorry I'm not in position to share any specific links to the work as its proprietary to Fiserv, but I am thinking about writing a linkedIn article about it in general terms.
==Overview==
:The Postman Testrunner Framework was born out of a need to be able to test the API used by a serving our mobile banking app apps in an a large, integrated test environment , over which we did not have little control. The :Our API servers (platform) acts as an aggregator for a number of different several core online banking systems (OLB's), each one of which servicing many serving multiple financial institutions (FI's), and each with its own data/interface contract. :The integrated environment is used by hundreds of staff, across the company, and the data setup changes constantly. We Testing here is never deterministic, it has to be opportunistic, and needs to respond appropriately to any number of situations. :To monitor the environment's health 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. It had to be flexible to run for a range of users, different FI's, from different and OLB's , from as well as for different test environments. We essentially need deploy instances of our platform, and finally to be able to emulate handle the flow range of dynamic responses possible in such a fluid environment. :To start with, we captured and observed the API calls for a variety of users as they would have been made by the applicationmobile app (Using Fiddler, Burp Suite, and MITM Proxy) and tried to design a Postman solution to emulate the app's behaviour. 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 response, and saved saves 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. However, the developer/test analyst must know the sequence of calls to make to start a session, and thenthey can perform some feature testing. :This collection is actively maintained and versioned with pull requests and reviews in a Git repo. It is a really wonderful resource, meant we needed and this project tries to simply leverage it's value by implementing a framework that can orchestrate the correct sequence of API requests to fulfillx the feature test automate common functional (API) scenarios. Finally, we need :The Postman Testrunner Framework (PTF) uses an external data file to handle different responsesspecify a sequence of steps called userActions. We may receive different success or failure A userAction executes a request from the underlying collection, and then has a list of handlers for the possible response codes, but also we may receive information . Response handlers are little snippets of code that makes determine the next userAction to perform. When no next userAction is specified in the feature incapable of being executedresponse handler, eg, if execution moves to the next userAction in the external data file until the feature scenario is completed. The PTF is switched off for a simple state-machine. :The PTF implements a data store of the information necessary to be able to test with many different users, FI's, OLB's, deploy instances, etc. A data syntax was developed that links different data types, or and selects the values necessary to initiate a scenario for a user isn't configured . The input variables are processed, the relevant data links expanded, so that the Postman global and environment variables are ready prior to permit itthe first request.:Throughout the implementationA custom reporter was developed to receive the
==Objectives==
==Testrun Datafiles==
==Requirements==
==Schema Validation==
==Custom Reporter==
:Using JUnit.xml file format optimised for TFS build results
==TFS==
:powershell script:variables:builds : - base : - Fi's : - time schedule:build agents:testrun results:dashboards of historic data
==PTFWeb==
Dashboards of results