${taskforce.name} Avatar
  1. OMG Task Force

UML Testing Profile 1.2 (UTP) RTF — All Issues

  • Key: UTP12
  • Issues Count: 35
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UTP12-35 Rename predefined type Time to Timepoint UTP 1.1 UTP 1.2 Resolved closed
UTP12-34 ValidationAction should extends CallOperationAction UTP 1.1 UTP 1.2 Resolved closed
UTP12-33 Typos, style glitches and figures UTP 1.1 UTP 1.2 Resolved closed
UTP12-32 UTP should constitute a new conceptual package structure UTP 1.1 UTP 1.2 Resolved closed
UTP12-31 Modernization of introductory chapters UTP 1.1 UTP 1.2 Resolved closed
UTP12-30 LogAction should be FinishAction UTP 1.1 UTP 1.2 Resolved closed
UTP12-29 Base class of TestComponents must be instances of BehavioredClassifier, too UTP 1.1 UTP 1.2 Resolved closed
UTP12-28 TestLog should have detailed information as TestLogEntry UTP 1.1 UTP 1.2 Resolved closed
UTP12-27 Correction for issue #15652 UTP 1.1 UTP 1.2 Resolved closed
UTP12-26 Tag definitions of test management concepts should be of type ValueSpecification UTP 1.1 UTP 1.2 Resolved closed
UTP12-25 Integration of TTCN-3 template modification UTP 1.1 UTP 1.2 Resolved closed
UTP12-3 Issue in the UTP 1.2 normative XMI file UTP 1.2 open
UTP12-4 Verdict should be renamed to VerdictKind UTP 1.1 open
UTP12-11 Constraints on superclasses needs to be overwritable for test data specifications UTP 1.1 open
UTP12-13 TestComponent stereotype should extend Property UTP 1.1 open
UTP12-14 Attribute CodingRule::coding should be typed by ValueSpecification UTP 1.1 open
UTP12-1 Unnecessary Comment in the normative XMI representation of UTP UTP 1.1 open
UTP12-2 Figure B.28 - Transaction detail - is erroneous UTP 1.1 open
UTP12-12 Invalid Figure B.14 UTP 1.1 open
UTP12-5 Align test-related actions for Interactions with UML 2.4 UTP 1.0 open
UTP12-6 Alter predefined interfaces to stereotypes with constraints UTP 1.0 open
UTP12-16 Test scheduling should be supported explecitely UTP 1.0 open
UTP12-15 OCL expressions should be used for precise description of constraints UTP 1.0 open
UTP12-18 term data value issue UTP 1.0 open
UTP12-17 Test Cases as an Operation UTP 1.0 open
UTP12-24 Visual & Standalone Test Cases UTP 1.0 open
UTP12-22 Anatomy of a Test Case UTP 1.0 open
UTP12-23 Test Case Types & Instances UTP 1.0 open
UTP12-19 Test Context UTP 1.0 open
UTP12-7 Test Maps UTP 1.0 open
UTP12-8 Associations among Test Cases UTP 1.0 open
UTP12-9 getDistributionInterval UTP 1.0 open
UTP12-10 Default UTP 1.0 open
UTP12-21 Grey box testing UTP 1.0b1 open
UTP12-20 Data guards on observations UTP 1.0b1 open

Issues Descriptions

Rename predefined type Time to Timepoint

  • Key: UTP12-35
  • Legacy Issue Number: 17292
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.1 — Tue, 10 Apr 2012 04:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

ValidationAction should extends CallOperationAction

  • Key: UTP12-34
  • Legacy Issue Number: 17231
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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)

  • Reported: UTP 1.1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Typos, style glitches and figures

  • Key: UTP12-33
  • Legacy Issue Number: 17229
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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)

  • Reported: UTP 1.1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

UTP should constitute a new conceptual package structure

  • Key: UTP12-32
  • Legacy Issue Number: 17224
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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

  • Reported: UTP 1.1 — Mon, 12 Mar 2012 04:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Modernization of introductory chapters

  • Key: UTP12-31
  • Legacy Issue Number: 17223
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.1 — Mon, 12 Mar 2012 04:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 23:16 GMT

LogAction should be FinishAction

  • Key: UTP12-30
  • Legacy Issue Number: 17222
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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

  • Reported: UTP 1.1 — Mon, 12 Mar 2012 04:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Base class of TestComponents must be instances of BehavioredClassifier, too

  • Key: UTP12-29
  • Legacy Issue Number: 16906
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.1 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

TestLog should have detailed information as TestLogEntry

  • Key: UTP12-28
  • Legacy Issue Number: 16902
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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

    { timestamp : UML::TimeExpression [0..1] ... }

  • Reported: UTP 1.1 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Correction for issue #15652

  • Key: UTP12-27
  • Legacy Issue Number: 16900
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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]
  • Reported: UTP 1.1 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Tag definitions of test management concepts should be of type ValueSpecification

  • Key: UTP12-26
  • Legacy Issue Number: 16898
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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

    { priority : ValueSpecification [0..1] }

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

    MyPriorityKind

    { low medium high }

    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

    { type = MyPriorityKInd instance = low }

    }
    }

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

  • Reported: UTP 1.1 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Integration of TTCN-3 template modification

  • Key: UTP12-25
  • Legacy Issue Number: 16878
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Resolved — UTP 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Issue in the UTP 1.2 normative XMI file

  • Key: UTP12-3
  • Legacy Issue Number: 19084
  • Status: open  
  • Source: INRIA ( Juan Cadavid)
  • Summary:

    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.

  • Reported: UTP 1.2 — Thu, 14 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Verdict should be renamed to VerdictKind

  • Key: UTP12-4
  • Legacy Issue Number: 17228
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

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

  • Reported: UTP 1.1 — Tue, 13 Mar 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Constraints on superclasses needs to be overwritable for test data specifications

  • Key: UTP12-11
  • Legacy Issue Number: 16905
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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

    {i >= 0 and i <= 100}

    }

    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

    {i >= 0 and i <=100}

    } //constraint inherited by class A

    DP_2 extends A{ //invalid
    + a : Integer

    {i < 0}

    }

    DP_3 extends A{ //invalid
    + a : Integer

    {i > 0}

    }

    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

    {i < 0 and i >= 0 and i <=100}

    }

    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.

  • Reported: UTP 1.1 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

TestComponent stereotype should extend Property

  • Key: UTP12-13
  • Legacy Issue Number: 16901
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.1 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Attribute CodingRule::coding should be typed by ValueSpecification

  • Key: UTP12-14
  • Legacy Issue Number: 16899
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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)

  • Reported: UTP 1.1 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Unnecessary Comment in the normative XMI representation of UTP

  • Key: UTP12-1
  • Legacy Issue Number: 19018
  • Status: open  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    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.

  • Reported: UTP 1.1 — Wed, 16 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure B.28 - Transaction detail - is erroneous

  • Key: UTP12-2
  • Legacy Issue Number: 17230
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.1 — Tue, 13 Mar 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Invalid Figure B.14

  • Key: UTP12-12
  • Legacy Issue Number: 16568
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.1 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Align test-related actions for Interactions with UML 2.4

  • Key: UTP12-5
  • Legacy Issue Number: 15999
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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...)

  • Reported: UTP 1.0 — Mon, 31 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Alter predefined interfaces to stereotypes with constraints

  • Key: UTP12-6
  • Legacy Issue Number: 15998
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.0 — Mon, 31 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Test scheduling should be supported explecitely

  • Key: UTP12-16
  • Legacy Issue Number: 15914
  • Status: open  
  • Source: sepp.med ( Armin Metzger)
  • Summary:

    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.

  • Reported: UTP 1.0 — Wed, 5 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

OCL expressions should be used for precise description of constraints

  • Key: UTP12-15
  • Legacy Issue Number: 15726
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    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.

  • Reported: UTP 1.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

term data value issue

  • Key: UTP12-18
  • Legacy Issue Number: 15933
  • Status: open  
  • Source: Grand Software Testing ( Jon Hagar)
  • Summary:

    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

  • Reported: UTP 1.0 — Thu, 13 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Test Cases as an Operation

  • Key: UTP12-17
  • Legacy Issue Number: 15927
  • Status: open  
  • Source: Grand Software Testing ( Jon Hagar)
  • Summary:

    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:

  • Reported: UTP 1.0 — Tue, 11 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Visual & Standalone Test Cases

  • Key: UTP12-24
  • Legacy Issue Number: 15937
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    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.

  • Reported: UTP 1.0 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Anatomy of a Test Case

  • Key: UTP12-22
  • Legacy Issue Number: 15936
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    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.

  • Reported: UTP 1.0 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Test Case Types & Instances

  • Key: UTP12-23
  • Legacy Issue Number: 15935
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    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.

  • Reported: UTP 1.0 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Test Context

  • Key: UTP12-19
  • Legacy Issue Number: 15934
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    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.

  • Reported: UTP 1.0 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Test Maps

  • Key: UTP12-7
  • Legacy Issue Number: 15940
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

    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.

  • Reported: UTP 1.0 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Associations among Test Cases

  • Key: UTP12-8
  • Legacy Issue Number: 15938
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

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

  • Reported: UTP 1.0 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

getDistributionInterval

  • Key: UTP12-9
  • Legacy Issue Number: 15944
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

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

  • Reported: UTP 1.0 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Default

  • Key: UTP12-10
  • Legacy Issue Number: 15943
  • Status: open  
  • Source: KnowGravity Inc. ( Mr. Markus Schacher)
  • Summary:

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

  • Reported: UTP 1.0 — Wed, 12 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Grey box testing

  • Key: UTP12-21
  • Legacy Issue Number: 6956
  • Status: open  
  • Source: Motorola ( Paul Baker)
  • Summary:

    Monitoring of interfaces between components within the SUT.

  • Reported: UTP 1.0b1 — Fri, 13 Feb 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Data guards on observations

  • Key: UTP12-20
  • Legacy Issue Number: 6955
  • Status: open  
  • Source: Motorola ( Paul Baker)
  • Summary:

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

  • Reported: UTP 1.0b1 — Fri, 13 Feb 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT