110 likes | 332 Views
Test Case Development. Test case development is very much dependent on the goals of testing. The more aggressive the goal, the more we will need to spend on test case development.
E N D
Test Case Development • Test case development is very much dependent on the goals of testing. • The more aggressive the goal, the more we will need to spend on test case development. • In test case development we would like to ensure that as much of the requirements and as much of the design & code are covered
Ideal Testing Situation Requirement. Coding testing Requirements grow and not all are implemented Implementation grows more than the requirements Requirements, implementation and testing almost matches
Two Major Types of Testing • Black Box Testing • Develop test cases to ensure the requirements are met • Consider the inputs and the outputs (mostly externals), without considering the internal processing (code and design logic) • Good for catching missing requirements • White Box Testing • Develop test cases to ensure that the code is performing what it is suppose to • Consider the internal processing (code and design logic) • Good for catching design anamolies, extraneous code or extra implementation
How would You Test This Requirement? • Develop a Software Function which will perform the following: • Given three inputs, a, b, and c, it provide the roots for the quadratic equation: ax2 + bx + c = 0
Simple Example (book page 374) • Given three inputs, a, b, and c, provide the roots for the quadratic equation: ax2 + bx + c = 0 Another Black Box Approach: - Again, we do not consider the code implementation. - Consider the inputs only. - For each of the variables a, b, and c consider: - a < b < c - a < c < b - b < a < c - b < c < a - c < b < a - c < a < b - Thus we could generate a total of 6 different permutations A Black Box Approach: - We do not consider the code implementation. - Consider the inputs only. - For each of the variables a, b, and c consider: i) negative value ii) zero iii) positive value - Thus we could generate a total of 3 x 3 x 3 = 27 test cases to cover all the above permutations
Simple Example (book page 374) cont Input a,b,c A possible flow diagram of the code for White Box testing Inputs Valid (include a=0) No Error message Yes R1 = [-b +√ (b2 -4ac) ] /2a R2 = [-b -√ (b2 – 4ac) ] /2a Output R1 & R2
Simple Example (book page 374) cont. • White Box Approach : • - We consider the implementation and look at the code. • - We need to generate a test case for: • input validity check and error message path • root computation path • - We also notice that the implementation uses the quadratic root formula • [-b + or - √ (b2 – 4ac) ] / 2a only after testing variable a for 0 and • after testing a, b, and c for numerical ( integer and floating) values. • - We decide to include the following test cases: • - a = 0 (to cover the input checking statements) • - b = ‘z’, a = 2, and c = - 4 (to cover the input checking statements) • - b = 4, a = 2, and c = 2 so that (b2 – 4ac ) = 0 (cover root comp.) • - b = 4, a = 3, and c = 2 so that (b2 – 4ac ) < 0 (cover root comp.) • - b = 4, a = 2, and c = 1.5 so that (b2 – 4ac) > 0 (cover root comp.) How much of this should we do?
More Detailed Look at the Solution Input A,B,C A>0 and <100 No Error message on input Yes B>0 and <100 No Error message on input Yes C>0 and <100 No Error message on input Yes R1 = [-b +√ (b2 -4ac) ] /2a R2 = [-b -√ (b2 – 4ac) ] /2a Output R1 and R2 - Would you modify your test cases? - Why? stop
Another Version of Solution Input A,B,C terminate Yes A = -100 End message No A>0 and <100 No Error message; ask for A Input A Yes B>0 and <100 No Input B Error message; ask for B Yes C>0 and <100 No Error message; ask for C Input C Yes - Is this a better solution? - How would you test this? - would black box be enough? R1 = [-b +√ (b2 -4ac) ] /2a R2 = [-b -√ (b2 – 4ac) ] /2a Output R1 and R2
Test Case Development • Note that the Black Box and the White Box approaches lead us to consider a broader range of test cases. • We should consider both approaches • Back Box testing is sometimes known as Closed Box or Functional Test • White Box testing is sometimes known as Open Box or Path Test
Class Assignment • Generate the Black Box test cases by just considering the tax problem described on page 343. • Generate the White-box test cases by looking at the implementations on page 343 • Without using the table • Using the table and a loop