Database Traffic Mirroring for Pre-Production Testing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software applications often encounter unforeseen issues in production environments due to synthetically generated input not accurately representing real-world data patterns and variations, leading to defects that are not identified during quality assurance.
Innovation Solution
Deriving input for pre-production versions from production environments, selectively filtering and amplifying real-world input to mimic real-world conditions, allowing for defect identification and reducing the need for synthetic testing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If synthetically generated input is used to test the application, then the testing process is automated and resource-efficient, but the test input does not accurately represent real-world data patterns and variations
Solution Approach 1:
The patent captures and stores actual database requests from the production environment, creating copies of real-world input data. These captured requests are then replayed against the database instance during testing, replacing synthetic test data with authentic production data patterns while maintaining automation through systematic capture and replay mechanisms
Solution Approach 2:
The system performs preliminary capture of production database requests and stores them in a request store before testing occurs. This advance preparation allows the testing phase to replay authentic requests without manual intervention, combining the representativeness of real data with the efficiency of automated testing
2Reliability
If all production database requests are replayed for testing, then real-world patterns are captured, but computing resources are wasted on irrelevant or redundant requests
Solution Approach 1:
The patent extracts and isolates only the relevant subset of production database requests that are suitable for testing. By filtering out irrelevant, redundant, or inappropriate requests from the complete production traffic, the system retains only the essential test cases that provide maximum testing value while minimizing resource consumption
Solution Approach 2:
Different filtering criteria are applied to different categories of requests based on their testing value. The system evaluates each request type, complexity, and origin to determine its relevance, applying selective filtering that preserves high-value test cases while eliminating low-value ones, optimizing the balance between test accuracy and resource efficiency
3Reliability
If the rate of test input matches production environment rate, then production-like conditions are simulated, but testing becomes resource-intensive and time-consuming
Solution Approach 1:
The system applies amplification factors to selectively increase the rate of specific request types during testing. By amplifying only certain categories of requests that are critical for testing while maintaining or reducing rates for others, the system achieves production-like conditions for key scenarios without the full resource intensity of replaying all requests at production rates
Solution Approach 2:
The testing system dynamically adjusts the rate and composition of replayed requests based on testing objectives, request priority, and resource availability. Rather than maintaining a static production-rate copy, the system flexibly modulates test input rates to optimize both fidelity and efficiency across different testing phases and scenarios
Data Source
AI summary
Defects are identified in a pre-production version of an application. Input used to test the pre-production version is derived from input received by a production version of the application. Input to the production version may be selectively filtered and/or amplified before being provided as test input to the pre-production version. In this way, the makeup and rate of the test input can be controlled while maintaining the character, pattern, and unpredictable nature of real-world input. Defects may be identified when the test input causes the pre-production version to crash, hang, write to an error log, or otherwise manifest or report a malfunction. In addition to identifying defects, filtered and amplified input may also be used to perform regression testing, load testing, performance testing, etc.