US7523425B2 - Test case generation algorithm for a model checker - Google Patents
Test case generation algorithm for a model checker Download PDFInfo
- Publication number
- US7523425B2 US7523425B2 US11/408,506 US40850606A US7523425B2 US 7523425 B2 US7523425 B2 US 7523425B2 US 40850606 A US40850606 A US 40850606A US 7523425 B2 US7523425 B2 US 7523425B2
- Authority
- US
- United States
- Prior art keywords
- property
- test
- test case
- sequence
- debug
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related, expires
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
- G06F30/3323—Design verification, e.g. functional simulation or model checking using formal methods, e.g. equivalence checking or property checking
Definitions
- the present invention generally relates to verification, validation and testing.
- the present invention relates to test specification, test case generation, test automation, formal specification, formal verification, and model checking.
- V&V The verification and validation (V&V) or testing phase of an engineering project is one of the major contributors to the overall development effort and cost of the project.
- Verification is the process of determining if a system meets the system requirements correctly.
- Validation is the process of evaluating the system to determine whether it satisfies the specified requirements and meets customer needs. Validation typically takes place after verification is completed.
- One part of verification and validation is generating test cases.
- a test case is a set of conditions or variables under which a test procedure determines if a requirement is satisfied. A number of test cases may be necessary to determine that the requirement is fully satisfied.
- a verification engineer (a/k/a test engineer) specified tests based on requirements, which a systems engineer typically specified in text documents using natural language and simple graphics.
- the verification engineer manually specified the test cases by reading and interpreting the requirements, attempting to understand the coherence and interferences between the various requirements, and deriving test cases based on his gathered knowledge.
- the verification engineer wrote test scripts that automated the test cases.
- Formal methods are mathematically based techniques (e.g., temporal logic formulas) for the specification, development and verification of software and hardware systems.
- Formal verification is the act of proving or disproving the correctness of a system with respect to a certain formal specification or property, using formal methods.
- Formal verification is becoming a key technology to ensure the quality of complex systems (e.g., hardware/software).
- Today, formal verification is widely used in the design phase of hardware projects. However, formal verification is more or less neglected in software and systems development.
- Model checking is a method for algorithmically verifying formal systems using a model often derived from a hardware or software design.
- GateProp a model checker
- the verification engineer specified a particular test case to test a specific aspect of the system that described this aspect, but did not describe how to reach the start state of the test case. This is problematic, because an automated test procedure needs to start from a well-defined idle state.
- test cases used model checkers to generate stimuli (inputs) and responses (outputs) for test cases.
- VHDL integrated circuit hardware description language
- Other approaches generated test cases from specifications without model checking but by simply determining all combinations or permutations of parameters, input/output signals, etc.
- test case generation using methods other than model checking typically are slow and create so large a number of test cases that they cannot be executed in a reasonable timeframe.
- Exemplary embodiments of the present invention include a test case generation algorithm for a model checker.
- One embodiment is a method for test case generation.
- a first property of a system is verified with a model checker.
- a second property is automatically generating to reach an initial state of a negation of the first property from an initial state of the system.
- a debug sequence for the second property is produced.
- One or more internal signals are added from a last time step of the debug sequence for the second property to an assume part of the negated first property to produce a third property.
- a final debug sequence is produced using a concatenation of the second and third properties.
- Another embodiment is a computer readable medium storing instructions for performing this method.
- Another embodiment is a system for test case generation, including a model checker and a test case generator.
- the model checker provides debug sequences.
- the test case generator uses a debug sequence from the model checker for a first property to automatically create a second property to reach an initial state of the negation of the first property from an initial state of a system.
- the test case generator adds internal signals from a last time step of the debug sequence for the second property to an assume part of the negated first property to produce a third property.
- the model checker produces a final debug sequence using a concatenation of the second and third properties.
- FIG. 1 is a block diagram illustrating the evolution from manual test specification to model checking generated test cases
- FIG. 2 is a block diagram illustrating an overview of verification with model checking
- FIG. 3 illustrates a mode transition table (MTT) for an exemplary signal
- FIG. 4 illustrates a data transformation table (DTT) for an exemplary signal
- FIG. 5 illustrates an exemplary macro for preventing erroneous inputs
- FIG. 6 illustrates a first property
- FIG. 7 illustrates an exemplary mapping of input signals to test procedures for the first property of FIG. 6 ;
- FIG. 8 illustrates an exemplary generated test script for the first property of FIG. 6 ;
- FIG. 9 illustrates a second property that starts from the initial state of the system and leads to the initial state of the first property of FIG. 6 ;
- FIG. 10 illustrates another first property that does not start from the initial state of the system
- FIG. 11 illustrates exemplary input signals from a debug sequence generated with the negation of the first property
- FIG. 12 illustrates a second property
- FIG. 13 illustrates the debug sequence generated with the second property of FIG. 12 ;
- FIG. 14 illustrates the executable test scripts generated for the debug sequence of FIG. 13 ;
- FIG. 15 illustrates an exemplary general_assertion macro
- FIG. 16 illustrates a third property that starts from the system state in the last time step of the second property of FIG. 12 ;
- FIG. 17 is a message sequence chart illustrating an exemplary method of test case generation.
- FIG. 18 is a high-level block diagram showing a computer. To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.
- the description of the present invention is primarily within a general context of a test case generation algorithm for the model checker called GateProp.
- GateProp a test case generation algorithm for the model checker
- the invention is generally applicable to other model checkers, to any kind of verification of systems, software, or application specific integrated circuit (ASIC) design and may be applied in many industries, such as telecommunications, semiconductors, automotive, aerospace, military systems, consumer electronics and other industries. Accordingly, the general concepts of the present invention are broadly applicable and are not limited to any particular model checker, verification system, or industry.
- Verification is one of the most expensive and time-consuming parts of complex system development. Usually verification engineers perform verification using techniques like manual inspection (technical reviews), simulation, and test. Formal verification techniques—in particular model checking—are becoming more widely used to improve the system verification process. For the design of complex hardware devices like ASICs, field-programmable gate arrays (FPGAs) or systems-on-chip, model checking can replace long, expensive simulation runs. Also for software and even for abstract system specifications, model checking can improve system quality and increase the efficiency of verification.
- FPGAs field-programmable gate arrays
- model checking can improve system quality and increase the efficiency of verification.
- a formal language e.g., temporal logic formulas
- the model checker provides debug information to show how the system fails to meet the property.
- test cases for verification are manually specified using simple text documents or test specification languages (e.g., testing and test control notation (TTCN-3)).
- TTCN-3 testing and test control notation
- FIG. 1 illustrates the evolution from manual test specification to model checking generated test cases.
- Past approaches include system specification 102 in text, unified modeling language (UML), etc.
- the verification engineer manually generated a test case specification 104 in text, TTCN-3, etc. and performed manual script coding and code generation for test automation 106 (e.g., test scripts).
- the system specification 102 was implemented as a simulation model or system-under-test 108 and the test scripts 106 were executed on the simulation model 108 .
- a formal model and formal properties 110 are input to a test case generator 112 using model checking.
- the formal model 110 is a formal specification generated from the system specification 102 .
- the test case generator 112 generates the test specification 104 and generates code for test automation 106 .
- FIG. 2 illustrates an overview 200 of verification with model checking.
- the model checker 208 receives as input the abstract model 204 (e.g., in VHDL) and a property 202 specified in temporal logic that the final (i.e., implemented) system is expected to satisfy.
- the output of the model checker 208 indicates either that the property holds and the model is okay 210 or that the property fails, in which case a counter-example is generated 212 .
- the counter-example 212 explains in detail why the model does not satisfy the specification.
- model checking is directly applied to the VHDL code. To verify textual system specifications 206 at a high level of abstraction, first the specification needs to be transformed into an abstract model 204 .
- the system specification 206 and the abstract model 204 are corrected and the property 202 is verified again by the model checker 208 to ensure that the abstract model 204 satisfies all the required system properties. This Increases the confidence in the correctness of the abstract model 204 and, thus, in the specification 206 from which the abstract 204 model is derived.
- This model checking approach finds system failures in the early phases of a system development process and, thus, can significantly shorten the time-to-market.
- ADeVA advanced design and verification of abstract systems
- model checker GateProp the model checker GateProp.
- ADeVA is a state/transition based language for system specification. ADeVA was originally designed for ASIC-based systems, but it may be used to specify the control flow of any hardware or software system.
- the basic view of the ADeVA paradigm is that the system consists of a set of signals or variables, which are either input signals or driven signals. Input signals receive their values from outside of the system.
- the dynamic behavior of driven signals is specified by two kinds of tables: mode transition tables (MTTs) and data transformation tables (DTTs). MTTs are intended to reflect the dynamics of control flow while DTTs are especially suited to specifying data value transformations.
- MTTs mode transition tables
- DTTs data transformation tables
- the chosen semantics enables a straightforward mapping of the specification language to VHDL and, thus, allows existing tools to be used for verification tasks (e.g., the model checker GateProp).
- SpecEdit which is available from Lucent Technologies, New Jersey, is used to specify a system in the ADeVA language.
- the invention is not limited to any particular tools and other embodiments use various other tools.
- SpecEdit allows MTTs and DTTs to be edited and data types to be defined.
- SpecEdit can also generate a behavioral VHDL model from the ADeVA specification, which is needed by the model checker GateProp.
- a stack has just one input signal: command ⁇ push, pop, none ⁇ .
- the driven signals are: push_int, pop_int ⁇ false,true ⁇ stack_pointer ⁇ NATURAL fill_level ⁇ empty, normal, full ⁇ .
- the signal fill_level is also driven to the output of the system.
- FIG. 3 illustrates a mode transition table (MTT) for an exemplary signal.
- MTT mode transition table
- the third row expresses that the signal push_int changes its value from true to false if the condition stack_pointer ⁇ 5 becomes false.
- the behavior of the pop_int signal is similar.
- the behavior of the stack_pointer signal is better described with a DTT as shown in FIG. 4 .
- FIG. 4 illustrates a data transformation table (DTT) for an exemplary signal.
- DTT data transformation table
- the first row in FIG. 3 means that the signal stack_pointer is incremented if the signal push_int becomes true and pop_int is false. It is decremented if pop_int becomes true and push_int is false.
- One difference between an MTT at a DTT is that for a DTT the current state of the signal does not matter.
- a DTT is also used for the fill_level signal.
- This stack model example is simplified (e.g., the stack does not hold any data). Of course, there are other possible ways of modeling a stack.
- GateProp allows a verification engineer to specify properties with an interval time language (ITL), which uses a VHDL syntax (called VHI) or Verilog syntax (called VHI).
- ITL interval time language
- VHI VHDL syntax
- VHI Verilog syntax
- Each specified property has two parts: an assume part and a prove part.
- the verification engineer specifies a number of assumptions in the assume part and specifies a number of commitments in the prove part.
- GateProp attempts to prove the commitments under the conditions specified by the assumptions for the property.
- the verification engineer specifies a property of the system that he wants to formally verify against a model of the specification. Later, the verification engineer tests the implemented (real) system.
- the property starts from the initial state of the system, i.e., the assume part is specified as follows.
- initial_state is a macro that sets all internal signals as well as outputs to some predefined values.
- the stable_state macro is required in an asynchronous modeling approach. Without this macro GateProp can, for example, choose the value push for the input signal command in the first time step.
- the push operation will not be done, because no signal event for the command signal is detected.
- the stable_state macro sets the value of command to none in the first time step.
- GateProp can choose the value push. Then a signal event is detected (i.e., the command changes its value from none to push) and the push operation is performed.
- one exemplary embodiment includes a tool that allows entering and editing the mapping of input signals to existing test procedures.
- the test case generator uses a database created by this tool to map the input signals extracted from the debug sequence to the existing test procedures.
- a macro can be defined once for a system and reused in every property.
- FIG. 5 shows an exemplary macro for preventing erroneous inputs.
- the NEXT operator refers to the value of the signal in the next time step, e.g., if the stack is full in the current time step, the command signal in the next time step must not be push.
- FIG. 6 illustrates a first property, P 1 , which is a very simple example of a property that starts from the initial state of the system.
- P 1 a very simple example of a property that starts from the initial state of the system.
- the general_assertions macro (see FIG. 5 ) is not required for this particular property, but it does no harm to use it anyway.
- FIG. 7 illustrates an exemplary mapping of input signals to test procedures for the first property of FIG. 6 .
- These input signals are now mapped to test procedures.
- This information is taken from the mapping database.
- the retrieve procedure getFillLevel is called with parameter normal. In other words, it is expected that the fill level will be normal.
- the information about what retrieval procedures must be called to retrieve an output value is stored in the database, in one embodiment.
- the generated test script is shown in FIG. 8 .
- FIG. 8 illustrates an exemplary generated test script for the first property of FIG. 6 .
- FIG. 9 illustrates a second property P 2 that starts from the initial state of the system and leads to the initial state of the first property P 1 of FIG. 6 .
- the general_assertions macro is used to prevent some inputs that would lead to an error during execution of the generated test script.
- the signals and values of the prove part of the property described the initial state of the property P 1 . In a majority of cases, these are the signals from the assume part of the property P 1 . Because the debug sequence generated by GateProp will mostly contain all internal signals, the verification engineer additionally specifies the relevant signals, whose values will be reached with the property P 2 .
- the test case generator extracts the values of these signals from the first time step of the debug sequence of the property !P 1 (i.e., negated P 1 ) and puts them to the prove part of the property P 2 , so that the property P 2 is generated automatically.
- Another issue associated with automatically generating the property P 2 is choosing a matching value for x in the during commitment. Because there is no way in the ITL used by GateProp to express that some states have to be reached no matter how many time steps are required, the verification engineer must specify the maximal time step number x. Therefore, he needs to estimate how many time steps are approximately required to reach the initial state of the property P 1 from the initial state of the system. In a doubtful case, it is better to choose more time steps than are actually needed. If too few time steps are chosen and the desired state can not be reached, GateProp will provide no debug sequence (i.e., the property P 2 holds) and the test case generator will return an error. The verification engineer can then increase the maximal time step number and run the test case generation again. Choosing too many time steps will not produce an error, but might cause GateProp to run into a state space explosion problem.
- FIG. 11 illustrates exemplary input signals from a debug sequence generated with the negation of the first property !P 1 .
- the verification engineer specifies the relevant internal signals, which values should be reachable from the initial state of the system. In this case, it is just the fill_level signal and the approximate number of time steps to do it (e.g., 10 time steps are enough to fill the stack with 5 elements). Having this information, the test case generator automatically generates the property P 2 as illustrated in FIG. 12 . The debug sequence produced with this property is illustrated in FIG. 13 .
- the complete input sequence After concatenating this sequence with the input sequence generated with the property !P 1 , the complete input sequence is obtained.
- the complete input sequence leads from the initial state of the system to the desired state defined in the prove part of the property P 1 .
- the executable test script illustrated in FIG. 14 is obtained.
- a third property P 3 is generated that starts from the system state in the last time step of the property P 2 .
- the prove part of P 3 contains the same commitments as the property !P 1 , as illustrated in FIG. 16 .
- the debug sequence generated with P 2 is concatenated with the debug sequence generated with P 3 .
- Another advantage of this approach is that the initial state of the property P 3 is guaranteed to be reachable, because it is the last system state of the property P 2 .
- !P 1 instead of P 3 , it is not possible that GateProp will choose a system state that is not reachable from the initial state of the system.
- FIG. 17 is a message sequence chart illustrating an exemplary embodiment of a test case generation algorithm 1700 .
- a user 1702 e.g., verification engineer
- a test case generator 1704 e.g., a test case generator 1704
- a model checker 1706 participate in the method 1700 .
- This exemplary embodiment generates test cases using a model checker 1706 , such as GateProp, for an abstract model of a specification and a test case generator 1704 .
- the abstract model may be described with the ADeVA language using tables, such as MTTs and DTTs or another model language, such as VHDL. Properties of the abstract model are selected for test case generation and specified using a property specification language, such as ITL for GateProp.
- exemplary embodiments use the model checker GateProp to efficiently generate test cases from the ADeVA models and, in general, from any VHDL models (because internally ADeVA is transformed into behavioral VHDL). Generating test cases instead of manually writing the test scripts saves test automation effort and, thus, enables the verification engineer to significantly increase his test coverage and the overall quality. Furthermore, exemplary embodiments make it possible to easily generate test cases for scenarios that are not obvious from the specification, especially if the states to be tested are very deep in the state space. The principle of first verifying a property against the specification and thereafter using this property for generating a test case automatically from the specification ensures that the test case tests what it is intended to test, whereas manual test automation scripting is error-prone.
- exemplary embodiments of the algorithm are very fast.
- a model checker run typically lasted a few seconds and performing steps 3 to 8 of the algorithm, including script generation, took a few minutes.
- the invention helps to improve quality to reduce development costs and to speed up time-to market.
- a model checker such as GateProp.
- a model checker in combination with the invention would have a significant advantage by extending a verification tool environment by a test case generation facility.
- FIG. 18 is a high-level block diagram showing a computer.
- the computer 1800 may be employed to implement embodiments of the present invention.
- the computer 1800 comprises a processor 1830 as well as memory 1840 for storing various programs 1844 and data 1846 .
- the memory 1840 may also store an operating system 1842 supporting the programs 1844 .
- the processor 1830 cooperates with conventional support circuitry such as power supplies, clock circuits, cache memory and the like as well as circuits that assist in executing the software routines stored in the memory 1840 . As such, it is contemplated that some of the steps discussed herein as software methods may be implemented within hardware, for example, as circuitry that cooperates with the processor 1830 to perform various method steps.
- the computer 1800 also contains input/output (I/O) circuitry that forms an interface between the various functional elements communicating with the computer 1800 .
- I/O input/output
- the present invention may be implemented as a computer program product wherein computer instructions, when processed by a computer, adapt the operation of the computer such that the methods and/or techniques of the present invention are invoked or otherwise provided.
- Instructions for invoking the inventive methods may be stored in fixed or removable media, transmitted via a data stream in a broadcast media or other signal-bearing medium, and/or stored within a working memory within a computing device operating according to the instructions.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
Description
command ε{push, pop, none}.
The driven signals are:
push_int, pop_int ε{false,true}
stack_pointer εNATURAL
fill_level ε{empty, normal, full}.
The signal fill_level is also driven to the output of the system.
at t: initial_state;
at t: stable_state;
where initial_state is a macro that sets all internal signals as well as outputs to some predefined values. The stable_state macro sets all input signals to the values that do not allow any system state changes. For the stack example, this would be command=none. The stable_state macro is required in an asynchronous modeling approach. Without this macro GateProp can, for example, choose the value push for the input signal command in the first time step. However, the push operation will not be done, because no signal event for the command signal is detected. Using the stable_state macro, sets the value of command to none in the first time step. In the second time step, GateProp can choose the value push. Then a signal event is detected (i.e., the command changes its value from none to push) and the push operation is performed.
during[t+0; t+x]: general_assertions;
Note that for a push operation on the full stack, the model would behave correctly (i.e., push_int would not become true and no push operation would occur), but the test case generator would map the input signal command=push to a test procedure that would try to do a push operation. This would probably cause an error.
-
- 1. The verification engineer specifies a property P1 of the system and verifies it with GateProp. (Step 1708)
- 2. If the property P1 holds, the verification engineer negates P1 (or P1 may be negated automatically) and specifies the relevant internal states and maximal time step number as described above. (
Steps 1708 and 1710) - 3. The negated property !P1 is passed to GateProp and will always fail. (Step 1712)
- 4. The test case generator uses the first time step of the produce debug sequence to automatically create a new property P2 to reach the initial state of the property !P1 from the initial state of the system (Only if !P1 does not already start with the initial state of the system). (Step 1714)
- 5. The internal signals from the last time step of the debug sequence from the property P2 are added to the assume part of the property !P1, resulting in property P3. (Step 1716)
- 6. The debug sequences produced with the properties P2 and P3 are concatenated. (Step 1718)
- 7. The input signals from the overall debug sequence are mapped to the test procedures using the existing database. (Step 1720)
- 8. Retrieval procedures are appended to the end of the test case to retrieve the current value of some output signals and to compare them to the expected values in the last time step of the debug sequence. The test case is successful, if they retrieve values are equal to the expected values; otherwise, the test case fails. (
Steps 1722 and 1724)
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/408,506 US7523425B2 (en) | 2006-04-21 | 2006-04-21 | Test case generation algorithm for a model checker |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/408,506 US7523425B2 (en) | 2006-04-21 | 2006-04-21 | Test case generation algorithm for a model checker |
Publications (2)
Publication Number | Publication Date |
---|---|
US20070250799A1 US20070250799A1 (en) | 2007-10-25 |
US7523425B2 true US7523425B2 (en) | 2009-04-21 |
Family
ID=38620895
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/408,506 Expired - Fee Related US7523425B2 (en) | 2006-04-21 | 2006-04-21 | Test case generation algorithm for a model checker |
Country Status (1)
Country | Link |
---|---|
US (1) | US7523425B2 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100057693A1 (en) * | 2008-09-04 | 2010-03-04 | At&T Intellectual Property I, L.P. | Software development test case management |
US20110041116A1 (en) * | 2009-08-14 | 2011-02-17 | Gm Global Technology Operations, Inc. | Formal analysis driven based evolution of requirements specifications |
US20120047488A1 (en) * | 2010-08-23 | 2012-02-23 | Micro Focus (Us), Inc. | State driven test editor |
US20120047490A1 (en) * | 2010-08-23 | 2012-02-23 | Micro Focus (Us), Inc. | Architecture for state driven testing |
US10346140B2 (en) | 2015-08-05 | 2019-07-09 | General Electric Company | System and method for model based technology and process for safety-critical software development |
US10509718B2 (en) * | 2017-12-08 | 2019-12-17 | Cognizant Technology Solutions India Pvt. Ltd | System and method for automatically generating software testing scripts from test cases |
US10592212B2 (en) | 2016-10-21 | 2020-03-17 | Samsung Electronics Co., Ltd. | System and method for software development based on procedures |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TWI322350B (en) * | 2006-12-15 | 2010-03-21 | Inst Information Industry | Test device, method, application program, and computer readable medium for deriving a qualified test case plan from a test case database |
JP4853312B2 (en) * | 2007-01-30 | 2012-01-11 | 日本電気株式会社 | Behavioral synthesis apparatus, method, and program having test bench generation function |
US7937673B1 (en) * | 2007-03-12 | 2011-05-03 | Cadence Design Systems, Inc. | Method and system for implementing top down design and verification of an electrical circuit design |
US8234609B2 (en) * | 2007-12-21 | 2012-07-31 | Cadence Design Systems, Inc. | Method and system for implementing top down design and verification of an electronic design |
US7984335B2 (en) * | 2008-03-20 | 2011-07-19 | Microsoft Corporation | Test amplification for datacenter applications via model checking |
US8458664B2 (en) * | 2009-02-23 | 2013-06-04 | International Business Machines Corporation | Command line interface permutation executor |
US20110083121A1 (en) * | 2009-10-02 | 2011-04-07 | Gm Global Technology Operations, Inc. | Method and System for Automatic Test-Case Generation for Distributed Embedded Systems |
DE102010062553A1 (en) * | 2010-12-07 | 2012-06-14 | Siemens Aktiengesellschaft | Apparatus and method for efficiently performing system test runs |
US8972928B2 (en) * | 2011-08-30 | 2015-03-03 | Uniquesoft, Llc | System and method for generating application code |
US10452775B2 (en) * | 2011-09-13 | 2019-10-22 | Monk Akarshala Design Private Limited | Learning application template management in a modular learning system |
US9047427B1 (en) | 2011-11-03 | 2015-06-02 | Cadence Design Systems, Inc. | Method and system for performing verification of an electronic design |
US9372770B2 (en) * | 2012-06-04 | 2016-06-21 | Karthick Gururaj | Hardware platform validation |
US10007594B2 (en) * | 2015-07-21 | 2018-06-26 | International Business Machines Corporation | Proactive cognitive analysis for inferring test case dependencies |
US10536349B1 (en) * | 2015-12-31 | 2020-01-14 | VCE IP Holding Company LLC | Configuration system and method for an integrated computing system |
US10025696B2 (en) | 2016-02-09 | 2018-07-17 | General Electric Company | System and method for equivalence class analysis-based automated requirements-based test case generation |
US10169217B2 (en) | 2016-04-06 | 2019-01-01 | General Electric Company | System and method for test generation from software specification models that contain nonlinear arithmetic constraints over real number ranges |
US10909013B2 (en) * | 2018-10-16 | 2021-02-02 | Rohde & Schwarz Gmbh & Co. Kg | TTCN-based test system and method for testing test-cases, non-transitory computer-readable recording medium |
CN112345869A (en) * | 2020-11-25 | 2021-02-09 | 武汉光庭信息技术股份有限公司 | Automobile electronic equipment testing method and system, electronic equipment and storage medium |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060010428A1 (en) * | 2004-07-12 | 2006-01-12 | Sri International | Formal methods for test case generation |
-
2006
- 2006-04-21 US US11/408,506 patent/US7523425B2/en not_active Expired - Fee Related
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060010428A1 (en) * | 2004-07-12 | 2006-01-12 | Sri International | Formal methods for test case generation |
Non-Patent Citations (2)
Title |
---|
Wang F., Gossens S., Haas W., Heinkel U., Generierung von Plänen für die funktionale Verifikation automatenbasierter Entwürfe, Workshop Dresdner Arbeitstagung Schaltungs- und Systementwurf (DASS 2004), Dresden, Apr. 2004. |
Wang F., Gossens S., Haas W., Heinkel U., Generierung von Testvorschlägen aus tabellarischen Spezifikationen 16, GI/TG/GMM Workshop "Testmethoden und Zuverlässigkeit von Schaltungen und Systemen", Dresden, Deutschland, 29.02-Feb. 3, 2004. |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100057693A1 (en) * | 2008-09-04 | 2010-03-04 | At&T Intellectual Property I, L.P. | Software development test case management |
US8463760B2 (en) | 2008-09-04 | 2013-06-11 | At&T Intellectual Property I, L. P. | Software development test case management |
US20110041116A1 (en) * | 2009-08-14 | 2011-02-17 | Gm Global Technology Operations, Inc. | Formal analysis driven based evolution of requirements specifications |
US20120047488A1 (en) * | 2010-08-23 | 2012-02-23 | Micro Focus (Us), Inc. | State driven test editor |
US20120047490A1 (en) * | 2010-08-23 | 2012-02-23 | Micro Focus (Us), Inc. | Architecture for state driven testing |
US8543980B2 (en) | 2010-08-23 | 2013-09-24 | Micro Focus (Us), Inc. | State driven testing |
US8543984B2 (en) * | 2010-08-23 | 2013-09-24 | Micro Focus (Us), Inc. | Architecture for state driven testing |
US8543981B2 (en) * | 2010-08-23 | 2013-09-24 | Micro Focus (Us), Inc. | State driven test editor |
US10346140B2 (en) | 2015-08-05 | 2019-07-09 | General Electric Company | System and method for model based technology and process for safety-critical software development |
US10592212B2 (en) | 2016-10-21 | 2020-03-17 | Samsung Electronics Co., Ltd. | System and method for software development based on procedures |
US10509718B2 (en) * | 2017-12-08 | 2019-12-17 | Cognizant Technology Solutions India Pvt. Ltd | System and method for automatically generating software testing scripts from test cases |
Also Published As
Publication number | Publication date |
---|---|
US20070250799A1 (en) | 2007-10-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7523425B2 (en) | Test case generation algorithm for a model checker | |
US6591403B1 (en) | System and method for specifying hardware description language assertions targeting a diverse set of verification tools | |
KR100329305B1 (en) | System design verification method and design verification device | |
US6385765B1 (en) | Specification and verification for concurrent systems with graphical and textual editors | |
US6931611B2 (en) | Design verification system for avoiding false failures and method therefor | |
CN103064403B (en) | A kind of ECU hardware-in-loop simulation automated testing method and system | |
US8108745B2 (en) | On-device constrained random verification for device development | |
Siegl et al. | Model based requirements analysis and testing of automotive systems with timed usage models | |
JP2009087354A (en) | Automatic test generation system and method for web application | |
US8140315B2 (en) | Test bench, method, and computer program product for performing a test case on an integrated circuit | |
CN114169271A (en) | Automatic debugging of fake-certified power-aware formal attributes using static checker results | |
US8510692B2 (en) | Verification system and method using constrained random test parameter selection | |
US6634012B2 (en) | Design verification by symbolic simulation using a native hardware description language | |
KR101334806B1 (en) | Method of proudcing input sets of test case in test case generating system | |
US5353433A (en) | Method and apparatus for organizing and analyzing timing information | |
CN114091383A (en) | Test sequence generation method, device and system and related equipment | |
US7283945B2 (en) | High level verification of software and hardware descriptions by symbolic simulation using assume-guarantee relationships with linear arithmetic assumptions | |
US6970816B1 (en) | Method and system for efficiently generating parameterized bus transactions | |
US10599802B2 (en) | Methods for automatic engineering change order (ECO) bug fixing in integrated circuit design | |
US7236917B1 (en) | Method and apparatus for generating minimal node data and dynamic assertions for a simulation | |
Xu et al. | Generating regression tests via model checking | |
CN117350208A (en) | Method and apparatus for checking performance of sequential logic element | |
US6678841B1 (en) | Function test support system and function test support method and hardware description model | |
US11023357B1 (en) | Method and system for sequential equivalence checking | |
KR101731629B1 (en) | Method and device for automatic generating go code from circus |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: LUCENT TECHNOLOGIES INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BUNIN, GRYGOIY;SCHNEIDER, AXEL;REEL/FRAME:017808/0843 Effective date: 20060421 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY Free format text: MERGER;ASSIGNOR:LUCENT TECHNOLOGIES INC.;REEL/FRAME:022305/0904 Effective date: 20081101 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
REMI | Maintenance fee reminder mailed | ||
LAPS | Lapse for failure to pay maintenance fees | ||
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20170421 |