| The overall lesson of this chapter is that model-based specification, in addition to being a good tool for use case failure analysis, is a good tool for test design: any work done modeling the use case for failure analysis is easily translated into test cases. Here's a review of the two major sections of this chapter. In the first section, you learned why preconditions, postconditions, and invariants, taken as a unit, are a veritable triple threat test case for black-box testing: Preconditions are an ideal source for test point selection both in terms of valid and failure scenario test cases. Postconditions provide the all important primary expected result. Invariants provide a crosscheck on the expected result of the postcondition or can act as a "better late than never" precondition if a precondition is not available. Plus, global invariants have the added benefit of being both a precondition on steroids and a mini test case that can be executed anytime, anywhere in the use case.
The second section reviewed Binder's Extended Use Case Test Design Pattern, a method of specifying test cases from a use case by modeling the use case as a relation described via a decision table, called an operational relation. You also learned that model-based specification can be used as a relational description of a use case and is easily translated into the decision table format of an operational relation. This approacha model-based specification-style operational relationcoupled with an expanded table format, has a number of benefits: The workflow nature of a use case is preserved, which is handy for testing. The overall combination of a test case described in natural language augmented with a model stated in terms of preconditions, postconditions, and invariants provides a test case that is both understandable and rigorous. Use of unprimed and primed state variables allows you to talk about the before and after versions of state variables when describing preconditions, postconditions, and invariants. Preconditions, postconditions, and invariants are grouped in such a way to make evident their "team" structure and the use case operation or step they are describing.
|
