State Assertion Framework for Automated Regression Testing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In network environments, ensuring the reliability of software deployment is challenging due to misconfigurations and unintended changes introduced during the deployment of new software, which can impair or degrade servers, highlighting the need for effective testing of application code.

Innovation Solution

A State Assertion Framework (SAF) is implemented to monitor software objects and track state changes and communications, generating assertions for baseline behavior and allowing for the replay of user interactions to verify application code changes, thereby facilitating regression testing and ensuring consistent application behavior.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If new software is deployed to a server, then functionality and features are improved, but misconfigurations or unintended changes can be introduced resulting in server impairment or degradation

Engineering Contradiction:
Improvesoftware functionalityVSAvoidserver reliability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent applies preliminary action by performing regression testing before deploying new software to production. The system automatically executes a suite of regression test cases that simulate user interactions with the application, verifying that new code changes do not break existing functionality. This pre-deployment verification prevents misconfigurations and unintended changes from reaching the production environment, thus maintaining server reliability while allowing functionality improvements.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements feedback through an automated regression testing system that provides immediate information about whether new software changes have introduced defects. The system monitors application behavior during testing and compares it against expected outcomes, generating feedback that indicates whether the deployment is safe or requires correction. This feedback loop enables developers to identify and fix issues before they impact production servers.

Inventive Principle:
Principle #23Feedback

2Measurement precision

If application code is tested manually, then testing thoroughness is improved, but time consumption and resource expenditure increase

Engineering Contradiction:
Improvetesting thoroughnessVSAvoidtesting time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent applies self-service by implementing an automated regression testing system that executes test cases without human intervention. The system automatically launches the application, simulates user interactions through scripted test cases, monitors software object state changes, and generates test results. This automation eliminates the need for manual testing while maintaining comprehensive coverage, significantly reducing testing time and resource expenditure compared to manual processes.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent replaces the mechanical system of manual testing with an automated computational system. Instead of human testers manually interacting with the application and recording results, the system uses automated scripts and software agents to execute test cases, detect state changes, and generate reports. This substitution of manual mechanical actions with automated computational processes maintains testing thoroughness while dramatically reducing time consumption.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

3Measurement precision

If instrumentation code is added to monitor all software objects, then state change detection accuracy is improved, but code complexity and overhead increase

Engineering Contradiction:
Improvestate change detection accuracyVSAvoidcode complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent applies local quality by strategically placing instrumentation code only in specific software objects that are critical to the application's core functionality and state changes. Rather than instrumenting every single object in the application, the system identifies key objects whose state changes need to be monitored for regression testing purposes. This selective instrumentation maintains high detection accuracy for critical state changes while minimizing the added code complexity and overhead.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements universality by creating a standardized instrumentation framework that can be applied across multiple software objects with a single approach. The instrumentation code uses a universal interface and common monitoring logic that works across different object types, reducing the need for custom instrumentation code for each object. This multi-functional approach simplifies the overall code structure while maintaining comprehensive monitoring capability.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS9229846B1Testing application code changes using a state assertion framework
Publication Date: 2016.01.05 BUSINESS OBJECTS SOFTWARE
  • US9229846B1 patent drawing
  • US9229846B1 patent drawing
  • US9229846B1 patent drawing

AI summary

Systems and methods are disclosed for analyzing application code changes. The method may include adding instrumentation code to a selected one or more of a plurality of software objects associated with an application, when a corresponding object class for the selected software objects matches at least one preferred object class. In response to at least one application-related event, detecting using the instrumentation code, one or more state changes of the selected software objects or one or more communications between at least two of the selected software objects. At least one baseline assertion may be generated using the instrumentation code based on the one or more state changes or communications. A notification may be generated upon detecting at least one subsequent assertion that does not match the at least one baseline assertion. A list with the at least one preferred object class may be accessed in a configuration file.