The goals of this chapter are: What are your initial questions? Should I analyse the specification carefully, as in black-box testing, to discover “what the code should be doing”? Does white-box testing have an advantage, over black-box testing, in testing “what the program is not intended to do”? Should I carefully test interfaces, exceptions, or error returns, or should I concentrate on confirming the correctness of functional “internal” behaviour? | Software Construction Lecture 19 Software Testing-2 Learning Goals for Today D3 2 Develop a test suite for some code after looking at it. (White-box testing.) What are your initial questions? (Have you written some already?) Should I analyse the specification carefully, as in black-box testing, to discover “what the code should be doing”? Does white-box testing have an advantage, over black-box testing, in testing “what the program is not intended to do”? Should I carefully test interfaces, exceptions, or error returns, or should I concentrate on confirming the correctness of functional “internal” behaviour? Start to develop your own “principled approach” to software testing. White-Box Testing D3 3 “This strategy derives test data from an examination of the program’s logic “(and often, unfortunately, at the neglect of the specification).” What is the overall strategy or “gold standard” for white-box testing? “Causing every statement in the program to execute at least once”? No this | Software Construction Lecture 19 Software Testing-2 Learning Goals for Today D3 2 Develop a test suite for some code after looking at it. (White-box testing.) What are your initial questions? (Have you written some already?) Should I analyse the specification carefully, as in black-box testing, to discover “what the code should be doing”? Does white-box testing have an advantage, over black-box testing, in testing “what the program is not intended to do”? Should I carefully test interfaces, exceptions, or error returns, or should I concentrate on confirming the correctness of functional “internal” behaviour? Start to develop your own “principled approach” to software testing. White-Box Testing D3 3 “This strategy derives test data from an examination of the program’s logic “(and often, unfortunately, at the neglect of the specification).” What is the overall strategy or “gold standard” for white-box testing? “Causing every statement in the program to execute at least once”? No this is “highly inadequate”. A Gold Standard for White-Box Testing D3 4 Exhaustive Path Testing: a gold standard for White-Box Testing “if you execute, via test cases, all possible paths of control flow through the program, then possibly the program has been completely tested.” Testing all possible paths of control flow is not enough to prove correctness in a white-box test, so how can this be a gold standard? Testing all possible inputs is not enough to prove correctness in a black-box text, yet this is still the gold standard for black-box testing. The justification is the other way around! If you don’t exercise all control paths, then a test case for this path may reveal an obvious bug in this path. Someone might ask: why didn’t you test that path? How would you respond. Testing all paths is often infeasible. The gold-standard for black-box testing (of testing all possible inputs) is almost always infeasible. Even if you know you can’t possibly “reach the gold”, you can still use this .
