Develop Test-Cases From Use-Cases
Test case development made easy: How to use test cases to derive the right test cases
In many companies, use cases are currently being introduced with the great promise that effects such as easy readability, reusability and automatically generated test cases will arise directly. However, these results never occur from the outset, they are a result of targeted and adapted use cases. This story describes how systematic test cases can be derived from use cases.
A Complex System Environment Requires Well Thought-out Processes
A large part of technical systems are ERT systems, in which hardware and software are combined with each other. The automobile is a good example to illustrate the increased presence of ERT systems in reality. It is not easy to specify such software-hardware systems, since they are extremely complex due to the strong embedding and networking of the individual systems and the large number of exceptional cases.
The systematic analysis and the test based on it represent critical steps in the development. This article is intended to show the steps of the system analysis and the derivation of the test cases from the created analysis documents. Above picture shows the steps that should provide an overview of the procedure. ERT systems usually communicate intensively with their surroundings, and can even be structurally anchored in one another. It must therefore be explicitly clarified what lies within and outside the system limits. We present these results in a use case diagram, which, in addition to the contextual delimitation, also provides us with the further service of breaking down our system into manageable pieces from a black-box perspective.
Creating Use-Cases
View the system from the outside, as a black box, and look for actors who you want to know what they expect from your system. In our case, these actors are neighboring systems that (as required) communicate with the system and have expectations of its behavior. We have to show system boundaries and interface specifications using UML-compliant diagrams, since UML does not contain any context diagrams even in the latest version.
The logical context can be delimited well with use case diagrams. The following conventions must be observed: exact naming of the system, identification of all neighboring systems — even those that only deliver events or only receive events. Mark real actors as initiators. Identification and documentation of all possible events of all actors in order to be able to derive all test cases. Take the view of neighboring systems in order to find the expectations of this system for your own system. Specify inputs and outputs. A table is helpful for many events and additional information. Separate two use cases if different preconditions or postconditions are to be expected!
The Formalization of UML behavior diagrams
The high level of abstraction of the black box behavior of the created and described system is to be converted into a formal notation. A process flow description is now created from each individual use case, which considers the behavior of the use case (detached from the overall system). An activity or status diagram is recommended as notation. Our next task is to derive test cases as efficiently as possible from the state diagrams of the use cases. The processes to be tested correspond to the paths in the behavior diagrams, whereby we regard the incoming events as triggers for the transitions. The start and end points of these paths are given by modeling.
A complete test assumes that all possible paths from the start to the end point are considered. Occurring cycles may only be run through once. A test case can be identified for each path of the diagram. The preconditions and postconditions of the test case are derived from the corresponding use case.
Coming to an End
Here you have received an introduction and instructions on how the appropriate test cases can be derived from existing use cases. As you noticed through hands-on, the test cases are still relatively raw.
The refinement and composition of test cases and the transfer of the test cases into more meaningful and meaningful cases will be the subject of another article.
