19.2 Devise black box and white box test data to test the following program.. Try not to look at the text of the program, given below, until you have completed the design of the black bo
Trang 1278 Chapter 19 ■Testing
made considerably easier Various approaches are explained in Chapter 24 on incre-mental development
We have seen that exhaustive testing is infeasible Therefore complete testing is impossible and, whatever testing methods are used, they can never ensure that the software is free from bugs Thus testing is a poor technique but until formal verification becomes
wide-ly applicable it is a vital technique
However much we test our programs, using all our skill and intuition, we can never
be sure that we have eradicated all the faults The situation is well summed up by one
of computing’s gurus, Dijkstra, in his famous remark, “Testing can only show the pres-ence of bugs, never their abspres-ence.” This has been (anonymously) rephrased as, “Just because you have never seen a mermaid doesn’t mean that they don’t exist.” It can be reassuring to adopt the view that a test that reveals no bugs is a successful test But rather we should look upon such a test as unsuccessful!
It is difficult to get accurate data on the number of bugs present in production soft-ware because, unsurprisingly, organizations do not want to reveal this kind of informa-tion The indications are that there are typically between 2 and 50 bugs per 1,000 lines
of source code in commercial production software A figure like this is more properly
called a fault density It measures the number of known faults per 1,000 lines of code
(LOC) A figure of 2 is considered to be most creditable Ways of measuring this quan-tity are explained in Chapter 29 on metrics and quality assurance
The trouble is, of course, that bugs always surface at the worst possible time, for example, when you are demonstrating the completed software to the client This phe-nomenon has long been known to students of reliability, who quote Murphy’s laws:
1. “If a system can fail, it will,”
2. “and at the worst possible moment.”
Another, more objective, observation is that some bugs create serious faults, while others lie dormant and do not give any trouble
Chapter 31 on assessing methods looks at the evidence that is available to compare verification techniques, including testing The surprising indications are that simply inspecting code is more effective than carrying out testing
The worrying conclusion to any discussion of verification is that all software (of any significant size) contains faults
19.9 ● Discussion
Summary
Testing is one set of techniques for verifying software
Exhaustive testing is a practical impossibility
Trang 219.1 Consider a program that has 16 if-then statements in it Then there are 216 possi-ble paths through it If each test takes 50 microseconds and each action takes 50 microseconds (a gross underestimate), how much computer time is needed to test all program paths?
19.2 Devise black box and white box test data to test the following program The program specification is:
The program inputs a series of integers from the keyboard using a text field The program finds the largest of the numbers The numbers are terminated when a but-ton labeled Start Again is pressed
Try not to look at the text of the program, given below, until you have completed the design of the black box data
The program involves the following class:
class Biggest { private int largest;
public Biggest() { largest = 0;
} public void nextNumber(int n) {
if (n > largest) largest = n;
} public void display(TextField textField) { textField.setText("largest so far is" + largest);
} public void startAgain() { largest = 0;
} }
Exercises
In black box (or functional) testing, sample data based on the specification is used
This is termed equivalence partitioning
In white box (or structural) testing, the internal structure of the software is used
to select test data This means that every path through the program is tested
Unit testing tests each component in isolation Drivers and stubs are used to sub-stitute for missing components Integration testing tests components as they are brought together
•
Trang 3280 Chapter 19 ■Testing
19.3 Devise black box and white box test data to test the following program The program specification is:
The program is to determine insurance premiums for a holiday, based upon the age and gender (male or female) of the client
For a female of age >= 18 and <= 30 the premium is $5 A female aged >= 31 pays $3.50 A male of age >= 18 and <= 35 pays $6 A male aged >= 36 pays $5.50 People aged 50 or more pay half premium Any other ages or genders are an error, which is signaled as a premium of zero
The Java code for this program is:
public float calcPremium(float age, String gender) { float premium;
if (gender.equals("female"))
if ((age >= 18) && (age <= 30)) premium = 5.0f;
else
if (age >= 31) premium = 3.50f;
else premium = 0.0f;
else
if (gender.equals("male"))
if ((age >= 18) && (age <= 35)) premium = 6.0f;
else
if (age >= 36) premium = 5.5f;
else premium = 0.0f;
else premium = 0.0f;
if (age >= 50) premium = premium * 0.5f;
return premium;
}
19.4 Suggest features for software tools that could assist in using each of the following techniques:
■ black box testing
■ white box testing
19.5 Substantial testing of a system uncovers not a single error What conclusions would you draw?
Trang 4Answers to self-test questions
19.1 A row number is in three partitions:
1. within the range 1–8
2. less than 1
3. greater than 8
If we choose one representative value in each partition (say 3, –3 and 11 respectively) and a similar set of values for the column numbers (say 5, –2 and 34), the test data will be:
We now remember that data near the boundary of the partitions is important and therefore add to the test data for each partition so that it becomes:
1. within the range 1–8 (say 3)
2. less than 1 (say –3)
3. greater than 8 (say 11)
4. boundary value 1
5. boundary value 8
6. boundary value 0
7. boundary value 9
which now gives many more combinations to use as test data
➞
Trang 5282 Chapter 19 ■Testing
This book surveys studies of the types of fault that occur and explains the different
test-ing methods, in a very readable way: Marc Roper, Software Testtest-ing, McGraw-Hill,
1994
A readable practical review of testing techniques: Cem Kaner, Testing Computer Software, John Wiley, 1999.
The following book describes lessons in debugging and testing learned at Microsoft The author, Steve Maguire, is a strong advocate of stepping through code using the debugger as a good way of finding bugs The examples given are in C: Steve
Maguire, Writing Solid Code, Microsoft Press, 1993
19.2 There are four paths through the program, which can be exercised by the following test data:
19.3 There are three paths through the program extract, including the path
where neither of the conditions in the if statements are true But each
of the error messages can be triggered by two conditions Suitable test data is therefore:
Further Reading
•
Trang 6This chapter is about collaborative ways of working – both informal and semi-formal.
We look at structured walkthroughs, inspections and pair programming These aim to improve software productivity and quality, and perhaps also enhance the enjoyment of programming
Programmers are often seen as loners Given a clear specification, a programmer often carries out the complete process of program design, coding and testing entirely on their own Programmers are seen as low-profile technicians in contrast to the articulate extro-vert systems analysts Thus a program is sometimes seen as a personal work of art, the creation of an individual programmer These attitudes deny that “two heads are better than one”, that through discussion with others we can produce better work
The common experience that someone else can spot errors better than the author
lead to the invention of the structured walkthrough Credit for its invention belongs to
G Weinberg, in his book The Psychology of Computer Programming Weinberg
suggest-ed that programmers see their programs as an extension of themselves He suggestsuggest-ed that we get very involved with our own creations and tend to regard them as manifesta-tions of our own thoughts We are unable to see mistakes in our own programs, since to
do so would be to find a fault in ourselves, and this, apparently, is unacceptable to us
20.2 ● The individual and the error
20.1 ● Introduction
CHAPTER
20 Groups
This chapter explains:
■ how to use structured walkthroughs
■ how to use inspections
■ how to carry out pair programming
Trang 7284 Chapter 20 ■Groups
The term for this is cognitive dissonance The solution is to seek help with fault finding In
doing this we relinquish our private relationship with our work Programming becomes
ego-less programming This is a completely informal technique, carried out by colleagues in
a friendly manner It is not a formalized method carried out at fixed times and made into
a rigid procedure of the organization Indeed, to formalize ego-less programming would
be to destroy its ethos and therefore its effectiveness If you get a friend or a colleague to inspect your program, it is extraordinary to witness how quickly someone else can see a fault that has been defeating you for hours Studies also show that different people tend to uncover different types of fault This further suggests the use of team techniques
This is simply the term for an organized meeting at which a program (or some other product) is examined by a group of colleagues The major aim of the meeting is to try
to find bugs which might otherwise go undetected for some time (There are other goals, which are explained later.) The word “structured” simply means “well organ-ized” The term “walkthrough” means the activity of the programmer explaining step
by step the working of his/her program The reasoning behind structured walk-throughs is just this: that by letting other people look at your program, errors will be found much more quickly
To walkthrough a program you need only:
■ the specification
■ the text of the program on paper
In carrying out a walkthrough, a good approach is to study it one method at a time Some of the checks are fairly straightforward:
■ variables initialized
■ loops correctly initialized and terminated
■ method calls have the correct parameters
Another check depends on the logic of the method Pretend to execute the method
as if you were a computer, avoiding following any calls into other methods Check that:
■ the logic of the method achieves its desired purpose
During inspection you can also check that:
■ variable and method names are meaningful
■ indentation is clear and consistent
The prime goal of a walkthrough is to find bugs, but checking for a weakness in style may point to a bug
The evidence from controlled experiments suggests that walkthroughs are a very effective way of finding errors In fact walkthroughs are at least as good a way of iden-tifying bugs as actually running the program (doing testing)
Trang 8Although structured walkthroughs were initially used to find bugs in program code, the technique is valuable for reviewing the products at every stage of development – the requirements specification, a software specification, architectural design, component design, the code, the test data, the results of testing, the documentation
There are several key points in organizing walkthroughs successfully:
■ gauge the size and membership of the group carefully so that there are plenty of ideas, but so that everyone is fully involved
■ expect participants to study the material prior to the meeting
■ concentrate attention on the product rather than the person, to avoid criticizing the
author
■ limit the length of the meeting, so that everyone knows that it is business-like
■ control the meeting with the aid of agreed rules and an assertive chairperson
■ restrict the activity to identifying problems, not solving them
■ briefly document the faults (not the cures) for later reference
The benefits of structured walkthroughs can be:
1. software quality is improved because
■ more bugs are eliminated
■ the software is easier to maintain, because it is clearer
2. programmer effort is reduced because
■ specifications are clarified before implementation
■ errors are detected early, and so costly rework is avoided
■ the time spent at the meeting (and in preparation for it) is more than repaid in time saved
3. meeting deadlines is improved because
■ visibility of the project is better (so potential catastrophes are prevented)
■ major errors are avoided early
4. programmer expertise is enhanced because
■ everyone learns from everyone else
5. programmer morale is improved because
■ people gain satisfaction from better work
■ people get to find out what is going on
■ people enjoy the discussions with colleagues
Trang 9286 Chapter 20 ■Groups
Of course walkthroughs do mean that the individual has to be relaxed about pre-senting their work to colleagues
These are similar to structured walkthroughs – a group of people meet to review a piece
of work But they are different from walkthroughs in several respects Checklists are used
to ensure that no relevant considerations are ignored Errors that are discovered are clas-sified according to type and carefully recorded on forms Statistics on errors are com-puted, for example in terms of errors per 1,000 lines of code Thus inspections are not just well organized, they are completely formal In addition management is informed of the results of inspections, though usually they do not attend the meeting Thus inspec-tions are potentially more threatening to the programmer than walkthroughs
There are other, minor, differences between inspections and walkthroughs Normally there are only four members in an inspection team:
■ the moderator, who co-ordinates activities
■ the person who designed the program component being inspected
■ the programmer
■ the tester – a person who acts as someone who will be responsible for testing the component
The essence of inspections is that the study of products is carried out under close management supervision Thus inspections are overtly a mechanism for increased con-trol over programmers’ work, similar to the way that quality concon-trol is carried out on a factory floor Some programmers might feel threatened in this situation and become defensive, perhaps trying to hide their mistakes Perhaps this makes the discovery of errors more painful, and programming a less enjoyable activity
From an organizational point of view, keeping records of faults discovered during inspections provides information to predict the quality of the software being written Also, by highlighting common mistakes it can be used to improve programmers self-awareness and thereby improve their skills
Here two people sit down together, looking at the same computer screen, and carry out programming, including writing and applying tests
The people have different roles One has the use of the keyboard and mouse They are thinking and working on the implementation of the current piece of code (usually
a particular method) They are thinking on a small scale and locally The other person does two things:
■ observe, looking for errors
■ think more strategically
20.4 ● Inspections
Trang 10The strategic thinking considers the role of the method within the class, and whether this method is appropriate within the context of the whole system The person thinks about such questions as: Which other components use it? Can the system be simplified so that this method is just not needed? Can the method be generalized so that it is more
wide-ly useful? Is this method in the right place, or should it be relocated into some other class? The pair periodically switch roles, so that overall they are working as equals Pairs don’t stay together, but change from day to day It simply depends on who is available, but the people are drawn from the same project team, so they have a shared under-standing of the project And no one forces people to pair up if they do not get along When a pair starts work, it may be that one person will have more experience or expertise Later, the gap narrows, so that they are genuinely collaborating on an equal basis, one person’s strengths compensating for the other’s weaknesses
The central feature of pair programming is that two people are communicating intensely, sharing ideas, learning from each other, supporting each other, articulating ideas verbally and solving problems It is creative, sociable, enjoyable and effective It is claimed that pair programming improves productivity, code quality and job satisfaction Even though, at first sight, twice the effort is spent on development, the time is more than reclaimed in more effective working
Of course, pair programming means that pairs of people are working closely – almost intimately – together This depends on an organizational culture that is collaborative and supportive
Perhaps the ultimate method for collaborative working aimed at reducing bugs is open source development This is such an important technique that we devoted a whole sep-arate chapter to the topic
How effective are the techniques of walkthroughs, inspections and pair program-ming? The answer is that they are surprisingly effective as compared with using testing
We review the evidence in Chapter 31 on assessing methods
20.6 ● Discussion
Summary
A structured walkthrough is a meeting at which a document is examined by a group
of people in order to find errors Structured walkthroughs are based on the prem-ise that ideas that are shared will be the better for it The careful organization of a walkthrough is important Walkthroughs can lead to improved software quality – reliability and maintainability – because of the scrutiny of project material by a group Effort can be reduced and deadlines more easily met
Inspections are a more formal approach to a group review meeting
In pair programming, two people sit at the computer, working closely together on design, coding and testing