Relación entre cada ensamble de clases de talla y las variables ambientales

During the coding stage, the programmer writes the programs and tests them. We assume that you understand what coding is, so we won't describe it here. But we will describe g/<zs.s

box testing (sometimes called white box testing), because this is the kind of testing the

programmer is especially well equipped to do during coding.

Glass box testing is distinguished from black box testing, in which the program is treated as a black box. You can't see into it. The tester (or programmer) feeds it input data, observes output data, but does not know, or pretends not to know, how the program works. The test designer looks for interesting input data and conditions that might lead to interesting outputs. Input data are "interesting" representatives of a class of possible inputs if they are the ones most likely to expose an error in the program.

In contrast, in glass box testing, the programmer uses her understanding and access to the source code to develop test cases. This provides benefits:

• Focused testing: The programmer can test the program in pieces. She can write special test code that feeds interesting values to an isolated module, and reports intermediate results obtained from the module. It's much easier to give an individual suspect module a thorough workout in glass box testing than in black box testing.

• Testing coverage: The programmer can also find out which parts of the program are exercised by any test. She can find out which lines of code, which branches, or which paths haven't yet been tested, and she can add tests that she knows will cover the areas not yet touched. We briefly discuss

coverage monitors, which track and report the degree of testing coverage, in this chapter and in

Chapter 11.

• Control flow: The programmer knows what the program is supposed to do next, as a function of its current state. She can modify the program so that it constantly reports what it's doing, or she can use a special program called a debugger to run the program and track the order in which lines of code are executed. (Debuggers track many other things too, such as the values of key variables and reads from or writes to identified areas of memory.) When the program goes astray, she can tell immediately. • Data integrity: The programmer knows which parts of the program modify (or should modify) any item of data. By tracking a data item through the system, she can spot data manipulation by inappropriate modules. She might also write special code th at calculates the value that a test variable should have at a given point in the program, compares this with the value the variable actually has, and reports an error. This is an example of automated testing using an oracle, which we further discuss, briefly, in Chapter 11.

44

GLASS BOX CODE TESTING IS PART OF THE CODING STAGE

• Internal boundaries: The programmer can see internal boundaries in the code that are completely invisible to the outside tester. For example, a program might use different calculation methods to estimate values of the chi-square function depending on whether its shape parameter (degrees of freedom) is smaller or larger than 100 (recommended by Abramowitz & Stegun, 1964, p. 941). Other programs will put input data into temporary storage if too much comes too quickly. The programmer is in a much better position than a blade box tester to force a memory or processing time overflow and see how well the program handles temporary storage.

• Algorithm-specific testing: For example, there are many ways to invert a matrix, and well under stood ways to miscalculate the result. The programmer can apply standard numerical analysis techniques to predict (and thus check) the results. We'll mention Carnahan, Luther, & Wilkes (1969) as an old but instructive general sourcebook of numerical analysis. If your program uses traditional algorithms to perform complicated calculations, and you know the algorithms, check the most technical university library in your area. You might find a book with directly rele vant test cases and expected results.

We think of glass box testing as part of the programming process because so many programmers routinely run glass box tests of their modules just before and just after integrating them with other parts of the system. This is common good practice, taught to all programming students. However, you should know that most testing textbooks spend most of their pages describing glass box techniques. These authors expect testers, as well as programmers, to run glass box tests.

This book is about black box testing, which is what most of the testers that we know spend most of their time , doing. (The exceptions test mainframe data processing applications, which are better analyzed by authors like Beizer, Hetzel, and Myers than by us.) Black box testers don't invest the time learning the source code; instead they study the program from the outside, which is how the customer will work with it And, just as the glass box approach makes it easy to run certain types of tests, black box thinking exposes errors that will elude glass box testers (see Chapter 12, "What types of tests to cover in testplanning documents: What glass box testing misses").

In the next few sections we describe basic glass box concepts that you must be familiar with or traditionally trained testers will consider you an ignoramus. We briefly return to glass box methods in Chapters 7 and 11. In the Appendix we describe many software errors in terms of the internal problem, letting you imagine black box tests that could expose the symptoms of one of these problems, in the particular type of program you're testing.

S

Structural testing is glass box testing. The main concern is proper selection of program or subprogram paths to

exercise during the battery of tests.

Functional testing is one type of black box testing. Functions are tested by feeding them input and

45