UML Testing Profile Avatar
  1. OMG Specification

UML Testing Profile — Open Issues

  • Acronym: UTP
  • Issues Count: 16
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Align test-related actions for Interactions with UML 2.4

  • Key: UTP12-5
  • Legacy Issue Number: 15999
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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 ( 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 ( 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. ( 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. ( 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. ( 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. ( 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. ( 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. ( 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. ( 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. ( 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