Portable Automation Framework for Heterogeneous Component Testing

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 flexibility are essential.

Innovation Solution

A portable automation framework that enables testing in both UI and API modes with features like selective UI interaction, just-in-time provisioning, mapping of UI templates to API schemas, specification and invocation of alternate resource locators, and custom error handling, allowing for a single test script to operate in both modes and reducing resource usage.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If separate test scripts are written for UI and API modes, then testing coverage is complete, but device complexity and resource usage increase

Engineering Contradiction:

Improvetesting coverageVSAvoidtest script complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a single test script that can operate in both UI mode and API mode through configuration parameters. The test framework includes a mode selection mechanism that allows the same script to be executed differently based on the underlying system capabilities, eliminating the need for maintaining separate test scripts for different testing modes.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The test script incorporates dynamic execution logic that adapts its behavior based on configuration parameters indicating whether UI or API mode should be used. The framework dynamically selects the appropriate execution path, rendering UI elements or invoking API calls based on the configured mode, allowing flexible testing across different modes without script duplication.

Inventive Principle:

Principle #15Dynamics

2Adaptability or versatility

If separate test scripts are written for UI and API modes, then testing flexibility is maintained, but productivity decreases due to increased resource usage

Engineering Contradiction:

Improvetesting flexibilityVSAvoidtesting efficiency

Core Design Contradiction:

Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent implements a single test script that can operate in both UI mode and API mode through configuration parameters. The test framework includes a mode selection mechanism that allows the same script to be executed differently based on the underlying system capabilities, eliminating the need for maintaining separate test scripts for different testing modes.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent merges the functionality of separate UI and API test scripts into a single unified test script. The framework combines both testing approaches within one script structure, allowing test authors to write one script that serves multiple purposes depending on the execution mode configured, thereby reducing duplication and improving productivity.

Inventive Principle:

Principle #5Merging (Combining)

3Reliability

If UI elements are rendered and interacted with during setup, then UI mode testing is thorough, but testing time increases

Engineering Contradiction:

ImproveUI mode testing completenessVSAvoidsetup time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The test script incorporates dynamic execution logic that adapts its behavior based on configuration parameters indicating whether UI or API mode should be used. The framework dynamically selects the appropriate execution path, rendering UI elements or invoking API calls based on the configured mode, allowing flexible testing across different modes without script duplication.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent applies different execution strategies to different parts of the test script based on the configured mode. In API mode, setup operations bypass UI rendering and directly invoke API calls, while in UI mode, the full UI rendering and interaction sequence is executed. This localized differentiation optimizes setup time for API mode while maintaining UI thoroughness when needed.

Inventive Principle:

Principle #3Local quality

Data Source

PatentUS11310680B2Reusing provisioned resources during heterogeneous component-based testing in a portable automation framework

Publication Date: 2022.04.19 SPIRENT COMM INC

AI summary

The disclosed technology for utilizing already-provisioned components in a test scenario without need to purge and re-provision the already provisioned components includes interpreting first and second sections of a test script. In the first section, the method includes encountering a reusable-resource-tag and a first instance of requesting provisioning of an associated resource, and provisioning the associated resource and designating the associated resource as reusable. In the second section, the disclosed method includes encountering a second instance of requesting provisioning of the associated resource, determining that the associated resource was designated as being reusable, and reusing an already provisioned instance of the associated resource instead of provisioning a new instance and instead of destroying the already provisioned instance and re-provisioning the associated resource. Further, extending test scripting to determining whether an associated resource has already been provisioned, and the interpreter determining that the resource was designated as being reusable.