Black-Box versus White-Box Testing with Use Cases

   
graphics/whiteboxtest_icon.gif

We began this chapter by considering the system as a black box. Our testing strategy was fundamentally based on the concept of testing "all the things that go into the box and all the things that come out." However, experience has shown that no amount of purely functional testing can assure that there are no defects in the system. In functional testing we see only the result of the implementation against the limited test criteria we can establish , and in systems of complexity there are a nearly infinite number of possible input sets, system conditions, environmental conditions, and so on. We cannot possibly test them all.

Therefore, in addition to testing the black-box behavior of the system, it may also be necessary to test the white-box behavior of the system. For white-box testing, we need to look inside the system and see how it does what it does. This process of internal inspection, often referred to as design assurance , looks at the architecture and implementation of the system to see whether or not it should perform correctly. Do use cases help us in white-box testing?

In a word, yes . We saw in Chapter 25 that the problem of orthogonality (the difference between the methods and representations we used to express the requirements imposed on the system and the methods and representations we used to implement the system) can be largely mitigated with use cases. With our method, for every use case, there is a use-case realization that represents how the system is designed to accomplish the use case. The use case itself lives in the problem or requirements domain and simply specifies necessary behavior. The use-case realization lives inside the solution domain and describes how the behavior is accomplished by the system (Figure 26-3).

Figure 26-3. Use case and its associated use-case realization

graphics/26fig03.gif

Further, as we learned in Chapter 25, the use-case realization is composed of both a static and a dynamic part. The static part can be reviewed and analyzed for its fitness to the intended purpose. The dynamic part can be analyzed by inspection or viewed with runtime emulators, debug code stubs, and a variety of other execution testing techniques.

   


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
EAN: N/A
Year: 2003
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net