Dynamic Testing System Optimizing Test Coverage

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current testing methods for computer systems are inefficient and costly, particularly in identifying bugs and ensuring reliability, as they often require extensive and resource-intensive testing processes that do not account for component vintage and real-time conditions, leading to potential failures and increased non-recurring engineering (NRE) costs.

Innovation Solution

A dynamic testing system that utilizes historical, component, and real-time data to determine which test cases to execute and for how long, using a machine learning model to optimize test environments and schedules based on component vintage, failure rates, and testing constraints, thereby maximizing test coverage within limited time and budget.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If extensive and resource-intensive testing processes are used, then reliability of bug detection is improved, but non-recurring engineering costs and time consumption increase

Engineering Contradiction:
Improvebug detection reliabilityVSAvoidtesting process complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The testing system dynamically adapts test case selection and execution parameters based on real-time component data, historical performance, and actual system conditions. This allows the testing process to be flexible and responsive rather than static and rigid, optimizing resource allocation while maintaining detection reliability.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes testing parameters such as test case selection, execution duration, and resource allocation based on component vintage, historical failure rates, and real-time conditions. This enables tailored testing approaches for different components rather than uniform testing for all systems.

Inventive Principle:
Principle #35Parameter changes

2Productivity

If component-specific and condition-based testing is implemented, then test efficiency is improved, but testing system complexity increases

Engineering Contradiction:
Improvetest efficiencyVSAvoidtesting system complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The testing system automatically collects component data, retrieves historical performance information, and determines optimal test cases without manual intervention. The system serves itself by making intelligent decisions about what to test and how, reducing the need for complex manual test planning and execution.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system utilizes historical performance data and real-time component information as feedback to continuously improve test case selection and execution strategies. This feedback loop enables the system to learn from past testing results and adapt to actual component behavior and failure patterns.

Inventive Principle:
Principle #23Feedback

3Reliability

If historical performance data and real-time conditions are utilized, then test coverage optimization is improved, but data processing requirements increase

Engineering Contradiction:
Improvetest coverageVSAvoiddata processing load
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The system extracts only the most relevant features and parameters from historical performance data and real-time component information, rather than processing all available data. This selective extraction reduces computational burden while maintaining the ability to make informed testing decisions.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS11734141B2Dynamic testing of systems
Publication Date: 2023.08.22 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US11734141B2 patent drawing
  • US11734141B2 patent drawing
  • US11734141B2 patent drawing

AI summary

Aspects of the invention include receiving system data associated with a first system, the first system comprising a plurality of system components, wherein the system data comprises component data for each system component in the plurality of system components, obtaining historical performance data for each system component in the plurality of system components, determining at least one testing constraint associated with the first system, determining a test environment for the first system, the test environment comprising a plurality of test cases for the first system based on the system data, the historical performance data, and the at least one testing constraint, and executing the test environment on the first system.