In our earlier posts, we went through a brief overview of Oracle BRM Testing, and how BRM UI interface works and is tested in Oracle BRM GUI Testing. In this post, we will be focusing on BRM API testing.
API calls are much faster compared to browser/UI responses and are used to transmit/retrieve data to and from the server. Whenever an API call is made, it sends a request to the data source to transmit the required data. If the data retrieval was successful, it displays a 200 OK code along with the data requested. There are different codes displayed whenever an API call is made. Some of the common status codes are displayed below:
In BRM, whenever there is an event (any action such as changing the password of a customer account, creating an account, updating an account, etc,.) on the BRM UI, the data is transmitted to the BRM database using API calls. All the actions (some of the common operations in BRM like creating accounts, updating accounts, changing passwords, managing the plans)performed on the BRM UI are executed using BRM API calls.
In order to test the API calls, we have leveraged our hybrid framework which is developed using Ruby/Selenium/Gherkin scripts. We utilized Microsoft Excel to manage all the test data, a sample image is given below.
We have the same set of scenarios to test BRM API as we have for BRM GUI. Using Ruby/Selenium we have created utility files to automatically generate Cucumber BDD test scripts using the test data from the excel files. It would take about 250 hours to manually write ~7,500 tests for BRM API testing, which would take only a few minutes to create when we generate the BDD scripts using our utility files. The timeframe to build a hybrid framework that can generate these files is about 40 hours. A sample utility file is shown below:
The folder structure for service testing is similar to GUI testing:
All of the Cucumber BDD feature files are in the features folder (which includes Functional_Test_Suite, ServiceType1_PricePlans, ServiceType1_Regression, etc.,) and the framework related files (files built using Ruby/Selenium) are in the step_definitions folder. The Test_Assets folder has files that are exclusively used for API testing. The Env_Assets folder has files that contain information regarding different test environments and credentials which are usually in JSON format. A sample JSON file is shown below:
The only difference between the web and API folder structure is that all the common files are in the web folder to avoid duplicating files.
Our sample services feature file is shown below:
Our framework is compatible with both SOAP and RESTful APIs. API testing utilizes two excel files – one excel file has the test data and the other one has sample Requests and Responses for each API call. The input values in the requests are dynamic. For example, while creating an account, the device numbers like Serial_Number, IMEI which must be unique are retrieved from the BRM database while running the script. Using the ActiveRecord gem and JDBC connection, BRM Oracle database is connected and by running the appropriate queries, the device numbers are generated dynamically. These device numbers are replaced in the service request. The sample request is shown below.
All the dynamic elements in the request are replaced using our framework.
We have employed Git and SVN to maintain the automation framework, test data, and test scripts.
Some of the common operations performed by BRM include creating customer accounts, updating accounts, and deleting the accounts which are done on both BRM UI and also using BRM API calls.
All the actions on the customer accounts are performed by executing service calls respective to each action. Each time an action is performed a confirmation file (typically an XML file) is generated and saved in the BRM server for reference. Using Net::SSH library, the file is accessed, parsed, and read to make sure the precise device numbers exist in the file.
All the scripts are moved to Awetest (a brief description on Awetest is given in our earlier post on Oracle BRM Testing) and are run on different browsers on different VMs. It will be cumbersome to move each file to Awetest, hence Awetest is integrated with some of the common Version Control and cloud services as shown below. Using this integration, it is very easy to move all assets and test data to Awetest with just one click.
By using any combination of required tests, specific tests within chosen environments, and any browser (including different browser versions), we can run different tests in Awetest and analyze various reports as indicated below.
Tests can be run immediately or scheduled to run later as well. A detailed report on the passed and failed tests is generated as shown below.
Our hybrid framework was used to test BRM APIs easily. The identified defects are logged in JIRA. Awetest is used to view the requests, responses, and logs of each API call. Any number of dynamic parameters can be added and using our framework the parameters are replaced with the respective constants. New tests and test data can be added at any given time, and the test scripts are automatically generated using our Utility files.
