U2TP Analysis Johnny.deng U2TP is a test modeling language based on UML2.0, which can be used to test modeling from each level of the unit test to system integration test. It can be used independently of UML based on MOF.
Four logical concepts organize together to form U2TP: Test Architecture / Test Data / Test Behavior / Test Time. Test Architecture specifies the structure of the U2TP; Test Behavior specifies the behavior of U2TP; Test Data is data that represents the U2TP test behavior; Test Time is quantified for U2TP test behavior.
The semantics of each part of the U2TP:
1) Test configuration:
First, configure a test system with Test Configuration: The Test Component, Test Component Contacts, interacts with each other, interacts with each other, the interface they contact must follow some Coding Rule, such as XML, COBAR, IIOP, ANS.1; there is a variety of components, such as components such as the test system feature, and they play a secondary test, and one of its typical instances is the ATM magnetic card in the ATM test. Between the Test Components, according to the actual connection, each Test Component is a separate test system with their respective test Verdict. Verdict is the evaluation result of the correctness of the measured system, he has four predefined values: Pass, InconClusive (not sure), Fail (test results are inconsistent with the expected results), Error (test system has errors or abnormal). Verdict is evaluated by Arbiter, arbiter is a gathering section of each test case or test convention (Test Context), and its evaluation criteria have default implementations or user-defined. Verdict is different from Stimulus and Observation. Stimulus is a test input. Observation is the result value of the test. They are in the form of Test Data. It is the conclusion that OBSERVATION and expectations are compared, not Test Data. The connection between SUT and TEST COMPONENTS has basically constructed the static structure of U2TP (the configuration of the test system), and Test Context controls the implementation of the test based on this combined structure, and a Test Context contains a collection of Test Case, Arbiter instance, SUT instance, and test details such as performing control of Test Case.
2) Test implementation:
Test context includes a collection of Test Case, which is the foundation of the test implementation, and the full control of the test action must be returned to the Scheduler under which: Scheduler knows each time, the Test Components exists on each test point, which controls Test COMPONENTS creation and destruction, it knows Test CoMPONENTS Test Cases, and its implementation starts a test case via startTestCase (), records the end of Test Componet, and finally notifies arbiter to assess this Temperature, in addition, it also records Test Component created by Test Component via CreateTestComponent (TC: TestComponent). Each Test Case starting with SCHEDULER defines the behavioral feature of the test. It specifies the interaction target between Test Components and SUT (the following figure explains Test Objective) and interactive implementation means, Test case execution interaction is based on Test Configuration The final result of performing the interaction is a Verdict. In the execution of Test Case, you can set the behavior of the control test, even interrupt Test Case, for example, when a set Timer exceeds the time limit of a set Timer It produces a timeout time event that is only sent to the owner of Timer. At the same time, coordination and synchronization of each Test Component is a problem (especially in distributed tests), which can be customized by Timezone, specifying that each Test Components belongs to one timezone, which has the same time in the same Timezone Test Components Features, that is, they are synchronized. Test case's execution process is defined by Test Data, which specifies SUT STIMULI, OBSERVATIONS, and Test Components synchronization, where Data Pool contains Data Partitions or displayed data, is the foundation of repeated test, they pass Data Selector provides different data selection strategies to be selected. Default is an important part of the test behavior. It is a supplement to the SUT standard and expected test behavior. If an unspecisive test behavior is observed during a test implementation, the default processing can be applied when the behavior cannot be described. (Default) ). Default is defined into multiple layers, and their processing is always extended from the most mileage. The testing process also includes testing and test logs such as finishction, logaction. Validwithdrawal Test is to WITHDRAWMONEY
3) Metal model
4) Questions and Thinking
1. Test Control and Scheduler's functional differences, personal thinking Test Control is just an abstract concept, collectively testing the test control, is the test control, SCHEDULER?
