In UTP 1.1 there are two predefined time-related types: Time and Duration. Time is used for starting a timer (Timer::start(expre:Time)), so it represent rather a Duration. In addition, time is ambiguous, because it is not clear what time actually represents, a particular point in time or a duration of time units.

Since UTO already defines a Duration type to express a duration of time unit, Time should be renamed to Timepoint to cope with particular points in time. Concrete timepoint formats are not given by UTP.

Furthermore, Timer should offer a second start() method with the signature Timer::start(duration:Duration). The user would be able to decide whether a time should timeout at a certain point in time or after a given duration.

The RTF agreed that the UML Testing Profile should allow to set both a duration and a timepoint for a timer to expire. This is consistent with the UML simple time concepts, where a user can express TimeEvents in terms of Duration or TimeExpression. However, it is not the intention of UTP to predefine or determine the concrete format of a Timepoint or Duration. There is ongoing work within the OMG to standardize those things.
Additionally, the RTF agreed on setting a constraint how values/instances of these two primitive types have to be expressed. In order to align the imperative timer concept of UTP with the declarative one of UML simple time, instances/values for utp::Timepoint shall be expressed as utp::TimeExpression with type set to utp::Timepoint. Consequently, instances/values of utp::Duration have to be expressed as uml::Duration with type set to utp::Duration. Again, the concrete format of such a ValueExpression is not predefined and is left open to the user. Finally, the predefined Timer interface of UTP should offer operations to start a Timer with either a Duration or Timepoint for expiration.

There was an error introduced into the textual definition of ValidationAction during the sophisticated restructuring of UTP 1.0 to UTP 1.1.

So actually, ValidationAction should extend CallOperationAction instead of Dependency (as it is correctly depicted in the abstract syntax)

This is indeed a copy and paste error. The abstract syntax and the machine readable files are correct, but the wrong base class is mentioned in the specification document. This will be changed accordingly.

During UTP 1.1 revision, the entire document structure has been modernized, cleaned-up and restructured. However, there are several typos and style glitches in the current specification, which mostly originated from copy and paste errors.

In addition, some of the figures need polishing as well (e.g. Figure 7.8, Figure B.14, Figure B.23, Figure B.26, Figure B.28)

Some obvious copy and paste errors as well as typos are addressed by this issue. However, part of the resolution is the submission of new issues requesting the correction of several figures (in particular in the examples section) and the harmonization of the style of the specification with other profiles. In case the task force decides to have a proprietary style guide, it must be assured that the style guide will be applied consistently throughout the specification.

Currently, UTP consists of four conceptual (not technical) packages: test architecture, test behavior, test data and timer concepts.

The concepts which are described within those packages (which are represented as different subsections in the normative section of the specification) can be further separated.

For example, timing (all concepts of timer concepts package) is mainly associated with test behavior. A timer can only be started if a behavior is executed. It might be more consistent to move the concepts from timer concepts into test behavoir as well, since it is clearly dedicated to test behavior.

Another example are some concepts which clearly belong to the test management area like TestObjective and/or TestLog. Those test management concepts are part of UTP since its adoption by OMG, so it would just be consequent to establish a new package exclusively for test management concepts.

A more consistent conceptual package structure could look like this:

1. Test Architecture
2. Test Behavior
2.1 Test Case and Defaults
2.2 Test Actions
2.3 Test Timer
3 Test Data
3.1 Wildcards
3.2 Test Data Structure
4. Test Management

The RTF agreed that having a modernized and polished specification document is highly beneficial. Therefore, a new outline and new introductory chapters have been written. Except from changes in the outline and introductory sections, this resolution does not change the semantics of a stereotype.
NOTE: For the sake of clarity, this resolution is split into two parts.
The first part incorporates only changes from section 1 (Scope) to 6 (Additional Information). These changes are marked with the issue tag (Issue 17224 (part one)) and are incorporated into the intermediate convenience document with change bars.
The second part incorporates changes from newly created section 7 until the end of the document. These changes are marked with the issue tag (Issue 17224 (part two)) and are incorporated into the final convenience document with change bars. The second part is responsible for several new sections, section and figure renumbering. The issue marker in the change-bared convenience document provide information whether this section has been newly incorporated or changed. This ensures a direct traceability from the old document structure to the new one.

UTP is a specification for the creation of model-based test specififcation, thus, it has an important and meaningful role in the realm of model-based testing.

Unfortunately, the introductory chapters do not mentione, nor define, model-based testing, test model or any relevant concept related to MBT techniques. As the first and the most sophisticated standardization approach of MBT concepts, the UTP specification should be much clearer on its purpose and relationship to MBT.

In fact, being incepted and mostly written almost 10 years ago, UTP needs a modernization polishing.

The RTF addressed this issues with the restructuring of the specification itself.
Disposition: See issue 17224 for disposition

The term 'LogAction' actually refers to the element FinishAction. So it should be renamed to 'FinishAction' and a new term for 'LogAction' should be included

This issue addresses a flaw in the terms and definitions section and was most probably a result of the refactoring of UTP 1.1 revision.

Since TestComponents can define test-relevant behavior, it must be ensured by definition that each base class of a TestComponent is also a BehavioredClassifier.

Behaviors for test cases can be expressed as operations in the test component, for example. To make this formally and by definition possible (and if we do not change the base class of TestComponent to Property - see previously submitted issue by me), we should also extend BehavioredClassifier and make clear that a base class, to which <<TestComponent>> is applied must be both a StructuredClassifier and BehavioredClassifier.

RTF agreed on narrowing the possible metaclasses the stereotype <<TestComponent>> down to uml::Class. Furthermore, uml::Behavior and uml::AssociationClass is excluded from the list of extendable metaclasses by a constraint, because they just do not make sense to be treated as a test component. This results in three concrete metaclasses where <<TestComponent>> can be applied to, which are: Class, Component and Node.

TestLog describe the actual execution of a test case against the SUT it was stimulating. A TestLog is described as concrete subclass of Behavior.

For particular behavioral descriptions (Activity, Interaction) the tets log allows the integration of more details for the exeuction of a single test step, e.g. a timestamp when this test step (sending of a message, performing a validation action, ...) has been carried out by the test execution environment.

Therefore, there should be at least for test log's represented as Interaction and Activity a concept like the following:

TestLogEntry extends OccurrenceSpecification/Action

The RTF agreed on introducing a new concept called TestLogEntry. A TestLogEntry can be combined with the ordinary Behavior concepts, but must be included in a Behavior stereotyped as TestLog.
As in the summary suggested, a TestLogEntry will have an only one tag definition solely, namely timestamp. The timestamp represents the point in time when a corresponding test step during a test case execution has actually been executed. Such a timestamp is part of almost every test execution tool and test case log. It helps in analyzing the log and to reveal time-dependent issues.
The RTF decided to base TestLogEntry solely on OccurrenceSpecification of Interactions. The RTF is not aware of any tooling or method that logs test case execution as Activity or StateMachine, because a test case always represents an interaction between the test environment and system under test. This is represented in almost all tools as Sequence Diagram.

This is a correction for issue #15652:

In the resolution for issue #15652 we restricted the number of <<TestComponent>> lifelines that are covered by a <<DetermAlt>> to one.

This is too restrictive. There can be of course several test component lifelines being covered by the very same <<DetermAlt>>.

Possible resolution:
Remove the first paragraph in the semantics section

Change the first sentence of the current second paragraph from

If a deterministic alternative is reached during the execution of an interaction, the involved test component waits until it receives an input

to

If a deterministic alternative is reached during the execution of an interaction, the involved test component lifeline waits until it receives an input

• Remove constraint [2]

The way UTP 1.1 has refined or clarified the ‘determAlt’ ended up in a description identical to TTCN-3, the language where the ’determAlt’ concept was taken over from. The fact that the equivalent altsteps (in TTCN-3) are applied to each test component separately should not influence the way how this concept has to be applied in UTP. UTP should rather abstract from a concrete technical implementation and describe the concept according to the possibilities or semantics of UML Interactions.
In short, the resolution partially takes over what the issue submitter said, i.e. that more than one test component can be covered by a CombinedFragment with «determAlt» applied. Furthermore, some typos and misspellings will be corrected.

In most situation in the UML superstructure, the abstract metaclass ValueSpecification is used when flexibility should be granted to the user in how to model concrete values for an attribute/tag definition.

Using ValueSpecification allows a clear way for tools to deal with different ways of how user model values.

In the test management extension chapter, the tag definitions are typed as semantic-free string types, which makes it hard to calculate them automatically and to interchange the models.

Going from String to ValueSpecification would allow user to define their UML_compliant way of value modeling and still not restrict the user to a certain modeling method.

Example:

TestCase

A user could therefore provide an enumeration for priorities he uses in his test process like

MyPriorityKind

This allows the user to fill the priority tag definition of test case with a user-specific value of priority.

instance:TestCase{
slot{
definingFeature = priority
value=InstanceValue

}
}

Possible solution:
Change tag definition types in the test management extension chapter from String to ValueSpecifcation

The necessity to have additional and normative test management concepts available for several main artifacts in UTP is high. In UTP 1.1 we already introduced a set of optional concepts, mainly tag definitions that cope with some standard test management concepts. In this resolution we decided to move some of those non-normative tag definitions into the normative part, but keep the backward compatibility by declaring all tag definitions as optional, i.e. a lower multiplicity of 0. The main target was to harmonize UTP with industry-relevant testing standards, in particular with ISO 29119, IEEE:829-2008, ETSI and ISTQB. The RTF found that UTP should cope with the required information of this standards, since they represent a common knowledge of wat is deemed necessary to plan and document/report testing process, without being methodology-dependent. The RTF paid high attention to kep UTP as open ended as possible, but precise as necessary.
For TestLog the following tag definitions will be moved from the non-normative part to the normative part (in parenthesis a justification by stating what standards require the information): Tester (required by IEEE829, ETSI)
– executedAt (required by IEEE829, ETSI, ISO 29119, ISTQB)
– duration (required by IEEE829, ETSI, ISO 29119, ISTQB)
– verdict (required by IEEE829, ETSI, ISO 29119, ISTQB)
– verdictReason (required by IEEE829, ETSI, ISO 29119, ISTQB)
For TestContext, the RTF decided to move the following concept to the normative part:
– testLevel (required by ISO 29119, IEE829)
For TestCase, the RTF decided to move the following concept to the normative part:
– priority (required by ISO29119, ISTQB, ETSI)
– testType (required by ISO29119, ISTQB)
A precise definition of the changes is given below.
All time-related tag definitions reuse the UTP’s predefined primitive types Timepoint or Duration. All other tag definitions are typed as ValueSpecification, since this provides the highest degree of flexibility to the user. Instead of predefining a certain schema for test levels, priorities or test types, UTP rather allows to be tailored for any process or methodology. The RTF found that this information cannot be predefined by UTP at all, since they are varying from company to company, even from project to project.
The resolution will, however, show examples how the new tag definitions can be leveraged.
Furthermore, a new issue will be submitted to consider an additional library with some well-known values and concepts for test level (e.g. an enumeration of component, integration, system, acceptance etc.) or a quality schema for test type (e.g. ISO 9126, FURPS etc.). This will most probably solved and elaborated in in the upcoming UTP 1.3 RTF.

This issue is probably coupled with (at least related with issue #15941 http://www.omg.org/issues/uml-testing-profile-rtf.open.html#Issue15941) and targets a more convenient handling of UML instance specifications for test modeling to avoid redundancy.

TTCN-3 offer quite efficient and proven concepts to exploit already defined/created instance specifications (called template in TTCN-3). The concept is called "modifies" and allows the derivation of new templates by reusing existing templates.

See Clause 15.5 of TTCN-3 core specification (ETSI ES 201 873-1 V4.2.1) for further information.

UML is very inflexible with regard to the reuse of already modeled InstanceSpecifications. This may be caused by the fact that concrete data and InstanceSpecifications are rather pertinent and more used in testing than in other system development. However, the RTF agreed on having a dedicated concept in UTP that allows tester to exploit already existing InstanceSpecifications in order to defined large sets of complex data by avoiding redundancy. Therefore, UTP will get a new and very important, yet useful concept called Modification that resembles the modifies concept of TTCN-3.

I’d like to report on an issue on the normative files for the UML Testing Profile version 1.2.
According to the PDF spec, section 11.4 « Test Result Analysis », the TestLog stereotype extends the Behavior metaclass. This extension relationship is not specified in the utp_1.2.xmi file.

The enumeration Verdict should be renamed to VerdictKind, to be consistent with UML and all other UML profiles.

UML supports the substitution principle of the object-oriented paradigm among other by not allowing the violation of constraints on superclasses in specialized subclasses. This is fine for the definition of system specifications. Testing, however, has to deal with invalid situations and data types. The most common test design/test data design technique relies on that fundamental principle of identifying "invalid" partitions of data types - the equivalence classes. Invalid means that the data partition does not comply with the constraints that is either applied to an interface operation or the data type itself.

In UTP, data partitions are defined as stereotypes on classifier, hence it is possible to reuse existing type definition (from an existing system model) and to create data partitions for that type (let's called it base type) that divides the base type into several different data partitions.

As an example, consider the following:

class A{
+ i : Integer

}

Applying the equivalence class method, this base data type would result in three equivalence classes/data partitions:

1. DP_1 = i >= 0 and <= 100 //valid
2. DP_2 = i < 0 //invalid
3. DP_3 = i > 100 //invalid

If we want to reuse the base data type for the design of test specifications, we would have to generalize the already existing class A by three different data partitions like:

DP_1 extends A{ //valid
+ a : Integer

} //constraint inherited by class A

DP_2 extends A{ //invalid
+ a : Integer

}

DP_3 extends A{ //invalid
+ a : Integer

}

Creating DP_2 and DP_3 would result in a contradiction, since UML disallows constraints to be deactivated or overwritten. DP_2 would look like this:

DP_2 extends A{ //invalid
+ a : Integer

}

This requires a mechanism to explicitly target constraints in superclasses which are overwritten (not redefined) in subclasses with <<DataParition>> applied.

To summarize: Test specifications address a larger set of data types than sytem specification, since they have to stimulate the system with data which are invalid by the system specification.

A possible and minimal inversive solution could the following be:

Introduce a new stereotype <<OverwritingConstraint>> or <<TestConstraint>> that has at least one tag definition, namely:

+ overwrittenConstraints : Constraint [1..*]

whereas each Constraint being referenced by the tag definition must be a constraint initially introduced by the base type of the data partition or one of its subclasses.

In situations where components already exist which shall be reused for the test architecture, it is contra-productive that test component only extends StructuredClassifier. This requires always the creation of a completely new test component (maybe using generalization) for the test architecture.

Treating TestComponent, in addition to its current representation, similar to <<SUT>> (which extends Property) would result in more flexibility since existing classifier can be reused for being both the SUT and a TestComponent in different tets context.
This is in particular helpful for reusing existing classifier.

This way would ot restrict the situation where completely new tets component classifiers must be created (maybe though generalization from already existing classifier in the system model). Current approaches would not become invalid, in contrast, this would result in a more precise and clear test configuration.

The specification states that coding rules should be defined outside of the utp model and just being referred from the utp model.

In some situations, it can might be required to include a precise coding and decoding of values already in the model.

Therefore, the coding attribute should be typed by ValueSpecification, which would allow both merely naming the coding rule that should be used by an external test execution environment (LiteralString) and a formal representation of the coding/decoding mechanism itself (Expression/InstanceValue/OpaqueExpression)

In the normative XMI representation of the UML Testing Profile version 1.2 (http://www.omg.org/spec/UTP/20120801/utp_1.2.xmi) there is the following ownedComment element:

<packagedElement xmi:type="uml:Stereotype" xmi:id="_PsR94OVOEeG84fBOY39c0g" name="TestCase">
<ownedComment xmi:type="uml:Comment" xmi:id="_ZvGtsOVOEeG84fBOY39c0g">
<body>[09.08.2012 09:16:54] ... my choice would be: Scandic Palace Tallinn, 3 VABADUSE VALJAK SQUARE, TALLINN, EE10141</body>
</ownedComment>

It seems to me that comment is by mistake, and not necessary in the profile definition.

Figure B.28 depicts an interaction between a tect component lifeline and several SUT lifeline. The first two and the last two messages invoke an operation called checkBalance with a actual parameter p.euAccount/p.usAccount, where p is of type TrxnData.

The type TrxnData is specified in Figure B.23, and in this Figure (which is the only Figure for the definition of TrxnData) there are no attributes for TrxnData called euAccount or usAccount, but account.

Given by constraint 6 of UML::Message (Section 14.3.18 in UML 2.4 Superstructure), messages are not allowed to cross boundaries of a CombinedFragment. Gates manage the connection of messages outside of a CombinedFragment to messages inside the CombinedFragment. So, in general, a cfragmentGate should be used in this Figure.

However, in picture B.14 a Default is depicted. Defaults express behavior for exceptional situation within a test case specfication, so actually, the behavior of a Default is added to the receiving test component lifeline for a particular message (shown in Figure B.13), or for a set of messages (not mentioned in the spec at all). Thus, the two boundary-crossing messages shown in B.14 do not have a real counterpart in Figure B.13 (they are just additional messages).

For resolution, I suggest to use found messages (UML::Message with MessageKind::Found) within the InteractionOperands of the determAlt CombinedFragment, to indicate they are additional message for which no real counterparts exists in the interaction applying a Default.

In the current UTP specification, the different test actions (StartTimerAction, ValidationAction, etc.) are indirectly bound to a lifeline by being referenced from an ActionExecutionSpecification that covers a lifeline, representing a structured classifier with <<TestComponent>> stereotype applied. This was necessary because there was no adequate meta model element in Interactions for placing a single action onto a lifeline. With UML 2.4, the meta model of Interactions have been reworked significantly in the way that the meta model element OccurrenceSpecification became a concrete class, specializing InteractionFragment. An OccurrenceSpecification has a reference to exactly one lifeline it covers. This the precise redefinition of test actions for Interactions, using the new UML 2.4 semantics.

Therefore, each test action (StartTimerAction, StopTimerAction, ValidationAction, etc.) shall extend UML::OccurrenceSpecification directly. Since OccurrenceSpecifications do not have a notation a priori, each test action has to define a dedicated notation (for some actions, there is already a notation defined, e.g. TimeOutMessage). This makes the actions easily and freely positionable on the lifelines. By doing so, the applicability of UTP would be significantly simplified. Besides, the memory footprint in the background would be extremly decreased, due to the fact that the event would be bound directly to the OccurrenceSpecification instead of creating a lot of elements (ActionExecutionSpecification, Action, Event, Input/OutputPins...)

The UTP predefines three interfaces, that are Scheduler, Arbiter and Timer. Mixing interfaces and stereotypes, which are supposed to work with those interfaces, is confusing and complicates the implementation of the profile. The idea of those interfaces is straight forward, however, the technical realization is hard to achieve due to mixed meta layers. UML::Interfaces instances are located at meta layer M1 (model layer), whereas Stereotype instances are located at meta layer M2 (meta-model layer).

Since the profile mechanism allows the definition of constraints for the base class of a stereotype, it is possible to express the semantics of the predefined interfaces with stereotypes and constraints, being applied on them. Even if a UML profile tool does not include OCL evaluation, the profile would be still easily implementable. The key point is here: Including OCL constraints into the semantics of a stereotype does not restrict the technical feasibility of the profile. Rather, the modeler would be responsible to respect the constraints of the stereotype. If a tool makes use of OCL expressions, the validity of the model would be checked automatically.

Some test cases might required additional hardware that is only available in specific timeframes. This means the test cases must be scheduled in detail and in certain sequences. Also, test cases may depend on each other.

Corresponding model element assignments can be established in principle with the current UTP specification, but a corresponding rule-set or a basic standard is missing.

Such kind of rule-set standard is necessary for potential tooling support of scheduling aspects coming out of an UTP test model.

Rational
#####################
OCL is the OMG’s formal, MOF-based language to express fine-grained constraints in MOF-based models. OCL expressions are unambiguous, precise and computable.

Issue
#####################
All constraints in UTP specification are defined with natural language. In order to help readers (tool vendors, tester, modeler) to implement, understand and apply the stereotypes of UTP properly, it would be helpful to use formal OCL expressions for these constraints. The natural language description may remain in the specification, meaning the OCL supplements the already existing description. The benefits would be two-folded: Both readers with and without OCL knowledge would be able to understand the specification.
UML 2.3 Superstructure, section 18.3.2 Extension, subsection Semantics explains how OCL constraints can be exploited to define restriction on the extended metaclass.

Source: Lockheed Martin, Jon Hagar
Specification: UML Testing Profile
Section: term data value
Nature: Issue
Severity: med
Summary:

The term data value is used many places and seems to be a root for data definitions, e.g. pools, but is not semantically defined.

Resolution:

Create a semantic definition for data values

Source: Lockheed Martin, Jon Hagar

Specification: UML Testing Profile
Section: fig 6.2

Nature: Issue
Severity: med
Summary:

Test Cases as an Operation
There isn’t a formal diagram notation for an operation in the UTP; therefore you can’t show it on a diagram using a standard notation. Tool vendors have provided solutions but they are not part of the standard. Figure 6.2 shows test case and operation (metaclass)

Resolution:

Provide notation definition of operation to be used throughout the standard.

Revised Text:

A common early step in specifying test cases is identifying a set of test cases. Today, «TestCase» is a stereotype of an "Operation" or a "Behavior" which is a specialization of a "Class". To support test case identification a test case should be a first-class model element that may exist standalone and that may visually be recognized as a test case.

A single test case must be stateful as it controls the sequence of the individual test steps and may need to store temporary data while being executed. These requirements make it difficult to have test cases based on operations. On the other hand, test cases need to be parameterized to achieve some level of genericity, which is less common to behaviors.

A single test case is a type that needs to be instantiable (i.e. executed) many times. Instances of a single test case may either be executed in a sequence or in parallel (in which case multiple instances of the same test case exist at the same time). When a single instance of a test case has been executed it should mainly be frozen but may be retained for historical reasons.

Today, «TestContext» is a stereotype of a "StructuredClassifier". However, test contexts must be able to contain anything that is useful to model test specifications, including other test contexts, test cases, test components, and even different kinds of diagrams.

When identifying test cases one of the most important goals is to minimize the number of test cases while maximizing the test coverage. The core approach to achieve this is to employ various mechanism that facilitate reusability. Therefore, it is very helpful to visualize families of related test cases and their associations on dedicated diagrams.

Test cases must support various associations among them so that they may be organized into families of related test cases.

The role of operation "getDistributionInterval" on class "DataPool" (in figures 6.39 and 6.41) is not clear.

The wildcard * to indicate any kind of default is particularly on state machines uncommon and inflexible.

Monitoring of interfaces between components within the SUT.

For each operand the guard has to be on each leading event within an alternative