Input Interface

Specification of ATG input interface

By default the input interface part of the interface definition tab offers only the classes of the parts instantiated by the test context of the test architecture to which the ATGComponent refers. To disable this filter change property AutomaticTestGenerator::Settings::StimulationInterfaceFilterMode of the referenced code generation configuration to None and synchronize ATG data with application.

Context menus for the selection of the interface are defined on the frame of the interface definition tab, for the entire input and traced interface sections and for the individual classes offered in the respective section, and for individual member operations and event receptions.

For the input interface, the context menu consists of the following entries (where menu context can be one of entire interface definition, input interface definition, class or actor):

Reset Interface of menu context

resets all definitions for the menu context, i.e. all input instances, or actual class or actor

Set Interface of menu context

sets instances of classes or actors in the menu context (i.e. all, all input instances, or actual class or actor) that are not already selected to '0', where '0' denotes the 1st instance of the respective class. Note that using qualified instance names -if applicable- is always preferable over using instance numbers.

Set Interface of menu context according to TestContext (direct)

sets instances by qualified name according to the instantiation of the respective class or actor in the test context. The SUT instances in the test context are selected for direct driving, i.e. the operations of the SUT instances belong to the input interface for test case generation (see Driving directly).

Set Interface of menu context according to TestContext (port based)

sets instances by qualified name according to the instantiation of the respective class or actor in the test context. The SUT instances in the test context are not selected for direct driving, i.e. the operations of the SUT instances are only driven indirectly via port relay operations. Only operations of test component instances belong to the input interface for test case generation, in particular only those operations that are stereotyped <<RelayOperation>> (see Driving via Port-Relay Operations).

Identification of instances with qualified name vs. instance index

It is strictly recommended to identify instances of classes selected in the interface by their qualified name w.r.t the test context (e.g. TCon_X.itsX) rather than identifying by their creation number (e.g. '0' - denoting the first instantiation of the respective class).

The algorithm in ATG that translates raw recorded traces into sequence diagrams makes use of the specified qualified names - this translation will not be able to identify the roles of instances within the test architecture if the instances are denoted by their creation number.

ATG will generate correct qualified instance names for instances of offered classes and actors for context menu entries 'Set Interface of menu context according to TestContext (direct)' and 'Set Interface of menu context according to TestContext (port based)'.

Only if ATG can't propose valid qualified instance names, as for e.g. dynamically created instances for aggregations, it may be useful in rare cases, to identify instances by their creation number.

Supported Syntax for qualified instance names

In most cases, it will be sufficient to use the suggestion of ATG according to the context menu functionality. In rare cases ist might be helpful, to enter a name manually: a qualified name starts with the namme of the test context name. The path through instance names (parts) is separated by dots. Indexed access to multiple parts is specified by the instance number in index notation, e.g. '[2]'.Multiple instances can be specified as a comma separated list

Supported Syntax for creation numbers

• simple number, e.g. 3 - denotes the 3rd instance of a particular class created in the application - enumeration starts with 0.
• comma separated list of numbers for multiple instances.

Driving the SUTs directly

Selecting the SUT instance(s) and their operations and event receptions for the input interface lets ATG generate test cases by attemting to directly invoke the operations and event receptions.

ATG will attempt to remap these calls to suitable test components as drivers if possible. When no test component can be found that could invoke a paticular operation, the message will be mapped to be sent by the test context.

This strategy of direct invocation and remapping the origins of messages will work pretty well if all operations of the SUT(s) can be invoked by ATG - i.e. if no operations or event receptions are unselected due to their signature, and if no helper functions need to be employed in order help ATG generating particular series of triggers.

If ATG can not stimulate the SUT(s) directly due to unsupported argument types of operations or event receptions or if helper functions need to be used in order to stimulate the SUT(s) with particular series of operation calls or events, then it is recommended to equip test components with appropriate helper functions and to stimulate the SUT(s) via these helper functions - i.e. select the respective test component and its dedicated helper functions as input interface instead of the SUT and its member operations and event receptions.

Driving the SUTs indirectly - via Port-Relay Operations

In particular for SUT(s) with ports, the test component instances connected to the SUTs ports can be used to stimulate the SUT(s) via their interfaces. In the extreme, if all SUT operations and event receptions can be stimulated via port connection by the test component instances no direct driving of the SUT may be neccessary to reach maximal coverage.

Mixing the driving approaches

In practice, one will often mix the direct driving approach with the port based driving approach. If not all functionality of the SUT is available via ports or if coverage can be increased by direct driving, it will be recommended to define a test case generation input interface combining the benefits of both approaches optimally.

Preselection of ATGConfiguration input interface on 'Apply ATG'

The input interface of the ATGConfiguration created using 'Apply ATG' is by default preselected according to the port based approach. The default can be changed using property AutomaticTestGenerator::Settings::StimulationInterfaceMode of the code generation configuration for which Applying ATG on TestArchitectures is invoked.

Specifying argument values

For each argument of a selected operation or event reception, the permitted values can be specified:

auto generated

AUTOGEN

Let ATG freely determine suitable values in the domain of the argument. This will always work correctly but may be a rather ineffective setting. Assumed, we want to invoke an operation with argument of type OMString. We further assume, that in the function the argument is compared to the string constants "Valid" and "Not Valid". We easily understand, that only these two values and maybe a third value, not fitting the constants are neccessary to invoke the operation with all relevant argument values.

comma separated enumeration

e.g. "Valid","Not Valid" or 0,1,2,3,5,7

Suitable for all supported types

Only explicitly enumerated values are used in calls of the respective operation or event reception.

range

e.g. 0-32000

Suitable for scalar types with order, such as int, char, or double e.t.c

ranges and enumerations can be mixed, as e.g. in -3200--100,100-3200

discreted range with amount of values specification

e.g. [0-32000];#5

select 5 equidistant values from the range (first value will be the lower bound of the range, 5th value will be as close to the upper bound as possible).

Suitable for scalar types with order, such as int, char, or double e.t.c

Notation can not be mixed with other notations.

discreted range with step size specification

e.g. [0-32000];1000

enumerate values from the range (first value will be the lower bound of the range, 1000 denotes the step size of enumeration, last value will be as close to the upper bound as possible. In the examle, 33 values with distance will be enumerated: 0,1000,2000,...32000).

Suitable for scalar types with order, such as int, char, or double e.t.c

Notation can not be mixed with other notations.