Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
second. So we devise two tests: Test number Data Outcome 1 12 cannot vote 2 21 can vote 19.4 Black box (functional) testing 271 We have reasoned that we need two sets of test data to test this program. These two sets, together with a statement of the expected outcomes from testing, constitute a test specification. We run the program with the two sets of data and note any discrepancies between predicted and actual outcome. Unfortunately we can see that these tests have not investigated the important distinction between someone aged 17 and someone aged 18. Anyone who has ever written a program knows that using if statements is error prone, so it is advisable to investigate this particular region of the data. This is the same as recognizing that data values at the edges of the partitions are worthy of inclusion in the testing. Therefore we create two additional tests: Test number Data Outcome 3 17 cannot vote 4 18 can vote In summary, the rules for selecting test data for black box testing using equivalence partitioning are: 1. partition the input data values 2. select representative data from each partition (equivalent data) 3. select data at the boundaries of partitions. In the last program, there is a single input; there are four data values and therefore four tests. However, most programs process a number of inputs. Suppose we wish to test a program that displays the larger of two numbers, each in the range 0–10,000, entered into a pair of text boxes. If the values are equal, the program displays either value. Each input is within a partition that runs from 0 to 10,000. We choose values at each end of the partitions and sample values somewhere in the middle: first number: 0 54 10,000 second number: 0 142 10,000 Now that we have selected representative values, we need to consider what combinations of values we should use. Exhaustive testing would mean using every possible combination of every possible data value, but this is, of course, infeasible. Instead, we use every combination of the representative values. So the tests are:
272 Chapter 19 ■ Testing Test number 1st number 2nd number Outcome 1 0 0 0 2 0 142 142 3 0 10,000 10,000 4 54 0 54 5 54 142 142 6 54 10,000 10,000 7 10,000 0 10,000 8 10,000 142 10,000 9 10,000 10,000 10,000 Thus the additional step in testing is to use every combination of the (limited) representative data values. SELF-TEST QUESTION 19.1 In a program to play the game of chess, the player specifies the destination for a move as a pair of indices, the row and column number. The program checks that the destination square is valid, that it is not outside the board. Devise black box test data to check that this part of the program is working correctly. 19.5 ● White box (structural) testing This form of testing makes use of knowledge of how the program works – the structure of the program – as the basis for devising test data. In white box testing every statement in the program is executed at some time during the testing. This is equivalent to ensuring that every path (every sequence of instructions) through the program is executed at some time during testing. This includes null paths, so an if statement without an else has two paths and every loop has two paths. Testing should also include any exception handling carried out by the program. Here is the Java code for the voting checker program we are using as a case study: public void actionPerformed(ActionEvent event) { int age; age = Integer.parseInt(textField.getText()); if (age >= 18) { result.setText("you can vote"); } >
- Page 243 and 244: 220 Chapter 15 ■ Object-oriented
- Page 245 and 246: 222 Chapter 16 ■ Programming in t
- Page 247 and 248: 224 Chapter 16 ■ Programming in t
- Page 249 and 250: 226 Chapter 16 ■ Programming in t
- Page 251 and 252: 228 Chapter 16 ■ Programming in t
- Page 253 and 254: 230 Chapter 16 ■ Programming in t
- Page 255 and 256: 232 Chapter 16 ■ Programming in t
- Page 257 and 258: 234 Chapter 16 ■ Programming in t
- Page 259 and 260: 236 Chapter 16 ■ Programming in t
- Page 261 and 262: 238 Chapter 17 ■ Software robustn
- Page 263 and 264: 240 Chapter 17 ■ Software robustn
- Page 265 and 266: 242 Chapter 17 ■ Software robustn
- Page 267 and 268: 244 Chapter 17 ■ Software robustn
- Page 269 and 270: 246 Chapter 17 ■ Software robustn
- Page 271 and 272: 248 Chapter 17 ■ Software robustn
- Page 273 and 274: 250 Chapter 17 ■ Software robustn
- Page 275 and 276: 252 Chapter 17 ■ Software robustn
- Page 277 and 278: 254 Chapter 17 ■ Software robustn
- Page 279 and 280: 256 Chapter 17 ■ Software robustn
- Page 281 and 282: 258 Chapter 17 ■ Software robustn
- Page 283 and 284: 260 Chapter 18 ■ Scripting GNU/Li
- Page 285 and 286: 262 Chapter 18 ■ Scripting In sum
- Page 288: PART D VERIFICATION
- Page 291 and 292: 268 Chapter 19 ■ Testing We begin
- Page 293: 270 Chapter 19 ■ Testing within a
- Page 297 and 298: 274 Chapter 19 ■ Testing if (a >=
- Page 299 and 300: 276 Chapter 19 ■ Testing 3. apply
- Page 301 and 302: 278 Chapter 19 ■ Testing made con
- Page 303 and 304: 280 Chapter 19 ■ Testing 19.3 Dev
- Page 305 and 306: 282 Chapter 19 ■ Testing 19.2 The
- Page 307 and 308: 284 Chapter 20 ■ Groups The term
- Page 309 and 310: 286 Chapter 20 ■ Groups Of course
- Page 311 and 312: 288 Chapter 20 ■ Groups • Exerc
- Page 314 and 315: CHAPTER 21 This chapter explains: 2
- Page 316 and 317: Stage Input Output 21.3 Feedback be
- Page 318 and 319: Summary The essence and the strengt
- Page 320 and 321: CHAPTER 22 This chapter: 22.1 ● I
- Page 322 and 323: 22.2 The spiral model 299 to try to
- Page 324 and 325: 22.4 ● Discussion Exercises 301 A
- Page 326 and 327: CHAPTER 23 Prototyping This chapter
- Page 328 and 329: Therefore, in summary: ■ the prod
- Page 330 and 331: 23.5 Evolutionary prototyping 307 U
- Page 332 and 333: Reuse components 23.6 Rapid prototy
- Page 334 and 335: Pitfalls For users, the problems of
- Page 336 and 337: Answers to self-test questions 313
- Page 338 and 339: 24.2 ● Big-bang implementation 24
- Page 340 and 341: Tested component Figure 24.1 Top-do
- Page 342 and 343: 24.7 ● Use case driven implementa
272 Chapter 19 ■ Testing<br />
Test number 1st number 2nd number Outcome<br />
1 0 0 0<br />
2 0 142 142<br />
3 0 10,000 10,000<br />
4 54 0 54<br />
5 54 142 142<br />
6 54 10,000 10,000<br />
7 10,000 0 10,000<br />
8 10,000 142 10,000<br />
9 10,000 10,000 10,000<br />
Thus the additional step in testing is to use every combination of the (limited) representative<br />
data values.<br />
SELF-TEST QUESTION<br />
19.1 In a program to play the game of chess, the player specifies the destination<br />
<strong>for</strong> a move as a pair of indices, the row and column number. The<br />
program checks that the destination square is valid, that it is not outside<br />
the board. Devise black box test data to check that this part of the<br />
program is working correctly.<br />
19.5 ● White box (structural) testing<br />
This <strong>for</strong>m of testing makes use of knowledge of how the program works – the structure<br />
of the program – as the basis <strong>for</strong> devising test data. In white box testing every statement<br />
in the program is executed at some time during the testing. This is equivalent to<br />
ensuring that every path (every sequence of instructions) through the program is executed<br />
at some time during testing. This includes null paths, so an if statement without<br />
an else has two paths and every loop has two paths. Testing should also include<br />
any exception handling carried out by the program.<br />
Here is the Java code <strong>for</strong> the voting checker program we are using as a case study:<br />
public void actionPer<strong>for</strong>med(ActionEvent event) {<br />
int age;<br />
age = Integer.parseInt(textField.getText());<br />
if (age >= 18) {<br />
result.setText("you can vote");<br />
}<br />
>