Contact Person

George Din
Fraunhofer FOKUS
Kaiserin-Augusta-Allee 31
D 10589 Berlin
Tel.: +49 (0)30 3463 7101
Fax.: +49 (0)30 3463 8000
george [dot] din [at] fokus [dot] fraunhofer [dot] de

Seite Drucken

Architecture Driven Testing

Architecture Driven Testing (ADT) is a technique to derive tests out of, so called, architecture viewpoints. An architecture viewpoint is a simplified representation of the system model on a specific perspective and regards the structure of the system under this perspective. The architecture viewpoints concentrate on specific aspects and allow the combination of the aspects, relations, and models of the various kinds of system components and thereby provide a unified solution.


Architecture Viewpoint Examples

We explain the architecture view concept by providing some examples. A viewpoint is the logical view that shows the system in the form of functional blocks to realize the required functionality without taking into account any technical aspects of their realization: e.g. whether they will be realized in soft- or hardware, the hardware they are to be running on as single blocks or in combination with others, the technical resources being available and used in competition with other blocks, etc.. Those technical aspects will be taken into account under another viewpoint, technical view. Here we exactly look at them and assign the functional blocks from the logical view to a realization in or on specific hardware. Another view, the topological view, may pay respect to the aspects where those hardware blocks are located in the system, the wire harnesses and other aspects concerned with the “topology” of the system. Other views may be used and applied as well to get a less complex view on the system by concentrating on a specific aspect of it.

The functional requirements need to be linked directly or indirectly to the system architecture artefacts under the different views. The functionality is given in a simple form of Preconditions, Events and Reactions (PER). PERs statements contain references to names of blocks or ports where certain signals are produced or observed. A Precondition or Event is to be linked to the Out-Port of the functional block that initially sends that signal to the system. A Reaction is to be linked to the In-Port of the functional block where the reaction is to be finally observed. All functional blocks participating in the realization of a specific functional requirement are to be linked to the function block.

Use of Viewpoints for Test Derivation

Looking at the architectural descriptions on the different layers and the relationships specified, we can identify interesting aspects for testing. Each viewpoint can be used to derive tests.

  • Functional View. The functional requirements defined in the functional view describe how the system should react for certain stimuli. They can be used directly to derive functional tests which reproduce the stimuli defined in the requirements and correspondingly validate whether the system produces the expected reactions. 
  • Logical View. The realization of multiple functional requirements by the combination of the same sets of  function blocks in the logical architecture may cause interferences between the functional blocks and, therefore, cause system malfunction. In this situation, we can use the logical view to detect which particular functional blocks may interfere (e.g., are directly interconnected). Based on this structural information we generate tests to validate whether other functional blocks are affected by functional blocks implementing a certain functional requirement.
  • Technical View. The mapping of logical function blocks on the same technical blocks in the technical architecture view causes competition for limited hardware resources and, therefore, interference in the execution of those functions which may also cause malfunction of the system. Similar statements hold for the combined use of communication channels. Based on the linking information about which functional blocks are realized by which technical blocks in the technical view, we generate tests for particular technical blocks which might get overloaded during system runtime.
  • Topological View. The collocation of hardware or wires in the topological view may cause electromagnetic interferences, which may be a reason for the malfunction of the system again.



 

  back     top  

Contact Person

George Din
Fraunhofer FOKUS
Kaiserin-Augusta-Allee 31
D 10589 Berlin
Tel.: +49 (0)30 3463 7101
Fax.: +49 (0)30 3463 8000
george [dot] din [at] fokus [dot] fraunhofer [dot] de