15.3 System Tests


A unit test verifies a particular outcome from a single activity. System tests, on the other hand, verify the proper execution of a use case that may involve multiple system interactions by multiple actors. Figure 15.9 shows all the activities in the Order Merchandise use case.

Figure 15.9. Activity Diagram for the Use Case Order Merchandise

graphics/15fig09.gif

System tests share many of the same characteristics of unit tests: Both begin by establishing the state of the system based on preconditions, both have execution traces started by an initial signal, and both terminate with results that can be verified against postconditions.

The principal distinction is when the execution trace ends. For a unit test, the trace ends when there are no more signals to process, but for a larger use case, the conclusion of one activity merely means that there are more activities to be done. For example, when the customer checks out the order (one activity), that is followed by another activity by the credit card company either to accept or to decline the charge.

A system test should therefore chain together the activities that make up the use case. It does this by recognizing the completion of one activity and then initiating the subsequent activities.

Recognizing completion of an activity means there are no more signals to process. This could mean that the activity has produced outbound signals or that the trace has transitioned into a state that generates no signals.

Once activity completion is recognized, the test must verify the correct execution of the activity and, depending on the outcome of the test, initiate the subsequent activity.

Generally, it should not be necessary to do any work to set up the state of the system for the next activity, as the postcondition of one activity should match up to the precondition for the subsequent activity.[2] To build distinct scenarios for system tests, identify different combinations of state-of-the-system conditions and initial signal parameters.

[2] However, to ensure that the system test checks as many threads of execution as possible, it is typically necessary to work backwards so that the preconditions associated with the later actions can be associated with postcondition/precondition pairs of objects earlier in the process, so that a downstream feature must be compatible with an upstream feature. If there is no possible upstream pre/post path to downstream pre/post paths, this is a feature interaction problem a requirement defect. In some cases, there is signifcant complexity required to identify such defects.

Separately, depending on the full input space of the inputs, there may be partial spaces of the input space for which reachability can be achieved, but not all. Reachability analysis requires more than just checking simple values and operations (e.g., Boolean, Enumerations). [3]

Additionally, a use case's activity diagram may show several different subsequent activities for a given activity. For example, after each Add Item, the customer can either add another item or check out. Different scenarios can yield the one-item order, the two-item order with different products, the two-item order with the same product, and so forth.

System tests are executed much like unit tests, except the test script has code to recognize the completion of one activity and to initiate the next activity automatically. For example, when the credit card charge is created, we send in a signal that either approves or declines the charge.

The result of a system test can be documented on a collaboration or sequence diagram such as the one in Figure 15.10. A model verifier tool should generate these diagrams. Though they provide a good visual overview of an execution trace, they are incredibly painful to draw by hand.

Figure 15.10. Sequence Diagram for Multiple-Item Ordering Scenario

graphics/15fig10.gif



Executable UML. A Foundation for Model-Driven Architecture
Executable UML: A Foundation for Model-Driven Architecture
ISBN: 0201748045
EAN: 2147483647
Year: 2001
Pages: 161

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