The art of software testing. Myers (2nd edition) (2004) (The art of software testing. Myers (2nd edition) (2004).pdf), страница 12

If an input condition specifies a set of input values and thereTest-Case Design55is reason to believe that the program handles each differently(“type of vehicle must be BUS, TRUCK, TAXICAB,PASSENGER, or MOTORCYCLE”), identify a validequivalence class for each and one invalid equivalenceclass (“TRAILER,” for example).4.

If an input condition specifies a “must be” situation, such as“first character of the identifier must be a letter,” identifyone valid equivalence class (it is a letter) and one invalidequivalence class (it is not a letter).If there is any reason to believe that the program does not handleelements in an equivalence class identically, split the equivalence classinto smaller equivalence classes. An example of this process will beillustrated shortly.Identifying the Test CasesThe second step is the use of equivalence classes to identify the testcases. The process is as follows:1.

Assign a unique number to each equivalence class.2. Until all valid equivalence classes have been covered by(incorporated into) test cases, write a new test case coveringas many of the uncovered valid equivalence classes as possible.3. Until your test cases have covered all invalid equivalenceclasses, write a test case that covers one, and only one, of theuncovered invalid equivalence classes.The reason that individual test cases cover invalid cases is that certain erroneous-input checks mask or supersede other erroneousinput checks. For instance, if the specification states “enter booktype (HARDCOVER, SOFTCOVER, or LOOSE) and amount(1–999),” the test case, XYZ 0, expressing two error conditions(invalid book type and amount) will probably not exercise the checkfor the amount, since the program may say “XYZ IS UNKNOWNBOOK TYPE” and not bother to examine the remainder of theinput.56The Art of Software TestingAn ExampleAs an example, assume that we are developing a compiler for a subset of the FORTRAN language, and we wish to test the syntaxchecking of the DIMENSION statement.

The specification is listedbelow. (This is not the full FORTRAN DIMENSION statement; it hasbeen cut down considerably to make it a textbook-sized example.Do not be deluded into thinking that the testing of actual programsis as easy as the examples in this book.) In the specification, items initalics indicate syntactic units for which specific entities must be substituted in actual statements, brackets are used to indicate optionitems, and an ellipsis indicates that the preceding item may appearmultiple times in succession.A DIMENSION statement is used to specify the dimensions of arrays.The form of the DIMENSION statement isDIMENSION ad[,ad]...where ad is an array descriptor of the formn(d[ ,d]...)where n is the symbolic name of the array and d is a dimensiondeclarator.

Symbolic names can be one to six letters or digits,the first of which must be a letter. The minimum and maximumnumbers of dimension declarations that can be specified for anarray are one and seven, respectively. The form of a dimensiondeclarator is[lb: ]ubwhere lb and ub are the lower and upper dimension bounds.A bound may be a constant in the range −65534 to 65535 or thename of an integer variable (but not an array element name).If lb is not specified, it is assumed to be one. The value of ub mustbe greater than or equal to lb. If lb is specified, its value may benegative, zero, or positive. As for all statements, the DIMENSIONstatement may be continued over multiple lines. (End ofspecification.)Test-Case Design57The first step is to identify the input conditions and, from these,locate the equivalence classes.

These are tabulated in Table 4.1. Thenumbers in the table are unique identifiers of the equivalence classes.Table 4.1Equivalence ClassesInput ConditionNumber of arraydescriptorsSize of array nameArray nameArray name starts withletterNumber of dimensionsUpper bound isInteger variable nameInteger variable starts withletterConstantLower bound specifiedUpper bound to lowerboundSpecified lower boundLower bound isMultiple linesValid EquivalenceClassesone (1), > one (2)Invalid EquivalenceClassesnone (3)1–6 (4)has letters (7),has digits (8)yes (10)0 (5), > 6 (6)has somethingelse (9)no (11)1–7 (12)constant (15),integer variable(16)has letter (19), hasdigits (20)yes (22)0 (13), > 7 (14)array element name(17), somethingelse (18)has something else(21)no (23)−65534–65535 (24)≤65534 (25),>65535 (26)yes (27), no (28)greater than (29),equal (30)negative (32), zero(33), > 0 (34)constant (35), integervariable (36)yes (39), no (40)less than (31)array element name(37), somethingelse (38)58The Art of Software TestingThe next step is to write a test case covering one or more validequivalence classes.

For instance, the test caseDIMENSION A(2)covers classes 1, 4, 7, 10, 12, 15, 24, 28, 29, and 40. The next step isto devise one or more test cases covering the remaining valid equivalence classes. One test case of the formDIMENSION A 12345 (I,9, J4XXXX,65535,1,KLM,X100), BBB(−65534:100,0:1000,10:10, I:65535)covers the remaining classes. The invalid-input equivalence classes,and a test case representing each, are(3):(5):(6):(9):(11):(13):(14):(17):(18):(21):(23):(25):(26):(31):(37):(38):DIMENSIONDIMENSION (10)DIMENSION A234567(2)DIMENSION A.1(2)DIMENSION 1A(10)DIMENSION BDIMENSION B(4,4,4,4,4,4,4,4)DIMENSION B(4,A(2))DIMENSION B(4,,7)DIMENSION C(I.,10)DIMENSION C(10,1J)DIMENSION D(−65535:1)DIMENSION D(65536)DIMENSION D(4:3)DIMENSION D(A(2):4)D(.:4)Hence, the equivalence classes have been covered by 18 test cases.You may want to consider how these test cases would compare to aset of test cases derived in an ad hoc manner.Test-Case Design59Although equivalence partitioning is vastly superior to a randomselection of test cases, it still has deficiencies.

It overlooks certaintypes of high-yield test cases, for example. The next two methodologies, boundary-value analysis and cause-effect graphing, cover manyof these deficiencies.Boundary-Value AnalysisExperience shows that test cases that explore boundary conditions havea higher payoff than test cases that do not. Boundary conditions arethose situations directly on, above, and beneath the edges of inputequivalence classes and output equivalence classes.

Boundary-valueanalysis differs from equivalence partitioning in two respects:1. Rather than selecting any element in an equivalence class asbeing representative, boundary-value analysis requires thatone or more elements be selected such that each edge of theequivalence class is the subject of a test.2. Rather than just focusing attention on the input conditions(input space), test cases are also derived by considering theresult space (output equivalence classes).It is difficult to present a “cookbook” for boundary-value analysis,since it requires a degree of creativity and a certain amount of specialization toward the problem at hand.

(Hence, like many otheraspects of testing, it is more a state of mind than anything else.) However, a few general guidelines are as follows:1. If an input condition specifies a range of values, write testcases for the ends of the range, and invalid-input test cases forsituations just beyond the ends. For instance, if the validdomain of an input value is −1.0–+1.0, write test cases forthe situations −1.0, 1.0, −1.001, and 1.001.2. If an input condition specifies a number of values, write testcases for the minimum and maximum number of values and60The Art of Software Testingone beneath and beyond these values. For instance, if aninput file can contain 1–255 records, write test cases for 0, 1,255, and 256 records.3.

Use guideline 1 for each output condition. For instance, if aprogram computes the monthly FICA deduction and if theminimum is $0.00 and the maximum is $1,165.25, write testcases that cause $0.00 and $1,165.25 to be deducted. Also,see if it is possible to invent test cases that might cause a negative deduction or a deduction of more than $1,165.25. Notethat it is important to examine the boundaries of the resultspace because it is not always the case that the boundaries ofthe input domains represent the same set of circumstances asthe boundaries of the output ranges (e.g., consider a sinesubroutine). Also, it is not always possible to generate a resultoutside of the output range, but it is worth considering thepossibility, nonetheless.4.