U2TP分析
Johnny.Deng
U2TP是基于UML2.0的测试建模语言，可以用于从单元测试到系统集成测试的各个级别的测试建模。它基于MOF，可以独立于UML使用。
四个逻辑概念组织起来共同构成了U2TP：Test architecture/Test data/Test behavior/Test time。Test architecture 指定了U2TP的结构；Test behavior 指定了U2TP的行为；Test data 是代表了贯穿U2TP测试行为始终需要的数据；Test time 是对U2TP测试行为的量化。
以下说明U2TP各部分的语义：
1） 测试配置：
首先，通过Test Configuration配置一个测试的系统：被测系统（SUT）、测试组件（Test Component）通过定义的接口彼此联系，相互交互，他们联系的接口必须遵循某种Coding rule，诸如XML、COBAR、IIOP、ANS.1；同时存在各式各样的组件（Utility Part），诸如表征测试系统特性的组件，他们起到辅助测试的目的，它的一个典型实例就是ATM测试中的ATM磁卡。
各个Test Component之间也根据测试的实际相联系，每个Test Component 是一个独立的测试系统，具有各自的测试Verdict。
Verdict是对被测系统正确性的评价结果，他有四个预定义值：Pass、Inconclusive（测试结果不确定）、Fail（测试结果与期望结果不一致）、Error（测试系统有错误或者异常）。Verdict由Arbiter评价得到，Arbiter是每个测试用例（Test case）或者测试上下文（Test context）中的一个聚集部分，它的评价标准具有默认实现，也可以用户定义。Verdict与Stimulus和Observation不同，Stimulus是一次测试的输入，Observation是测试的结果值，他们都是以Test Data的形式存在与Test Pool中的，而Verdict则是Arbiter根据Observation值再判断的评价结果，是将Observation与期望结果比较后的结论，不是Test Data。
SUT与Test Components的联系基本构成了U2TP的静态的结构（配置好的测试系统），Test context则以这个组合结构为基础控制测试的实施，一个Test Context包含了诸如Test case的集合，Arbiter实例，SUT实例，以及对Test case的执行控制等测试细节。
2） 测试实施：
Test context中包括Test case的集合，它是测试实施的基础，而对测试动作的全面控制必须归公于其下的Scheduler，Scheduler清楚每个时刻、每个测试点上存在的Test Components，它控制Test Components的创建和销毁，它知道Test Components参与的Test cases，它的实现通过startTestCase（）来开始一个测试用例，通过finishTestCase（tc：TestComponent）来记录Test Componets执行的结束，并最后通知Arbiter来评估此次测试，另外，它也通过createTestComponent（tc：TestComponent）来记录被Test Component创建的Test Component。
每个被Scheduler开始的Test Case定义了测试的行为特征，它指定了Test Components和SUT之间交互目标（下图解释了Test Objective）和交互实现手段，Test case执行交互是建立在Test configuration基础上，执行交互的最终结果就是一个Verdict，Test case的一次执行过程中可以通过设置Timer来对控制测试的行为，甚至在适当的时候中断Test case，例如：当一个设置的Timer超过预舍的期限时，它会产生一个timeout的时间事件，这个事件仅被送到Timer的所有者。
同时，各个Test Component的协调与同步是一个问题（尤其在分布式测试中），这可以通过TimeZone来定制，规定每个Test Components属于至多一个timezone，在同一个timezone中的Test Components具有同样的时间特性，即它们是同步的。
Test case的执行过程中的数据通过Test Data来定义，它规定了SUT的Stimuli、Observations，以及Test Components的同步，其中，Data Pool中包含Data Partitions或者显示的数据，是反复测试的基础，他们通过Data Selector提供的不同数据选择策略被挑选出来。
Default是测试行为重要组成部分，是对SUT标准、预期测试行为的补充，如果在一个测试执行过程中，观察到一个未预期的测试行为，这个行为不能被描述时，就可以应用默认处理（Default）。Default被定义成多层，它们的处理过程总是从最里向最外扩展。
测试过程还包括诸如：FinishAction、LogAction的测试动作和Test Log。
ValidWithdrawal测试的目标就是WithdrawMoney
3） 元模型
4） 问题及思考
1． Test Control 与Scheduler的功能上差异，个人认为Test Control只是抽象的概念，对测试控制的统称，真正实现测试控制的是Scheduler？
