Automated Test Input Generation via Domain Cost Constraints
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current software testing and verification processes are inefficient due to the manual identification and configuration of data structure elements, leading to time-consuming and costly exhaustive testing, especially when dealing with infinite or large data sets, and the inability to automate the generation of meaningful input data for testing computer programs.
Innovation Solution
A framework for automatically generating tests by defining data types, assigning costs, and configuring domains, which recursively builds trees and uses predicates to determine valid input parameters, reducing the search space through cost summation and data type limitations, and employing graphical user interfaces for domain configuration.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If exhaustive testing with infinite data sets is performed, then testing completeness is improved, but time consumption and cost increase significantly
Solution Approach 1:
The patent extracts only the essential and meaningful data from the infinite data set by defining constrained domains for each data type. Instead of testing all possible integers, it extracts a meaningful subset (e.g., Age: 1-100, Salary: 0-100000) that represents real-world scenarios, thereby reducing testing scope while maintaining effectiveness
Solution Approach 2:
The patent changes the parameters of testing by introducing domain constraints and cost functions. It transforms the testing problem from exploring an infinite space to exploring a bounded space defined by domain minimums, maximums, and cost limits, making the testing process finite and manageable
2Measurement precision
If manual identification and configuration of data structure elements is performed, then testing accuracy is improved, but productivity decreases
Solution Approach 1:
The patent implements self-service by enabling the testing system to automatically analyze program source code, identify data structure elements, and generate domain configurations without manual intervention. The system extracts type definitions, field names, and relationships directly from the code, eliminating the need for manual identification while maintaining accuracy
Solution Approach 2:
The patent replaces the manual mechanical process of identifying and configuring data structures with an automated computational system. It uses program analysis algorithms to substitute human effort with machine-based code interpretation, thereby increasing productivity while preserving testing accuracy
3Reliability
If the complete set of integers is tested, then testing thoroughness is improved, but practical feasibility deteriorates
Solution Approach 1:
The patent applies local quality by assigning different domain characteristics to different data types based on their specific requirements. Instead of using a uniform testing approach for all data, it tailors domain constraints to each data type (e.g., Age has 1-100 range, Salary has 0-100000 range, Boolean has true/false values), making testing both thorough and practical
Solution Approach 2:
The patent uses partial action by testing only a representative subset of possible values rather than the complete set. It selects meaningful portions of the data space that are sufficient for validating program behavior without requiring exhaustive coverage of all theoretically possible inputs
4Reliability
If thousands of data relationships are manually configured, then relationship coverage is improved, but device complexity increases
Solution Approach 1:
The patent implements universality by creating a unified program analysis framework that automatically handles all data relationship configurations. The system uses a single automated mechanism to analyze code, extract relationships, and generate configurations for all data structures and their interconnections, eliminating the need for separate manual configuration processes
Data Source
AI summary
A test domain configuration module generates graphical user interfaces for identifying information about desired tests such as data types and domain configurations, and collects information used by other modules to generate tests. The identified information may include, for example, an abstract syntax, a static semantic, max counts on instances of data types, or costs of field accesses or data types for max path costs or max expression costs. A test input generator, generates test input for the identified and configured data types. In one case, the generated test inputs are generated as tree data structures. A predicate determines whether a generated test input follows semantic conditions. A test input evaluator counts instances of data types in, sums paths through, or sums total costs of, the generated test inputs. A test acceptance module saves test inputs acceptable to the predicate and the test input evaluator.