This shows the flow of deliverables among major participants (the stick figures in the use case diagram above).
The darker vertical lines illustrate the principal exchanges of artifacts of information — the teamwork necessary among participants.
Each artifact's color identify one of the 4 metalayers (packages) of abstraction defined by the UML 2.0 Test Profile (U2TP) standard:
1. Test Architecture defining concepts related to test structure and test configuration (containing the relationship of elements involved in a test project)
2. Test Behaviors defining concepts related to the dynamic aspects of test procedures — structural (static) Model -> Test Execution Directives (The interface for testing)
3. Test Data (the structures and meaning of values to be processed in a test)
4. Test Time defining concepts for a time quantified definition of test procedures (constraints and time observation for test execution)
The word "Profile" in U2TP means that it conforms to UML standards.
The seven basic types of testing as defined by SourceLab's "CERT7" are:
Type of Testing
1. Unit Testing
2. Functional Testing
3. Security Testing
4. Stress Testing
6. Reliability Testing
7. Integration Testing
Mercury Interactive's Quality Center (formerly TestDirector) product organizes each requirement for testing as a test subject for each AUT under a Test Plan Tree hierarchy. Both manual and automated scripts can be specified in TestDirector. Each test script selected from the tree becomes a Test Step in a Test Set actually executed by TestDirector.
In Rational's TestManager, a test plan contains test cases organized within test case folders. These are read by Rational's ClearQuest defect tracking system.
Why Bother with UML Test Profiles?
o You can describe a system precisely using UML. That's the reason why UML was invented. The visual representation of test artifacts aims for common and thus hopefully unambiguous intrepretation of test designs.
o UML is the language (lingua franca) "spoken" by "professional" system architects and developers. Testers need to understand the Model Drive Architectures (MDA) that they design and build.
o The UML standard Test Profiles includes specification of plain-text XML which (at this point, theoretically) enables tool independent interchange of test profile information.
o Soon, test tools will require testers to augment UML created by architects to specify testing at a higher level of abstraction instead of crafting scripts as automation testers do now. Testers will specify executable UML action semantics which are automatically compiled into platform-specific test components used to conduct testing.
The purpose of testing is to obtain information needed to make decisions about a System Under test (SUT).
With UML: A Test Log is an interaction resulting from the execution of a test case. It represents (remembers) the different messages exchanged between test components and the SUT and/or the states of the test components involved.
A log is associated with verdicts representing the adherence of the SUT to the test objective of the associated test case.
The names of test log files usually differ by vendor:
o Logs output by the testing tool:
+ WinRunner, test Logs
+ LoadRunner output.txt and run logs.
o Logs output by scripts within test tools.
o Java JVM verbose logs
o Windows OS Application logs and Security logs.
o An application's stdout and stderr files.
Test Results are Key Measures in Test
o Number of
o Time needed to run script
Work Load Analysis Model
See Performance Testing using LoadRunner
Test Evaluation Summary
Performance Reports and Enhancement Requests, Defect Reports, or something.
Test Plan Sections
Test Interface Specs
With U2TP, a test suite has a constraint: it must contain exactly one property realizing the
A structured classifier acting as a grouping mechanism for a set of test cases. The composite structure of a test suite is referred to as test configuration. The classifier behavior of a test suite is used for test control.
Test Environment Configuration
Test Automatation Architecture
Starting from the upper right corner of this diagram from the UML 2.0 Test standard document:
The System Under Test (SUT)
The system under test (SUT) is a part and is the system, subsystem, or component being tested. An SUT can consist of several objects.
In UML testing profiles, the system under test (SUT) is not specified as part of the test model, but as a <
The SUT is exercised via its public interface operations and signals by the test components.
It is assumed that no further information can be obtained from the SUT as it is a black-box.