Portable Automation Framework for Unified UI and API Test Scripting
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing test automation frameworks require users to write distinct test scripts for both user interface (UI) and application programming interface (API) modes, leading to inefficiencies and increased resource usage, especially in rapidly evolving telecommunications networks where quick testing and configuration are necessary.
Innovation Solution
A portable automation framework that enables test scripts to operate in both UI and API modes, utilizing a directive to select the execution mode, allowing for reusable resources, just-in-time provisioning, mapping of UI templates to API schemas, specification and invocation of alternate resource locators, and enhanced error handling.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If distinct test scripts are written for UI and API modes, then testing coverage is improved, but device complexity and resource usage increase
Solution Approach 1:
The patent implements a universal test script that can execute in both UI and API modes through a mode selection mechanism. The test script contains mode-agnostic test logic that adapts its execution path based on the selected mode, allowing a single script to cover both testing scenarios without requiring separate scripts for each mode.
Solution Approach 2:
The test script is segmented into mode-specific sections (UI mode section and API mode section) with clear directives indicating which section should execute in which mode. This segmentation allows the framework to selectively execute only the relevant portion of the script based on the chosen mode, reducing unnecessary complexity while maintaining comprehensive testing coverage.
2Measurement precision
If distinct test scripts are written for UI and API modes, then testing accuracy is improved, but productivity decreases
Solution Approach 1:
The framework implements partial execution by selecting only the relevant mode-specific section (UI or API) based on the chosen mode. This prevents the framework from executing unnecessary code paths, thereby maintaining testing accuracy for the selected mode while improving productivity by avoiding redundant execution overhead.
3Adaptability or versatility
If separate test scripts are maintained for different modes, then adaptability is improved, but ease of operation worsens
Solution Approach 1:
A single universal test script maintains adaptability to both UI and API modes through embedded mode selection logic. The script includes directives that specify which section executes in which mode, allowing users to maintain one script file while achieving the flexibility of mode-specific testing without the operational burden of managing multiple separate scripts.
4Loss of energy
If mode-specific execution is implemented, then resource usage is reduced, but device complexity increases
Solution Approach 1:
The test script is divided into clearly marked UI mode section and API mode section with directives indicating execution conditions. This segmentation enables the framework to execute only the necessary section based on the selected mode, reducing resource consumption by avoiding execution of irrelevant code while keeping the added framework complexity manageable through clear structural organization.
Data Source
AI summary
Disclosed is a method of efficient testing by selective UI interaction, through test script sections including setup, execution and verification, applied to an AUT that operates in both API mode and UI)mode, including providing a test environment that, when testing the UI mode of the AUT, defaults to ignoring the UI mode during setup and supplying setup values stored in a file directly to an API without rendering or interacting with UI elements in the setup section of the script. The method includes encountering an override directive in the setup section of the test script, which mandates interaction with a specified UI element in the setup section, and responsive to the directive, overriding of the default of ignoring the specified UI element in the setup section, rendering the specified UI element, and applying a bot to interact with and supply setup values from the file to the specified UI element.