![]() |
Common Types Of Assurance Target |
|
|
|
|
|
|
|
||||
|
|
The Assurance Target is used to identify the things of interest within the software system. It identifies both the compile-time & run-time elements that are of interest and which aspects of their behaviour are of interest. Assurance Targets are based on the use of a Service Delivering Assembly( SDA ) a fairly generic mechanism for identifying a sub-set of software system. This approach has evolved as a result of problems experienced using generic classifications when attempting to communicate / document what is to be tested ( see Problems Using Generic Classes of Test ) This section illustrates some patterns that commonly occur in Assurance Targets. The examples given relate to commonly used generic types of targets often found in Test Strategies. Hopefully they illustrate the additional information that is needed to provide a good definition of a target over and above identifying an instance of a generic class.
|
||||||
|
Software is 'function like' if it has a single entry point by which it is called. Parameters are passed with the call and some values may be passed back to the client when the call completes. Whether something is 'function like' or not does not depend upon the amount of work done by the software. The function could be a standalone piece of code or it could use sophisticated statistical libraries to get its result. It may operate in no time, it may take hours to complete its job. These factors do not alter its inherent nature. A 'function like' piece of software may need testing. Though this may seem a trivial thing to define there are issues to address such as how far down into the other software the function uses should testing delve? Assurance targets can help to clarify and communicate these requirements. 'Function like' assurance targets are illustrated in the section 'Function Like' Assurance Targets. |
|||||||
|
Many languages and software development approaches have the concept of a class or something similar that encapsulates methods and data. Generally multiple, independent instances of a class can be created. Often classes can inherit implementation from ancestor classes. When an instruction is given to 'test class XYZ' it can be taken to mean many different things. A simple instruction like this can, quite legitimately, be interpreted in many ways. Assurance Targets can be used provide a less ambiguous definition of what is to be tested. 'Class like' assurance targets are illustrated in the section 'Class Like' Assurance Targets.
|
|||||||