WO2007014521A1 - Procede permettant de concevoir un scenario d'essai et systeme correspondant - Google Patents

Procede permettant de concevoir un scenario d'essai et systeme correspondant Download PDF

Info

Publication number
WO2007014521A1
WO2007014521A1 PCT/CN2006/001899 CN2006001899W WO2007014521A1 WO 2007014521 A1 WO2007014521 A1 WO 2007014521A1 CN 2006001899 W CN2006001899 W CN 2006001899W WO 2007014521 A1 WO2007014521 A1 WO 2007014521A1
Authority
WO
WIPO (PCT)
Prior art keywords
branch
test case
condition
target
path
Prior art date
Application number
PCT/CN2006/001899
Other languages
English (en)
French (fr)
Inventor
Tong Wang
Original Assignee
Tong Wang
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Tong Wang filed Critical Tong Wang
Publication of WO2007014521A1 publication Critical patent/WO2007014521A1/zh

Links

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 the field of software testing, and more particularly to a test case design method and a test case design system in the field of software testing. Background technique
  • the software testing methods mainly include black box testing and white box testing.
  • the black box test is also called the function test, and the test case is generally designed according to the functional requirements of the program.
  • the white box test is based on the internal logic structure of the program, and the test coverage is generally designed using the logic overlay method.
  • Test Case There is currently no classic definition. A test case is generally a test task that executes the test program under the set conditions. There are no uniform standards for describing test cases. They can be broadly divided into two categories: non-executable test cases and executable test cases. Non-executable test cases use words, tables, or other means to describe program functions or related data.
  • Scope, etc. generally used as a specification for testing or as a basis for further writing executable test cases; executable test cases are code and data that can be compiled or interpreted, or stored in a canonical format in a spreadsheet, database, etc. Data that can be used to generate executable code.
  • the common logical overlays for white box testing are: statement coverage, decision coverage, expression coverage, condition coverage, decision condition coverage, condition value combination coverage, and path coverage, which are defined as follows:
  • Expression Overlay Design enough test cases to calculate each condition for each decision at least once.
  • Conditional Coverage (Conditional Value Coverage): Design enough test cases to have all possible values for each condition of each decision performed at least once.
  • Decision Condition Coverage Design enough test cases to have all possible values for each condition in each decision be executed at least once. At the same time, the determined true branch and the fake branch are experienced at least once.
  • Conditional Combination Coverage (Conditional Value Combination Coverage): Design enough test cases so that the combination of all possible conditional values for each decision is performed at least once. .
  • Path coverage Design enough test cases to make all possible paths in the program execute at least once.
  • a program contains a loop structure', a very simple program may generate a large number of paths.
  • Complete path coverage is not practical in actual test work. Therefore, for path coverage, the actual number of loops is generally not considered when counting paths. Only consider the case where at least one loop body is executed and the loop body is not executed.
  • This simplified path coverage is also called Z path coverage. Since the complete path coverage is not practical, we refer to the path 'path coverage' as the Z path coverage. .
  • conditional coverage Since the logical target of expression coverage is a conditional expression, we call expression coverage called conditional coverage; The logical target of conditional coverage is the possible value of the condition. We call the conditional coverage the conditional value coverage. Since the logical target of the conditional combination coverage is the combination of the conditional possible values, we refer to the conditional combination coverage as the conditional value combination coverage, ie Use the name in parentheses in the above definition
  • Each logical coverage has its advantages and disadvantages. In general, the logical coverage behind it, the integrity of the test is high, of course, more test cases are required, and the test cost is higher.
  • the white box test method requires the tester to fully understand the logical structure of the program.
  • the general process is to draw a program logic structure diagram according to the program logic structure, such as a program flow chart or a control flow diagram, and design a test case against the program logic structure diagram.
  • white-box testing places a high demand on testers and requires high time costs.
  • Black box test coverage can also be used to verify the integrity of the black box test. After the black box test, if Some code is not overwritten, it is likely that the function points related to these codes have not been tested. Black box testing is a test of program features, which is an indispensable aspect of software testing. If the basic functions of the program are not correct, other aspects are even more No
  • the black box test also completes a certain logic coverage
  • you perform the black box test according to the program function, check the logical coverage, and add the test case to test according to the uncovered logical unit you can reduce the repetitive work.
  • the logic coverage has the characteristics of being overly difficult, that is, starting a small number of test cases can quickly increase the coverage, and later, designed to complete the test of remaining coverage.
  • the test cost is high in the prior art.
  • the technical problem to be solved by the present invention is to provide a low-cost and high-efficiency method for designing a white-box test case for the problem that the white-box test cost is too high.
  • Another technical problem to be solved by the present invention is to provide a method and system for quickly designing test cases for various logical coverages based on existing test cases, in view of the problem of white box testing.
  • the technical solution proposed by the present invention is:
  • test case design method characterized in that it comprises the steps of:
  • the technical solution proposed by the present invention is:
  • step C is replaced by the following steps:
  • a test case design system comprising:
  • a device for approximating test cases for computing logical targets is provided.
  • a device for generating a modification prompt A device for generating a modification prompt.
  • the first technical solution of the present invention automatically generates test cases.
  • the technical solution can generate a set of test cases covered by various logics.
  • the tester does not need to analyze the logical structure of the program, and does not need to draw any charts.
  • the test input data can be determined according to the automatically generated test cases, and the test code is written for testing. Since the logic structure of the manual analysis program and the drawing are not required, the invention reduces the requirements for the white box test and improves the efficiency of the white box test, and can complete the white with high integrity at a low cost. Box testing helps improve software quality and reduce development costs.
  • the second technical solution and the third technical solution of the present invention calculate an approximate test case that can cover the expected logical target in the existing test case.
  • a small modification of the approximate test case can cover the expected logical target.
  • the technical solution can also propose a modification prompt, indicating which data and the range of data to be modified or the conditions to be met, so that the modification work is efficient and accurate.
  • the invention can quickly complete the white box test on the basis of the black box test, and verify the integrity of the black box test by the white box test. The more test cases that have been used, the closer the approximate test case is to the coverage requirement of the intended logical target, and the fewer modifications are required. Therefore, the second and third technical solutions of the present invention completely overcome the white box test.
  • the characteristics of the catastrophe can also be used for pure white box testing.
  • Figure 1 is a general flow diagram of one embodiment of the present invention.
  • FIG. 2 is a schematic diagram showing the internal data structure of each structural object and a structural object tree in an embodiment of the present invention, wherein FIG. 2A is a schematic diagram of internal data structure of a statement block object, and FIG. 2B is a schematic diagram of internal data structure of a branch tree object. 2C is a schematic diagram of the internal data structure of the branch object, and FIG. 2D is a schematic diagram of the structure object tree.
  • Figure 3 is an example of sample code and code slice classification.
  • Figure 4 is a flow diagram of mapping a code slice to a structural object.
  • FIG. 5 is a schematic flow chart of a statistical program path, wherein FIG. 5A is a schematic flowchart of a statistical path when the object is a statement block, FIG. 5B is a flow chart of a statistical path when the object is a branch, and FIG. 5C is a schematic diagram of the object when the object is a branch tree. A schematic diagram of the flow of the statistical path.
  • Figure 6 is a flow diagram showing the overlay test case for generating a path.
  • Figure 7 is a flow diagram showing a portion of a test case generated based on the bar # ⁇ straight combination.
  • FIG. 8 is a general flow diagram of another embodiment of the present invention. '
  • Fig. 9 is a schematic view showing the overall configuration of still another embodiment of the present invention. ⁇
  • step A maps program code to a structural object
  • step B counts a program path
  • step C generates a test case.
  • step A shown in Fig. 1 is described in detail below. First, the structural object described in the step A will be described in detail, and the structural object is used to describe the logical structure of the program.
  • This embodiment divides the program logic structure into two types: a sequence structure and a branch structure.
  • the sequence structure corresponds to a sequence of statements. If the first statement is executed in this sequence of statements, then all the statements will be executed if no exception occurs and the return statement is not returned in advance. All consecutive statements shall be considered to belong to the same sequential structure and shall not be split, that is, one part shall not be regarded as belonging to one sequential structure, and the other part shall be regarded as belonging to another sequential structure.
  • the order structure has an entry point and an exit point, the entry point is the first statement in the structure, and the exit point is the last statement in the structure, but if a statement in the sequence structure is a return statement (such as C++ return) Statement), the function returns when the statement is executed, and the following statement will not be executed. In fact, the following statement is invalid. Therefore, the statement is the actual exit point of the sequential structure. Since GOTO statements (such as the C+ ten goto statement) break down the structured design and are used less and less in today's development, this embodiment does not consider GOTO statements.
  • the branch structure corresponds to a sequence of statements in which statements containing judgments and/or jump statements or the like are executed, and under certain conditions, some of them may or may not be executed or executed repeatedly.
  • the most typical branch structure is the selection structure, and the loop structure also belongs to the branch structure. Since the branch structure performs or does not execute or repeat certain statements under different conditions, the branch structure contains at least two possible execution routes, which are called branches, that is, one branch structure contains at least two Branch. To simplify the problem, the loop structure is considered to have two branches that enter the loop body and do not enter the loop body, regardless of the number of loops.
  • the more common selection structures are:
  • IF structure such as C/C++/; 3 ⁇ 4va's if(.../dse...; Pascal's if... then ...else...; Basic IF... THEN.. END IF;
  • the structure may or may not have an ELSE branch, and an unlimited number of ELSE IF branches may be added before the ELSE branch.
  • SWITCH structure such as C/C++/Java switeh(..., Pascal case...of..., Basic SELECT CASE...
  • this structure can contain multiple CASE branches, which can contain It is also possible to exclude the DEFAULT branch.
  • the more common loop structures are:
  • FOR structure For( )... such as C/C++/Java, for...do... for Pascal, FOR...NEXT and FOR EACH...NEXT for Basic.
  • WHILE structure such as C/C++/Java while(..., Pascal's while...do..., Basic's DO WHILE... LOOP, DO UNTIL LOOP.
  • Do...WHILE structure such as C/C++/Java do...while((7), Basic DO....LOOP WHILE..., DO.. ⁇ OOP UNTIL..., the structure Execute at least one loop body.
  • branching structures and programming languages are not exhaustive, and any code structure having two or more execution routes is considered a branching structure. .
  • the loop structure is regarded as having two branches that enter the loop body and not enter the loop body, regardless of the number of loops, and the DO...WHILE loop structure executes at least the loop body once, and therefore, it does not enter the loop body.
  • the branch is unreachable.
  • the branch structure also has an entry point and an exit point. Regardless of its internal execution route, the entry is always entered by the entry point without leaving an exception, and the exit point leaves the structure.
  • the structure contains a return statement, the function returns when the statement is executed, and does not leave the branch structure from the exit point.
  • Some branches of some branch structures are implicit, such as the F structure. If there is no ELSE branch at the end, it contains an implicit branch, even if it contains an ELSE IF branch.
  • the execution conditions and routes of this implicit branch are: When the IF and all ELSE IF decisions are false, jump directly to the exit point of the structure.
  • the loop structure does not enter the loop body branch.
  • the execution conditions and lines of the branch are: When the loop condition is judged for the first time, the condition is false and jumps directly to the exit point of the structure. ;
  • SWITCH structure when there is no DEFAULT branch, also contains an implicit branch'
  • the execution conditions and routes are: All CASE branch conditions are not met, do not execute any CASE branch, jump directly to the exit point of the structure .
  • each branch structure contains at least two branches, it can be said that the branch structure is composed of branches.
  • the branch contains two aspects - the branch decision and the branch.
  • the calculation result of the branch decision is generally only two values: true and false.
  • the branch is executed, otherwise the branch is not executed.
  • the branch decisions and branches of the implicit branch are empty.
  • For a branch its branch has a certain range, called scope.
  • specific symbols are used to define the start and end of the scope, for example: C/C++ with curly braces ( ⁇ ), PASCAL with begin And end to specify the start and end of the scope. All statements in the scope, regardless of their structure and number, belong to the branch. Therefore, the branch of a branch can contain one or more sequential structures, and can also contain one or more branch structures. Structure, substructure can in turn contain its own substructure.
  • the embodiment divides the program logic structure into a branch structure and a sequence structure
  • a branch structure includes at least two branches, and each branch may further include a sequence structure and/or a branch structure, and we include the inclusion structure.
  • nesting, nesting levels and numbers There are no restrictions on nesting, nesting levels and numbers.
  • Both the branch structure and the sequence structure have an entry point and an exit point. When the program executes to any structure, the structure is always entered from the entry point without exiting the exception, and the structure is removed from the exit point, unless executed. Return to the return statement in advance.
  • This embodiment uses a structural object to describe the above-mentioned program logical structure: a branch tree object is used to describe the branch structure, a branch object is used to describe a branch in the branch structure, and a statement block object is used to describe the sequence structure.
  • the branch object can nest any number of branch tree objects and/or statement block objects, the number of nested levels and number is not limited, the statement block object is not nested other) .
  • this embodiment regards the whole of the target program as a branch, which is called a top-level branch, and is described by a top-level branch object, which is different from other branch objects in that it is not nested in other objects.
  • - "Branch objects" described later including top-level branch objects and branch objects of other levels. We refer to branch tree objects, branch objects, and statement block objects collectively as structural objects.
  • object A nests object B
  • object B the object A 1 ⁇ 2 child.
  • the object A parent object
  • object B the object A 1 ⁇ 2 child.
  • the object A nested the object B (sub-object)
  • the object A holds the object B itself or the object A holds the pointer or reference of the X-inch image B, or the object A saves other data that can be referenced to object B, and object A can refer to object B.
  • a statement block object has no child objects, and a branch object may not have child objects.
  • the top-level image has no parent object, the parent object of the other image is a branch tree object; the parent object of the branch tree object and the statement block object are branch objects (including the top-level branch object); we call the parent object of the statement block object The branch where the statement block is located.
  • FIG. 2 is a schematic diagram showing the internal data structure of each of the above objects and a structural object tree in the present embodiment, wherein FIG. 2A is a schematic diagram showing the internal data structure of the statement block object, and FIG. 2B is a schematic diagram showing the internal data structure of the branch tree object, FIG. 2C It is a schematic diagram of the internal data structure of the branch object.
  • the solid line is a fixed component, and the dotted line is a dispensable and unlimited number of components.
  • FIG. 2D is a structure. A schematic diagram of the object tree.
  • FIG. 2A is a schematic diagram showing the internal data structure of a statement block object.
  • the statement block object has a code field for storing the program code corresponding thereto, and has a name field for identifying different statement block objects.
  • the name can be represented by letters, such as 'a', V, V.
  • FIG. 2B is a schematic diagram showing the internal data structure of the branch tree object. As shown in FIG. 2B, at least two branch objects are nested in the branch tree object, and more branch objects can be nested. Each branch in the branch structure is actually an integral part of the branch structure. Without these branches, the branch structure does not exist. The branch is separated as an object for processing, just for the sake of simplicity of description and implementation. At the same time, it is more in line with object-oriented thinking.
  • This embodiment adds a field for saving the peripheral code to the branch tree corresponding to the SWITCH structure, which is called a peripheral code field, and is used to save the peripheral code similar to switchC..), but does not save the scope start and end characters.
  • a branch tree corresponding to the SWTTCH structure is called a special branch tree.
  • FIG. 2C is a schematic diagram showing the internal data structure of the finned image.
  • the scaled image has a branch decision field for storing its corresponding branch decision, and the top branch has no corresponding branch decision, so the field is empty.
  • Branch objects can nest any number of branches Tree - object and / or statement block object, if there is no nested branch tree object and statement block object, the branch object is called an empty branch object, like the statement block object, the branch object also has a name field, used to identify different Branch object, the name can be represented by a letter, such as ea 'c
  • FIG. 2D is a schematic diagram of a structural object tree consisting of structural objects obtained from the code mapping shown in Figure 3A.
  • a post-sequence scan or a pre-sequence scan may be performed on the structural object tree.
  • the post-sequence scan refers to: starting from the top-level branch object, for each X-inch image, recursively calculating each of its Sub-object, after the sub-object is calculated, the object itself is calculated. Since the statement block object and the empty branch object have no sub-objects, they are calculated directly, so they are recursive termination conditions.
  • the only difference between the pre-sequence scan and the post-sequence scan is that for each object, the pre-sequence scan first calculates the object itself and then recursively counts the sub-objects.
  • Step A shown in FIG. 1 maps the program code to a structural object, and specifically includes: parsing a logical structure of the program code, and generating a corresponding branch tree object and a corresponding branch object according to the branch structure of the code generation, according to the order of the program code
  • the structure generates a corresponding statement block object, and nests the branch tree object and the statement block object in a corresponding level of the hierarchy'. Further details are as follows:
  • the code slice refers to a code unit that determines a category by a structural feature.
  • the code slice category has a - decision, a domain symbol, a statement block, and the domain symbol is further divided into a domain start and a domain end.
  • a decision is a piece of code that contains a judgment or jump or similar keyword to control the execution or non-execution of statements within its scope, such as C++ if(%), else if(%), else, whileC ..), switc ...), caseN; Basic IF..., ELSE IF..., ELSE, DO WHILE.... The decision must be complete.
  • C++'s if((7) is a complete decision, regardless of the condition in the parentheses, which is part of the decision and cannot be split.
  • the domain symbol is the code that defines the scope of the decision.
  • the domain begins with the decision, which is used to specify the start of the scope of the decision.
  • the end of the field is used to specify the end of the scope of the decision.
  • Typical domain symbols such as C++ " ⁇ " and “ ⁇ ”, "begin” and "end” of PASCAL;
  • a statement block refers to a code sequence corresponding to the sequential structure described above, which cannot contain a decision. Comments located within a code slice can be ignored or part of the code slice, and comments outside the code slice can be ignored or attributed to subsequent code slices.
  • 3B is an example of a code slice classification. As shown in FIG. 3B, code chips corresponding to codes 301, 303, and 305 are determined; code chips corresponding to codes 302 and 307 are domain symbols, where code chips corresponding to code 302 start with a domain. The code piece corresponding to the code 307 is the end of the field; the code piece corresponding to the code 304, 306, and 308 is a statement block.
  • This embodiment uses a data structure containing three fields of code content, category, and additional categories to store code slices, which are stored in data containers such as linked lists or arrays.
  • code slices which are stored in data containers such as linked lists or arrays.
  • the domain symbol is omitted.
  • the domain symbol in C++ code, when the scope has only one statement, the domain symbol can be omitted.
  • the domain symbol in the Basic IF...THEN... structure, it does not wrap after it.
  • the domain is the same line after the THEN statement, ⁇ is the domain start, the domain end is omitted;
  • the end of the field is omitted before ELSE IF, and the end of the field is omitted before ELSE.
  • the code is decomposed, it is guaranteed that there will be a matching domain start and a domain end after each decision. If the domain symbol is omitted, the corresponding domain symbol should be added, and the code is empty.
  • the implicit branch is also considered when decomposing the code.
  • the IF structure lacks the ELSE branch
  • the SWITCH structure lacks the DEFAULT branch
  • the loop structure that is considered to be the branch structure it contains the implicit branch.
  • Three pieces of code should be added to the implicit branch: one decision, one field starts, one field ends, and their code is empty.
  • FIG. 4 is a schematic flowchart of mapping a code slice to a structure object in this embodiment.
  • 401 is an input parent object, and the branch tree object and the statement block object generated in the process are all nested in the parent object.
  • a parent object can only be a branch object.
  • 402 is a code slice queue, which stores the code slices in the order of the code, in a first-in, first-out queue, called a code slice queue.
  • the "pop-up code piece” described later refers to taking the first piece of code from the code slice queue and deleting the code piece from the code slice queue; the "code piece” described later is unrestricted.
  • step 403 it is determined whether the code slice queue is empty. If it is empty, the process ends. Otherwise, step 404 is executed. Step 404 pops up the code slice. In step 405, the code slice is determined. If the category is a statement block, step 411 is performed. If it is determined, step 421 is performed, if the category is a domain symbol, since the domain symbol should not appear at this time, step 490 is performed, and step 490 reports an error and exits.
  • Step 411 generates a statement block object and nests it in the image.
  • an automatically incremented character variable is used as the name of each statement block object when generating the statement block object, such as ', V, .
  • Step 412 saves the code, copies the code content of the code slice into the code field of the statement block object, and returns to step 403 to process the next code slice.
  • Step 421 generates a branch tree object and nests it into the parent object.
  • step 422 it is determined whether the branch tree belongs to a special branch tree according to an additional category of the code slice. If it is a special branch tree, step 431 is performed, otherwise step 441 is performed.
  • Step 431 saves the peripheral code and copies the code content of the code slice to the peripheral code field of the special branch tree object.
  • Step 432 determines whether the code slice queue is empty. If it is empty, step 490 is reported and exits. Otherwise, step 433 is executed to pop up the code slice, and in step 434, the code slice is determined. If the category is started, the process returns to the execution step.
  • step 432 (ignoring the domain of the peripheral code starts, step 472 ignores the end of the domain of the peripheral code), if the category is a decision, step 41 is performed, and if the category is not the domain start or the decision, the execution step is wrong and exits.
  • Step 441 generates a branch object, which is nested in the branch tree object generated in step 421.
  • an auto-incrementing character variable is used as the name of each branch object, such as ', V, V, when generating the branch object.
  • Step 442 saves the branch decision and copies the code content of the code slice to the branch decision field of the branch object.
  • Step 443 determines whether the code slice queue is empty. If it is empty, step 490 is reported and exits. Otherwise, step 445 is executed to pop up the code slice, and in step 446, the code slice is determined. If the category is the domain start, the shell executes! Step 447, otherwise step 490 is executed and an error is exited.
  • Step 447 generates a variable N for determining whether the domain symbol matches, and assigns a value of 1, indicating that a domain is read.
  • Step 451 determines whether the code slice queue is empty. If it is empty, step 490 is reported and exits, otherwise the step is executed.
  • 452 pops up the code piece, and determines the category of the code piece in step 453. If the category is the domain start, then N is incremented by 1. If the domain is over, N is decremented by 1, and then it is judged whether the value of N is 0 or not.
  • Step 462 processes the branch code, uses the branch object generated in step 441 as a parent object, and the temporary queue as a code queue, performs a recursive call, and then clears the temporary queue.
  • Step 463 determines whether the code slice queue is empty, if it is empty, it ends, otherwise, in step 471, the code slice is popped up, and in step 472, the type of the code slice is determined. If the category is the domain end, step 471 is returned, if If the category is a decision, then step 473 is performed, otherwise returning to step 405 to process the subsequent code slice until the end. Step 473 determines whether the code slice belongs to a subsequent branch of the previous branch according to the auxiliary category of the code slice. If yes, step 441 is performed. Otherwise, the current branch tree has been processed, and the execution returns to step 405 to process the subsequent code slice until the end. ⁇
  • Step B shown in Fig. 1 is described in detail below, which counts the program path.
  • the path refers to the execution route of the program.
  • the path described in this embodiment includes: statement combination and branch combination, that is, the statement combination and branch combination are used to describe the path.
  • the statement combination refers to the sequence of the statement block executed by the path, and the statement block name is composed of the execution order of the path;
  • the branch combination refers to the sequence of branches that the path experiences, and the branch name is composed of the path history;
  • the statement combines the statement executed by the record path, and the branch combines the branch that the record path goes through.
  • the path is divided into two categories: normal and return.
  • the returned path is passed through a block containing the return statement, so it ends early; the normal path ends at the end of the program.
  • the default class of the path is normal.
  • the class of the path is set to return, and the path ends.
  • Step B specifically includes: sequentially scanning the structural object, and for each structural object, using an input path set as initial data for path statistics, and the input path set of the top branch object includes only one empty path; for the statement block object, The statement block name is recorded in each path of the input path set; for the branch object, the branch name is recorded in each path of the input path set, and the output path set of the previous sub-object is used as the input path set of the next sub-object; For a branch tree object, a copy of the input path set is taken as the input path set for each child object.
  • FIG. 5 is a schematic flowchart of a statistical program path in the embodiment, wherein FIG. 5A is a schematic flowchart of a statistical path when the object is a sentence block, and FIG. 5B is a flow chart of a statistical path when the object is a branch, and FIG. 5C is a flow chart of the object.
  • FIG. 5A is a schematic flow chart of a statistical path when an object is a statement block.
  • step 503 scans the path set, that is, scans the input path set 501. For each path, it determines its category in step 504. If the category is returned, it returns to step 503 to process the next path. Otherwise, in the step.
  • step 50 Determine whether the code of the statement block object contains a return statement. If yes, execute step 506 to set the path category to return and execute step 507. Otherwise, step 507 is directly executed, and step 507 records the statement name, that is, the statement in the path. The statement block name is added at the end of the combination. After all the path processing is completed, the output path set 502 is obtained, and the number of paths in the output path set is consistent with the input path set.
  • Fig. 5B is a flow chart showing the statistical path when the object is a branch.
  • the child object of the object is calculated in turn, and the output path set calculated by the previous child object is used as the input path set of the next child object. Until all the child objects are calculated, the output path set of the last child object is The set of output paths for this branch object.
  • step 511 records the branch, that is, the branch name is added at the end of the branch combination of each path of the input path set.
  • Step 512 scans each child object, if it is finished or has no child objects, otherwise it proceeds to step 513.
  • Step 513 determines whether the sub-object is a statement block. If yes, step 514 is performed.
  • step 515 is performed.
  • Step 514 recursively performs the calculation shown in FIG. 5A, and uses the calculated path set as the input path set of the next sub-object.
  • Step 515 recursively performs the calculation shown in FIG. 5C and uses the output path set as the input path set of the next sub-object.
  • Step 51 and step 515 are both performed after returning to step 512 to process the next sub-object until the end.
  • Figure 5C is a flow chart showing the statistical path when the object is a branch tree.
  • step 523 rejects the return path: the path of the input path set 521 whose class is returned is copied to the output path set 522 and deleted from the input path set 521.
  • step 524 scans the sub-object (branch), and after reading a branch, step 525 copies a copy of the input path set as the set of paths to the branch.
  • step 526 recursively performs the calculation shown in Figure 5 for the branch, and then returns to step 524 to process the next branch.
  • step 527 summarizes the output path set of each branch into the output path set 522 of the entire branch tree object, and the calculation ends.
  • the input path set of the top-level branch object contains only one empty path, which refers to the path where both the statement combination and the branch combination are empty;
  • the output path set of the top-level branch object is the path set of the program.
  • Each path in the path set records the statement executed by the path: ⁇ The sequence of objects and the sequence of images that the path experiences.
  • Step C shown in Fig. 1 is described in detail below, which generates a test case.
  • a test expression is used to describe a test case, that is, a test expression is used to construct a test case, which is an unexecutable test case, and the user determines a specific input data according to the prompt expression; 'writing the test code, the test can be executed.
  • the hint expression is used to describe the range or condition of the input data of the test case, including: a judgment formula, an inverse judgment formula, a conditional expression, and an inverse conditional expression. .
  • the judgment expression is a judgment expression, that is, an expression for deciding whether or not to execute a branch in the judgment, and one judgment has a judgment formula.
  • a conditional expression is a conditional expression. In a decision, there are one or more conditions, and each condition has a conditional expression. Both the decision and the condition have only two calculations: true or false.
  • A>0AND B ⁇ 0 is the decision formula of this decision, and includes two conditions.
  • the conditional expression of condition 1 is: A>0;
  • the conditional expression of condition 2 is: B ⁇ 0.
  • the loop structure only focuses on whether or not the loop body will be executed once. Therefore, the loop structure's decision formula is an expression used to determine whether the loop body will execute at least once.
  • the judgment formula of the WHILE structure is easier to understand, for example, WHILE X>0AND Y>0 DO..., the judgment formula is X>0
  • FOR structure is more complicated 'some FOR structure is simple for syntax'
  • the inverse judgment is the result of the negation of the judgment
  • the inverse condition is the result of the conditional negation.
  • the negation is to replace the equality operator, relational operator, and logical operator in the expression with the opposite operator.
  • the empty expression is still empty after the negation, and the opposite operators are as follows: equal and not equal to each other Conversely, greater than and less than or equal to each other are opposite, less than and greater than or equal to each other, and logical and logical or mutually In contrast, the opposite operator of a logical NOT is generally omitted or empty.
  • the program code is mapped to a structural object in step A, and the branch object description and processing are determined. Therefore, we refer to the judgment formula, the condition, the conditional expression, the inverse judgment formula, and the inverse conditional expression as the branch judgment formula, condition, Conditional, anti-judgment, anti-conditional.
  • the determined fake branch also corresponds to a branch object, and its decision formula, condition, conditional expression, inverse judgment formula, and inverse conditional expression are all empty.
  • condition a A>0A DB ⁇ 0
  • condition b branch b's decision formula, condition '
  • the conditional, anti-judgment, and anti-conditional terms are all empty;
  • branch a has two conditions
  • the conditional expression of condition 1 is: A>0
  • conditional expression of condition 2 is: B ⁇ 0
  • conditional coverage is to cover each conditional expression of each branch.
  • condition 1 and condition 2 are calculated at least once, regardless of the calculation result of the condition. ⁇
  • condition 1 of branch a is expressed as : Ti, Fi
  • condition 2 is expressed as: T2, F2.
  • Conditional value coverage is to cover all values of all conditions of each branch. For branch a, it is to cover the condition values Ti, FK T2, F2.
  • condition value combinations of the above branches a are: TlT2, TiF2, FiT2, FiF2, and we refer to the branch a as the branch of the combination of these condition values.
  • the method of listing the combination of condition values belongs to the prior art. For example, a combination of all condition values of a branch can be obtained by using a multi-layer loop, which will not be described in detail herein.
  • a condition value combination actually includes two aspects: each condition of the branch and the value of each piece.
  • one of the condition value combinations of the branch a, TlF2 means that the condition 1 is true, and the condition 2 is false.
  • some conditions are unreachable, and this embodiment shields the unreachable conditions.
  • the unreachable condition is a condition that is not calculated when the program is executed or a condition that is meaningless even if the calculation is performed. For example, the judgment formula A>0 AND B ⁇ 0 of the branch a, if the value of the condition 1. is false, the condition 2 is not calculated. Therefore, when condition 1. is false, condition 2 is unreachable, we replace the unreachable condition of the condition value combination with the letter S, then the four condition value combinations of branch a: TiT2 TiF2, FiT2, F1F2 should be changed to: TlT2, TiF ⁇ FiS, FiS. Unobstructed conditions may cause certain condition value combinations to be repeated. For example, in conditional value combination of branch a, the shielding unreachable condition causes the latter two conditions.
  • condition value combination coverage is to cover all valid condition value combinations of each branch. For branch a, it is to cover its three combinations of condition values: TiT2, TiF2, FiS, where the unreachable condition is negligible.
  • the branch a actually covers: TiT2, TiF2, Fi.
  • the condition value combination of a branch mentioned later refers to the combination of valid condition values of the branch.
  • the CASE branch uses the SWITCH expression and the constant expression to form an equation, such as the SWUCH structure of C++: switc (X) ⁇ case 0...case l...case N... ⁇ , which can be combined
  • the FOR branch uses a conditional expression as a decision, and multiple conditional expressions are logically connected, and the condition variable can be replaced with the initial value of the condition variable.
  • the variable therefore, has a decision formula of: 0 ⁇ 10.
  • the loop structure is regarded as having two branches of the execution loop body and the loop body. The loop judgment actually considers only the first calculation result, and therefore, when the condition variable can be determined When the initial value is used, the condition variable can be replaced by its initial value.
  • conditional variables The advantage of the initial value instead of the variable is to improve the efficiency of determining the test input data according to the prompt expression.
  • the judgment formula is 0 ⁇ 10, the calculation result is always true, and it is not necessary to consider the expression when determining the test input data.
  • the test case containing the judgment formula is invalid.
  • the other branch uses the conditional expression in the decision as the decision formula, such as the branch decision if(a ⁇ 0 && B>0) of C++, the judgment formula is a ⁇ 0 && B>0, and the branch decision IF A ⁇ 0 AND B>0 THEN
  • the judgment formula is: A ⁇ 0AND B>0.
  • This embodiment generates a test case for the following logical coverage: statement coverage, decision coverage, conditional coverage, condition value coverage, condition value combination coverage, path coverage, that is, generating a set of test cases that can complete the logical coverage according to different logical coverages. , each of which is composed of a prompt expression.
  • white-box testing selects only one or two of the logical overlays without having to complete all of the logical overlays. The specific steps of generating test cases for various logical overlays are described in detail below:
  • Generating a path coverage test case specifically comprising: performing, for each path in the path set obtained in step B, a step of generating an overlay test case for generating a path.
  • the step of generating an overlay test case for a path specifically includes: selecting, for each of the experienced branches of the path, an inverse decision of the preceding sister branch of the calendar branch, and a decision formula of the experience branch itself.
  • the sister branch of the branch is all branches of the parent object of the branch, that is, all branches directly belonging to the same branch tree, that is, all branches directly belonging to the same branch structure, and of course, the branch itself, wherein, the branch is arranged in the branch
  • the previous branch is called the previous sister branch of the branch.
  • 6 is a schematic flowchart of an overlay test case for generating a path. As shown in FIG. 6, step 601 scans a branch combination of paths. For each experience branch, step 602 scans its sister branches, for each sister branch, in step 603.
  • step 605 selects the inverse decision of the sister branch, and then returns to step 602 to process the next sister branch;
  • step 605 selects the decision formula of the experience branch itself, and then returns to step 601 to process the next experience branch until all branches have been processed.
  • the generated statement covers the test case, specifically: ' Filters the minimum number of target paths that can cover all statements.
  • the statement override is to cover all the statement block objects in the structure object obtained in step A. Generally speaking, there are many test case combinations that reach the statement coverage. This embodiment covers all the statements with a minimum number of test cases.
  • the specific steps for selecting the target path are as follows: All statements are uncovered at the beginning, select a path with the largest number of uncovered statements as the target path, and mark the statement that the target path already contains as overwritten 'Continue selection until Once all the statements have been overwritten, you get the minimum number of target paths that can cover all statements.
  • step of generating an overlay test case for generating a path described in step C1 is performed to generate a test case. Because the selected path contains all the statements, the test cases that cover those paths are the test cases covered by the statement.
  • the decision coverage is also called branch coverage, which is to cover all the branch objects in the structure object obtained in step A.
  • branch coverage is to cover all the branch objects in the structure object obtained in step A.
  • This embodiment covers all branches with a minimum number of test cases. .
  • the specific steps for selecting the target path are as follows: All branches are uncovered at the beginning, select a branch combination that contains the most uncovered branches, mark the branches already included as covered, continue to select until all branches are overwritten , you get the minimum number of target paths that can cover all branches. ⁇
  • step of generating an overlay test case for generating a path described in step C1 is performed to generate a test case. Since the selected path contains all the branches, the test cases that cover those paths are the test cases that are overwritten.
  • Generating a condition value combination overlay test case specifically comprising: performing a step of generating an overlay test case for combining a condition value for each condition value combination of each branch.
  • the step of generating a coverage test case for combining a condition value specifically includes: selecting a path that experiences the combination of the condition values as a target path; and for each leading branch of the target path, sequentially selecting the preceding sister branch of the leading branch.
  • the path through the straight combination refers to the path through which the branch of the condition value combination is located, that is, the branch combination contains the path of the branch where the condition value combination is located.
  • the leading branch ' is referred to in the branch combination of the target path, located in the combination of the condition values
  • This step is divided into two steps: generating the first half of the test case based on the target path and generating the second half of the test case based on the combination of condition values.
  • the first step is similar to the step of covering the test case for generating a path described in step C1. The only difference is that the prompt expression is selected only for the leading branch, and subsequent branches are ignored, and the specific steps are not repeated.
  • the second step is described in detail below.
  • FIG. 7 is a schematic flowchart of generating a part of the test case according to the condition value combination. As shown in FIG. 7, step 701 scans the condition value combination.
  • step 702 determines whether it is unreachable or unreachable.
  • the condition is that the condition value is marked as S in the condition value combination. If yes, the process returns to step 701 to process the next condition. Otherwise, step 703 is performed. Step 703 determines the value of the condition. If the value is true, step 705 is performed. Otherwise, the process is performed. Step 704. Step 704 selects the inverse conditional expression of the condition, and step 705 selects the conditional expression of the condition. After steps 704 and 705 are executed, the process returns to step 701 to process the next condition until all the conditions are processed.
  • conditional cover test case which specifically includes: For each branch, perform the following steps:
  • the specific steps for selecting the target condition value combination are as follows: At the beginning, all the conditions of the branch are uncovered, and a condition value combination with the highest number of reachable un ⁇ cover conditions is selected in the condition value combination of the branch, and the condition value is selected. The condition that is reachable in the combination is marked as covered, and the selection continues until all the conditions of the branch have been covered, and a minimum number of target condition value combinations that can cover all the conditional expressions of the branch are obtained.
  • the conditional value combination of branch a is: TiT2, TlF2, FlS, the first scan, TiF2 is selected, the two conditions have been overwritten, so the target condition value combination is TlF2.
  • step C4 For each target condition value combination, the step of generating an overlay test case for a condition value combination described in step C4 is performed to generate a test case. Because the selected condition value combination contains all the conditions, the test cases that cover the combination of these condition values are the conditional coverage test cases.
  • the specific steps for selecting the target condition value combination are as follows: At the beginning, all the condition values of the branch are uncovered, and a condition value combination containing the largest number of uncovered condition values is selected in the condition value combination of the branch, and the condition value is selected. The condition values already included in the combination are marked as overwritten, and the selection continues until all condition values have been overwritten, resulting in a minimum number of target condition value combinations that can cover all of the branches.
  • conditional value combinations for branch a are: TiT2, TlF2, FiS, first scan, select TiT2, which overrides two condition values: ⁇ , ⁇ 2, scan again, select TiF2, which covers the remaining one of the condition values: F2, scan again, select FiS, it covers the remaining one condition value: Fi, so the target condition value combination is TiT2, TlF2, FiS.
  • step C4 For each target condition value combination, the step of generating an overlay test case for a condition value combination described in step C4 is performed to generate a test case. Because the selected condition value combination contains all of the condition values, the test cases that override these combination of condition values are the test cases covered by the condition values.
  • Simplification is generally based on a set of sister prompt expressions.
  • An expression branch based on the path and its prompt expression generated in the former sister branch is called a set of sister hint expressions.
  • test expression is used to describe a test case.
  • the test case cannot be directly executed.
  • the user determines the specific test input data according to the prompt expression, and writes an executable test code.
  • Another embodiment of the present invention described later is based on an existing executable test case, in order to achieve a certain logical coverage, New test cases. Since there are already executable test cases, the embodiment selects an approximate test case of the logical target from the existing test case, and describes the modification prompt by using the prompt expression, and the user can modify the approximate test case according to the modification prompt, and the method can be used for 3 ⁇ 4 Test cases that cover the expected logical target.
  • FIG. S is a general flow diagram of another embodiment of the present invention. As shown in FIG. S, steps A and B are the same as in the first embodiment, step D inserts the program, step E compiles and runs the inserted program, step F records logical coverage information, and step G calculates the approximate of the logical target. Test case, step H generates a modification prompt.
  • step D inserts the program.
  • Cartridge is a commonly used technology in the field of software testing. It is to insert code into the program under test.
  • the instrumentation technology is prior art. The detailed implementation details are not described here, but different instrumentation purposes have different instrumentation functions and The insertion position, the insertion function and the insertion position of the present embodiment are described in detail below.
  • the instrumentation function is the function called by the instrumentation code.
  • the purpose of the interpolation in this embodiment is to monitor the execution status of a statement or condition, and two interpolation functions are used: a statement monitoring function and a condition monitoring function, and a statement monitoring function is used to monitor the execution of the statement.
  • the statement monitoring function is The statement execution name is the identifier of the statement, that is, the statement block name, and the condition monitoring function is used to monitor the calculation of the condition or the calculation result.
  • the cow monitoring function transmits the value of the bar # when the condition is calculated.
  • This embodiment can design test cases for various logical coverage targets, such as statement coverage, decision coverage, and path coverage. It can be inserted only using function ,. For conditional coverage, condition value coverage, and condition value combination coverage, Use function B for instrumentation. .
  • the function A is as follows (pseudo code):
  • Function A can have no return value, only one parameter:
  • the statement block name is used to identify the block of statements being monitored.
  • the function B is as follows (pseudo code):
  • BOOL function B (branch name, condition number, condition value)
  • Function B returns a Boolean value that is always true (TRUE).
  • the calling code of function B_ is inserted in the front and rear ends of each condition.
  • the condition value argument is false, and when the backend is called, the condition value argument is true;
  • the end call is consistent, the branch object name is used as the first argument, and the number of the condition in the branch is made as the second argument.
  • function B The code that calls function B and the conditional expression are connected by a logical AND, and it is best to enclose the three in parentheses. Since function B always returns a true value, it does not interfere with the calculation process and calculation result of each condition in the judgment and judgment.
  • instrumentation prseudo code, underlined code that calls the instrumentation function
  • Function A runs the name of the statement, and function B passes the branch name, condition number, and condition value at run time. Therefore, the function they need to implement is the step of sending this information to the record logic overlay information. If the step of recording logical coverage information belongs to another application, you can use interprocess data exchange technology when transferring data. There are many ways to implement it, such as shared memory, network, named pipes, or you can save data to a file. The steps of the logical coverage information are actively read. The specific implementation details are prior art and will not be described in detail herein.
  • step E compiles and runs the instrumented program.
  • a driver is required, the driver sets the input data, and calls the program under test to make the program under test run. Since the present embodiment has an executable test case, the test case constitutes a driver.
  • one test case runs the test program once.
  • the following code to be tested programming language is C++, the same way applies to other programming languages 3 ⁇ 4»: Int CMyClass::Add(int x, int y) return x + y;
  • test cases which use different input data to drive the test program to execute once.
  • the user-provided compiler compiles the loaded test program and its driver to obtain an executable file, and runs the executable file to run the tested program.
  • step F records the logical coverage information.
  • the instrumentation code passes the logic overlay information, and step F records the information, including:
  • test case • Measure the coverage of covered and covered paths. After the test program finishes running, compare the statement combination of the path with the statement combination of each test case. If the statement combination of the path is a subset of the statement combination of the test case, The Bessie path has been covered by this test case, called the covered path, and the test case is called the coverage use case for the path. Since path statistics do not take into account the number of loops, when a loop structure contains branches, a test case may overwrite multiple paths. That is, a test case may be an overwrite use case for multiple paths.
  • function B passes the condition value at the time of conditional execution. For each condition, this embodiment uses a set (such as an array or a linked list) to record the execution result of the condition in each test case, which is called conditional coverage record. A collection item, the initial value of each collection item is not overwritten.
  • conditional coverage record A collection item, the initial value of each collection item is not overwritten.
  • step G calculates an approximate test case for the logical target.
  • a logical target is one of the logical units that the designed test case is intended to cover. For example, a statement block, a branch, a path, a conditional, a condition value, and a combination of condition values can all be used as logical targets. In general, a logical target is an uncovered logical unit.
  • a branch is a logical target that determines coverage.
  • Step G selects an approximate test case from the existing test cases. Therefore, the approximate test case is an existing test case, and the test case can cover the logical target with a minimum modification, and the minimum modification refers to the data to be modified. May be less.
  • test program has three parameters, there are two test cases, and the logical target is a statement block.
  • test case 1 needs to modify two parameters.
  • Test case 2 needs to modify one parameter.
  • Example 2 is an approximate test case for this logical target.
  • Different logical objectives use different steps to calculate approximate test cases, which are described in detail as follows:
  • the logical target is the path.
  • the path is the target path.
  • the approximate path of the target path is calculated by calculating the approximate path of the target path.
  • the near test case of the target path is equal to the coverage case of the approximate path of the target path. .
  • the step of calculating the approximate path of the target path specifically includes: comparing the target path with the branch combination of each covered path, and the overlapped path with the most overlapping branches is the approximate path of the target path.
  • Overlapping branches are consecutive identical branches starting from the beginning. When multiple overlapping paths overlap the same branch, the first non-overlapping branch is compared, and the first non-overlapping branch is prioritized and closest to the first priority.
  • the first non-overlapping branch is compared, if there is a candidate path in the latter There is a previous candidate path, and the candidate path is selected after the candidate; if there are multiple subsequent candidate paths, the first one is selected; if there are multiple previous candidate paths, the last one is selected, "Before” and “behind” means that the first non-overlapping branch of the candidate path is compared with the first non-overlapping branch of the target path, and the "first" and “last” refer to the first of the candidate paths.
  • Non-overlapping branches are compared, since the branch names of this embodiment are auto-incremented, and all the first non-overlapping points Branches belong to the same branch tree object. Comparing branch names can identify "before”, “behind” and "front” and "final”. We refer to the first non-overlapping branch of the target path as the blocking branch, and the first non-overlapping branch of the approximate path as the critical branch.
  • the logical target is the branch.
  • We call this branch the target branch. Calculate its approximate test case using the following steps:
  • All the paths that go through the target branch are selected as the candidate target path, that is, the path including the target branch in the branch combination is selected as the candidate target path.
  • An approximate path of each candidate target path for each candidate target path, the step of calculating the approximate path of the target path described in step G1 is performed to calculate an approximate path thereof;
  • the critical difference is the difference between the offset of the target branch in the candidate target path and the offset of the critical branch of the approximate path of the candidate target path.
  • the offset of the branch refers to the number of branches before the branch in one path. For example: The branch combination of the candidate target path is: abdflb The target branch is f, the branch combination of the approximate path is abekj, then the offset of the target branch in the candidate target path is 3, and the critical branch of the approximate path is e (the first non Overlapping branches), the offset is 2, and the critical difference is 1.
  • the approximate test case of the target branch is equal to the coverage use case of the approximate path of the target path.
  • the logical target is the statement block. • We refer to this block of statements as the target statement.
  • the approximate test case of the target statement is equal to the approximate test case of the branch where the target statement is located.
  • the approximate test case is the target path, approximate path, and approximate test case of the target statement.
  • the logical target is a combination of conditional values.
  • This combination of conditional values as a combination of target condition values, and perform the steps of an approximate test case for calculating a combination of target condition values to calculate an approximate test case for the combination of target condition values.
  • the steps of the approximate test case for calculating the target condition value combination specifically include:
  • the target branch is the branch where the target condition value combination is located. According to the conditional coverage record, if at least one of the condition value combinations of the target branch of a test case has a value of true or false, the test case covers the target branch. On the basis of completing the statement coverage, the qualified candidate test cases must exist. If they do not exist, the statement coverage should be completed first.
  • Select candidate test cases with the highest condition value as the approximate test case for the combination of target condition values. Specifically, for each candidate test case, the condition value combination of the test case of the target branch is compared with the target condition value, and the candidate test case with the highest condition value is an approximate test case of the target condition value combination.
  • the logical target is the conditional expression. We call this conditional expression the target conditional expression.
  • the branch where the target conditional expression is located is called the target branch.
  • the approximate test case for the target conditional expression is calculated by the following steps:
  • Select the condition value combination that is reachable by all the target conditional conditions as the candidate target condition value combination Select the condition value combination that the target conditional condition is reachable in the condition value combination of the target branch, that is, the condition corresponding to the target conditional expression is not masked
  • the combination of condition values is used as a candidate target condition value combination.
  • An approximate test case for calculating each candidate target condition value combination for each candidate target condition value combination, performing the step of approximating the test case for calculating the target condition value combination described in step G4 to calculate an approximate test case of the candidate target condition value combination .
  • Select the candidate condition value combination with the most pre-conditions covered as the target condition value combination Calculate the number of the previous conditions of the target branch covered by the approximate test case of each candidate target condition value combination, and the most is the target condition value. combination.
  • the number of pre-conditions is the number of conditions before the target conditional expression in the candidate target condition value combination, excluding the unreachable condition; the condition covered by the test case means that the target branch is in the condition value combination of the test case. , the condition that the cow value is true or false.
  • the approximate test case of the target conditional is equal to the approximate test case of the target condition value combination.
  • the logical target is the condition value.
  • the branch where the target condition value is located is called the target branch.
  • the approximate test case for calculating the target condition value is calculated by the following steps:
  • An approximate test case for calculating each candidate target condition value combination for each candidate target condition value combination, performing the step of approximating the test case for calculating the target condition value combination described in step G4 to calculate an approximate test case of the candidate target condition value combination .
  • the pre-condition value is the condition value before the target condition value in the candidate target condition value combination, excluding the unreachable condition; the condition value that has been covered by the approximate test case refers to the condition value and the target of the approximate test case.
  • the condition value of the corresponding condition value in the condition value combination of the branch is the condition value before the target condition value in the candidate target condition value combination, excluding the unreachable condition; the condition value that has been covered by the approximate test case refers to the condition value and the target of the approximate test case.
  • the approximate test case for the target condition value is equal to the approximate test case for the target condition value combination.
  • step H generates a modification prompt.
  • the modification prompt is used to guide the modification of the approximate test case of the logical target so that the modified test case can override the logical target.
  • the modification prompt consists of the prompt expression and is divided into two categories: the condition and the condition to be satisfied have been satisfied.
  • the condition to be satisfied is an unsatisfied condition of the approximate test case, and the approximate test case can be modified according to the condition to be satisfied to obtain the expected coverage.
  • Test cases for logical targets; conditions that have been met indicate that the approximate test case has been met, and the modified test case should still meet the conditions.
  • the condition to be met is the core of the modification prompt.
  • the condition that has been met is only a reference and is not required.
  • the target path is the target path of the logical target. Before the blocking, it refers to: Before the blocking branch of the target path, the blocking branch is not included.
  • the critical path Before the critical branch, it refers to: Before the critical branch of the approximate path of the target path, including the critical branch, that is, according to In the branch that selects the prompt expression (including the experience branch of the target path and the previous sister branch of the experience branch), if a blocking branch occurs, from the blocked branch, the selected prompt expression is a condition to be satisfied, or If the critical branch of the approximate path of the target path appears, starting from the next branch of the critical branch, the selected prompt expression is the condition to be satisfied.
  • the target path, approximate path, blocking branch and critical branch are described in detail in steps G1, G2, and G3. Since the condition that has been met is only a type of reference information, the condition that has been met can be ignored when generating the modification prompt.
  • the satisfied condition generated by the above steps is composed of a judgment formula or an inverse judgment formula. If the judgment of the branch contains a plurality of conditions, the satisfied condition may not be clear enough, which affects the accuracy of the modification prompt.
  • modification hints C++ syntax
  • a new test case can be obtained by changing the value of a to 0 or changing the value of X to 1, but there are actually two possibilities for satisfying the condition: a>0 or b ⁇ 0, ' If a>0, then changing the value of a to 0 destroys the satisfied condition and the new test case will not cover the expected logical target.
  • the improved step HI which includes:
  • the preceding sister branch of the experience branch and the prompt expression of the experience branch itself are sequentially selected, wherein the branch before or before the threshold selects a prompt expression according to the following steps:
  • the conditional expression of the condition for taking the true value is selected, the inverse conditional condition of the condition for taking the false value is ignored, and the unreachable condition is ignored; the other branches select the prompt expression according to the following steps:
  • the anti-judgment formula is subjected to the branch self-selection judgment formula.
  • the condition has been met before the blockage or the critical predecessor, otherwise it is a condition to be satisfied; the condition that has been met can be ignored.
  • An approximate test case is an approximate test case for a logical target. Using the improved steps HI generated above, there are two possible outcomes:
  • Modifying the approximate test case according to the modification prompt generated by the above steps can obtain the test case that can cover the expected logical target, but the modification suggestion is more complicated, and the condition to be satisfied may be more
  • the workload of modifying the test case is relatively large.
  • the above steps may further include: ignoring the branch after the blocking branch. That is to say, the above steps end after the decision formula of the blocking branch is selected, and the following branches are ignored. In this way, there are few conditions to be met, and the workload of modifying the test case is small. Usually, only one data needs to be modified, but the test case may not cover the expected logical target.
  • the logical target is a path
  • the actual coverage is It may be another path through the blocked branch, but it also achieves the goal of improving path coverage.
  • the logic can be chosen at will, and the logic coverage is increased with a minimum amount of work each time, which is highly efficient.
  • the target branch refers to the branch where the logical target is located, that is, the branch where the target condition value combination is located.
  • the target condition value combination has been described in detail in steps G4, G5, and G6. Selecting an covered path that passes through the target branch as the target path means selecting a path from the covered path to include the path of the target branch as the H! target path. If the statement is overwritten, the target path must exist.
  • step H2 Similar to step HI, in order to get more precise modification tips, an improved step H2 can be used, which specifically includes:
  • the above steps can be further included: ignoring the target condition and the conditions after the target condition.
  • the target condition is: For conditional value combination coverage, there is no target condition.
  • conditional coverage the condition corresponding to the target conditional expression is the target condition.
  • conditional value coverage the condition corresponding to the target condition value is the target condition.
  • conditional coverage and conditional value coverage the condition of the target conditional or target condition value and the value of the subsequent condition have no effect on whether to override the conditional or conditional value, so these can be ignored when selecting the prompt expression. condition.
  • the prompt expression selected for the target path belongs to the condition; the prompt expression selected for the target condition value combination, the prompt expression corresponding to the condition whose condition value has been covered by the approximate test case belongs to The conditions are met and the other conditions are to be met.
  • the condition value that has been covered by the approximate test case refers to the condition value that corresponds to the corresponding condition value in the condition value combination of the branch where the target condition value combination of the approximate test case is combined.
  • the conditions that have been met are negligible.
  • the modification prompt may be simplified, that is, the semantic repetition or contradiction in the modification prompt is deleted or merged.
  • Step C of the first embodiment describes the simplification of the test case in detail.
  • the modification prompt of the example and the test case of the first embodiment are both composed of the prompt expression. Therefore, the detailed steps of simplifying the modification prompt are the same as the steps of simplifying the test case described in the first embodiment.
  • the modification prompt consists of a prompt expression. In most cases, new test data can be determined based on the modification prompt, but the modification prompt does not describe the dependencies between the codes, such as the following pseudo code:
  • the modification prompt includes the prompt expression: X ⁇ 1.
  • the parameter X can take a value of 0.
  • X is 0 and cannot overwrite the target statement due to the dependency between the codes.
  • the modification prompt may further include a prompt code, which is the code executed by the target path, and the target path refers to the target path described in step HI or H2.
  • the path has a statement combination.
  • the statement combination is the sequence of statement block objects executed by the path.
  • the statement block object stores the corresponding code.
  • the code corresponding to the statement combination of the path is the execution code of the path.
  • the hint code only needs to include the leading code of the target path.
  • the leading code refers to the code before the branch is blocked. If the logical target is a conditional, conditional or conditional value combination, the leading The code is the code before the target branch, and the target branch is the branch where the logical target is located.
  • the method for judging the leading code is: scanning the combination of the target path, for each statement block object, if one of its direct or indirect parent branches is a blocking branch or a target branch, the statement block object is the termination point of the leading code. That is, the preamble code refers to the code corresponding to the statement block object before the statement block object in the statement combination of the path.
  • a direct or indirect parent branch of a statement block object refers to a branch object in the direct or indirect parent of the statement block object.
  • step I can also be added, which statistically covers the logical coverage, ie for some logical coverage, the covered and uncovered portions.
  • the statistical results obtained in step I can be used to display the logical coverage of existing tests, and can also list uncovered The logical target is for the user to choose.
  • Step I specifically includes:
  • statement coverage is to cover all the statement block objects obtained in step A, the statements recorded in the statement coverage record are overwritten statements, and the others are uncovered statements.
  • the branch experienced by the covered path is the covered branch, that is, all branches in the branch combination of the covered path are covered branches, and all branches that have not been covered by the covered path are not covered. Branch.
  • conditional coverage according to the condition ⁇ cover record, if the value of each test case of the condition is not ⁇ cover, the conditional expression is not covered, otherwise the conditional expression has been covered.
  • Statistical condition value ® cover according to the condition ⁇ cover record, if the condition is in the value of each test case. At least one of the conditions is true, the true value of the condition has been covered, otherwise it is not covered; the same method is used to count the condition The value of the fake.
  • condition value combination of each test case is the combination of the conditional value of the ⁇ cover condition, and the condition value combination unrecorded in the condition coverage record is uncovered.
  • Fig. 9 is a schematic view showing the overall configuration of still another embodiment of the present invention.
  • this embodiment is a test case design system, including: a device 901 for mapping program code into a structure object, a device 902 for counting program paths, and a device 903 for inserting a program.
  • the device automatically inserts the program. If the device is omitted, the program can be manually inserted; the device 905 and the device 907 are also optional.
  • the device 901 is used to map the program code to a structural object
  • the device 903 is used to insert the program
  • Compile the instrumented program with a user-provided compiler get the executable file, and run the executable file.
  • the device 904 is used to record logical coverage information; ' ⁇
  • An approximate test case for computing a logical target is calculated using device 906;
  • the device 907 is used to generate a modified pinch.
  • This embodiment implements the apparatus 901 according to the method described in the step ⁇ of the foregoing embodiment; the method implementation apparatus 902 described in step B; the method implementation apparatus 903 described in step D; the method implementation apparatus 904 described in step F; The described method implements apparatus 905; the method described in step G implements apparatus 906; the method described in step H implements apparatus 907, which is not repeated here.

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)

Description

测试用例设计方法和系统 技术领域
本发明涉及软件测试领域， 更具体地，涉及软件测试领域的测试用例设计方法和测试用例设计系统。 背景技术
软件测试的方法主要有黑盒测试和白盒测试。 黑盒测试又叫功能测试， 一般根据程序的功能要求来 设计测试用例。 白盒测试依据程序的内部逻辑结构， 一般采用逻辑覆盖法设计测试用例。测试用例（Test Case) 目前没有经典的定义， 一个测试用例， 一般是指一个测试任务， 该任务在设定的条件下执行被测 试程序。 描述测试用例的方式也没有统一标准， 大体上可以分为两类： 不可执行的测试用例和可执行的 测试用例， 不可执行的测试用例用文字、 表格或其他方式说明程序的功能或相关数据的范围等， 一般作 为进行测试的规范或作为进一步编写可执行测试用例的依据； 可执行的测试用例是可编译执行或解释执 行的代码及数据， 或用电子表格、 数据库等存储的有规范格式的、 可用以生成可执行的代码的数据。
白盒测试常用的逻辑覆盖有： 语句覆盖、 判定覆盖、 表达式覆盖、 条件覆盖、 判定条件覆盖、 条件 值组合覆盖、 路径覆盖， 分别定义如下：
1.语句覆盖: .设计足够的测试用例， 使每一可执行语句至少执行一次。
2.判定覆盖： 又叫分支覆盖， 设计足够的测试用例， 使每个判定的取真分支和取假分支至少经历一 次。
3.表达式覆盖 (条件式覆盖)： 设计足够的测试用例， 使每个判定的每个条件至少计算一次。
4.条件覆盖 (条件值覆盖)： 设计足够的测试用例， 使每个判定的每个条件的所有可能取值至少执行 一次。
5.判定条件覆盖： 设计足够的测试用例， 使每个判定中每个条件的所有可能取值至少执行一次' 同 时， 判定的取真分支和取假分支至少经历一次。
. .条件组合覆盖 (条件值组合覆盖)： 设计足够的测试用例， 使每个判定的所有可能的条件取值的组 合至少执行一次。 .
' 7.路径覆盖： 设计足够的测试用例， 使程序中所有可能的路径至少执行一次。 程序中含有循环结构' 时，一个很简单的程序 可能产生大量的路径， 完全的路径覆盖在实际的测试工作中不具实用性， 因此， 对于路径覆盖， 统计路径时一般不考虑循环的实际次数， 只考虑至少执行循环体一次和不执行循环体两 种情况， 这种简化的路径覆盖又叫 Z路径覆盖， 由于完全的路径覆盖不具实用性， 我们所说的路'径覆盖 是指 Z路径覆盖。
从上述各种逻辑覆盖的定义可看出： 表达式覆盖、 条件覆盖、 判定条件覆盖、 条件组合覆盖均与条 件有关， 其中判定条件覆盖是判定覆盖与条件覆盖的组合， 可以用判定覆盖加条件 ¾盖的方式完成判定 条件覆盖， 因此， 我们把判定条件覆盖看成是一种测试完整性的度量方法而不是一种测试用例设计方法， 不对判定条件覆盖作进一步描述； 表达式覆盖、条件覆盖、条件组合覆盖这三种逻辑覆盖名称不太准确， 进行深入的描述时容易混洧、 难于理解， 由于表达式覆盖的逻辑目标是条件表达式， 我们把表达式覆盖 称为条件式覆盖； 由于条件覆盖的逻辑目标是条件的可能取值， 我们把条件覆盖称为条件值覆盖； 由于 条件组合覆盖的逻辑目标是条件可能取值的组合， 我们把条件组合覆盖称为条件值组合覆盖， 即采用上 述定义中括号内的名称。
每种逻辑覆盖都有其优缺点， 总体来说， 排在后面的逻辑覆盖， 测试的完整性较高， 当然需要的测 试用例也更多， 测试成本也更高。
白盒测试方法要求测试人员充分理解程序的逻辑结构， 一般过程是根据程序逻辑结构画出程序逻辑 结构图， 如程序流程图或控制流图， 对照程序逻辑结构图设计测试用例。 由于需要理解和分析程序逻辑 结构， 白盒测试对测试人员的要求较高， 并且需要较高的时间成本。 ' 黑盒测试依据程序的功能要求来设计测试用例， 以功能覆盖率衡量测试完整性， 白盒测试依据程序 逻辑结构设计测试用例， 用逻辑覆盖率衡量测试完整性， 两者各有侧重' 不能互相替代， 但两者也有内 在的联系， 例如： 黑盒测试也完成了一定的逻辑覆盖率，"白盒测试的覆盖率也可用以检验黑盒测试的完 整性， 进行黑盒测试后， 如果某些代码未覆盖， 很可能是这些代码相关的功能点未被测试到。 黑盒测试 针对程序功能进行测试， 是软件测试不可缺少的方面， 如果程序的基本功能都不正确， 其他方面就更无
1
确 认 本 从谈起' 因此， 程序测试时一般先进行黑盒测试， 在此基础上再进行适当的白盒测试。
由于黑盒测试也完成了一定的逻辑覆盖率， 因此， 如果先依据程序功能进行黑盒测试， 再检査逻辑 覆盖率， 根据未覆盖的逻辑单位， 添加测试用例进行测试， 则可以减少重复工作， 降低测试成本， 但实 际上， 由于逻辑覆盖具有逾后逾难的特点， 即开始吋数量较少的测试用例就可以令覆盖率迅速提高， 越 到后来， 设计用于完成剩余覆盖率的测试用例就越难， 而且， 功能测试所实际完成的逻辑覆盖往往是最 容易毅盖的部分。 要达到理想的白盒测试覆盖率， 就现有技术而言， 测试成本很高。
事实上， 虽然充分的黑盒测试和白盒测试是提高软件质量的必要手段， 但目前的软件开发中， 进行 了比较充分测试的并不多， 尤其是进行了充分的白盒测试的更少， 特别是国内的中小软件开发企业， 多 数并未进行实际的白盒测试， 造成这一周面的原因之一就是白盒测试的成本太髙， 达到较高完整性的白 盒测试的成本往往是软件幵发企业难于承受的。
发明内容
本发明要解决的技术问题是针对白盒测试成本太高的问题， 提出一种低成本高效率的设计白盒测试 用例的方法。
本发明要解决的另一个技术问题是针对白盒测试逾后逾难的问题， 提出一种在已有测试用例的基础 上， 快速设计用于各种逻辑覆盖的测试用例的方法和系统。
为了解决上述第一个技术问题， 本发明提出的技术 案是：
一种测试用例设计方法， 其特征在于， 包括步骤：
A.将程序代码映射为结构对象； -
B.统计程序路径;
C.生成测试用例。
为了解决上述第二个技术问题， 本发明提出的技术方案是：
—种根据上述第一技术方案的测试用例设计方法， 其特征在于， 用下述步骤代替所述步骤 C:
D.对程序进行插装； ， ' . ■
E.编译并运行插装后的程序；
F.记录逻辑覆盖信息； .
G.计算逻辑目标的近似测试用例。 '
还可以进一步包括下述步骤：
H.生成修改提示。
为了解决上述第二个技术问题， 本发明提出的另一技术方案是：
一种测试用例设计系统， 其特征在于， 包括：
用于将程序代码映射为结构对象的装置；
用于统计程序路径的装置；
用于记录逻辑覆盖信息的装置；
用于计算逻辑目标的近似测试用例的装置。
还可以进一步包括：
用于生成修改提示的装置。
本发明的第一个技术方案自动生成测试用例。 该技术方案可以生成各种逻辑覆盖的测试用例集， 测 试人员不需要分析程序的逻辑结构， 不需要画出任何图表， 依据自动生成的测试用例即可确定测试输入 数据， 编写测试代码进行测试。 由于不需人工分析程序的逻辑结构和画出图表， 本发明降低了对白盒测 试的人员要求并提高了白盒测试的效率， 可在较低的成本耗费下， 完成具有很高完整性的白盒测试， 有 利于提高软件质量、 降低开发成本。
本发明的第二个技术方案和第三个技术方案在已有测试用例中，计算出可覆盖预期逻辑目标的近似 测试用例' 对该近似测试用例进行少量的修改， 即可覆盖预期逻辑目标。 该技术方案还可以提出修改提 示， 指出需修改哪些数据及数据的范围或需满足的条件， 使修改工作高效准确。 本发明可在黑盒测试的 基础上， 快速完成白盒测试， 并通过白盒测试来验证黑盒测试的完整性。 已有测试用例越多， 近似测试 用例就越接近预期逻辑目标的覆盖要求， 所需修改就越少， 因此， 本发明的第二个和第三个技术方案彻 底克服了白盒测试的逾后逾难的特点， 也可以用以纯粹的白盒测试。 附图说明
下面结合附图对本发明的具体实施方式作进一步详细的说明：
图 1是本发明的一个实施例的总体流程图。
图 2是在本发明的一个实施例， 各结构对象的内部数据构成的示意图及结构对象树示意图， 其中图 2A是语句块对象的内部数据构成示意图， 图 2B是分支树对象的内部数据构成示意图， 图 2C是分支对 象的内部数据构成示意图， 图 2D是结构对象树示意图。
图 3是示例代码及代码片分类示例。
图 4是将代码片映射为结构对象的流程示意图。
图 5是统计程序路径的流程示意图， 其中， 图 5A是当对象为语句块吋统计路径的流程示意图， 图 5B是当对象为分支时统计路径的流程示意图， 图 5C是当对象为分支树吋统计路径的流程示意图。
图 6是生成一条路径的覆盖测试用例的流程示意图。
图 7是依据条 #{直组合生成测试用例的一部分的流程示意图。
图 8是本发明另一个实施例的总体流程图。 '
图 9是本发明再一个实施例的总体构成示意图。 ―
具体实施方式
图 1是本发明的一个实施例的总体流程图， 如图 1所示， 步骤 A将程序代码映射为结构对象； 步骤 B统计程序路径； 步骤 C生成测试用例。
下面详细描 ¾图1所示的步骤 A， 首先详细描述步骤 A所述的结构对象， 结构对象用于描述程序的 逻辑结构。
本实施例把程序逻辑结构分为两种： 顺序结构和分支结构。 顺序结构对应于一个语句序列， 在这个 语句序列中， 如果第一条语句执行了， 那么在没有发生异常， 也未因返回语句提前返回的情况下， 其他 所有语句也会执行， 符合这一条件的所有连续的语句应视为属于同一个顺序结构而不能分拆， 即不能把 其中的一部分视为属于一个顺序结构， 把另一部分视为属于另一个顺序结构。 顺序结构具有一个入口点 和一个出口点， 其入口点为结构中的第一条语句， 出口点为结构中的最后一条语句， 但如果顺序结构中 的某条语句是返回语句 (如 C++的 return语句)，执行到该语句时函数即返回， 后面的语句不会执行， 实际 上， 后面的语句是无效的， 因此， 该语句是该顺序结构的实际出口点。 由于 GOTO语句 (如 C+十的 goto 语句)破坏了结构化设计并且在当今的开发中使用越来越少， 因此， 本实施例不考虑 GOTO语句。
分支结构对应于一个语句序列， 在这个语句序列中， 含有判断和 /或跳转语句或类似功能的语句， 在 不同的条件下， 可能会执行或不执行或重复执行其中的某些语句。 最典型的分支结构是选择结构， 循环 结构也属于分支结构。 由于分支结构在不同的条件下会执行或不执行或重复执行某些语句， 所以， 分支 结构至少包含两种可能的执行路线， 这些执行路线叫做分支， 也就是说，一个分支结构至少包含两个分 支。 为了简化问题， 循环结构视为具有进入循环体和不进入循环体两个分支， 不考虑循环的次数。
比较常用的选择结构有：
IF结构， 如 C/C++/;¾va的 if(...).../dse...; Pascal的 if... then ...else...; Basic的 IF... THEN... END IF; 该 结构可含或不含 ELSE分支， ELSE分支之前可以增加不限数量的 ELSE IF分支。
SWITCH结构， 如 C/C++/Java的 switeh(...)...， Pascal的 case...of...， Basic的 SELECT CASE...， 该结 构可含多个 CASE分支， 可含也可不含 DEFAULT分支。
比较常用的循环结构有：
FOR结构：如 C/C++/Java的 for(...)...， Pascal的 for...do...， Basic的 FOR...NEXT和 FOR EACH...NEXT。 WHILE结构： 如 C/C++/Java的 while(...)...， Pascal的 while...do...， Basic的 DO WHILE... LOOP, DO UNTIL LOOP。
Do...WHILE结构：如 C/C++/Java的 do...while(...)， Basic的 DO....LOOP WHILE..., DO..丄 OOP UNTIL..., 该结构至少执行循环体一次。
上述分支结构和编程语言的示例并非穷举， 凡具有两个或两个以上执行路线的代码结构， 都视为分 支结构。 .
如上所述， 循环结构视为具有进入循环体和不进入循环体两个分支， 不考虑循环的次数， 而 DO...WHILE循环结构至少执行循环体一次， 因此， 它的不进入循环体的分支是不可达的。 分支结构也具有一个入口点和一个出口点， 不论其内部的执行路线如何， 在不发生异常的前提下， 总是由入口点进入该结构， 并由出口点离开该结构， 这里有一个特例， 如果结构内含有返回语句， 执行 到该语句时函数即返回， 而不会从出口点离开该分支结构。
有些分支结构的某些分支是隐含的，如 F结构，如果最后没有 ELSE分支，则包含一个隐含的分支， 即使含有 ELSE IF分支也是如此， 此隐含的分支的执行条件和路线是： 当 IF和所有 ELSE IF判定均为假 时， 直接跳转到结构的出口点。 含有隐含分支的情况还有： 循环结构的不进入循环体分支， 该分支的执 行条件和线路是： 第一次进行循环条件判断时， 该条件即为假， 直接跳转到结构的出口点； SWITCH结 构， 当不含 DEFAULT分支时， 也含有一个隐含的分支' 其执行条件和路线是： 所有 CASE分支的条件 均不满足， 不执行任一 CASE分支， 直接跳转到结构的出口点。
由于每一分支结构至少包含两条分支， 可以说， 分支结构是由分支构成的。 分支包含两方面内容- 分支判定和分支体， 分支判定的计算结果一般只有真和假两个值。 判定为真时， 执行分支体， 否则不执 行分支体。 隐含分支的分支判定和分支体都是空的。 对于某一分支来说， 其分支体具有一定的范围， 称 为作用域，一般使用特定的符号来定义作用域的开始和结束，例如： C/C++用花括号 ({})， PASCAL用 begin 和 end来指定作用域的开始和结束。 作用域内的所有语句， 不论其结构如何， 数量多少， 均属于该分支 体， 因此， 一个分支的分支体可以包含一个或多个顺序结构， 也可以包含一个或多个分支结构， 我们称 为子结构， 子结构又可以包含自己的子结构。
综上所述， 本实施例把程序逻辑结构分为分支结构和顺序结构， 一个分支结构至少包含两个分支， 每一分支又可以进一步包含顺序结构和 /或分支结构， 我们把这种包含称为嵌套， 嵌套的层次和数量没有 限制。 分支结构和顺序结构均有一个入口点和一个出口点， 程序执行到任一结构时， 在未发生异常的情 况下， 总是从入口点进入该结构， 从出口点离开该结构， 除非因执行到返回语句而提前返回。
本实施例用结构对象来对应描述上述程序逻辑结构： 用分支树对象描述分支结构， 用分支对象描述 分支结构中的一个分支， 用语句块对象描述顺序结构。 其中' 分支树对象嵌套至少两个分支对象， 分支 对象可以嵌套任意数量的分支树对象和 /或语句块对象， 嵌套的层次和数量没有限制， 语句块对象不嵌 套其他) ^象。 另外， 本实施例把目标程序的整体视为一个分支， 称为顶层分支， 用一个顶层分支对象来 描述， 该顶层分支对象与其他分支对象不同的是， 它不嵌套于其他对象。-后文所述"分支对象"， 包括顶 层分支对象和其他层次的分支对象。 我们把分支树对象、 分支对象、 语句块对象统称为结构对象。
如果对象 A嵌套了对象 B， 我们把对象 A称为对象 B的父对象， 对象 B称为对象 A ½子对象。 从 对象的内部数据的关系来说，对象 A (父对象)嵌套对象 B (子对象)，是指对象 A保存了对象 B本身或对象 A保存了 X寸象 B的指针或引用， 或对象 A保存了可以引用到对象 B的其他数据， 通过对象 A可以引用 对象 B。 语句块对象没有子对象， 分支对象也可能没有子对象。 顶层分 象没有父对象， 其他分 象的父对象为分支树对象；分支树对象和语句块对象的父对象都是分支对象 (包括顶层分支对象)；我们把 语句块对象的父对象称为该语句块所在的分支。
图 2是在本实施例，上述各对象的内部数据构成的示意图及结构对象树示意图，其中图 2A是语句块 对象的内部数据构成示意图， 图 2B是分支树对象的内部数据构成示意图， 图 2C是分支对象的内部数据 构成示意图， 图 2A到图 2C中， 实线画出的是固定的组成部分， 点划线画出的是可有可无并且不限数量 的组成部分， 图 2D是结构对象树示意图。
图 2A是语句块对象的内部数据构成示意图， 如图 2A所示， 语句块对象有一个代码字段， 用于储存 它所对应的程序代码，并有一个名称字段，用于识别不同的语句块对象，名称可以使用字母表示，如 'a'、 V、 V。
图 2B是分支树对象的内部数据构成示意图， 如图 2B所示， 分支树对象至少嵌套了两个分支对象， 还可以嵌套更多的分支对象。 分支结构中的每一分支实际上是该分支结构的不可分割的组成部分， 没有 这些分支， 分支结构也就不存在， 将分支独立出来作为一个对象来处理， 仅是为了描述和实施上的简便, 同时也更符合面向对象的思想。本实施例为对应于 SWITCH结构的分支树增加一个保存外围代码的字段， 称为外围代码字段， 用于保存类似于 switchC..)的外围代码， 但不保存作用域开始符和结束符， 我们把对 应于 SWTTCH结构的分支树称为特殊分支树。
图 2C是分翅象的内部数据构成示意图， 如图 2C所示， 分 寸象有一个分支判定字段用于储存它 对应的分支判定， 顶层分支没有对应的分支判定， 因此该字段为空。 分支对象可以嵌套任意数量的分支 树―对象和 /或语句块对象， 如果没有嵌套分支树对象和语句块对象， 则该分支对象称为空分支对象， 与语 句块对象一样， 分支对象还具有一个名称字段， 用于识别不同的分支对象， 名称可以使用字母表示， 如 ea 'c
上述结构对象构成了树状关系， 称为结构对象树。 图 2D是结构对象树示意图， 由图 3A所示的代码 映射获得的结构对象组成。
为了遍历上述每一结构对象， 可对上述结构对象树进行后序扫描或前序扫描， 后序扫描是指： 从顶 层分支对象开始计算， 针对每一 X寸象， 先递归计算它的每一个子对象， 子对象计算完成后， 再计算该对 象自身， 由于语句块对象和空分支对象没有子对象， 计算它们吋直接计算自身， 因此它们是递归终止条 件。 前序扫描与后序扫描相比， 唯一区别在于， 针对每一对象， 前序扫描先计算该对象自身， 再递归计 算子对象。
图 1所示的步骤 A将程序代码映射为结构对象， 具体包括： 解析程序代码的逻辑结构， 依据程序代. 码的分支结构生成对应的分支树对象及对应的分支对象， 依据程序代码的顺序结构生成对应的语句块对 象， 并将所述分支树对象和所述语句块对象嵌套于对应层次的分¾¾象中' 进一步详细描述如下：
首先， 将程序代码分解为代码片。 所述代码片是指以结构特征来确定类别的代码单位， 代码片类别 有- 判定、 域符号、 语句块， 域符号又分为域开始和域结束。 判定是指含有判断或跳转或类似关键字、 用于控制其作用域内的语句执行或不执行的代码片，例如 C++的 if(...)、else if(...)、else、whileC..)、switc ...)、 caseN; Basic的 IF... 、 ELSE IF...、 ELSE、 DO WHILE...。 判定必须完整， 例如， C++的 if(...)是一个完整 的判定， 不论括号内的条件有多长， 都属于该判定的组成部分， 不能分拆。 域符号是定义判定的作用域 的代码， 域开始紧接着判定， 用于指定判定的作用域的开始， 域结束用于指定判定的作用域的结束， 典 型的域符号如 C++的 "{ "与 "} "， PASCAL的 "begin"与 "end"; 语句块是指对应于前文所述的顺序结 构的代码序列， 其中不能含有判定。 位于某一代码片内的注释可忽略也可作为该代码片的一部分， 位于 代码片外的注释可忽略也可归于其后的代码片。图 3B是代码片分类示例，如图 3B所示，代码 301、 303、 305对应的代码片为判定;代码 302和 307对应的代码片为域符号，其中代码 302对应的代码片为域开始， 代码 307对应的代码片为域结束； 代码 304、 306、 308对应的代码片为语句块。
本实施例使用包含代码内容、 类别、 附加类别三个字段的数据结构来存储代码片， 代码片保存在如 链表或数组之类的数据容器中。 分解代码时， 针对判定类代码片， 应判断是不是属于特殊分支树，.及判 断是不是属于一个分支树的后续分支， 可根据判定的关键字分辨是否属于特殊分支树， 如 C++代码的 switch关键字； 后续分支也可根据判定的关键字来辨识， 如针对 C++代码， 如果是 else关键字引出的判 定或 else if关键字引出的判定， 则属于后续分支， 如果一个判定类代码片属于特殊分支树或后续分支 (两 者不可能并列)， 贝 录在附加类别中。
有时， 域符号是省略的， 如 C++代码， 当作用域只有一条语句时， 域符号是可省略的， 再如， Basic 的 IF...THEN...结构中， ΊΉΕΝ后不换行， 其作用域为同一行的 THEN后的语句， ΊΉΕΝ是域开始， 域结 束省略； IR..THEN...END IF 结构中， THEN 和 END IF是域开始和域结束， 而 IF...THEN...ELSE IF...THEN...ELSE...END IF结构中， ELSE IF之前省略了域结束， ELSE之前也省略了域结束。 代码分解 时， 每个判定之后应保证具有匹配的域开始和域结束， 凡域符号省略的， 应补上相应的域符号， 其代码 为空。
分解代码时还要考虑隐含分支， 当 IF结构缺少 ELSE分支， SWITCH结构缺少 DEFAULT分支时， 以及视为分支结构的循环结构， 均含有隐含分支。 应为隐含分支加上三个代码片： 一个判定， 一个域开 始， 一个域结束， 它们的代码均为空。
不同的编程语言， 代码分解依据的语法及关键字略有不同， 具体分解过程可用编译技术中的词法分 析和语法分析技术来实现， 实现过程属于现有技术' 在此不作详述。
完成代码分解后， 进一步将代码片映射为结构对象。 图 4是本实施例将代码片映射为结构对象的流 程示意图， 如图 4所示， 401是输入的父对象，流程中所生成的分支树对象和语句块对象均嵌套于父对象 中， 父对象只能是分支对象。 402是代码片队列， 将代码片按代码的本来顺序， 用先进先出的队列储存， 称为代码片队列。后文所述的 "弹出代码片"， 是指从代码片队列中取出最前的一个代码片， 并将该代码 片从代码片队列中删除； 后文所述 "代码片"， 当未作限定时， 是指最新弹出的代码片； 后文所述 "压入 临时队列"， 是指将代码片保存到临时代码片队列的尾部。本实施例将图 4所示的流程编写为一个递归调 用的函数， 用参数方式传递父对象和代码片队列， 初始调用吋， 生成一个顶层分支对象作为父对象， 代 码片队列包含程序的所有代码片， 当处理一个分支时， 为了进一步处理分支体所对应的代码片， 将该分 支作为父对象， 该分支的分支体对应的代码片保存在一个临吋代码片队列中作为输入的代码片队列， 进 行递归调用。
步骤 403判断代码片队列是否为空， 如果为空则结束， 否则执行步骤 404， 步骤 404弹出代码片， 在 步骤 405判断该代码片的类别， 如类别为语句块， 执行步骤 411， 如类别为判定， 执行步骤 421， 如类别 为域符号， 由于此时不应该出现域符号， 执行步骤 490， 步骤 490报告错误并退出。
步骤 411生成一个语句块对象， 并嵌套在 象中， 本实施例在生成语句块对象时使用一个自动递 增的字符变量作为每一个语句块对象的名称， 如 '、 V、 。 步骤 412保存代码， 将代码片的代码 内容拷贝到语句块对象的代码字段中， 然后返回到步骤 403处理下一代码片。
步骤 421生成分支树对象， 并嵌套到父对象中， 在步骤 422中根据代码片的附加类别判断该分支树 是否属于特殊分支树， 如果是特殊分支树， 执行步骤 431， 否则执行步骤 441。 步骤 431保存外围代码， 将代码片的代码内容拷贝到特殊分支树对象的外围代码字段。 步骤 432判断代码片队列是否为空， 如果 为空则执行步骤 490报错并退出， 否则执行步骤 433弹出代码片， 并在步骤 434判断该代码片的类别， 如果类别为域开始， 则返回执行步骤 432(忽略外围代码的域开始， 步骤 472忽略外围代码的域结束)， 如 果类别为判定则执行步骤 41， 如果类别不是域开始也不是判定， 则执行步骤 艮错并退出。
步骤 441生成一个分支对象， 嵌套于步骤 421生成的分支树对象中， 本实施例在生成分支对象时使 用一个自动递增的字符变量作为每一个分支对象的名称， 如 '、 V、 V。 步骤 442保存分支判定， 将代码片的代码内容拷贝到该分支对象的分支判定字段。 步骤 443判断代码片队列是否为空， 如果为空 则执行步骤 490报错并退出， 否则执行步骤 445弹出代码片， 并在步骤 446判断该代码片的类别， 如果 类别是域开始，贝!]执行步骤 447， 否则执行步骤 490报错并退出。步骤 447生成一个用于判断域符号是否 匹配的变量 N并赋值为 1,表示读到了一个域开始， 步骤 451判断代码片队列是否为空， 如果为空则执行 步骤 490报错并退出， 否则执行步骤 452弹出代码片， 并在步骤 453中判断该代码片的类别， 如果类别 是域开始， 则 N加 1， 如果是域结束， 则 N减 1， 然后判断 N的值是否为 0， 如果为 0，表示对应的域结 束已弹出； 实现了域匹配，执行步骤 462， 否则在步骤 454将代码片压入临时队列， 并返回步骤 451循环 处理下一代码片。 步骤 462处理分支体代码， 将步骤 441生成的分支对象作为父对象， 临时队列作为代 码片队列， 进行递归调用， 然后清空临时队列。'
步骤 463判断代码片队列是否为空， 如果为空则结束， 否则在步骤 471弹出代码片，'并在歩骤 472 判断该代码片的类别， 如果类别是域结束， 则返回执行步骤 471， 如果类别是判定， 则执行步骤 473， 否 则返回执行步骤 405处理后续的代码片直到结束。 步骤 473根据代码片的附属类别判断该代码片是否属 于上一分支的后续分支， 如是则执行步骤 441， 否则表示当前的分支树已处理完毕， 返回执行步骤 405 处理后续的代码片直到结束。 ·
下面详细描述图 1所示的步骤 B， 该步骤统计程序路径。 路径是指程序的执行路线， 本实施例所述 的路径包括： 语句组合和分支组合， 也就是说， 用语句组合和分支组合来描述路径。 语句组合是指路径 所执行的语句块的序列， 由语句块名按路径的执行顺序组成； 分支组合是指路径所经历的分支的序列， 由分支名按路径的经历顺序组成； 也就是说， 语句组合记录路径执行的语句， 分支组合记录路径经历的 分支。 我们把路径的语句组合中的语句称为路径的执行语句， 把路径的分支组合中的分支称为路径的经 历分支。 另外， 由于统计路径的需要， 路径还分为两类： 正常和返回， 类别为返回的路径经过了一个含 有返回语句的语句块， 因此提前结束； 类别为正常的路径在程序结束时结束。 统计路径时， 路径的缺省 类别为正常， 当一条路径经过一个含有返回语句的语句块时， 将该路径的类别设为返回， 该路径即结束。
步骤 B具体包括： 后序扫描所述结构对象， 针对每一结构对象， 将一个输入路径集作为初始数据进 行路径统计， 顶层分支对象的输入路径集只含一条空路径； 针对语句块对象， 在输入路径集的每条路径 中记录该语句块名； 针对分支对象， 在输入路径集的每条路径中记录该分支名， 前一子对象的输出路径 集作为下一子对象的输入路径集； 针对分支树对象， 将输入路径集的拷贝作为每一子对象的输入路径集。 下面描述上述步骤中递归计算各结构对象时统计路径的详细步骤：
图 5是本实施例统计程序路径的流程示意图，其中，图 5 A是当对象为语句块时统计路径的流程示意 图，图 5B是当对象为分支时统计路径的流程示意图，图 5C是当对象为分支树时统计路径的流程示意图。 图 5A是当对象为语句块时统计路径的流程示意图。 如图 5A所示， 步骤 503扫描路径集， 即扫描输 入路径集 501，针对每一条路径，在步骤 504判断它的类别，如果类别为返回， 则返回到步骤 503处理下 一条路径， 否则在步骤 50 判断该语句块对象的代码是否含有返回语句， 如果是， 则执行步骤 506将路 径的类别设为返回再执行歩骤 507， 否则直接执行步骤 507， 步骤 507记录语句名， 即在路径的语句组合 的最后添加该语句块名。所有路径处理完成后即得到输出路径集 502，输出路径集中的路径的数量与输入 路径集一致。
图 5B是当对象为分支时统计路径的流程示意图。当对象为分支吋， 依次计算该对象的子对象，前一 子对象计算后的输出路径集， 作为下一子对象的输入路径集， 直到所有子对象计算完毕， 最末子对象的 输出路径集就是该分支对象的输出路径集。如图 5B所示， 步骤 511记录分支， 即在输入路径集的每条路 径的分支组合的最后添加该分支名。 步骤 512扫描每一子对象， 如果完毕或没有子对象则结束， 否则执 行步骤 513。步骤 513判断该子对象是不是语句块，如果是则执行步骤 514，否则执行步骤 515，步骤 514 递归执行图 5A所示的计算， 并将计算后的路径集作为下一子对象的输入路径集； 步骤 515递归执行图 5C所示的计算， 并将输出的路径集作为下一子对象的输入路径集。步骤 51 和步骤 515执行后均返回到 步骤 512处理下一子对象直到结束。
图 5C是当对象为分支树时统计路径的流程示意图。 如图 5C所示， 步骤 523剔除返回路径： 将输入 路径集 521中类别为返回的路径拷贝到输出路径集 522中， 并从输入路径集 521删除。 步骤 524扫描子 对象 (分支)， 读取一个分支后， 步骤 525将输入路径集拷贝一份作为该分支的 ί俞入路径集。步骤 526针对 该分支递归执行图 5Β所示的计算， 然后返回到步骤 524处理下一分支。所有分支计算完成后， 步骤 527 将各分支的输出路径集汇总到整个分支树对象的输出路径集 522中， 计算结束。
•顶层分支对象的输入路径集只含一个空路径， 所述空路径是指语句组合和分支组合均为空的路径； 顶层分支对象的输出路径集就是程序的路径集。 路径集中的每条路径， 均记录了该路径所执行的语句:^ 对象序列和该路径所经历的分«象序列。
当程序较复杂时， 路径的数量会很庞大， 要设计测试用例覆盖所有路径是不现实的。 可以将一些特 定的代码所对应的对象隐藏， 统计路径时， 忽略隐藏的对象及其直接或间接子对象， 以便压缩路径的数 量， 如， 可以隐藏嵌套层次太深的对象。
下面详细描述图 1所示的步骤 C， 该步骤生成测试用例。 本实施例用提示表达式来描述测试用例， 即用提示表达式来构成测试用例，属于不可执行的测试用例，用户依据提示表达式确定具体的输入数据;' 编写测试代码， 即可执行测试。 所述提示表达式用于描述测试用例的输入数据的范围或条件， 包括： 判 定式、 反判定式及条件式、 反条件式。 .
首先描述判定式和条件式， 判定式就是判定表达式， 即判定中用于决定是否执行分支体的表达式， 一个判定有一个判定式。 条件式就是条件表达式， 在一个判定中， 有一个或多个条件， 各条件具有条件 式。 判定和条件都只有两个计算结果： 真或假。
我们用示例来进一步解释， 如下面的判定：
EFA>0AND B<0 THEN
A>0AND B<0就是该判定的判定式， 包含两个条件， 条件 1的条件式是： A>0; 条件 2的条件式是： B<0。
循环结构只关注是否会执行循环体一次， 因此， 循环结构的判定式是用于判断循环体是否至少会执 行一次的表达式。 WHILE结构的判定式比较容易理解，例如 WHILE X>0AND Y>0 DO...，判定式是 X>0
A D Y>0, FOR结构比较复杂' 有些 FOR结构为了语法简洁' 判定式常与其他表达式如初始化表达式、 递增表达式混合， 如 C十+的 FOR结构： for(int i=0; i<10; i++) ， 判定式是 10; 再如 BASIC的 FOR结 构： FOR 1=0 TO 10 THEN..., 其判定式是 1<=10， 再如 BASIC的 FOREACH Items DO...NEXT更特殊， 判断循环体是否至少会执行一次的是 Items 中集合项是否不为空， 因此可列出这样的判定式：
Items.Count>0, 由于本实施例生成的测试用例是不可执行的， 只是一种提示信息， 用户能理解并确定输 入数据就行， 因此， 即使 Items没有 Count属性， 这种判定式也是可行的。
反判定式就是判定式取反的结果， 反条件式就是条件式取反的结果。 取反就是将表达式中的等于操 作符、 关系操作符、 逻辑操作符用相反的操作符替换， 空表达式取反后仍为空， 所述相反的操作符如： 等于和不等于互为相反， 大于和小于等于互为相反， 小于和大于等于互为相反， 逻辑与和逻辑或互为相 反， 逻辑非的相反操作符一般是省略的即空的。 例如：
上述判定 IF A>0 AND B<0 THEN的反判定式是： A<=0 OR B>=0
条件 1的反条件式是： A<=0
条件 2的反条件式是： B>=0
再如， C++的判定 if(C)...， 其判定式是： C， 反判定式是- !C， 条件式是： C, 反条件式是： ！C。 本实施例在步骤 A将程序代码映射为结构对象， 由分支对象描述和处理判定， 因此，我们把判定式、 条件、 条件式、 反判定式、 反条件式称为分支的判定式、 条件、 条件式、 反判定式、 反条件式。 判定的 取假分支也对应于一个分支对象， 其判定式、 条件、 条件式、 反判定式、 反条件式均为空。 例如， 对于 判定： IF A>0 AND B<0 THEN， 如果没有 ELSE IF分支， 无论是否具有 ELSE分支， 均可对应于两个分 支对象： 分支 a和分支 b, 分支 b的判定式、条件'、 条件式、 反判定式、 反条件式均为空； 分支 a的判定 式为： A>0A D B<0， 反判定式为： A<-0 OR B>=0; 分支 a具有两个条件， 条件 1的条件式是： A〉0， 反条件式是： A<=0， 条件 2的条件式是： B<0， 反条件式是： B>=0。
判定有两种计算结果： 真和假， 判定覆盖就是要覆盖每个判定的真和假两种可能的计算结果， 由于 取假分支也对应于一个分支对象， 因此， 判定覆盖就是覆盖所有分支对象。
条件式覆盖就是覆盖各分支的每个条件式， 对于上述分支 a来说, 就是条件 1和条件 2均至少计算 一次， 不考虑条件的计算结果。 ·
每个条件有两种取值： 真和假， 我们用 *¾示取真， 用 F来表示取假， 并加一个下标表示^ #的 序号， 如分支 a的条件 1的取值表示为: Ti、 Fi， 条件 2的取值表示为： T2、 F2。 条件值覆盖就是要覆 盖各分支的所有条件的所有取值， 对于分支 a来说， 就是要覆盖条件值 Ti、 FK T2、 F2。
条件的取值有多种可能组合， 上述分支 a的条件值组合有： TlT2、 TiF2、 FiT2、 FiF2， 我们把分支 a 称为这些条件值组合的所在分支。 列出条件值组合的方法属于现有技术， 例如用多层循环可以得到分支 的全部条件值组合， 在此不作详述。 一个条件值组合实际上包括两方面信息： 分支的各个条件和每个 件的取值， 例如， 分支 a的条件值组合之一 TlF2， 是指条件 1取值为真， 条件 2取值为假。 .在条件值组 合中， 有些条件是不可达的， 本实施例将不可达的条件屏蔽。 不可达条件就是程序执行时不计算的条件 或者即使计算也没有意义的条件， 例如， 分支 a的判定式 A>0 AND B<0， 如果条件 1.的值为假， 则条件 2是不计算的， 因此， 当条件 1.为假吋， 条件 2是不可达的， 我们用字母 S来替换条件值组合中不可达 的条件的取值， 那么， 分支 a的四个条件值组合： TiT2、 TiF2、 FiT2、 F1F2应改为： TlT2、 TiF^ FiS, FiS.屛蔽不可达条件可能会造成某些条件值组合重复， 例如分支 a的条件值组合中， 屏蔽不可达条件造 成后两个条件值组合重复，我们把最后一个条件值组合删除，得到分支 a的有效条件值组合： TiT2、 TiF2、 F1S。可用数理逻辑算法判断条件值组合中的不可达条件， 属于现有技术， 在此不作详述。条件值组合覆 盖就是要覆盖各分支的所有有效条件值组合， 对于分支 a来说， 就是要覆盖它的三种条件值组合： TiT2、 TiF2、 FiS， 其中， 不可达的条件是可忽略的， 分支 a实际上要覆盖的是： TiT2、 TiF2、 Fi。 后文所说的 某一分支的条件值组合， 均是指该分支的有效条件值组合。
下面进一步详细描述本实施例计算各种分支对象的判定式的步骤：
空分支或 ELSE分支或 DEFAULT分支或顶层分支的判定式为空。
DO...WHILE结构的两个分支的判定式均为空。 由于 DO...WHILE结构的两个分支中，第一个分支肯 定会执行一次， 第二个分支肯定是不可达的， 它们的判定式在设计测试用例时可忽略， 因此把它们的判 定式视为空。
CASE分支用 SWITCH表达式与常量表达式组成等式作为判定式， 例如 C++的 SWUCH 结构： switc (X){case 0...case l...case N...}， 可组合出各分支的判定式为： Χ==0/Χ=-1/... Χ==Ν。
FOR分支用条件表达式作为判定式， 多个条件表达式用逻辑与连接， 并可用条件变量的初始值代替 该条件变量。 例如， C++的 FOR结构： for(int i=0;i<10;i++)..., 条件表达式为 i<10， 条件变量为 i， 其初 始值为 0， 可用条件变量的初始值代替该变量， 因此， 判定式为： 0<10。再如 Basic的 FOR结构 FOR 1-0 TO 10 THEN..., 其中 I=0 TO 10等价于 C++的 i=0; i<=10， 可以得到判定式为 0<=10。 如果具有'多个条 件表达式则用逻辑与连接，如 C++的 FOR结构 for(int i=0,intj=10; i<10j>0;i++，j--)...，其判定式为： 0<10 && 10>0o 本实施例将循环结构视为具有执行循环体和不执行循环体两个分支， 循环的判定实际上只考虑第 一次的计算结果， 因此， 当条件变量可确定初始值时， 可用其初始值代替该条件变量。 用条件变量的初 始值代替该变量的好处是提高依据提示表达式确定测试输入数据时的效率， 例如： 如果判定式为 0<10， 计算结果恒为真， 确定测试输入数据时无须考虑该表达式， 如果判定式为 0>=10， 计算结果恒为假， 含 有该判定式的测试用例是无效的。
其他分支用判定中的条件表达式作为判定式，如 C++的分支判定 if(a<0 && B>0)，其判定式为 a<0 && B>0, 再如 Basic的分支判定 IF A<0 AND B>0 THEN其判定式为： A<0AND B>0。
不同的编程语言有不同的语法， 但所有判定都是通过计箅出判定值来控制程序的执行路线， 因此， 所有分支都可以计算出判定式或列出可作为判定式的表达式， 当然， 有些分支的判定式为空。 计算出分 支的判定式后， 即可依据判定式推出反判定式， 条件式及反条件式， 具体的计算过程属于现有技术， 在 此不作详述。 '
本实施例为以下逻辑覆盖生成测试用例： 语句覆盖、 判定覆盖、 条件式覆盖、 条件值覆盖、 条件值 组合覆盖、 路径覆盖， 即依据不同的逻辑覆盖生成可完成该逻辑覆盖的一组测试用例， 其中每个测试用 例均由提示表达式组成。 一般来说， 白盒测试只选择其中一两种逻辑覆盖， 而不需要完成所有的逻辑覆 盖。 下面详细描述生成各种逻辑覆盖的测试用例的具体步骤：
C1.生成路径覆盖测试用例， 具体包括： 针对步骤 B所获得的路径集中的每一路径， 执行用于生成一 条路径的覆盖测试用例的步骤。
用于生成一条路径的覆盖测试用例的步骤具体包括： 针对所述路径的每一经历分支， 依次选择该经 历分支的在前姐妹分支的反判定式， 及该经历分支自身的判定式。 分支的姐妹分支， 就是该分支的父对 象的所有分支， 即直接属于同一分支树的所有分支， 也就是直接属于同一个分支结构的所有分支， 当然 也包括该分支自身， 其中， 排在该分支之前的分支称为该分支的在前姐妹分支。 图 6是生成一条路径的 覆盖测试用例的流程示意图， 如图 6所示，步骤 601扫描路径的分支组合， 针对每一经历分支， 步骤 602 扫描其姐妹分支， 针对每一姐妹分支， 在步骤 603根据分支名判断该姐妹分支是否是该经历分支自身， 如是， 则执行步骤 605， 否则执行步骤 604。步骤 604选择该姐妹分支的反判定式， 然后返回步骤 602处 理下一姐妹分支； 步骤 605选择该经历分支自身的判定式， 然后返回步骤 601处理下一个经历分支， 直 到所有经 分支均处理完毕。 ' ' C2.生成语句覆盖测试用例， 具体包括： ' 筛选可覆盖全部语句的最小数量的目标路径。 语句覆盖就是覆盖步骤 A所获得的结构对象中的所有 语句块对象， 一般来说， 达到语句覆盖的测试用例组合有多种， 本实施例用最小数量的测'试用例覆盖所 有的语句。 选择目标路径的具体步骤如下： 开始时所有语句均为未覆盖， 选择一条语句组合中包含未覆 盖语句数量最多的路径作为目标路径， 将该目标路径已包含的语句标为已覆盖' 继续选择直到所有语句 己覆盖， 就得到了可覆盖全部语句的最小数量的目标路径。
针对上述每一目标路径， 执行步骤 C1 所述的用于生成一条路径的覆盖测试用例的步骤生成测试用 例。 由于所选路径包含了所有语句， 因此， 覆盖这些路径的测试用例， 也就是语句覆盖的测试用例。
C3.生成判定覆盖测试用例， 具体包括：
筛选可覆盖全部分支的最小数量的目标路径。 判定覆盖又叫分支覆盖， 就是覆盖步骤 A所获得的结 构对象中的所有分支对象， 一般来说， 达到判定覆盖的测试用例组合有多种， 本实施例用最小数量的测 试用例覆盖所有的分支。 选择目标路径的具体步骤如下： 开始时所有分支均为未覆盖， 选择一条分支组 合中包含未覆盖分支数量最多的路径， 将该路径已包含的分支标为已覆盖， 继续选择直到所有分支已覆 盖， 就得到了可覆盖全部分支的最小数量的目标路径。 ―
针对上述每一目标路径， 执行步骤 C1 所述的用于生成一条路径的覆盖测试用例的步骤生成测试用 例。 由于所选路径包含了所有分支， 因此， 覆盖这些路径的测试用例， 也就是判定覆盖的测试用例。
C4.生成条件值组合覆盖测试用例， 具体包括： 针对每一分支的每一条件值组合， 执行用于生成一个 条件值组合的覆盖测试用例的步骤。
用于生成一个条件值组合的覆盖测试用例的步骤具体包括： 选择一条经历该条件值组合的路径作为 目标路径; 针对该目标路径的每一前导分支， 依次选择该前导分支的在前姐妹分支的反判定式， 及该前 导分支自身的判定式 ·； 针对该条件值组合， 依次选择取真值的条件的条件式， 及取假值的条件的反条件 式， 忽略不可达条件。 经历该条 直组合的路径， 是指经历该条件值组合所在分支的路径， 即分支组合 含有该条件值组合所在分支的路径。 所述前导分支' 是指在目标路径的分支组合中， 位于该条件值组合 所在分支之前的分支。 本步骤分成两步： 依据目标路径生成测试用例的前半部分和依据条件值组合生成 测试用例的后半部分。第一步与步骤 C1所述的用于生成一条路径的覆盖测试用例的步骤相似，唯一的区 别是， 只针对前导分支选择提示表达式， 忽略后续的分支， 具体步骤不再重复。 下面详细描述第二歩， 图 7是依据条件值组合生成测试用例的一部分的流程示意图， 如图 7所示， 步骤 701扫描条件值组合， 针对每一条件， 步骤 702判断是否不可达， 不可达条件就是在条件值组合中条件值标为 S的条件， 如是 则返回步骤 701处理下一条件，否则执行步骤 703，步骤 703判断该条件的取值，如果取真值则执行步骤 705， 否则执行步骤 704。 歩骤 704选择该条件的反条件式， 步骤 705选择该条件的条件式。 步骤 704和 705执行后均返回步骤 701处理下一条件， 直到所有条件均处理完毕。
C5.生成条件式稷盖测试用例， 具体包括： 针对每一分支， 执行下述步骤：
选择可覆盖该分支全部条件式的最小数量的目标条件值组合。选择目标条件值组合的具体步骤如下： 开始时该分支的所有条件均为未覆盖， 在该分支的条件值组合中选择一个可达的未 δ盖条件数量最多的 条件值组合， 将该条件值组合中可达的条件标为已覆盖， 继续选择直到该分支所有条件已覆盖， 就得到 了可覆盖该分支全部条件式的最小数量的目标条件值组合。 例如， 分支 a的条件值组合有： TiT2、 TlF2、 FlS， 第一次扫描， 选中 TiF2， 已将两个条件覆盖， 因此目标条件值组合就是 TlF2。
针对每一目标条件值组合，执行步骤 C4所述的用于生成一个条件值组合的覆盖测试用例的步骤生成 测试用例。 由于所选条件值组合包含了所有条件， 因此， 覆盖这些条件值组合的测试用例， 也就是条件 式覆盖的测试用例。
C6.生成条件值覆盖测试用例， 具体包括： 针对每一分支， 执行下述步骤：
选择可覆盖该分支全部条件值的最小数量的目标条件值组合。选择目标条件值组合的具体歩骤如下： 开始时该分支的所有条件值均为未覆盖， 在该分支的条件值组合中选择一个包含未覆盖条件值数量最多 的条件值组合， 将该条件值组合已包含的条件值标为已覆盖， 继续选择直到所有条件值已覆盖， 就得到 了可覆盖该分支全部条 直的最小数量的目标条件值组合。 例如， 分支 a的条件值组合有： TiT2、 TlF2、 FiS， 第一次扫描，.选中 TiT2， 它覆盖两个条件值： Τΐ、 Τ2， 再次扫描， 选中 TiF2， 它覆盖剩余的一个 条件值： F2,再次扫描，选中 FiS，它覆盖剩余的一个条件值： Fi， 因此目标条件值组合就是 TiT2、 TlF2、 FiS。
针对每一目标条件值组合，执行步骤 C4所述的用于生成一个条件值组合的覆盖测试用例的步骤生成 测试用例。 由于所选条件值组合包含了所有条件值， 因此， 覆盖这些条件值组合的测试用例， 也就是条 件值覆盖的测试用例。
为了得到更简洁的测试用例， 可以对测试用例进行化简， 即删除或合并测试用例中语义重复或矛盾 的部分。 化简一般以一组姐妹提示表达式为单位。 依据路径的一个经历分支及其在前姐妹分支生成的提 示表达式，称为一组姐妹提示表达式。示例一： C++的 SWrrCH结构： switch(X){case O·..case l…case 2…}， 各分支的判定式为： X==0/X==l X==2, 如果路径经历了第三分支， 则依据该经历分支及其在前姐妹分支 生成的提示表达式为： X!=0/X!=l/X==2, 显然， 前两个提示表达式是多余的； 示例二： C++的 IF结构， if(X>=1000)...else if (X>= 100)... else if(X>10)...else..., 如果路径经历了第四分支， 则依据该经历分支及其在 前俎妹分支生成的提示表达式为： <1000/X<100 X<=10, 显然， 前两个提示表达式是多余的。可以用字 符串对比的方法进行粗略的化简： 从后向前依次扫描各提示表达式' 如果某一变量或表达式是在后提示 表达式中某一等式的左操作数，则删除在前提示表达式中以该变量或表达式为左操作数的等式或不等式， 所述等式是指用等于操作符连接左操作数和右操作数的表达式， 所述不等式是指用不等于操作符连接左 操作数和右操作数的表达式， 如示例一； 如果某一变量或表达式是在后提示表达式中某一关系式的左操 作数， 则删除在前提示表达式中以该变量或表达式为左操作数的同符号的关系式， 所述关系式是指用关 系操作符如大于、 小于、 大于等于、 小于等于连接左操作数和右操作数的表达式， 所述同符号是指关系 操作符相同， 小于和小于等于、 大于和大于等于可以视为同符号， 如示例二。 使用词法分析和语法分析 技术解析提示表达式的语义， 然后删除或合并多余的表达式， 可以进行精确的化简， 具体实施步骤属于 现有技术， 在此不作详述。
上面详细描述了本发明的一个实施例， 在该实施例中， 使用提示表达式描述测试用例， 测试用例不 能直接执行， 用户依据提示表达式确定具体的测试输入数据， 编写可执行的测试代码， 才能执行测试。 后面描述的本发明的另一个实施例， 是在已有可执行的测试用例的基础上， 为了达到某一逻辑覆盖， 设 计新的测试用例。 由于已有可执行的测试用例， 该实施例从己有的测试用例中， 选择逻辑目标的近似测 试用例， 并用提示表达式描述修改提示， 用户依据修改提示修改近似测试用例， 即可得到用于 ¾盖预期 逻辑目标的测试用例。
图 S是本发明另一个实施例的总体流程图。如图 S所示， 步骤 A、 B与第一实施例相同， 步骤 D对 程序进行插装， 步骤 E编译并运行插装后的程序， 步骤 F记录逻辑覆盖信息， 步骤 G计算逻辑目标的近 似测试用例， 步骤 H生成修改提示。
如图 8所示， 歩骤 D对程序进行插装。 插装是软件测试领域常用的技术， 就是在被测试程序中插入 代码， 插装技术是现有技术， 在此不对具体实施细节作详细描述， 但不同的插装目的具有不同的插装函 数和插装位置， 下面详细描述本实施例的插装函数和插装位置。
插装函数就是插装代码调用的函数。 本实施例插装的目的是监视语句或条件的执行状况， 采用两个 插装函数： 语句监视函数和条件监视函数， 语句监视函数用于监视语句的执行， 在本实施例， 语句监视 函数在语句执行时传递语句的标识即语句块名， 条件监视函数用于监视条件的计算或计算结果， 在本实 施例， 牛监视函数在条件被计算时传递条#的值。 我们把语句监视函数称为函数 A， 把条件监视函数 称为函数 B。 本实施例可以为各种逻辑覆盖目标设计测试用例， 于语句覆盖、 判定覆盖和路径覆盖， 可以只使用函数 Α进行插装， 对于条件式覆盖、 条件值覆盖、 条件值组合覆盖， 则还应使用函数 B进行 插装。 .
函数 A原形如下 (伪代码)：.
VOBD 函数 A (语句块名）
函数 A可以没有返回值， 只有一个参数： 语句块名， 用于识别所监视的语句块。 插装时在各语句块 对象对应的代码前面插入函数 A的调用代码， 该语句块名作为实参。
函数 B原形如下 (伪代码)：
BOOL函数 B (分支名， 条件编号， 条件值）
函数 B返回一个布尔值， 该返回值恒为真 (TRUE)。三个参数：分支名，用于识别各分支； 条件编号， 用于识别一个分支里的各个条件； 条件值， 也是一个布尔值， 有真和假两个取值。 插装时， 在各条件的 前后两端分别插入函数 B_的调用代码， 前端调用时， 条件值实参为假， 后端调用时， 条件值实参为真; . 另外两个参数在前后端调用时一致， 分支对象名作为第一个实参， 分支中条件的编号作.为第二个实参。 调用函数 B的代码和条件表达式用逻辑与相连， 最好用括号把三者括起来。 由于函数 B总是返回一个真 值， 不会干扰判定及判定中各条件的计算过程和计算结果。
下面是插装的一个示例 (伪代码， 带下划线的为调用插装函数的代码)：
插装前：
IF A>0 AND B<= 0 THEN
语句块
END IF
插装后：
IF (函数 B (分支名, 1,假) AND A>0AND 函数 B (分支名, 1，真)) AND
(函数 B (分支名, 2,假) AND B<=0AND 函数 B (分支名， 2，真)） THEN . ' 函数 A (语句块名）
语句块
END IF
函数 A运行时传递语句名， 函数 B运行时传递分支名、 条件编号、 条件值， 因此， 它们要实现的功 能就是将这些信息发送给记录逻辑覆盖信息的步骤。如果记录逻辑覆盖信息的步骤属于另一个应用程序, 传递数据时可以使用进程间数据交换技术， 实现的途径有多种， 如共享内存、 网络、 命名管道， 也可以 将数据保存到文件， 由记录逻辑覆盖信息的步骤主动读取， 具体实现细节属于现有技术， 在此不作详述。
如图 8所示， 步骤 E编译并运行插装后的程序。 为了运行被测试程序， 需要有驱动程序， 驱动程序 设定输入数据， 并调用被测试程序， 使被测试程序得于执行。 由于本实施例已有可执行测试用例， 测试 用例就构成了驱动程序， 一般来说， 一个测试用例运行被测试程序一次。 例如下面的被测试代码 (编程语 言为 C++， 同样的方式适用于其他编程语 ¾»: int CMyClass::Add(int x, int y) return x + y;
}
可以用下面的驱动代码来运行：
CMyClass objl;
objl.Add(0, 0);
CMyClass obj2;
obj2.Add(l, 1);
包括两个测试用例， 使用不同的输入数据， 分别驱动被测试程序执行一次。 为了便于 i只别不同的测 试用例， 还可以在每个测试用例开始前向记录逻辑覆盖信息的步骤发送一个消息。
本实施例使用用户提供的编译器编译插装后的被测试程序及其驱动程序， 得到可执行文件， 运行可 执行文件' 即可运行被测试程序。
如图 8所示， 步骤 F记录逻辑覆盖信息。 被测试程序运行的时候， 插装代码传递逻辑覆盖信息， 步 骤 F记录这些信息， 具体包括：
记录语句覆盖信息： 当一个语句块被执行时， 函数 A传递该语句块名， .本实施例以一个测试用例所 执行的语句块作为一组， 记录语句块执行状况， 称为语句覆盖记录， 我们把一个测试用例所覆盖的语句 ±夬称为该测试用例的语句组合。 -
• 统计已覆盖路径及已覆盖路径的覆盖用例： 被测试程序运行结束后， 将路径的语句组合与各测试用 例的语句组合进行比较， 如果路径的语句组合是测试用例的语句组合的子集， 贝赅路径已被该测试用例 覆盖， 称为已覆盖路径， 该测试用例称为该路径的覆盖用例。 由于路径统计时不考虑循环的次数， 当循 环结构里含有分支时， 一个测试用例可能会覆盖多条路径， 也就是说， 一个测试用例可能是多条路径的 覆盖用例。
如杲插装时使用了函数 B， 还应记录条件覆盖信息。 函数 B传递的是条件执行时的条件值， 针对每 一条件， 本实施例用集合 (如数组或链表)来记录该条件在各个测试用例的执行结果， 称为条件覆盖记录 每个测试用例占用一个集合项，. 各集合项的初始值为未覆盖， 运行测试时， 如果条件前端的函数 B执行 了而后端的函数 B未执行， 则记录的是前端函数 B的条件值 (假)，如果两者都执行了， 则用后端函数的条 件值 (真)改写记录值。对于一个分支，一个测试用例所记录的条件值的组合，称为该分支在该测试用例的 条件值组合， 或该测试用例的该分支的条件值组合。 · .
如图 8所示， 步骤 G计算逻辑目标的近似测试用例。 逻辑目标就是所设计的测试用例意图覆盖的某 种逻辑单位。 例如， 语句块、 分支、 路径、 条件式、 条件值、 条件值组合， 都可以作为逻辑目标， 一般 来说， 逻辑目标是未覆盖的逻辑单位。 分支是判定覆盖的逻辑目标。 步骤 G从已有的测试用例中选择一 个近似测试用例， 因此， 近似测试用例是一个已有测试用例， 该测试用例作最小修改即可覆盖所述逻辑 目标， 最小修改是指需修改的数据尽可能少。 例如， 一个被测试程序有三个参数， 已有两个测试用例， 逻辑目标是一个语句块， 为了覆盖该语句块， 测试用例 1需要修改两个参数， 测试用例 2需要修改一个 参数， 贝麵试用例 2就是该逻辑目标的近似测试用例。不同的逻辑目标用不同的步骤计算近似测试用例， 分别详细描述如下：
G1.计算目标路径的近似测试用例：
逻辑目标是路径， 我们把该路径称为目标路径， 执行用于计算目标路径的近似路径的歩骤计算该目 标路径的近似路径； 目标路径的近 测试用例等于该目标路径的近似路径的覆盖用例。
用于计算目标路径的近似路径的步骤具体包括： 比较目标路径与各已覆盖路径的分支组合， 重叠分 支最多的已覆盖路径， 就是目标路径的近似路径。 重叠分支是从头开始的连续的相同分支。 多条已覆盖 路径重叠分支相同时， 比较首个非重叠分支， 首个非重叠分支在后优先和最接近优先， 具体来说， 比较 首个非重叠分支， 如果既有在后的候选路径又有在前的候选路径， 贝 I」选择在后的候选路径； 如果有多条 在后的候选路径， 则选择最前的； 如果有多条在前的候选路径， 则选择最后的， 所述 "在前"、 "在后"， 是指候选路径的首个非重叠分支与目标路径的首个非重叠分支相比较而言， 所述"最前"、 "最后"， 是指 候选路径的首个非重叠分支相比较而言， 由于本实施例的分支名是自动递增的， 并且所有首个非重叠分 支均属于同一个分支树对象， 比较分支名即可判别 "在前"、 "在后 "与 "最前"、 "最后"。 我们把目标路 径的第一个非重叠分支称为阻塞分支， 把近似路径的第一个非重叠分支称为临界分支。
G2.计算目标分支的近似测试用例：
逻辑目标是分支， 我们把该分支称为目标分支， 用下述步骤计算其近似测试用例：
选择所有经历目标分支的路径作为候选目标路径， 即选择分支组合中包含目标分支的路径作为候选 目标路径。
计 各候选目标路径的近似路径：针对每一候选目标路径，执行步骤 G1所述的用于计算目标路径的 近似路径的步骤计算其近似路径；
选择临界差最小的候选目标路径作为 ίϋ标路径： 计算各候选目标路径的临界差， 临界差最小的候选 目标路径为该目标分支的目标路径。 临界差就是候选目标路径中目标分支的偏移与该候选目标路径的近 似路径的临界分支的偏移的差， 分支的偏移是指在一条路径中， 该分支之前的分支的条数。 例如： 候选 目标路径的分支组合为： abdflb 目标分支为 f， 其近似路径的分支组合为 abekj, 则候选目标路径中目标 分支的偏移是 3， 近似路径的临界分支是 e (第一个非重叠分支)， 其偏移是 2， 临界差为 1。
目标分支的近似测试用例等于目标路径的近似路径的覆盖用例。
G3.计算目标语句的近似测试用例：
逻辑目标是语句块， · 我们把该语句块称为目标语句， 目标语句的近似测试用例等于该目标语句所在 分支的近似测试用例。 我们把目标语句所在的分支 (即该语句块的父对象)称为目标分支， 执行步骤 G2计 算目标分支的目标路径、 近似路径、 和近似测试用例， 该目标分支的目标路径、 近似路径、 和近似测试 用例就是目标语句的目标路径、 近似路径、 和近似测试用例。
G4.计算目标条件值组合的近似测试用例：
逻辑目标是条件值组合， 我们把该条件值组合称为目标条件值组合， 执行用于计算目标条件值组合 的近似测试用例的步骤计算该目标条件值组合的近似测试用例。
用于计算目标条件值组合的近似测试用例的步骤具体包括：
选择所有覆盖了目标分支的测试用例作为候选测试用例。目标分支是指目标条件值组合所在的分支。 依据条件覆盖记录， 如果一个测试用例的目标分支的条件值组合中， 至少有一个条件的值为真或假， 则 该测试用例覆盖了目标分支。 在完成了语句覆盖的基础上， 符合条件的候选测试用例一定存在， 如果不 存在； 应先完成语句覆盖》
选择相符条件值最多的候选测试用例作为目标条件值组合的近似测试用例。 具体来说， 针对每一候 选测试用例， 对比目标分支的该测试用例的条件值组合与目标条件值组合， 相符条件值最多的候选测试 用例为目标条件值组合的近似测试用例。
G5.计算目标条件式的近似测试用例：
逻辑目标是条件式， 我们把该条件式称为目标条件式， 把目标条件式所在的分支称为目标分支， 用 下述步骤计算该目标条件式的近似测试用例：
选择所有目标条件式可达的条件值组合作为候选目标条件值组合： 在目标分支的条件值组合中选出 目标条件式可达的条件值组合， 即目标条件式所对应的条件未被屛蔽的条件值组合作为候选目标条件值 组合。
计算各候选目标条件值组合的近似测试用例：针对各候选目标条件值组合，执行步骤 G4所述的用于 计算目标条件值组合的近似测试用例的步骤计算该候选目标条件值组合的近似测试用例。
选择已覆盖的在前条件式最多的候选条件值组合作为目标条件值组合： 计算各候选目标条件值组合 的近似测试用例所覆盖的目标分支的在前条件的个数， 最多者为目标条件值组合。 在前条件个数就是在 候选目标条件值组合中， 目标条件式之前的条件的个数， 不包括不可达条件； 测试用例所覆盖的条件， 是指目标分支在该测试用例的条件值组合中， 牛值为真或为假的条件。
目标条件式的近似测试用例等于目标条件值组合的近似测试用例。
G6.计算目标条件值的近似测试用例：
逻辑目标是条件值， 我们把该条件值称为目标条件值， 把目标条件值所在的分支称为目标分支， 用 下述步骤计算该目标条件值的近似测试用例：
选择所有包含目标条件值的条件值组合作为候选目标条件值组合： 在目标分支的条件值组合中选出 包含目标条件值的条件值组合， 作为候选目标条件值组合。
计算各候选目标条件值组合的近似测试用例：针对各候选目标条件值组合，执行步骤 G4所述的用于 计算目标条件值组合的近似测试用例的步骤计算该候选目标条件值组合的近似测试用例。
选择已覆盖的在前条件值最多的候选目标条件值组合作为目标条件值组合： 计算各候选目标条 j直 组合中已被近似测试用例所稷盖的在前条件值的个数， 最多者为 标条件值组合。 在前条件值就是在候 选目标条件值组合中， 目标条件值之前的条件值， 不包括不可达条件； 已被近似测试用例所禝盖的条件 值， 是指该条件值与近似测试用例的目标分支的条件值组合中相应条件值相符的条件值。
目标条件值的近似测试用例等于目标条件值组合的近似测试用例。
如图 8所示， 步骤 H生成修改提示。 修改提示用于指导对逻辑目标的近似测试用例进行修改， 使修 改后的测试用例可以覆盖该逻辑目标。 修改提示由提示表达式构成， 并分为两类： 已满足条件和待满足 条件， 待满足条件是近似测试用例未满足的条件， 依据待满足条件修改近似测试用例即可获得用以覆盖 预期的逻辑目标的测试用例； 已满足条件指出近似测试用例已满足的， 并且修改后的测试用例仍然应满 足的条件。 待满足条件是修改提示的核心， 已满足条件只是一种参考， 并不是必需的。
如果逻辑目标是路径、 语句块或分支， 用下述步骤生成修改提示：
HI.针对目标路径的每一经历分支， 依次选择该经历分支的在前姐妹分支的反判定式， 及该经历分支 自身的判定式。 阻塞前或临界前属已满足条件， 其他属待满足条件； 已满足条件可忽略。 目标路径是逻 辑目标的目标路径， 阻塞前是指： 目标路径的阻塞分支之前， 不包括阻塞分支， 临界前是指： 目标路径 的近似路径的临界分支之前， 包括临界分支， 也就是说， 据以选择提示表达式的分支中 (包括目标路径的 经历分支及经历分支的在前姐妹分支)， 如果出现了阻塞分支， 从该阻塞分支开始， 所选择的提示表达式 就是待满足条件， 或者， 如果出现了目标路径的近似路径的临界分支， 从该临界分支的下一分支开始， 所选择的提示表达式就是待满足条件。 目标路径、 近似路径、 阻塞分支与临界分支， 在步骤 Gl、 G2、 G3中已作详细描述。 由于已满足条件只是一种参考信息， 因此， 生成修改提示时可以忽略已满足条件。
上述步骤生成的已满足条件由判定式或反判定式组成， 如果分支的判定含有多个条件， 那么己满足 条件可能不够明确， 影响修改提示的精确性。 例如如下修改提示 (C++语法)：
已满足条件： a>0 ll <0 -
. 待满足条件： a==0 II x==l
仅从待满足条件看， 把 a的值改为 0或把 X的值改为 1都可以得到新的测试用例， 但已满足条件实 际上有两种可能： a>0或 b<0, '如果 a>0, 那么把 a的值改为 0就破坏了已满足条件， 新的测试用例将不 能覆盖预期逻辑目标。 为了得到更精确的修改提示， 可以使用改进后的步骤 HI , 具体包括：
针对目标路径的每一经历分支， 依次选择该经历分支的在前姐妹分支及该经历分支自身的提示表达 式， 其中， 阻塞前或临界前的分支按下述步骤选择提示表达式： 依据该分支在近似测试用例的条件值组 合， 选择取真值的条件的条件式， 取假值的条件的反条件式， 忽略不可达条件； 其他分支按下述步骤选 择提示表达式： 在前姐妹分支选择反判定式， 经历分支自身选择判定式。 阻塞前或临界前属已满足条件， 否则属待满足条件； 已满足条件可忽略。 近似测试用例是指逻辑目标的近似测试用例。 使用改进后的步 骤 HI生成的上述修改提示， 有两种可能结果：
已满足条件： a>0
待满足条件： a==0 ll x==l
在这种情况下， 只能把 X的值改为 1来得到符合预期的测试用例；
已满足条件： b<0
待满足条件： a==0 ll x==l
在这种情况下， 把 a的值改为 0或把 X的值改为 1都可以得到符合预期的测试用例。
根据上述歩骤 (包括改进前和改进后的步骤)生成的修改提示对近似测试用例进行修改，可得到可以覆 盖预期逻辑目标的测试用例， 但这种修改提示比较复杂， 待满足条件可能较多， 修改测试用例的工作量 有吋较大， 为了克服这些缺点， 上述步骤可以进一步包括： 忽略阻塞分支之后的分支。 也就是说， 上述 步骤在选择了阻塞分支的判定式后即结束， 忽略后面的分支。 这样， 待满足条件很少， 修改测试用例的 工作量很小， 通常只需修改一个数据， 但该测试用例覆盖的可能不是预期的逻辑目标， 例如， 当逻辑目 标是一条路径时， 实际覆盖的可能是另一条经过阻塞分支的路径， 但也达到了提高路径覆盖率的目的， 同时， 逻辑 标可以随便选择， 每次用最小的工作量提高逻辑覆盖率， 具有很高的效率。
如果逻辑目标是条件值组合、 条件式或条件值， 用下述歩骤生成修改提示：
H2.选择一条经历目标分支的已覆盖路径作为目标路径， 针对该目标路径的毎一前导分支， 依次选择 该前导分支的在前姐妹分支的反判定式， 及该前导分支自身的判定式； 针对目标条件值组合， 依次选择 取真值的条件的条件式， 取假值的条件的反条件式， 忽略不可达条件。 标分支是指逻辑目标所在的分 支， 也就是目标条件值组合所在的分支， 目标条件值组合在步骤 G4、 G5、 G6中已作详细描述。 选择一 条经历目标分支的已覆盖路径作为目标路径， 是指从已覆盖路径中选择一条分支组合包含了目标分支的 路径作为 H!标路径， 如果已完成语句覆盖， 目标路径一定存在。
与步骤 HI类似， 为了得到更精确的修改提示， 可以使用改进的步骤 H2， 具体包括：
选择一条经历目标分支的已殺盖路径作为目标路径， 针对该目标路径的每一前导分支， 依次选择该 前导分支的在前姐妹分支及该前导分支自身在近似测试用例的条件值组合中取真值的条件的条件式， 取 假值的条件的反条件式， 忽略不可达条件； 针对目标条件值组合， 依次选择取真值的条件的条件式， 取 假值的条件的反条件式' 忽略不可达条件。
上述步骤 (包括改进前和改进 的步骤)还可以进一歩包括：忽略目标条件及目标条件后的条件。 目标 条件是指： 对于条件值组合覆盖， 无目标条件， 对于条件式覆盖， 目标条件式对应的条件为目标条件， 对于条件值覆盖， 目标条件值对应的条件为目标条件。 对于条件式覆盖和条件值覆盖来说， 目标条件式 或目标条件值对应的条件及其后的条件的取值对于是否覆盖该条件式或条件值无影响， 因此选择提示表 达式时可以忽略这些条件。
上述步骤生成的修改提示中， 针对目标路径选择的提示表达式属已满足条件； 针对目标条件值组合 选择的提示表达式， 条件值已被近似测试用例所覆盖的条件对应的提示表达式属已满足条件， 其他属待 满足条件。 已被近似测试用例所覆盖的条件值， 是指该条件值与近似测试用例的目标条件值组合所在分 支的条件值组合中相应条件值相符的条件值。 已满足条件可忽略。
为了得到更简洁的修改提示， 可以对修改提示进行化简， 即删除或合并修改提示中语义重复或矛盾 的部分， 第一实施例的步骤 C对测试用例的化简作了详细描述， 本实施例的修改提示与第一实施例的测 试用例都是由提示表达式构成的， 因此， 对修改提示进行化简的详细步骤， 与第一实施例所述的对测试 用例化简的步骤相同。 - 修改提示由提示表达式构成， 在多数情况下， 依据修改提示可以确定新的测试数据， 但修改提示并 未描述代码间的依赖关系， 例如下面的伪代码：
函数名 (X) . ·
X = X + 1
IFX<1 THEN
目标语句
END IF
函数结束
为了覆盖目标语句， 修改提示包括提示表达式： X<1， 根据该提示表达式， 参数 X可以取值为 0， 显然， 由于代码间的依赖关系， X为 0并不能覆盖目标语句。 为了反映代码间的依赖关系， 修改提示还 可以包括提示代码， 所述提示代码就是目标路径所执行的代码， 目标路径是指步骤 HI或 H2所述的目标 路径。 如前所述， 路径具有语句组合 语句组合就是路径所执行的语句块对象序列， 语句块对象保存了 相应的代码， 路径的语句组合所对应的代码就是路径的执行代码。 一般来说， 提示代码只需包括目标路 径的前导代码， 如果逻辑目标是语句、 分支或路径， 前导代码是指阻塞分支之前的代码， 如果逻辑目标 是条件式、条件值或条件值组合， 前导代码是目标分支之前的代码， 目标分支就是逻辑目标所在的分支。 判断前导代码的方法是： 扫描目标路径的语句组合， 针对每一语句块对象， 如果它的直接或间接父分支 有一个是阻塞分支或目标分支， 则该语句块对象就是前导代码的终结点， 即前导代码是指路径的语句组 合中该语句块对象之前的语句块对象所对应的代码。 语句块对象的直接或间接父分支， 是指该语句块对 象的直接或间接父对象中的分支对象。 '
在步骤 G之前 ·， 还可以增加步骤 I， 该步骤统计逻辑覆盖， 即针对某种逻辑覆盖， 统计其已覆盖部 分和未覆盖部分。 步骤 I所获得的统计结果， 可用以显示已有测试的逻辑覆盖率， 也可以列出未覆盖的 逻辑目标供用户选择。
步骤 I具体包括：
11.统计路径覆盖， 即统计已 g盖路径和未覆盖路径， 具体步骤已在步骤 描述， 不再重复。
12.统计语句覆盖， 语句覆盖就是覆盖步骤 A所获得的所有语句块对象， 语句覆盖记录中所记录的语 句均为已覆盖语句， 其他为未覆盖语句。
13.统计分支覆盖， 已覆盖的路径所经历的分支， 就是已盈盖分支， 即已覆盖路径的分支组合中的所 有分支都是已覆盖分支， 所有已覆盖路径均未经历的分支为未覆盖分支。
14.统计条件式覆盖， 依据条件§盖记录， 如果该条件的各测试用例的值均为未 δ盖， 则该条件式未 覆盖， 否则该条件式已覆盖。
15.统计条件值 ®盖， 依据条件§盖记录， 如果该条件在各测试用例的值.至少有一个为真， 则该条件 的取真值已覆盖， 否则未覆盖； 用同样的方法统计条件的取假值。
16.统计条件值组合覆盖， 依据条件覆盖记录， 各测试用例的条件值组合为已 δ盖条件值组合， 条件 覆盖记录中未记录的条件值组合为未覆盖。
图 9是本发明再一个实施例的总体构成示意图。 如图 9所示， 本实施例是一个测试用例设计系统， 包括： 用于将程序代码映射为结构对象的装置 901， 用于统计程序路径的装置 902， 用于对程序进行插装 的装置 903， 用于记录逻辑覆盖信息的装置 904， 用于统计逻辑覆盖的装置 905， 用于计算逻辑目标的近 似测试用例的装置 906， 用于生成修改提示的装置 907， 其中， 装置 903是可选的， 该装置自动对程序进 行插装， 如果省略该装置， 可以用人工对程序进行插装； 装置 905和装置 907也是可选的。
使用本实施例示出的测试用例设计系统进行测试用例设计的步骤如下：
使用装置 901将程序代码映射为结构对象；
使用 902统计程序路径； .
使用装置 903对程序进行插装；
使用用户提供的编译器编译插装后的程序， 得到可执行文件， 运行可执行文件。
使用装置 904记录逻辑覆盖信息； '·
使用装置 905'统计逻辑覆盖；
使用装置 906计算逻辑目标的近似测试用例；
使用装置 907生成修改挺示。
本实施例依据前述实施例中步骤 Α所描述的方法实现装置 901； 步骤 B所描述的方法实现装置 902； 步骤 D所描述的方法实现装置 903； 步骤 F所描述的方法实现装置 904； 步骤 I所描述的方法实现装置 905； 步骤 G所描述的方法实现装置 906; 步骤 H所描述的方法实现装置 907， 在此不作重复。
以上实施例仅是本发明的较佳实施方式， 仅用以说明发本明而非限制， 对本发明进行修改、 变形或 者等同替换而不脱离本发明的精神和范围， 均应涵盖于本发明的范围之内。.

Claims

权 利 要 求 书
1.一种测试用例设计方法， 其特征在于， 包括步骤：
A.将程序代码映射为结构对象；
Β·统计程序路径；
C.生成测试用例。
2.裉据权利要求 1所述的测试用例设计方法， 其特征在于，所述结构对象包括： 语句块对象、分支树 对象及分支对象。
3.根据权利要求 2所述的测试用例设计方法，其特征在于，将程序逻辑结构分为顺序结构和分支结构； 所述语句块对象用于描述顺序结构， 所述分支树对象用于描述分支结构， 所述分支对象用于描述顶层分 支或分支结构的一个分支； 每一所述分支树对象至少嵌套了两个分支对象。
4.根据权利要求 1所述的测试用例设计方法， 其特征在于， 所述路径包括语句组合及分支组合。
5.裉据权利要求 1所述的测试用例设计方法，其特征在于，所述测试用例包括：提示表达式，所述提 示表达式包括： 判定式、 反^ J定式、 条件式及反条件式。
6.根据权利要求 5所述的测试用例设计方法，其特征在于，所述反判定式是判定式取反的结果，所述 反条件式是条件式取反的结果。
7.根据权利要求 6所述的测试用例设计方法， 其特征在于' 所述取反是指将表达式中的等于操作符、 关系操作符、 逻辑操作符用 反的操作符替换， 空表达式取反后仍为空。
8.裉据权利要求 1至 7任一权利要求所述的测试用例设计方法， 其特征在于，所述步骤 A具体包括: 解析所述程序代码的逻辑结构，依据所述程序代码的分支结构生成对应的分支树对象及对应的分支对象， 依据所述程序代码的顺序结构生成对应的语句块对象， 并将所述分支树对象和所述语句块对象嵌套于对 应层次的分 寸象中。
9.根据权利要求 1至 7任一权利要求所述的测试用例设计方法， 其特征在于， 所述步骤 B具体包括： 后序扫描所述结构对象， 针对每一结构对象， 将一个输入路径集作为初始数据进行路径统计， 顶层分支 对象的输入路径集只含一条空路径； 针对语句块对象， 在输入路径集的每条路径中记录该语句块名； 针 对分支对象， 在输入路径集的每条路径中记录该分支名， 前一子对象的输出路径集作为下一子对象的输 入路径集； 针对分支树对象， 将输入路径集的拷贝作为每一子对象的输入路径集。
10.根据权利要求 9所述的测试用例设计方法， 其特征在于， 所述步骤 B进一步包括: 当路径经过含 有返回语句的语句块对象时， 该路径即结束。
11.根据权利要求 9所述的测试用例设计方法， 其特征在于， 所述步骤 B进一步包括： 忽略隐藏的对 象及隐藏的对象的直接或间接子对象。 .
12.根据权利要求 1至 7任一权利要求所述的测试用例设计方法， 其特征在于， 用下述步骤计算分支 的判定式：
空分支或 ELSE分支或 DEFAULT分支或顶层分支的判定式为空；
DO...WHILE结构的两个分支的判定式均为空；
CASE分支用 SWITCH表达式与常量表达式组成等式作为判定式；
FOR分支用条件表达式作为判定式， 多个条件表达式用逻辑与连接， 并可用条件变量的初始值代替 该条件变量； .
其他分支用判定中的条件表达式作为判定式。
13.根据权利要求 1至 7任一权利要求所述的测试用例设计方法， 其特征在于， 所述步骤 C具体包括 下述步骤中的任一步骤：
C1.生成路径覆盖测试用例；
C2.生成语句覆盖测试用例；
C3.生成判定覆盖测试用例；
C4.生成条件值组合覆盖测试用例；
C5.生成条件式覆盖测试用例；
C6.生成条件值覆盖测试用例。
14.根据权利要求 13所述的测试用例设计方法， 其特征在于：
所述步骤 C1具体包括： 针对程序的每一路径， 执行用于生成一条路径的覆盖测试用例的步骤； 所述步骤 C2具体包括：筛选可覆盖全部语句的最小数量的目标路径； 针对每一所述目标路径，执行 用于生成一条路径的覆盖测试用例的步骤；
所述步骤 C3具体包括：筛选可覆盖全部分支的最小数 fi的目标路径； 针对每一所述目标路径， 执行 用于生成一条路径的覆盖测试用例的步骤；
所述步骤 C4具体包括：针对每一分支的每一条件值组合，执行用于生成一个条件值组合的覆盖测试 用例的步骤；
所述步骤 C5具体包括:针对每一分支，选择可 盖该分支全部条件式的最小数 fi的目标条件值组合； 针对每一所述目标条件值组合， 执行用于生成一个条件值组合的覆盖测试用例的步骤；
所述步骤 C6具体包括:针对每一分支，选择可覆盖该分支全部条件值的最小数量的目标条件值组合； 针对每一所述目标条件值组合， 执行用于生成一个条件值组合的覆盖测试用例的步骤。
15.根据权利要求 14所述的测试用例设计方法，其特征在于，所述用于生成一条路径的覆盖测试用例 的步骤具体包括： 针对所述路径的每一经历分支， 依次选择该经历分支的在前姐妹分支的反判定式， 及 该经历分支自身的判定式。
16.根据权利要求 14所述的测试用例设计方法，其特征在于，所述用于生成一个条件值组合的覆盖测 试用例的步骤具体包括： 选择一条经历该条件值组合的路径作为目标路径； 针对该目标路径的每一前导 分支， 依次选择该前导分支的在前姐妹分支的反判定式， 及该前导分支自身的判定式； 针对该条件值组 合， 依次选择取真值的条件的条件式， 及取假值的条件的反条件式， 忽略不可达条件。
17.根据权利要求 14所述的测试用例设计方法' 其特征在于， 所述步骤 C进一步包括： 用于将测试 用例化简的步骤。 ' . -
18.—种根据权利要求 1所述的测试用例设计方法， 其特征在于， 用下述步骤代替所述步骤 C:
D.对程序进行插装； '
E.编译并运行插装后的程序；
R记录逻辑覆盖信息；
G.计算逻辑目标的近似测试用例。
19:根据权利要求 18所述的测试用例设计方法， 其特征在于， 所述近似测试用例是已有测试用例。
20.根据权利要求 1S或 19所述的测试用例设计方法， 其特征在于， 用于插装的插装函数包括： 语句 监视函数； 所述语句监视函数用于监视语句的执行。
21.根据权利要求 20所述的测试用例设计方法，其特征在于，所述插装函数进一步包括：条件监视函 数； 所述条件监视函数用于监视条件的计算或计算结果。
22.根搪权利要求 21所述的测试用例设计方法，其特征在于，所述条件监视函数的插装位置是条件式 的两端。
23.根据权利要求 18或 19所述的测试用例设计方法， 其特征在于， 所述步骤 F具体包括步骤： 记录 语句覆盖信息； 统计已覆盖路径及已覆盖路径的覆盖用例。
24.根据权利要求 23所述的测试用例设计方法， 其特征在于， 所述步骤 F进一步包括步骤： 记录条 件覆盖信息。
25.根据权利要求 18或 19所述的测试用例设计方法， 其特征在于，所述步骤 G具体包括下述步骤中 的任一步骤：
G1.计算目标路径的近似测试用例；
G2.计算目标分支的近似测试用例；
G3.计算目标语句的近似测试用例；
G4.计算目标条件值组合的近似测试用例；
G5.计算目标条件式的近似测试用例；
G6.计算目标 牛值的 ¾似测试用例。
26.根据权利要求 25所述的测试用例设计方法， 其特征在于：
所述步骤 G1具体包括：执行用于计算目标路径的近似路径的步骤；所述目标路径的近似测试用例等 于该目标路径的近似路径的覆盖用例；
所述步骤 G2具体包括：选择所有经历目标分支的路径作为候选目标路径；计箅每一所述候选目标路 径的近似路径； 选择临界差最小的候选目标路径作为目标路径； 所述目标分支的近似测试用例等于所述 目标路径的近似路径的覆盖用例；
所述步骤 G3具体包括： 所述目标语句的近似测试用例等于该目标语句所在分支的近似测试用例； 所述步骤 G4具体包括:执行用于计箅目标条件值组合的近似测试用例的步骤计算所述目标条件值组 合的近似测试用例；
所述步骤 G5具体包括：选择所有目标条件式可达的条件值组合作为候选目标条件值组合；计算每一 所述候选目标条件值组合的近似测试用例； 选择已覆盖的在前条件式最多的候选条件值组合作为目标条 件值组合； 所述目标条件式的近似测试用例等于所述目标条件值组合的近似测试用例；
所述步骤 G6具体包括：选择所有包含目标条件值的条件值组合作为候选目标条件值组合；计算每一 所述候选目标条件值组合的近似测试用例； 选择已覆盖的在前条件值最多的候选条件值组合作为目标条 件值组合； 所述目标条件值的近似测试用例等于所述目标条件值组合的近似测试用例。
27.根据权利要求 26所述的测试用例设计方法，其特征在于：所述用于计算目标路径的近似路径的步 骤具体包括： 比较目标路径与各已覆盖路径的分支组合， 重叠分支最多的已覆盖路径， 就是目标路径的 近似路径； 所述用于计算目标条件值组合的近似测试用例的步骤具体包括： 选择所有覆盖了目标分支的 测试用例作为候选测试用例；选择相符条件值最多的候选测试用例作为目标条件值组合的近似测试用例。
28.根据权利要求 18所述的测试用例设计方法， 其特征在于， 进一步包括步骤：
H.生成修改提示。
29.根据权利要求 28所述的测试用例设计方法， 其特征在于， 所述修改提示包括： 提示表达式。
30.根据权利要求 29所述的测试用例设计方法， 其特征在于，所述修改提示包括待满足条件，也可以 进一步包括已满足条件。
31.根据权利要求 28所述的测试用例设计方法' 其特征在于， 所述步骤 H具体包括下述步骤中的任 —步骤：
HI .生成目标路径或目标语句或目标分支的近似测试用例的修改提示；
H2.生成目标条件值组合或目标条件式或目标条件值的近似测试用例的修改提示。
32.根据权利要求 31所述的测试用例设计方法， 其特征在于：
所述步骤 HI具体包括：针对目标路径的每一经历分支，依次选择该经历分支的在前姐妹分支的反判 定式， 及该经历分支自身的判定式； · ·
所述步骤 H2具体包括：选择一条经历目标分支的已覆盖路径作为目标路径，针对该目标路径的每一 前导分支， 依次选择该前导分支的在前姐妹分支的反判定式， 及该前导分支自身的判定式； 针对目标条 件值组合， 依次选择取真值的条件的条件式， 取假值的条件的反条件式， 忽略不可达条件。
33.根据权利要求 31所述的测试用例设计方法， 其特征在于：
所述步骤 HI具体包括：针对目标路径的每一经历分支，依次选择该经历分支的在前姐妹分支及该经 历分支自身的提示表达式， 其中， 阻塞前或临界前的分支按下述步骤选择提示表达式： 依据该分支在近 似测试用例的条件值组合， 选择条件值为真的条件的条件式， 条件值为假的条件的反条件式， 忽略不可 达条件； 其他分支按下述步骤选择提示表达式： 在前姐妹分支选择反判定式， 经历分支自身选择判定式； 所述步骤 H2具体包括：选择一条经历目标分支的己覆盖路径作为目标路径，针对该目标路径的每一 前导分支， 依次选择该前导分支的在前姐妹分支及该前导分支自身在近似测试用例的条件值组合中取真 值的条件的条件式， ； 假值的条件的反条件式， 忽略不可达条件； 针对目标条件值组合， 依次选择取真 值的条件的条件式， 取假值的条件的反条件式， 忽略不可达条件。
34.根据权利要求 32或 33所述的测试用例设计方法， 其特征在于， 所述步骤 HI进一步包括： 忽略 »分支之后的分支； 所述步骤 H2进一步包括： 忽略目标条件及目标条件后的条件。
35.根据权利要求 32或 33所述的测试用例设计方法， 其特征在于：
所述步骤 HI进一步包括： 阻塞前或临界前所选择的提示表达式属已满足条件， 其他属待满足条件； 所述步骤 H2进一步包括：针对目标路径选择的提示表达式属已满足条件；针对目标条件值组合选择 的提示表达式， 牛值已被近似测试用例所覆盖的条件对应的提示表达式属已满足条件， 其他属待满足 条件。
36.根据权利要求 35所述的测试用例设计方法， 其特征在于： 所述步骤 HI或 H2进一步包括： 忽略 已满足条件。
37.根据权利要求 32或 33所述的测试用例设计方法， 其特征在于： 所述步骤 H进一步包括： 用于将 修改提示化简的步骤。
38.根据权利要求 29所述的测试用例设计方法， 其特征在于： 所述修改提示进一步包括提示代码。
39.根据权利要求 18所述的测试用例设计方法， 其特征在于， 进一步包括步骤：
L统计逻辑稷盖。
40.根据权利要求 39所述的测试用例设计方法，其特征在于，所述步骤 I具体包括下述步骤中的任一 步骤.
11.统计路径覆盖；
12.统计语句覆盖；
13.统计分支覆盖；
14.统计条件式覆盖；
15.统计条件值覆盖；
16.统计条 直组合覆盖。
41.—种测试用 ¼设计系统， 其特征在于， 包括- 用于将程序代码映射为结构对象的装置；
用于统计程序路径的装置；
用于记录逻辑覆盖信息的装置； .
用于计算逻辑目标的近似测试用例的装置。
42.根据权利要求 41所述的测试用例设计系统， 其特征在于， 进一歩包括：
用于对程序进行插装的装置。
43.根据权利要求 41或 42所述的测试用例设计系统， 其特征在于， 进一步包括：
用于生成修改提示的装置。
44.根据权利要求 43所述的测试用例设计系统， 其特征在于， 进一步包括：
用于统计逻辑覆盖的装置。
PCT/CN2006/001899 2005-08-01 2006-07-28 Procede permettant de concevoir un scenario d'essai et systeme correspondant WO2007014521A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200510036189.0 2005-08-01
CNA2005100361890A CN1908892A (zh) 2005-08-01 2005-08-01 测试用例设计方法和系统

Publications (1)

Publication Number Publication Date
WO2007014521A1 true WO2007014521A1 (fr) 2007-02-08

Family

ID=37700009

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/001899 WO2007014521A1 (fr) 2005-08-01 2006-07-28 Procede permettant de concevoir un scenario d'essai et systeme correspondant

Country Status (2)

Country Link
CN (1) CN1908892A (zh)
WO (1) WO2007014521A1 (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101237662B (zh) * 2008-02-29 2011-09-14 华为终端有限公司 生成手机自动化测试用例的方法及装置
CN110888803A (zh) * 2019-11-08 2020-03-17 北京新能源汽车技术创新中心有限公司 一种将测试判定表转换为测试用例的方法及系统
CN111258916A (zh) * 2020-03-06 2020-06-09 贝壳技术有限公司 自动化测试方法、装置、存储介质及设备
CN111475410A (zh) * 2020-03-31 2020-07-31 北京经纬恒润科技有限公司 一种测试用例生成方法及装置
CN111566625A (zh) * 2018-01-17 2020-08-21 三菱电机株式会社 测试用例生成装置、测试用例生成方法和测试用例生成程序
CN112363922A (zh) * 2020-11-09 2021-02-12 中国农业银行股份有限公司 一种测试用例生成方法及其相关设备
CN117667750A (zh) * 2024-01-31 2024-03-08 北京纷扬科技有限责任公司 测试用例生成、测试方法、装置、计算机设备及存储介质

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101833508B (zh) * 2010-05-07 2012-06-13 北京大学 基于执行序列的JUnit测试用例化简方法
CN102141958B (zh) * 2011-03-09 2014-07-30 中国矿业大学 面向缺陷的路径覆盖测试数据进化生成方法
CN102708041A (zh) * 2011-07-12 2012-10-03 安徽中医学院 一种软件可信性质最小测试用例数的计算方法
CN102591777B (zh) * 2012-01-10 2016-04-13 深圳市同洲电子股份有限公司 一种单元测试代码生成方法及装置
CN103530223B (zh) * 2012-07-06 2018-05-04 百度在线网络技术（北京）有限公司 一种自动生成单元测试用例的方法及装置
CN103902255B (zh) * 2012-12-24 2019-01-15 腾讯科技（深圳）有限公司 一种函数关系调用树的生成方法及系统
CN103425584B (zh) * 2013-08-27 2016-01-13 上海复深蓝信息技术有限公司 基于Java字节码的大型应用回归测试信息处理方法
CN104657256B (zh) * 2013-11-19 2018-07-31 阿里巴巴集团控股有限公司 一种收集用例与代码之间映射关系的方法和装置
CN104731695B (zh) * 2013-12-19 2018-11-09 广州凯乐软件技术有限公司 一种支持表格驱动底层输入的单元测试系统和方法
JP6316120B2 (ja) * 2014-06-30 2018-04-25 日立オートモティブシステムズ株式会社 テストケース生成システム及びテストケースを記録した記録媒体
CN104077232B (zh) * 2014-07-21 2017-02-22 上海零一拼装信息技术有限公司 一种基于用例与源码双向追溯的测试装置及方法
CN104536897B (zh) * 2015-01-16 2018-02-13 安一恒通（北京）科技有限公司 基于关键字的自动测试方法及系统
CN106326090A (zh) * 2015-06-18 2017-01-11 中兴通讯股份有限公司 一种实现测试用例构建的方法及装置
CN108959056B (zh) * 2017-05-17 2021-11-16 富士通株式会社 测试用例生成方法和测试用例生成装置
CN110709814A (zh) * 2017-06-02 2020-01-17 三菱电机株式会社 程序代码生成装置和程序代码生成程序
CN109992498B (zh) * 2017-12-29 2022-12-02 北京京东尚科信息技术有限公司 测试用例的生成方法及系统、计算机系统
CN108763094B (zh) * 2018-06-01 2021-08-10 百度在线网络技术（北京）有限公司 测试用例生成方法、装置、设备及存储介质
CN109669436B (zh) * 2018-12-06 2021-04-13 广州小鹏汽车科技有限公司 一种基于电动汽车的功能需求的测试用例生成方法和装置
CN109828911A (zh) * 2018-12-26 2019-05-31 北京仁科互动网络技术有限公司 一种测试方法和装置
CN111949505B (zh) * 2019-05-14 2024-05-14 阿里云计算有限公司 一种测试方法、装置及设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001184232A (ja) * 1999-12-27 2001-07-06 Toshiba Corp ソフトウェアテストケース評価装置、ソフトウェア故障木装置、ソフトウェアハザード装置、およびソフトウェア振舞い記述装置
US20030126517A1 (en) * 2001-07-27 2003-07-03 Accordsqa Automated software testing and validation system
US20050050391A1 (en) * 2003-08-27 2005-03-03 Microsoft Corporation Access driven filtering

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001184232A (ja) * 1999-12-27 2001-07-06 Toshiba Corp ソフトウェアテストケース評価装置、ソフトウェア故障木装置、ソフトウェアハザード装置、およびソフトウェア振舞い記述装置
US20030126517A1 (en) * 2001-07-27 2003-07-03 Accordsqa Automated software testing and validation system
US20050050391A1 (en) * 2003-08-27 2005-03-03 Microsoft Corporation Access driven filtering

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101237662B (zh) * 2008-02-29 2011-09-14 华为终端有限公司 生成手机自动化测试用例的方法及装置
CN111566625A (zh) * 2018-01-17 2020-08-21 三菱电机株式会社 测试用例生成装置、测试用例生成方法和测试用例生成程序
CN111566625B (zh) * 2018-01-17 2024-01-09 三菱电机株式会社 测试用例生成装置、测试用例生成方法和计算机能读取的记录介质
CN110888803A (zh) * 2019-11-08 2020-03-17 北京新能源汽车技术创新中心有限公司 一种将测试判定表转换为测试用例的方法及系统
CN110888803B (zh) * 2019-11-08 2023-08-22 北京国家新能源汽车技术创新中心有限公司 一种将测试判定表转换为测试用例的方法及系统
CN111258916A (zh) * 2020-03-06 2020-06-09 贝壳技术有限公司 自动化测试方法、装置、存储介质及设备
CN111258916B (zh) * 2020-03-06 2023-08-15 贝壳技术有限公司 自动化测试方法、装置、存储介质及设备
CN111475410A (zh) * 2020-03-31 2020-07-31 北京经纬恒润科技有限公司 一种测试用例生成方法及装置
CN111475410B (zh) * 2020-03-31 2024-01-09 北京经纬恒润科技股份有限公司 一种测试用例生成方法及装置
CN112363922A (zh) * 2020-11-09 2021-02-12 中国农业银行股份有限公司 一种测试用例生成方法及其相关设备
CN117667750A (zh) * 2024-01-31 2024-03-08 北京纷扬科技有限责任公司 测试用例生成、测试方法、装置、计算机设备及存储介质
CN117667750B (zh) * 2024-01-31 2024-05-14 北京纷扬科技有限责任公司 测试用例生成、测试方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
CN1908892A (zh) 2007-02-07

Similar Documents

Publication Publication Date Title
WO2007014521A1 (fr) Procede permettant de concevoir un scenario d&#39;essai et systeme correspondant
US6408430B2 (en) Interactive software testing system and method
Garavel et al. Compilation and verification of LOTOS specifications.
JP5331203B2 (ja) グラフベース計算におけるデータ記録
Jones et al. Flow analysis of lazy higher-order functional programs
Pontelli et al. Justifications for logic programs under answer set semantics
US20080178149A1 (en) Inferencing types of variables in a dynamically typed language
Claessen et al. Generating constrained random data with uniform distribution
Asperti et al. A bi-directional refinement algorithm for the calculus of (co) inductive constructions
Kop WANDA-a higher order termination tool (system description)
Mosses Formal Semantics of Programming Languages:—An Overview—
Seidl et al. Constraint-based inter-procedural analysis of parallel programs
Johann A generalization of short-cut fusion and its correctness proof
Forgács et al. Feasible test path selection by principal slicing
Baldan et al. Generating test cases for code generators by unfolding graph transformation systems
Alexander et al. Analysis techniques for testing polymorphic relationships
Fernandez et al. State space reduction based on live variables analysis
Madet et al. An elementary affine λ-calculus with multithreading and side effects
Kenyon-Roberts et al. Supermartingales, ranking functions and probabilistic lambda calculus
Johann Short cut fusion: Proved and improved
Johann Short cut fusion is correct
Inverardi et al. Automatic verification of distributed systems: The process algebra approach
Sasano et al. A text-based syntax completion method using LR parsing and its evaluation
Facon et al. From OMT diagrams to B specifications
Sihler Constructing a static program slicer for R programs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06761604

Country of ref document: EP

Kind code of ref document: A1