Functional testing课件.ppt

精品文档 There is a potential confusion of terminology here. Some writers use the term “functional” to distinguish tests of functionality from tests of non-functional program qualities, such as usability. (Often these writers also treat performance and robustness as “non-functional” attributes, although this is questionable.) We use the term “functional” as it has long been used in the testing research community. Instructor suggestion: Ask students to attempt to calculate how many uniform random test cases it would take, on average, to find this bug. Encourage them to perform a quick, back-of-the-envelope calculation using reasonable assumptions. If we assume 32-bit floating point numbers, and that all 32-bit patterns represent legal and distinct numbers (which is not true), then there would be 2^32 different floating point numbers, thus a chance of 1 in 2^32 of choosing zero randomly. The chance of choosing the pair (0.0, 0.0) would then be 1 in 2^64, a very large number. Since not all bit patterns are valid and distinct floating point numbers, and since very small values of a may cause a detectable failure, in practice random testing will do a little better than this calculation indicates ... but not enough better to make it at all effective. It will take millions of random test cases, on average, to find this bug, while picking a few special values based on the specification will find it very quickly. Students (and others!) can get confused about testing strategies because they don’t make a clear distinction between reliability estimation and testing for the purpose of product improvement. The current chapter and the next few all deal with testing for the purpose of finding program faults. We can think of all the possible input values to a program as little boxes ... white boxes that the program processes correctly, and colored boxes on which the program fails. Our problem is that there are a lot of boxes ... a huge number, and the colored boxe