Platform-Agnostic Test Automation via REST API Reverse Engineering
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional test automation for storage system applications requires the development of product-specific libraries, which are tightly coupled to the product and platform, making it impractical to leverage automation libraries across platforms and increasing development costs, especially when REST APIs change frequently during the development process.
Innovation Solution
A test automation application that includes an API reader to create structured object.yml files from unstructured staging_object.yml files, an intelligent API converter to generate these files, and an API builder to build a REST API for the system under test, allowing for automated test automation without the need for manual creation of test automation libraries.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Extent of automation
If test automation libraries are created for a particular product, then test automation can be implemented, but the libraries become tightly coupled to that product and cannot be leveraged across platforms
Solution Approach 1:
The patent creates a universal test automation framework that can operate across multiple platforms and products without requiring product-specific libraries. The system uses a centralized test automation server that communicates with various storage systems through standardized protocols, enabling the same automation infrastructure to test different platforms (e.g., PowerMax, PowerVault) without modification.
Solution Approach 2:
The patent introduces an intermediary layer (the test automation server and its communication interface) that mediates between the test control application and the storage systems. This intermediary handles platform-specific details, allowing the test automation framework to remain platform-agnostic while still achieving comprehensive testing across different storage platforms.
2Adaptability or versatility
If test automation libraries are rebuilt several times during development, then they can adapt to API changes, but development cost and complexity increase
Solution Approach 1:
The test automation framework automatically adapts to API changes by using the system under test's own metadata and documentation to generate or update test cases. The framework extracts API specifications from the storage system itself and uses this information to create appropriate test scenarios, eliminating the need for manual library updates when APIs change.
Solution Approach 2:
The patent performs preliminary actions by establishing a flexible, platform-agnostic test automation infrastructure early in the development process. This framework is designed to accommodate future API changes without requiring substantial rework, as it uses standardized communication protocols and can dynamically adapt to new API versions through automatic specification extraction.
3Extent of automation
If automated test scripts depend on automation libraries, then test automation can be implemented, but scripts cannot be shared with customers for acceptance testing
Solution Approach 1:
The patent extracts the automation logic from product-specific libraries and consolidates it into a separate, standalone test automation server. This separation allows test scripts to be independent of any particular product implementation, enabling customers to receive and execute automation scripts without requiring access to proprietary automation libraries.
Solution Approach 2:
The test automation system is segmented into distinct components: a test control application for script management, a test automation server for execution, and storage system interfaces. This segmentation allows the automation scripts to be distributed and executed independently from the automation infrastructure, improving portability and customer accessibility.
Data Source
AI summary
An API reader reads a system application's API specification file and creates a root.yml file containing key:value pairs, in which the keys are objects, and the values are staging_object.yml files. Each staging_object.yml file includes a set of entries, with each entry including a REST operation, a REST endpoint, and a description of the operation to be performed using that entry. An intelligent API converter creates structured object.yml files based on corresponding unstructured staging_object.yml files, and replaces the staging_object.yml files of the root.yml file with the newly created object.yml files. Each object.yml file includes a plurality of entries, corresponding to the entries of the respective staging_object.yml file. Each entry of the object.yml file includes an OPERATION, a JSON payload, and a VALIDATION section. An API builder uses the root.yml file to build a REST API for the system under test which is used to automate testing of the application.