Abstract: A computerized method creates test coverage for non-deterministic programs. The method receives a graph of edges and states representing a program under test, and creates a continuous cycle of edges that reaches each edge in the graph at least once. In one example, the method splits the continuous cycle into discrete sequences that end at edges reaching non-deterministic nodes in the graph, and verifies that the executing program conforms to the behavior represented by the discrete sequences. In another example, a method creates probabilistic strategies for reaching one or more vertices in a non-deterministic graph. The strategies provide a graph path with a high probability of reaching a desired vertex.

Abstract: A computer system provides a test program and one or more unit tests, such as a traditional unit test and or a parameterized unit test. The system also includes a constraint solver, a theorem prover, an implementation under test, a symbolic executor, a generalizor, and generated test cases. The generalizor receives a traditional unit tests as input, and modifies the traditional unit test into a parameterized unit test. The modification includes replacing plural concrete values in the traditional unit test with symbols, and exporting the symbols into a signature of the parameterized unit test. A symbolic executor identifies constraints while symbolically executing the created parameterized unit test of the implementation under test. A constraint solver and or theorem prover generates a set of test cases by solving for values that satisfy the series of constraints. The test program executes the automatically generated test cases.

Abstract: A state component saves a present state of a program or model. This state component can be invoked by the program or model itself, thereby making state a first-class citizen. As the state of the program evolves from the saved state, the saved state remains for reflection and recall, for example, for testing, verification, transaction processing, etc. Using a state reference token, the saved state of the program or model can be accessed by the program or model. For example, the program or model by utilizing a state component, can return itself to the saved state. After returning to the saved state, a second execution path can be introduced without requiring re-execution of the actions leading to the saved state. In another example, the state space of an executing model is saved in order to generate inputs required to exercise a program or model.

Abstract: Diagnosing problems in distributed systems. In one aspect, a model of a distributed system defines trace statements are generated by various nodes of the system and placed in log files. The log files are sent to an automatic validator that attempts to reconcile the trace statements against the model. Results of the attempt are indicated. In another aspect, trace statements are received by a multiplexer that creates an ordering via sequence numbers. The ordering is forwarded to an automatic validator to determine whether the trace statements indicate correct behavior.

Abstract: Constraints are defined in view of a program implementation. Constraints check program state or variables to maintain data consistency. A constraint component determines a constraint's scope and variables upon which a constraint depends. Program flow is altered so constraints are checked whenever a variable upon which a constraint depends is updated. Optionally, program flow is altered dynamically to re-establish constraints whenever a variable upon which a constraint depends is updated. Re-establishing constraints provides efficiency, since a program flow is altered for a minimum cost based on a present evolving minimum set of active constraint-variable relationships.

Abstract: Techniques and tools for generating finite state machines (“FSMs”) for a software system with asynchronous callbacks are described. For example, method invocations in a model of the software system are partitioned into observable and controlled method invocations. The controlled method invocations are those which can be run from a test harness while the observed method invocations are those which are observed asynchronously as they are invoked in the system. An FSM is created with observation and control nodes such that observable transitions are found from observation nodes and controlled transitions are found from control nodes. If a state of the model contains both controlled and observable invocations, a timeout transition is added to the FSM to give an implementation time to come up with an observed method invocation before continuing to controlled invocations.

Abstract: A system for testing programs using a digital processor and programs in computer memory. A mock behavior generator identifies an interface indicated for mock behavior. The interface is identified as an input parameter of a parameterized unit test. The mock behavior generator creates a symbolic object with stubs to receive calls and mock behavior that returns symbolic values upon receiving a call to the stub. A symbolic executor, symbolically executes the parameterized unit test to obtain path constraints for an implementation under test, and at least one path constraint includes the symbol returned in response to the call to the stub. A constraint solver provides solutions for the paths including concrete values assigned to returned symbols. The mock behavior generator creates mock objects that return the concrete values when the implementation under test is executed.

Abstract: State spaces are traversed to produce test cases, or test coverage. Test coverage is a test suite of sequences. Accepting states are defined. Expected costs are assigned to the test graph states. Strategies are created providing transitions to states with lower expected costs. Linear programs and other approximations are discussed for providing expected costs. Strategies are more likely to provide access to an accepting state, based on expected costs. Strategies are used to append transitions to test segments such that the new test segment ends in an accepting state.

Abstract: In one embodiment, a computer system determines that a previously run test scenario configured to test a software program has failed to produce an expected result due to one or more semantic errors, generates error trace code configured to monitor the called component, processes the test scenario using the error trace code, and analyzes error trace information to determine the point at which the semantic error occurs in the called component. In an alternative embodiment, a computer system detects a semantic error in a software component of a software program, constructs an error condition that may include source code representing a minimum condition under which the error occurs, generates an object invariant based on the error condition that represents an opposite condition to that represented by the error condition, and automatically generates source code change recommendations using the object invariant that prevent the semantic error from reoccurring in subsequent test scenarios.

Abstract: In one embodiment a computer system automatically generates unit tests. The computer system accesses a parameterized unit test that provides a base outline from which one or more unit tests are automatically generated, generates input parameter values for a unit of software code, automatically generates a unit test configured to assess the functionality of the unit of software code, and receives test results from a software testing program and provides feedback to a user. In other embodiments, a computer system automatically maintains a unit test database. The computer system receives a unit test at a unit test database, assigns a test identity to the received unit test, determines that the test identity assigned to the received unit test is unique when compared to other unit tests, determines that the received unit test has different functionality coverage characteristics, and adds the received unit test to the unit test database.

Abstract: 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.

Abstract: Exploration algorithms are relevant to the industrial practice of generating test cases from an abstract state machine whose runs define the predicted behavior of the software system under test. Here, a new exploration algorithm allows multiple state groupings to simultaneously guide the search for states that are interesting or relevant for testing. In some cases, the algorithm allows exploration to be optimized from exponential to linear complexity. An extended example is included that illustrates the use of the algorithm.

Abstract: A model composition environment can allow for description of fill or partial symbolic system behavior, as well as the combination of models of specific features into compound models. Compositional operators can include intersection, concatenation, substitution, alternating refinement, as well as a set of regular expression-like operators. Models called “action machines” can represent object-oriented, reactive programs, and an action machine may be composed with another action machine using a compositional operator. This can allow for testing of particular scenarios or behaviors.

Abstract: A finite domain approximation for symbolic terms of a symbolic state is derived, given some finite domains for basic terms of the symbolic state. A method is executed recursively for symbolic sub-terms of a symbolic term, providing a domain over-approximation that can then be provided to a solver for determining a more accurate domain. The method can be applied to a wide array of system terms, including, for example, object states, arrays, and runtime types.

Abstract: The technology contributes the inference of formal specifications automatically, which can increase the acceptance of specifications. The technology introduces the symbolic execution of a modifier method to explore its behavior and then summarizing the results of the exploration using observer methods. This often results in concise, understandable specifications, which are a prerequisite for human analysis. Optionally, a generated specification is deemed sound and or complete. The specifications are presented as traditional pre-/post-condition specifications or parameterized unit tests. The former often serve as inputs to a program verification system, whereas the latter often provide inputs for tools that generate test cases.

Abstract: Symbolic execution identifies possible execution paths of a computer program or method, each having certain constraints over the input values. The symbolic execution also records updates of memory locations, e.g. updates of the fields of symbolic objects in the heap of an object oriented program, involving a description of the previous heap, the updated symbolic object, a field identification, and a newly assigned symbolic value. The symbolic execution can also record calls to summarized methods, involving a description of previous calls, an identification of the summarized methods, and its symbolic arguments. The behavior of summarized methods can be expressed by axioms. Axioms describe the relationship between summarized methods under certain conditions. Axioms can be generated from parameterized unit tests. A parameterized unit test is a method with parameters which executes a sequence of calls to methods of an implementation under test; it asserts constraints over the inputs and outputs of the calls.

Abstract: Separation of parameterized unit tests from specific test cases supports many benefits including automated test case generation. Symbolic execution assigns symbolic input variables to parameters of a parameterized unit test. Path constraints of an implementation under test (IUT) are identified during symbolic execution. A constraint solver automatically generates test cases by determining the test inputs that satisfy one of more paths, each described by constraints, through the IUT. Parameterized unit tests are used to populate behavioral summaries. Behavioral summaries are used later in future symbolic executions to emulate summarized methods. An intensional heap is provided to represent state changes performed by summarized methods. The extensional heap is used to explicitly update memory locations, e.g. object fields or array elements.

Abstract: A computer system provides a test program and one or more unit tests, such as a traditional unit test and or a parameterized unit test. The system also includes a constraint solver, a theorem prover, an implementation under test, a symbolic executor, a generalizor, and generated test cases. The generalizor receives a traditional unit tests as input, and modifies the traditional unit test into a parameterized unit test. The modification includes replacing plural concrete values in the traditional unit test with symbols, and exporting the symbols into a signature of the parameterized unit test. A symbolic executor identifies constraints while symbolically executing the created parameterized unit test of the implementation under test. A constraint solver and or theorem prover generates a set of test cases by solving for values that satisfy the series of constraints. The test program executes the automatically generated test cases.

Abstract: A system for testing programs using a digital processor and programs in computer memory. A mock behavior generator identifies an interface indicated for mock behavior. The interface is identified as an input parameter of a parameterized unit test. The mock behavior generator creates a symbolic object with stubs to receive calls and mock behavior that returns symbolic values upon receiving a call to the stub. A symbolic executor, symbolically executes the parameterized unit test to obtain path constraints for an implementation under test, and at least one path constraint includes the symbol returned in response to the call to the stub. A constraint solver provides solutions for the paths including concrete values assigned to returned symbols. The mock behavior generator creates mock objects that return the concrete values when the implementation under test is executed.

Abstract: Diagnosing problems in distributed systems. In one aspect, a model of a distributed system defines trace statements are generated by various nodes of the system and placed in log files. The log files are sent to an automatic validator that attempts to reconcile the trace statements against the model. Results of the attempt are indicated. In another aspect, trace statements are received by a multiplexer that creates an ordering via sequence numbers. The ordering is forwarded to an automatic validator to determine whether the trace statements indicate correct behavior.