US20090172649A1 - Automation of software verification - Google Patents
Automation of software verification Download PDFInfo
- Publication number
- US20090172649A1 US20090172649A1 US11/966,834 US96683407A US2009172649A1 US 20090172649 A1 US20090172649 A1 US 20090172649A1 US 96683407 A US96683407 A US 96683407A US 2009172649 A1 US2009172649 A1 US 2009172649A1
- Authority
- US
- United States
- Prior art keywords
- test
- compiler
- elements
- programming language
- semantic
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
Definitions
- the present invention relates to software verification.
- Black-Box Testing consists of activating a software application with a set of inputs or test-cases, and comparing the output produced by the software application to the expected output from the software application.
- a set of possible test-cases are created for the software application and used to activate the software application under test with the test-cases.
- Large scale software applications tend to require a vast number of test-cases with an infinite number of permutations of inputs.
- a compiler is a computer program that translates a high level programming language, such as C++ or Java, into a lower level language, such as machine code, assembly, or an intermediate bytecode form that can run on a virtual machine.
- a compiler checks for errors in the input program files that are to be translated by the compiler. When a compiler discovers an error in the input program file that is being compiled, the compiler may indicate both the error and the occurrence of an error during the compilation. When a compiler successfully translates the input file, an executable is generated.
- a compiler is verified by compiling a set of programs or test-cases with the compiler, and comparing the output from the compiler with the expected output of the compiler. Theoretically, a complete verification of a compiler requires a set of all possible test-cases. However, there are an infinite number of computer programs that can be compiled such that a complete verification of a compiler is unachievable. A practical approach for compiler verification is to create output producing test-cases that contain all words in the high level programming language and all the possible combinations of the words or statements in the language.
- Verification of all the words, elements, and statements, defined as a combination of elements in a programming language, of a programming language is referred to as checking the “syntax.” Verification of a compilers' ability to handle the syntax of a programming language alone is insufficient because the compiler must handle the semantic constraints of the programming language.
- the semantics of a programming language takes in to consideration the context, the surrounding statements or environment for the statement or element in the program. For example, it is possible that an action or statement may be correct within a loop construct in the language but the same action or statement may be incorrect within a conditional “if” statement construct.
- Compiler verification is done by compiling and running test-cases with predicted run results and comparing them to the actual run results at the end. Compiler verification must contain both legal and illegal test-cases for complete verification of the ability for the compiler to handle the syntax and semantics of the high level programming language. Illegal test-cases may be input to the compiler in order to verify the error-handling ability of the compiler. Legal test-cases may be input to the compiler to test the compiler's ability to generate and executable. As a result, complete compiler verification may require tens of thousands of test-cases to cover every possible test-case.
- a method, system, and computer program product are disclosed for automatic test generation for a compiler.
- the method, system and computer program product represent a test case for the compiler in a structure with one or more elements of a programming language, associate at least one syntactic rule and semantic rule with the one or more elements in the structure, create a test with the structure compiling the test with the compiler, and display results of the test.
- FIG. 1 is a flowchart for an implementation of an automatic test generator of a compiler.
- FIG. 2 is a block diagram of the functionality of an automatic test generator for a compiler.
- FIG. 3 is a block diagram of a test generator.
- FIG. 4 is flowchart for an implementation of an automatic test generator for a compiler.
- FIG. 5 illustrates an example of syntax language tree.
- FIG. 6 is a block diagram of an implementation of an automatic test generator for a compiler.
- FIG. 7 is a block diagram of an architecture that can support implementation of an automatic test generator for a compiler.
- the present invention is directed toward methods, systems, and computer program products for automatic generation of compiler tests.
- Embodiments of the present invention implement automatic generation of compiler tests in order to verify the compiler.
- a test for a compiler is a computer program, source code, or portion of a computer program written in the programming language supported by the compiler.
- the automatic test generator creates tests for a compiler with test-cases that cover the interesting semantic and syntactic scenarios supported by the programming language.
- FIG. 1 is a flowchart for an implementation of an automatic test generator for a compiler.
- a test-case for a compiler is represented in a structure comprising one or more elements of a programming language ( 100 ).
- the programming language elements in the test-case may be randomly selected or the user may designate an aspect of the programming language that the user desires to test.
- the user may designate the test of elements supported by the language, such as classes, if-then statement, for loops, templates, and structs.
- the compiler verification may be implemented for the e programming language, and the user may designate the test of elements of the language, such as aspect oriented structs, method extensions, and computed macros.
- the language elements may be expressions or actions supported by the programming language, and each element may be composed of one or more sub-elements that form the expression or action.
- an action in a programming language may be an if-then statement and an expression may be a “ ⁇ ” or “less than” comparison.
- the structure is a tree composed of nodes, with each node representing an element of the programming language in an expression or action.
- if-then action statement “if (a ⁇ b) ⁇ println; ⁇ ” would have a tree structure with nodes for elements of the action if-then statement and the expression “(a ⁇ b).”
- any type of data structure may be implemented to represent the elements of the programming language supported by the compiler that is being verified.
- the syntactic and semantic rules for each element of the programming language are associated with the elements in the structure that correspond to the rules for the elements of the programming language ( 102 ).
- Each element of the structure may have rules that restrict the elements related to that particular element.
- Related elements are connected to the element in the hierarchical structure.
- the structure is a syntax tree, a hierarchy of nodes or elements that abide by the syntax rules of the programming language. For example, a syntax tree is created by starting with a root node or element, and each element becomes responsible for creating its' own subtree. An element selects the syntactic properties of its' child nodes, such as the “+” element that may have two “expression” child nodes.
- the semantic manager may use the context information and semantic filters to create a legal instance of each element.
- the syntactic rules may be defined in a class definition for the element or node, and the semantic rules may be associated with the element or node when the element or node is instantiated with the class constructor during the creation of the tree or structure.
- the elements of the syntax tree may be instantiated with the class constructors for the elements in the class definition thereby associating the semantic rules with the elements of the syntax tree.
- a semantic manager may associate the semantic rules with the elements of a syntax tree.
- a semantic manager may use the rules associated with each element to call methods that filter out illegal elements or sub-elements to be created for that element.
- a semantic manager may be implemented with a factory design pattern.
- Each parent element may call the semantic manager associated with the parent element to filter or select legal sub-elements for the parent element.
- the tests for the compiler may then be created using the structure ( 104 ).
- Embodiments of the invention may create the test for the compiler by stepping through the elements in the structure and writing the necessary statements, lines of source code, or portions of statements in the test file for each of the elements in the structure.
- the statements written to the test file may be incorrect usage of the elements of the programming language in the structure to test the error handling of the compiler under test.
- the elements may provide information on the statements that can be placed in the test files which can be displayed to the user to alert the user of the progress of the current generation of the test file.
- the tests may then be compiled with compiler ( 106 ), and the results from the compilation are indicated.
- the results may be displayed or stored for later access ( 108 ).
- the test file may include statements that display the success or failure of the compilation of the test.
- Embodiments may generate tests that have statements within the test that allow for writing to standard error or an output file with the results of the compilation of the test. An output file may be used for comparison with an expected output file to verify the compiler in regards to the particular test.
- FIG. 2 is a block diagram of the functionality for an approach for automatic test generator for a compiler.
- a Test Generator Application Programming Interface (API) 200 is provided for the Test Generator 202 to allow for the specification of the constraints of the programming language supported by the Compiler 204 to be tested.
- the Test Generator 202 is described in detail below with the description of FIG. 3 .
- a user may define the syntactic and semantic constraints of each element of the programming language supported by the compiler with the Test Generator API 200 .
- the user defined syntactic and semantic constraints of the programming language can be stored in a Programming Language Element Library 206 .
- the Test Generator 202 will use the definitions for the syntax and semantics of the elements of the programming language stored in the Programming Language Element Library 206 to represent a test-case for the Compiler 204 .
- the Test Generator 202 may be used to create one or more Tests 208 , programs in the programming language supported by the compiler, for the Compiler 204 .
- the Tests 208 are used as input for the Compiler 204 and the Results 210 for the Tests 208 are indicated to the user.
- the Results 210 may be made available by displaying the results to the user or storing the Results 210 in a database.
- FIG. 3 is a block diagram of an approach for implementation of a Test Generator.
- the Test Generator 202 may access the Programming Language Element Library 206 to retrieve Element Definitions 300 of the programming language.
- Test Generator 202 in FIG. 3 has Element Definitions of the Type System 300 supported by the Compiler 204 to be tested or verified.
- the Element Definitions for the Type System 300 in FIG. 3 have Generic Types 302 , User Defined Types 302 , and Structures 304 .
- the Structures 304 of the programming language may contain the elements to be tested with the compiler.
- the Element Definitions 300 may define actions and expressions that are permitted in the programming language.
- An element may be a composite of one or more elements or sub-elements.
- a Test Generator 202 may employ the use of Expression and Action Factories 306 to create the Test Case Structure 314 with elements that comply with legal programming language expressions and actions for the programming language.
- the Expression and Action Factories 306 constrain the type and characteristics of the sub elements.
- Each Element Definition 300 may have the Element Syntax Rules, Element Semantic Rules, and Element Self-Code Generation Options.
- the Element Self-Code Generation Options may allow for the display of results of the test of a particular element of the programming language.
- the Test Generator 202 builds a Test Case Structure 314 using the Element Definitions 300 in the Programming Language Library 206 .
- the Test Case Structure 314 defines the test-case that will be generated by the Test Generator 202 .
- the Test Case Structure 314 is a hierarchical structure such as a tree. Each node of the tree is an element of the programming language and each child of the node is a sub-element of the element.
- the Test Generator 202 creates a syntactically correct test-case with the hierarchical creation of the Test Case Structure 314 using the rules provided in the Element Definition 300 . For example, a “plus” mathematic expression will have two operands required by the hierarchy.
- the Test Generator 202 is able to test the semantics of the programming language by using a Semantic Manager 310 .
- a Semantic Manager 310 has the Current Context 312 for the test case as it is being generated and constrains the elements of the tree to be semantically correct.
- Test Generator 202 in FIG. 3 has a Semantic Manager 310 with the current context data, including the current scope and methods 312 for the Test Case Structure 314 .
- a “plus” mathematic expression needs two operands as required by the hierarchy of the tree and the operands need to be of numeric type.
- the syntax language tree construction may be accomplished by recursively building layers of tree elements, where each element is responsible for the creation of its sub-tree using the Test Generator 202 which is aware of the context for the elements being created.
- Compiler testing consists of both legal and illegal tests as an input, so that syntactic/semantic error detection is provided as part of the testing process.
- self checking code segments may be created by each code element and inserted at different points, according to the semantic restrictions.
- the tests may be enhanced by random insertion of noise mechanisms such as Garbage Collection and other language neutral actions. For example, tests may allow for statements that intend to free unused memory (e.g. delete, free) or check the value of variable to ensure that the garbage collection statements did not corrupt the variable value.
- FIG. 4 is flowchart for an implementation of an automatic test generator for a compiler.
- a user may use the Test Generator API 200 to create a Programming Language Element Library 206 defining one or more elements of a programming language supported by a Compiler 204 with one or more constraints for the programming language ( 400 ).
- a test-case for the Compiler 204 is represented in a structure comprising one or more elements of the programming language ( 402 ).
- the Test Generator 202 steps through the elements in the structure to generate portions of the Test 208 (e.g. statements, actions, and expressions) that allow for checking the syntax of language either with legal or illegal test cases ( 404 ).
- portions of the Test 208 e.g. statements, actions, and expressions
- the Test Generator 202 Semantic Manager 310 enforces or allows for the creation of statements for semantic checks in the Test 208 for each element in the test case ( 406 ). For example, a test with a legal statement “print 2+2” after the statement “main( ) ⁇ ” and before “ ⁇ ” should pass compilation and evaluate the expression to be 4, and the Semantic Manager 310 may allow for the inclusion of the “print 2+2” in a legal test only after the “main( ) ⁇ ” statement has been included in the test.
- FIG. 5 illustrates an example of syntax language tree for an expression.
- the expression represented in the tree has a “+” operand element 500 that has two child or sub-elements, the “*” operand 502 and the “/” operand 504 .
- Operand element “*” 502 has child elements, “a” 506 and “b” 508 .
- Operand element 504 “/” has child elements, “c” 510 and “d” 512 .
- Each of the mathematical operand elements “+”, “/” and “*” in FIG. 5 have semantic rules that are associated with the elements. The semantic rules of the mathematical operands require that the elements or sub-elements of the operand elements to be numeric expressions.
- the Semantic Manager 310 may be set at node 500 to have context data that indicates the need for a numeric expression to result from the expressions “a*b” and “c/d.”
- the test can be created to check to ensure that a, b, c, and d are numeric expressions.
- the test can require the variables be checked as having a numeric value.
- FIG. 6 is a block diagram of an implementation of an automatic test generator for a compiler.
- the Test Generator 202 manages the automatic generation of syntactic-semantic self-checking tests.
- the programming language supported by the Compiler 204 to be tested is defined by Element Definitions 300 from a Programming Language Library 206 .
- the common testing coverage for programming language verification, such as the language datatypes, actions, expressions and code contexts are encapsulated in the Element Definitions 300 .
- Each Element Definition 300 may contain a self-check routine which is meant to be independent of the Test-Case Structure 312 .
- the self-check routine is an external implementation for a check of the functionality of the element under test.
- the element code creation and the element self-check routine there is no dependency between the element code creation and the element self-check routine.
- the check of the functionality of an element is not coupled with its code appearance and yet can allow for defect detection. For example, a print statement for the value of an expression can be indicated in the results for a test.
- the Test-Plan Parser 600 is an optional component of automatic test generation that allows the user to specify concrete aspects of the language to test and is useful when adding or changing an element in the language.
- the Test-Plan Parser may allow the user to define the coverage demands of a set of tests. By default, the requested coverage may be all the permutations of the defined elements.
- the Test Plan Parser 600 may allow the user to specify the test of define corner cases of a programming language. For example, all datatypes that may appear in print actions may be designated by the user as a set of elements of the programming language to test. Often it is difficult to randomly create tests for interesting features of an action or an expression. For example, it may be useful to the user to check the assignment of negative number to an unsigned numeric type variable.
- the user may want to specify that the tests include particular input datatypes, actions, expressions, or contexts. For example, the user may desire to check that an assignment of a variable is correct in an “if” action statement and a “for” action statement.
- the Code Coverage 602 is an optional component that may pass on the generated test-case syntax tree to collect information on the created elements and their dependencies with other elements. The generated tests can then be checked for their coverage of the programming language in the Analyzer 604 .
- the Analyzer 604 is responsible for managing the executed tests.
- the Analyzer 604 may receive the executed tests from the Runner and catalogues them in a database.
- the Analyzer 604 may report on the pass or failure of a test, and sort the tests and test results.
- the Runner 606 is a connection with an external application that is responsible for compiling and running the tests.
- the runner may be as simple as running a shell command or use a more complex interface.
- the tests may be stored for later regression testing in Regression 610 test storage.
- the Regression test storage may be a database.
- FIG. 7 is a block diagram of an illustrative computing system 1400 suitable for implementing an embodiment of the present invention.
- Computer system 1400 includes a bus 1406 or other communication mechanism for communicating information, which interconnects subsystems and devices, such as processor 1407 , system memory 1408 (e.g., RAM), static storage device 1409 (e.g., ROM), disk drive 1410 (e.g., magnetic or optical), communication interface 1414 (e.g., modem or Ethernet card), display 1411 (e.g., CRT or LCD), input device 1412 (e.g., keyboard), and cursor control.
- processor 1407 e.g., system memory 1408 (e.g., RAM), static storage device 1409 (e.g., ROM), disk drive 1410 (e.g., magnetic or optical), communication interface 1414 (e.g., modem or Ethernet card), display 1411 (e.g., CRT or LCD), input device 1412 (e.g., keyboard), and cursor control.
- computer system 1400 performs specific operations by processor 1407 executing one or more sequences of one or more instructions contained in system memory 1408 .
- Such instructions may be read into system memory 1408 from another computer readable/usable medium, such as static storage device 1409 or disk drive 1410 .
- static storage device 1409 or disk drive 1410 may be used in place of or in combination with software instructions to implement the invention.
- hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention.
- embodiments of the invention are not limited to any specific combination of hardware circuitry and/or software.
- the term “logic” shall mean any combination of software or hardware that is used to implement all or part of the invention.
- Non-volatile media includes, for example, optical or magnetic disks, such as disk drive 1410 .
- Volatile media includes dynamic memory, such as system memory 1408 .
- Computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
- execution of the sequences of instructions to practice the invention is performed by a single computer system 1400 .
- two or more computer systems 1400 coupled by communication link 1415 may perform the sequence of instructions required to practice the invention in coordination with one another.
- Computer system 1400 may transmit and receive messages, data, and instructions, including program, i.e., application code, through communication link 1415 and communication interface 1414 .
- Received program code may be executed by processor 1407 as it is received, and/or stored in disk drive 1410 , or other non-volatile storage for later execution.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
Description
- The present invention relates to software verification.
- The goal of software verification is to ensure that error free software has been produced and is an essential part of software development. Software verification is generally accomplished with “Black-Box Testing.” Black-Box Testing consists of activating a software application with a set of inputs or test-cases, and comparing the output produced by the software application to the expected output from the software application. To ensure that a software application is error free, a set of possible test-cases are created for the software application and used to activate the software application under test with the test-cases. Large scale software applications tend to require a vast number of test-cases with an infinite number of permutations of inputs. However, it is often impractical for one to manually create a set of all possible inputs and permutations of inputs for the test-cases, and therefore, automatic verification is a preferred approach for testing large scale software applications.
- A compiler is a computer program that translates a high level programming language, such as C++ or Java, into a lower level language, such as machine code, assembly, or an intermediate bytecode form that can run on a virtual machine. A compiler checks for errors in the input program files that are to be translated by the compiler. When a compiler discovers an error in the input program file that is being compiled, the compiler may indicate both the error and the occurrence of an error during the compilation. When a compiler successfully translates the input file, an executable is generated.
- A compiler is verified by compiling a set of programs or test-cases with the compiler, and comparing the output from the compiler with the expected output of the compiler. Theoretically, a complete verification of a compiler requires a set of all possible test-cases. However, there are an infinite number of computer programs that can be compiled such that a complete verification of a compiler is unachievable. A practical approach for compiler verification is to create output producing test-cases that contain all words in the high level programming language and all the possible combinations of the words or statements in the language. The verification of all the words, elements, and statements, defined as a combination of elements in a programming language, of a programming language is referred to as checking the “syntax.” Verification of a compilers' ability to handle the syntax of a programming language alone is insufficient because the compiler must handle the semantic constraints of the programming language.
- The semantics of a programming language takes in to consideration the context, the surrounding statements or environment for the statement or element in the program. For example, it is possible that an action or statement may be correct within a loop construct in the language but the same action or statement may be incorrect within a conditional “if” statement construct. Semantics are an important part of a high level programming language because the sentences or statements in the program are dependent upon each other. For example, in some high level programming languages, the statement “x=5;” cannot be written in the program without first declaring “int x;” in the program. Such semantic checks are called “Static Semantics.” In some programming languages, the statement “x=y/z” cannot be written when ‘z’ is equal to zero. These types of checks are “Dynamic Semantics” checks because the checks involve evaluation rules of the language.
- Compiler verification is done by compiling and running test-cases with predicted run results and comparing them to the actual run results at the end. Compiler verification must contain both legal and illegal test-cases for complete verification of the ability for the compiler to handle the syntax and semantics of the high level programming language. Illegal test-cases may be input to the compiler in order to verify the error-handling ability of the compiler. Legal test-cases may be input to the compiler to test the compiler's ability to generate and executable. As a result, complete compiler verification may require tens of thousands of test-cases to cover every possible test-case.
- An approach for compiler verification is the manual creation of program files and an expected output file corresponding to each program file. Approaches involving manual creation of test-cases may not handle all the relevant cases and make it difficult to handle updates of the programming language because the programs and expected output files must be manually altered. Obviously, the large amount of possible test-cases makes it impossible for human to cover all the scenarios.
- Automation of compiler verification, involving the generation of test-cases, that is capable of programming meaningful test-cases with algorithms that mimic those created by a programmer of a high level language in order to test the semantics of the programming language requires an extremely high level of Artificial Intelligence (AI). The complexity involved in developing such an AI solution for compiler verification makes such an approach infeasible. Yet, testing a compiler without semantic checks on meaningful test cases does not allow for an accurate verification of the compiler. Thus, the ability to automate compiler verification would significantly increase the verification quality, while reducing the time it consumes.
- A method, system, and computer program product are disclosed for automatic test generation for a compiler. In one approach, the method, system and computer program product represent a test case for the compiler in a structure with one or more elements of a programming language, associate at least one syntactic rule and semantic rule with the one or more elements in the structure, create a test with the structure compiling the test with the compiler, and display results of the test.
- The invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
-
FIG. 1 is a flowchart for an implementation of an automatic test generator of a compiler. -
FIG. 2 is a block diagram of the functionality of an automatic test generator for a compiler. -
FIG. 3 is a block diagram of a test generator. -
FIG. 4 is flowchart for an implementation of an automatic test generator for a compiler. -
FIG. 5 illustrates an example of syntax language tree. -
FIG. 6 is a block diagram of an implementation of an automatic test generator for a compiler. -
FIG. 7 is a block diagram of an architecture that can support implementation of an automatic test generator for a compiler. - The present invention is directed toward methods, systems, and computer program products for automatic generation of compiler tests.
- Embodiments of the present invention implement automatic generation of compiler tests in order to verify the compiler. A test for a compiler is a computer program, source code, or portion of a computer program written in the programming language supported by the compiler. The automatic test generator creates tests for a compiler with test-cases that cover the interesting semantic and syntactic scenarios supported by the programming language.
-
FIG. 1 is a flowchart for an implementation of an automatic test generator for a compiler. Initially, a test-case for a compiler is represented in a structure comprising one or more elements of a programming language (100). The programming language elements in the test-case may be randomly selected or the user may designate an aspect of the programming language that the user desires to test. The user may designate the test of elements supported by the language, such as classes, if-then statement, for loops, templates, and structs. In one or more embodiments, the compiler verification may be implemented for the e programming language, and the user may designate the test of elements of the language, such as aspect oriented structs, method extensions, and computed macros. The language elements may be expressions or actions supported by the programming language, and each element may be composed of one or more sub-elements that form the expression or action. For example, an action in a programming language may be an if-then statement and an expression may be a “<” or “less than” comparison. In one or more embodiments, the structure is a tree composed of nodes, with each node representing an element of the programming language in an expression or action. For example, the following if-then action statement “if (a<b) {println;}” would have a tree structure with nodes for elements of the action if-then statement and the expression “(a<b).” Those skilled in the art will recognize that any type of data structure may be implemented to represent the elements of the programming language supported by the compiler that is being verified. - Next, the syntactic and semantic rules for each element of the programming language are associated with the elements in the structure that correspond to the rules for the elements of the programming language (102). Each element of the structure may have rules that restrict the elements related to that particular element. Related elements are connected to the element in the hierarchical structure. In one or more embodiments, the structure is a syntax tree, a hierarchy of nodes or elements that abide by the syntax rules of the programming language. For example, a syntax tree is created by starting with a root node or element, and each element becomes responsible for creating its' own subtree. An element selects the syntactic properties of its' child nodes, such as the “+” element that may have two “expression” child nodes. The semantic manager may use the context information and semantic filters to create a legal instance of each element.
- The syntactic rules may be defined in a class definition for the element or node, and the semantic rules may be associated with the element or node when the element or node is instantiated with the class constructor during the creation of the tree or structure. When the syntax tree is created, the elements of the syntax tree may be instantiated with the class constructors for the elements in the class definition thereby associating the semantic rules with the elements of the syntax tree. In one or more embodiments, a semantic manager may associate the semantic rules with the elements of a syntax tree. A semantic manager may use the rules associated with each element to call methods that filter out illegal elements or sub-elements to be created for that element. In some embodiments, a semantic manager may be implemented with a factory design pattern. Each parent element may call the semantic manager associated with the parent element to filter or select legal sub-elements for the parent element.
- The tests for the compiler may then be created using the structure (104). Embodiments of the invention may create the test for the compiler by stepping through the elements in the structure and writing the necessary statements, lines of source code, or portions of statements in the test file for each of the elements in the structure. The statements written to the test file may be incorrect usage of the elements of the programming language in the structure to test the error handling of the compiler under test. Optionally, the elements may provide information on the statements that can be placed in the test files which can be displayed to the user to alert the user of the progress of the current generation of the test file.
- After the tests have been created, the tests may then be compiled with compiler (106), and the results from the compilation are indicated. The results may be displayed or stored for later access (108). In one or more embodiments, the test file may include statements that display the success or failure of the compilation of the test. Embodiments may generate tests that have statements within the test that allow for writing to standard error or an output file with the results of the compilation of the test. An output file may be used for comparison with an expected output file to verify the compiler in regards to the particular test.
-
FIG. 2 is a block diagram of the functionality for an approach for automatic test generator for a compiler. A Test Generator Application Programming Interface (API) 200 is provided for theTest Generator 202 to allow for the specification of the constraints of the programming language supported by theCompiler 204 to be tested. TheTest Generator 202 is described in detail below with the description ofFIG. 3 . A user may define the syntactic and semantic constraints of each element of the programming language supported by the compiler with theTest Generator API 200. The user defined syntactic and semantic constraints of the programming language can be stored in a ProgrammingLanguage Element Library 206. TheTest Generator 202 will use the definitions for the syntax and semantics of the elements of the programming language stored in the ProgrammingLanguage Element Library 206 to represent a test-case for theCompiler 204. TheTest Generator 202 may be used to create one ormore Tests 208, programs in the programming language supported by the compiler, for theCompiler 204. TheTests 208 are used as input for theCompiler 204 and theResults 210 for theTests 208 are indicated to the user. TheResults 210 may be made available by displaying the results to the user or storing theResults 210 in a database. -
FIG. 3 is a block diagram of an approach for implementation of a Test Generator. TheTest Generator 202 may access the ProgrammingLanguage Element Library 206 to retrieveElement Definitions 300 of the programming language. By way of illustration,Test Generator 202 inFIG. 3 has Element Definitions of theType System 300 supported by theCompiler 204 to be tested or verified. Those skilled in the art will recognize that the Type System is an example and that other aspects of a programming language may be tested with the automatic compiler verification approach. The Element Definitions for theType System 300 inFIG. 3 haveGeneric Types 302, User DefinedTypes 302, andStructures 304. TheStructures 304 of the programming language may contain the elements to be tested with the compiler. - The
Element Definitions 300 may define actions and expressions that are permitted in the programming language. An element may be a composite of one or more elements or sub-elements. ATest Generator 202 may employ the use of Expression andAction Factories 306 to create the Test Case Structure 314 with elements that comply with legal programming language expressions and actions for the programming language. The Expression andAction Factories 306 constrain the type and characteristics of the sub elements. EachElement Definition 300 may have the Element Syntax Rules, Element Semantic Rules, and Element Self-Code Generation Options. The Element Self-Code Generation Options may allow for the display of results of the test of a particular element of the programming language. TheTest Generator 202 builds a Test Case Structure 314 using theElement Definitions 300 in theProgramming Language Library 206. The Test Case Structure 314 defines the test-case that will be generated by theTest Generator 202. - In one or more embodiments, the Test Case Structure 314 is a hierarchical structure such as a tree. Each node of the tree is an element of the programming language and each child of the node is a sub-element of the element. The
Test Generator 202 creates a syntactically correct test-case with the hierarchical creation of the Test Case Structure 314 using the rules provided in theElement Definition 300. For example, a “plus” mathematic expression will have two operands required by the hierarchy. - In one or more embodiments, the
Test Generator 202 is able to test the semantics of the programming language by using aSemantic Manager 310. ASemantic Manager 310 has theCurrent Context 312 for the test case as it is being generated and constrains the elements of the tree to be semantically correct. By way of illustration,Test Generator 202 inFIG. 3 has aSemantic Manager 310 with the current context data, including the current scope andmethods 312 for the Test Case Structure 314. For example, a “plus” mathematic expression needs two operands as required by the hierarchy of the tree and the operands need to be of numeric type. Further, an operand that is a variable may need to be initialized to be of numeric type and the current scope may contain the information as to whether an operand is of numeric type and whether a variable has been initialized (e.g. int x; and int y; prior to the statement x=y+1;). The syntax language tree construction may be accomplished by recursively building layers of tree elements, where each element is responsible for the creation of its sub-tree using theTest Generator 202 which is aware of the context for the elements being created. - Compiler testing consists of both legal and illegal tests as an input, so that syntactic/semantic error detection is provided as part of the testing process. Based on the structure of the tree, self checking code segments may be created by each code element and inserted at different points, according to the semantic restrictions. The tests may be enhanced by random insertion of noise mechanisms such as Garbage Collection and other language neutral actions. For example, tests may allow for statements that intend to free unused memory (e.g. delete, free) or check the value of variable to ensure that the garbage collection statements did not corrupt the variable value.
-
FIG. 4 is flowchart for an implementation of an automatic test generator for a compiler. A user may use theTest Generator API 200 to create a ProgrammingLanguage Element Library 206 defining one or more elements of a programming language supported by aCompiler 204 with one or more constraints for the programming language (400). A test-case for theCompiler 204 is represented in a structure comprising one or more elements of the programming language (402). Next, theTest Generator 202 steps through the elements in the structure to generate portions of the Test 208 (e.g. statements, actions, and expressions) that allow for checking the syntax of language either with legal or illegal test cases (404). TheTest Generator 202Semantic Manager 310 enforces or allows for the creation of statements for semantic checks in theTest 208 for each element in the test case (406). For example, a test with a legal statement “print 2+2” after the statement “main( ){” and before “}” should pass compilation and evaluate the expression to be 4, and theSemantic Manager 310 may allow for the inclusion of the “print 2+2” in a legal test only after the “main( ){” statement has been included in the test. -
FIG. 5 illustrates an example of syntax language tree for an expression. In the syntax language tree ofFIG. 5 , the expression represented in the tree has a “+”operand element 500 that has two child or sub-elements, the “*”operand 502 and the “/”operand 504. Operand element “*” 502 has child elements, “a” 506 and “b” 508.Operand element 504 “/” has child elements, “c” 510 and “d” 512. Each of the mathematical operand elements “+”, “/” and “*” inFIG. 5 have semantic rules that are associated with the elements. The semantic rules of the mathematical operands require that the elements or sub-elements of the operand elements to be numeric expressions. When a test is created from the test case represented in the tree structure ofFIG. 5 , theSemantic Manager 310 may be set atnode 500 to have context data that indicates the need for a numeric expression to result from the expressions “a*b” and “c/d.” As a result, the test can be created to check to ensure that a, b, c, and d are numeric expressions. For example the test can require the variables be checked as having a numeric value. -
FIG. 6 is a block diagram of an implementation of an automatic test generator for a compiler. TheTest Generator 202 manages the automatic generation of syntactic-semantic self-checking tests. The programming language supported by theCompiler 204 to be tested is defined byElement Definitions 300 from aProgramming Language Library 206. The common testing coverage for programming language verification, such as the language datatypes, actions, expressions and code contexts are encapsulated in theElement Definitions 300. EachElement Definition 300 may contain a self-check routine which is meant to be independent of the Test-Case Structure 312. The self-check routine is an external implementation for a check of the functionality of the element under test. In some embodiments, there is no dependency between the element code creation and the element self-check routine. The check of the functionality of an element is not coupled with its code appearance and yet can allow for defect detection. For example, a print statement for the value of an expression can be indicated in the results for a test. - The Test-
Plan Parser 600 is an optional component of automatic test generation that allows the user to specify concrete aspects of the language to test and is useful when adding or changing an element in the language. The Test-Plan Parser may allow the user to define the coverage demands of a set of tests. By default, the requested coverage may be all the permutations of the defined elements. In one or more embodiments, theTest Plan Parser 600 may allow the user to specify the test of define corner cases of a programming language. For example, all datatypes that may appear in print actions may be designated by the user as a set of elements of the programming language to test. Often it is difficult to randomly create tests for interesting features of an action or an expression. For example, it may be useful to the user to check the assignment of negative number to an unsigned numeric type variable. The user may want to specify that the tests include particular input datatypes, actions, expressions, or contexts. For example, the user may desire to check that an assignment of a variable is correct in an “if” action statement and a “for” action statement. - The
Code Coverage 602 is an optional component that may pass on the generated test-case syntax tree to collect information on the created elements and their dependencies with other elements. The generated tests can then be checked for their coverage of the programming language in theAnalyzer 604. - The
Analyzer 604 is responsible for managing the executed tests. TheAnalyzer 604 may receive the executed tests from the Runner and catalogues them in a database. TheAnalyzer 604 may report on the pass or failure of a test, and sort the tests and test results. - The
Runner 606 is a connection with an external application that is responsible for compiling and running the tests. The runner may be as simple as running a shell command or use a more complex interface. - The tests may be stored for later regression testing in
Regression 610 test storage. In one or more embodiments, the Regression test storage may be a database. - In the following description, numerous details are set forth for purpose of explanation. However, one of ordinary skill in the art will realize that various embodiments of the invention may be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of various embodiments of the invention with unnecessary detail.
-
FIG. 7 is a block diagram of anillustrative computing system 1400 suitable for implementing an embodiment of the present invention.Computer system 1400 includes abus 1406 or other communication mechanism for communicating information, which interconnects subsystems and devices, such asprocessor 1407, system memory 1408 (e.g., RAM), static storage device 1409 (e.g., ROM), disk drive 1410 (e.g., magnetic or optical), communication interface 1414 (e.g., modem or Ethernet card), display 1411 (e.g., CRT or LCD), input device 1412 (e.g., keyboard), and cursor control. - According to one embodiment of the invention,
computer system 1400 performs specific operations byprocessor 1407 executing one or more sequences of one or more instructions contained insystem memory 1408. Such instructions may be read intosystem memory 1408 from another computer readable/usable medium, such asstatic storage device 1409 ordisk drive 1410. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and/or software. In one embodiment, the term “logic” shall mean any combination of software or hardware that is used to implement all or part of the invention. - The term “computer readable medium” or “computer usable medium” as used herein refers to any medium that participates in providing instructions to
processor 1407 for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such asdisk drive 1410. Volatile media includes dynamic memory, such assystem memory 1408. - Common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
- In an embodiment of the invention, execution of the sequences of instructions to practice the invention is performed by a
single computer system 1400. According to other embodiments of the invention, two ormore computer systems 1400 coupled by communication link 1415 (e.g., LAN, PTSN, or wireless network) may perform the sequence of instructions required to practice the invention in coordination with one another. -
Computer system 1400 may transmit and receive messages, data, and instructions, including program, i.e., application code, through communication link 1415 andcommunication interface 1414. Received program code may be executed byprocessor 1407 as it is received, and/or stored indisk drive 1410, or other non-volatile storage for later execution. - In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. For example, the above-described process flows are described with reference to a particular ordering of process actions. However, the ordering of many of the described process actions may be changed without affecting the scope or operation of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense.
Claims (15)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/966,834 US8156474B2 (en) | 2007-12-28 | 2007-12-28 | Automation of software verification |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/966,834 US8156474B2 (en) | 2007-12-28 | 2007-12-28 | Automation of software verification |
Publications (2)
Publication Number | Publication Date |
---|---|
US20090172649A1 true US20090172649A1 (en) | 2009-07-02 |
US8156474B2 US8156474B2 (en) | 2012-04-10 |
Family
ID=40800283
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/966,834 Expired - Fee Related US8156474B2 (en) | 2007-12-28 | 2007-12-28 | Automation of software verification |
Country Status (1)
Country | Link |
---|---|
US (1) | US8156474B2 (en) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100076742A1 (en) * | 2008-09-23 | 2010-03-25 | Atmel Corporation | Simulation model for transistors |
US20100186003A1 (en) * | 2009-01-22 | 2010-07-22 | Microsoft Corporation | Per Group Verification |
US20120226465A1 (en) * | 2011-03-04 | 2012-09-06 | International Business Machines Corporation | Method, program, and system for generating test cases |
US20140123109A1 (en) * | 2012-10-30 | 2014-05-01 | Oracle International Corporation | System and method for testing compiler implementation using dynamic combinatorial test generation |
US20150324274A1 (en) * | 2014-05-09 | 2015-11-12 | Wipro Limited | System and method for creating universal test script for testing variants of software application |
US20170004617A1 (en) * | 2015-06-30 | 2017-01-05 | Hon Hai Precision Industry Co., Ltd | Electronic device and mehod for capturing multi-aspect images using the electronic device |
US20170068609A1 (en) * | 2014-02-26 | 2017-03-09 | Western Michigan University Research Foundation | Apparatus and method for testing computer program implementation against a design model |
US9928042B2 (en) * | 2015-09-28 | 2018-03-27 | Semmle Limited | Automatic classification of compilers |
CN113238937A (en) * | 2021-05-11 | 2021-08-10 | 西北大学 | Compiler fuzzy test method based on code compaction and false alarm filtering |
US20210406448A1 (en) * | 2019-02-25 | 2021-12-30 | Allstate Insurance Company | Systems and methods for automated code validation |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101246486B (en) * | 2007-02-13 | 2012-02-01 | 国际商业机器公司 | Method and apparatus for improved process of expressions |
US9280439B2 (en) * | 2011-02-11 | 2016-03-08 | Sap Se | Usage analysis of productive environment to establish new data source for process optimization and project planning |
US8972928B2 (en) * | 2011-08-30 | 2015-03-03 | Uniquesoft, Llc | System and method for generating application code |
WO2015041575A1 (en) * | 2013-09-23 | 2015-03-26 | Сергей Михайлович НАЗАРОВ | Method for generating syntactically and semantically correct commands |
RU2534823C1 (en) * | 2013-09-23 | 2014-12-10 | Сергей Михайлович Назаров | Method of generating syntactically and semantically correct commands |
CN105354035A (en) * | 2015-11-17 | 2016-02-24 | 天津橙子科技有限公司 | Method for compiling test case of web engineering |
CN107741911A (en) * | 2017-11-01 | 2018-02-27 | 广州爱九游信息技术有限公司 | Interface test method, device, client and computer-readable recording medium |
FR3074931B1 (en) * | 2017-12-13 | 2020-01-03 | Vsora | PROCESSOR ARCHITECTURES |
US10437572B1 (en) | 2018-08-03 | 2019-10-08 | King Fahd University Of Petroleum And Minerals | Methods, computer readable media, and systems for compiling concise expressive design pattern source code |
Citations (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4802091A (en) * | 1986-10-31 | 1989-01-31 | International Business Machines Corporation | Method for improving the efficiency of arithmetic code generation in an optimizing compiler using the technique of reassociation |
US5325533A (en) * | 1993-06-28 | 1994-06-28 | Taligent, Inc. | Engineering system for modeling computer programs |
US5452457A (en) * | 1993-01-29 | 1995-09-19 | International Business Machines Corporation | Program construct and methods/systems for optimizing assembled code for execution |
US5655073A (en) * | 1994-06-22 | 1997-08-05 | Hitachi, Ltd. | Debugging method and debugger |
US5774726A (en) * | 1995-04-24 | 1998-06-30 | Sun Microsystems, Inc. | System for controlled generation of assembly language instructions using assembly language data types including instruction types in a computer language as input to compiler |
US5838948A (en) * | 1995-12-01 | 1998-11-17 | Eagle Design Automation, Inc. | System and method for simulation of computer systems combining hardware and software interaction |
US6029262A (en) * | 1997-11-25 | 2000-02-22 | Mosaid Technologies Incorporated | Graphical editor for defining memory test sequences |
US6038378A (en) * | 1993-07-29 | 2000-03-14 | Digital Esquipment Corporation | Method and apparatus for testing implementations of software specifications |
US6161217A (en) * | 1998-09-14 | 2000-12-12 | Sun Microsystems, Inc. | Accurate method for inlining virtual calls |
US6182258B1 (en) * | 1997-06-03 | 2001-01-30 | Verisity Ltd. | Method and apparatus for test generation during circuit design |
US6321376B1 (en) * | 1997-10-27 | 2001-11-20 | Ftl Systems, Inc. | Apparatus and method for semi-automated generation and application of language conformity tests |
US6550057B1 (en) * | 1999-08-31 | 2003-04-15 | Accenture Llp | Piecemeal retrieval in an information services patterns environment |
US20040216023A1 (en) * | 1999-06-08 | 2004-10-28 | Verisity Ltd. | Method and apparatus for maximizing and managing test coverage |
US20040243984A1 (en) * | 2001-06-20 | 2004-12-02 | Martin Vorbach | Data processing method |
US20050039079A1 (en) * | 2003-02-14 | 2005-02-17 | Shinsaku Higashi | Test emulator, test module emulator, and record medium storing program therein |
US20050165597A1 (en) * | 2004-01-27 | 2005-07-28 | Arm Limited | Apparatus and method for performing hardware and software co-verification testing |
US20050246693A1 (en) * | 2003-09-15 | 2005-11-03 | Plum Thomas S | Automated safe secure techniques for eliminating undefined behavior in computer software |
US7000224B1 (en) * | 2000-04-13 | 2006-02-14 | Empirix Inc. | Test code generator, engine and analyzer for testing middleware applications |
US7051303B1 (en) * | 2003-12-29 | 2006-05-23 | Sun Microsystems, Inc. | Method and apparatus for detection and isolation during large scale circuit verification |
US20070277130A1 (en) * | 2003-12-03 | 2007-11-29 | Evan Lavelle | System and method for architecture verification |
US20080215768A1 (en) * | 2006-10-24 | 2008-09-04 | Alastair David Reid | Variable coherency support when mapping a computer program to a data processing apparatus |
US20080271001A1 (en) * | 2006-09-11 | 2008-10-30 | Yo Nonomura | Method of generating program, information processing device and microcomputer |
US20090125882A1 (en) * | 2007-10-08 | 2009-05-14 | Matteo Frigo | Method of implementing hyperobjects in a parallel processing software programming environment |
US7681184B1 (en) * | 2004-05-24 | 2010-03-16 | Borland Software Corporation | System and methodology for cross language type system compatibility |
US7689973B2 (en) * | 2005-05-23 | 2010-03-30 | Alcatel-Lucent Usa Inc. | Language for development of test harness files |
US7702958B2 (en) * | 2005-05-24 | 2010-04-20 | Alcatel-Lucent Usa Inc. | Auto-recording tool for developing test harness files |
US7810081B2 (en) * | 2006-08-22 | 2010-10-05 | International Business Machines Corporation | Compilation error isolation, optimization and resolution |
-
2007
- 2007-12-28 US US11/966,834 patent/US8156474B2/en not_active Expired - Fee Related
Patent Citations (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4802091A (en) * | 1986-10-31 | 1989-01-31 | International Business Machines Corporation | Method for improving the efficiency of arithmetic code generation in an optimizing compiler using the technique of reassociation |
US5452457A (en) * | 1993-01-29 | 1995-09-19 | International Business Machines Corporation | Program construct and methods/systems for optimizing assembled code for execution |
US5530964A (en) * | 1993-01-29 | 1996-06-25 | International Business Machines Corporation | Optimizing assembled code for execution using execution statistics collection, without inserting instructions in the code and reorganizing the code based on the statistics collected |
US5325533A (en) * | 1993-06-28 | 1994-06-28 | Taligent, Inc. | Engineering system for modeling computer programs |
US6038378A (en) * | 1993-07-29 | 2000-03-14 | Digital Esquipment Corporation | Method and apparatus for testing implementations of software specifications |
US5655073A (en) * | 1994-06-22 | 1997-08-05 | Hitachi, Ltd. | Debugging method and debugger |
US5774726A (en) * | 1995-04-24 | 1998-06-30 | Sun Microsystems, Inc. | System for controlled generation of assembly language instructions using assembly language data types including instruction types in a computer language as input to compiler |
US5838948A (en) * | 1995-12-01 | 1998-11-17 | Eagle Design Automation, Inc. | System and method for simulation of computer systems combining hardware and software interaction |
US6182258B1 (en) * | 1997-06-03 | 2001-01-30 | Verisity Ltd. | Method and apparatus for test generation during circuit design |
US6347388B1 (en) * | 1997-06-03 | 2002-02-12 | Verisity Ltd. | Method and apparatus for test generation during circuit design |
US20020073375A1 (en) * | 1997-06-03 | 2002-06-13 | Yoav Hollander | Method and apparatus for test generation during circuit design |
US6321376B1 (en) * | 1997-10-27 | 2001-11-20 | Ftl Systems, Inc. | Apparatus and method for semi-automated generation and application of language conformity tests |
US6029262A (en) * | 1997-11-25 | 2000-02-22 | Mosaid Technologies Incorporated | Graphical editor for defining memory test sequences |
US6161217A (en) * | 1998-09-14 | 2000-12-12 | Sun Microsystems, Inc. | Accurate method for inlining virtual calls |
US20040216023A1 (en) * | 1999-06-08 | 2004-10-28 | Verisity Ltd. | Method and apparatus for maximizing and managing test coverage |
US6550057B1 (en) * | 1999-08-31 | 2003-04-15 | Accenture Llp | Piecemeal retrieval in an information services patterns environment |
US7000224B1 (en) * | 2000-04-13 | 2006-02-14 | Empirix Inc. | Test code generator, engine and analyzer for testing middleware applications |
US20040243984A1 (en) * | 2001-06-20 | 2004-12-02 | Martin Vorbach | Data processing method |
US7657877B2 (en) * | 2001-06-20 | 2010-02-02 | Pact Xpp Technologies Ag | Method for processing data |
US20080016396A1 (en) * | 2003-02-14 | 2008-01-17 | Advantest Corporation | Test emulator, test module emulator and record medium storing program therein |
US20050039079A1 (en) * | 2003-02-14 | 2005-02-17 | Shinsaku Higashi | Test emulator, test module emulator, and record medium storing program therein |
US20050246693A1 (en) * | 2003-09-15 | 2005-11-03 | Plum Thomas S | Automated safe secure techniques for eliminating undefined behavior in computer software |
US20070277130A1 (en) * | 2003-12-03 | 2007-11-29 | Evan Lavelle | System and method for architecture verification |
US7051303B1 (en) * | 2003-12-29 | 2006-05-23 | Sun Microsystems, Inc. | Method and apparatus for detection and isolation during large scale circuit verification |
US20050165597A1 (en) * | 2004-01-27 | 2005-07-28 | Arm Limited | Apparatus and method for performing hardware and software co-verification testing |
US7681184B1 (en) * | 2004-05-24 | 2010-03-16 | Borland Software Corporation | System and methodology for cross language type system compatibility |
US7689973B2 (en) * | 2005-05-23 | 2010-03-30 | Alcatel-Lucent Usa Inc. | Language for development of test harness files |
US7702958B2 (en) * | 2005-05-24 | 2010-04-20 | Alcatel-Lucent Usa Inc. | Auto-recording tool for developing test harness files |
US7810081B2 (en) * | 2006-08-22 | 2010-10-05 | International Business Machines Corporation | Compilation error isolation, optimization and resolution |
US20080271001A1 (en) * | 2006-09-11 | 2008-10-30 | Yo Nonomura | Method of generating program, information processing device and microcomputer |
US20080215768A1 (en) * | 2006-10-24 | 2008-09-04 | Alastair David Reid | Variable coherency support when mapping a computer program to a data processing apparatus |
US20090125882A1 (en) * | 2007-10-08 | 2009-05-14 | Matteo Frigo | Method of implementing hyperobjects in a parallel processing software programming environment |
Non-Patent Citations (2)
Title |
---|
Title: Automatic generation of provably correct parallelizing compilers, author: Gupta, G, source: IEEE, dated: 8/10/1998 * |
Title: Random program generator for Java JIT compiler test system, author:Yoshikawa, T, source: IEEE, dated: 11/6/2003 * |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8099270B2 (en) * | 2008-09-23 | 2012-01-17 | Atmel Corporation | Simulation model for transistors |
US20100076742A1 (en) * | 2008-09-23 | 2010-03-25 | Atmel Corporation | Simulation model for transistors |
US8826238B2 (en) * | 2009-01-22 | 2014-09-02 | Microsoft Corporation | Per group verification |
US20100186003A1 (en) * | 2009-01-22 | 2010-07-22 | Microsoft Corporation | Per Group Verification |
US9465724B2 (en) * | 2011-03-04 | 2016-10-11 | International Business Machines Corporation | Method, program, and system for generating test cases |
US20120226465A1 (en) * | 2011-03-04 | 2012-09-06 | International Business Machines Corporation | Method, program, and system for generating test cases |
US20120330598A1 (en) * | 2011-03-04 | 2012-12-27 | International Business Machines Corporation | Method, program, and system for generating test cases |
US9483385B2 (en) * | 2011-03-04 | 2016-11-01 | International Business Machines Corporation | Method, program, and system for generating test cases |
US9542166B2 (en) | 2012-10-30 | 2017-01-10 | Oracle International Corporation | System and method for inferring immutability of program variables |
US20140123109A1 (en) * | 2012-10-30 | 2014-05-01 | Oracle International Corporation | System and method for testing compiler implementation using dynamic combinatorial test generation |
US9733907B2 (en) * | 2012-10-30 | 2017-08-15 | Oracle International Corporation | System and method for testing compiler implementation using dynamic combinatorial test generation |
US20170068609A1 (en) * | 2014-02-26 | 2017-03-09 | Western Michigan University Research Foundation | Apparatus and method for testing computer program implementation against a design model |
US9983977B2 (en) * | 2014-02-26 | 2018-05-29 | Western Michigan University Research Foundation | Apparatus and method for testing computer program implementation against a design model |
US20150324274A1 (en) * | 2014-05-09 | 2015-11-12 | Wipro Limited | System and method for creating universal test script for testing variants of software application |
US9753842B2 (en) * | 2014-05-09 | 2017-09-05 | Wipro Limited | System and method for creating universal test script for testing variants of software application |
US20170004617A1 (en) * | 2015-06-30 | 2017-01-05 | Hon Hai Precision Industry Co., Ltd | Electronic device and mehod for capturing multi-aspect images using the electronic device |
US9928042B2 (en) * | 2015-09-28 | 2018-03-27 | Semmle Limited | Automatic classification of compilers |
US20210406448A1 (en) * | 2019-02-25 | 2021-12-30 | Allstate Insurance Company | Systems and methods for automated code validation |
CN113238937A (en) * | 2021-05-11 | 2021-08-10 | 西北大学 | Compiler fuzzy test method based on code compaction and false alarm filtering |
Also Published As
Publication number | Publication date |
---|---|
US8156474B2 (en) | 2012-04-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8156474B2 (en) | Automation of software verification | |
Burdy et al. | Java applet correctness: A developer-oriented approach | |
Kästner et al. | Type checking annotation-based product lines | |
Richters et al. | OCL: Syntax, semantics, and tools | |
Cok et al. | ESC/Java2: Uniting ESC/Java and JML: Progress and issues in building and using ESC/Java2, including a case study involving the use of the tool to verify portions of an Internet voting tally system | |
US6851107B1 (en) | Software development tool with instant updating and simultaneous view of graphical and a textual display of source code | |
Hou et al. | Using SCL to specify and check design intent in source code | |
US20060075305A1 (en) | Method and system for source-code model-based testing | |
US20110022551A1 (en) | Methods and systems for generating software quality index | |
US20070033440A1 (en) | Parameterized unit tests | |
US20020112225A1 (en) | Methods and systems for animating the interaction of objects in an object oriented program | |
Felgentreff et al. | Babelsberg: Specifying and solving constraints on object behavior | |
Crocker | Safe object-oriented software: the verified design-by-contract paradigm | |
Córdoba-Sánchez et al. | Ann: A domain-specific language for the effective design and validation of Java annotations | |
Anand | Techniques to facilitate symbolic execution of real-world programs | |
Jörges et al. | Back-to-back testing of model-based code generators | |
Lourenço et al. | OSTRICH: a rich template language for low-code development (extended version) | |
Kulcsár et al. | Case Study: object-oriented refactoring of Java programs using graph transformation | |
Paige et al. | Specification-driven design with Eiffel and agents for teaching lightweight formal methods | |
Yiu | Checkstyle for Legacy Applications [J] | |
Husseini Orabi et al. | Umple-TL: A Model-Oriented, Dependency-Free Text Emission Tool | |
Jung | Generator-composition for aspect-oriented domain-specific languages | |
Jula et al. | An Executable Specification of C♯ | |
Buuren | Domain-specific language testing framework | |
Almaghthawi | Model-driven testing in Umple |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CADENCE DESIGN SYSTEMS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TEPLITSKY, MARAT;OVADIA, MEIR;GRADOVICH, NOA;REEL/FRAME:020874/0629 Effective date: 20080427 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
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: 20200410 |