TFS

1. 背景描述
       如果您现在正在使用微软的.NET 2005平台进行开发，您应该也会使用Team Foundation 进行源代码控制，工作指派与跟踪。而Team Foudation Source Control是MS Source Safe的扩展，功能也更强大（不过大家都反映很不稳定，偶尔会把你的代码覆盖掉让你郁闷一把），更重要的是我们可以使用微软提供的Version Control Object Model（版本控制对象模型）进行编程，扩展VSTF原有功能或开发一些自定义的组件。

        然而，同Source safe一样，当代码迁出一直到迁入这一过程中，出现了一个空白，通常情况下不能对用户操作进行有效跟踪。解决的办法至少有两种：一种是扩展WorkItem（工作项）本身的属性和功能，增加WorkFlow的逻辑，这样仍能够在VSTF内部进行有效的管理。另一种就是自己开发一个工具，在这段空白期间负责记录用户操作。同时，开发人员可以在代码迁入之前将编译好的程序集通过该工具上传到指定存储目录或者保存在数据库中，同时测试人员收到通知，将程序集获取到进行针对某项BUG的测试或局部的集成测试，从而提高测试人员的工作效率。除此以外，还可以根据该工具记录的信息生成报表，提交给PM以方便进行管理。

       这里要着重讨论的就是第二种方式，描述一下该工具开发中的一些细节问题，我们为该工具取了一个名字，称为“测试管理中心(TestCenter)”。

2.相关流程

                图1 TestCenter-功能异常单处理流程

3.典型场景

3.1 程序员根据工作项迁出代码（After Check Out）

               图2 程序员在TestCenter的操作

前置条件：
1．程序员获得特定工作项，并根据工作项迁出代码，修改代码并编译代码。
用例描述：
1． 程序员登录TestCenter客户端界面，填写/选择任务及工作项等信息。
2． 程序员登录TestCenter客户端界面，上传编译好的dll文件。
3． 程序员确认在TestCenter客户端所做的操作并提交。
4． TestCenter会根据程序员提交的信息按照预定的规则通知测试人员。
后置条件：
    1．程序员在TestCenter客户端完成操作后，TestCenter会进行响应并给出提示。

3.2 测试人员测试代码（Before Check In）

                       图3 测试人员在TestCenter的操作

前置条件：
1．测试人员必须首先收到全部更改已经提交的通知
用例描述：
1．测试人员登录测试管理中心TestCenter，将所有相关dll文件下载到本地目录
   此时可以进行集成测试
2．测试人员根据测试结果登录测试管理中心，提交操作流转策略：
   如果测试成功，系统可以邮件方式通知程序员迁入代码
   如果测试不成功，系统可以邮件方式通知高级程序员进行Debug或者直接通知程序员进行Debug
后置条件：
    1．TestCenter对测试人员在客户端界面上的操作进行响应/发送邮件通知等

4.工作项(WorkItem)状态管理

        由于测试管理中心的系统边界局限于程序员迁出代码到迁入代码以及测试人员根据工作项获取代码并测试代码这一阶段，因此测试管理中心本身并不能直接控制VSTF中的工作流流程也不能对程序员的代码产生任何影响，因此只能对程序员的工作项和测试人员工作项的状态进行操作。实际上，这将引发VSTF内置的一种事件处理即WorkItemChangedEvent。这里TestCenter修改VSTF工作项状态，从而能在VSTF历史记录或报表中反映出程序员的更改操作。

4.1 程序员工作项的状态变化

        

图4 程序员工作项的状态变化

说明：程序员获得分配的工作项，迁出代码准备操作，此时相应的工作项处于激活状态。当程序员修改了代码，完成编译并进行本地测试后登录测试管理中心，提交所属任务和对应工作项的信息，并将生成的dll上传到数据库中存储，此时相应工作项处于非激活状态。如果测试人员测试通过，程序员会收到通知（邮件或口头的），此时程序员可以将代码迁入并将工作项关闭表明该工作项已经完成；如果测试没有通过，程序员也会得到通知，并将工作项重新激活并重新修改代码然后登录测试管理中心，再次提交信息，直到测试通过迁入代码完成工作项为止。

4.2 测试人员工作项的状态变化

                               

图5 测试人员工作项状态的变化

 

说明：与此同时，测试人员也有与某一任务关联的工作项，当程序员提交了所有与之相关的dll后，测试人员将会收到邮件通知，此时其工作项是激活的。接下来，测试人员将dll下载到本地并进行集成测试，如果测试通过，则通知程序员迁入代码，同时设置自己工作项状态，关闭工作项。否则，在测试人员反复下载dll并测试过程中，其工作项一直处于活动状态。
注意：这里存在一个工作项状态更新同步的问题，一个典型的场景是：程序员A修改完代码编译并上传自己的dll后，TestCenter会将其工作项的状态设置为“已完成”。然而，程序员A可能以前打开了工作项浏览器，上面显示的工作项状态仍为激活，这是因为该浏览窗口没办法实时动态的将数据库中工作项记录的改变反映在前端，这可能会对程序员A产生错误的影响。解决办法就是程序员需要经常手工刷新自己的工作项浏览器。

5. 数据结构

5.1 程序员操作记录实体

 

图6 TestCenter记录程序员操作信息的实体

图7 TestCenter记录测试人员操作信息的实体

工作项记录实体WorkItemRecords     
         该结构中记录有关程序员在测试管理中心填写的相关信息以及对相应工作项和程序文件状态与控制的信息。数据字典如下：

数据域名称 数据域描述
RecordId 工作项记录编号
TaskId 任务Id
TaskName 任务名称
PRId 程序员编号
PRName 程序员名称
WorkItemId 工作项ID
WorkItemName 工作项名称
Version 用以标识对同一用户同一工作项操作的批次，在没有最终关闭工作项前可能存在许多批次，同样在没有最终关闭任务前也可能存在许多批次。
RecordState 该工作项记录的当前状态，本批次结束前一直是活动态，结束后为关闭状态
CreateDate 该记录创建的日期
CanRedo 是否可对该记录重做上传动作
Comment 该记录的操作说明
   

上传文件记录实体ArchiveRecords
        该结构中存储上述一个工作项记录对应的所有上传文件信息。这里一个任务的一个工作项记录一定对应一  个程序员，但一个程序员可以对应一个任务的多个工作项或者多个任务的多个工作项。上传文件信息包括上传文件在相应存储区的路径，文件名的集合等，数据字典如下：

数据域名称 数据域描述
ArchiveRecordId 文件记录Id
RecordId 工作项记录Id
ArchivePath 该工作项记录对应上传文件路径
Archives 本次上传文件名称集合如File1,File2,File3等
   

5.2 测试人员操作记录实体

测试记录实体TestRecords
       该结构中存储测试人员在测试管理中心操作的相关信息，控制对应工作项是否满足迁入策略，允许程序员迁入代码或者引发事件通知高级程序员重新Debug。数据字典如下：

  数据域名称 数据域描述
TestId 测试编号
TaskId 任务Id
TesterId 测试者Id
TesterName 测试者名称
TestDate 测试日期
AssignTo 被指派的Advanced Programer Id
   
   

6. TestCenter整体解决方案

 

图8 测试管理中心TestCenter解决方案示意图

         测试管理中心(TestCenter)基于C/S架构，由一个WinForm的用户操作界面作为客户端以及一个WebService的Controller作为服务端构成。管理员也可以方便地通过Web Page访问服务端进行配置操作，同样的客户端也可以扩展为通过Browser完成原来WinForm界面的所有操作。
         当程序员根据具体工作项将代码迁出并进行修改，完成编译后直接在VS.NET IDE中打开TestCenter的客户端窗口，这是因为该TestCenter客户端程序已经作为插件(Plug-in)形式集成在IDE环境中。
此时，程序员在TestCenter客户端界面上输入或者选择相应的工程项目信息，任务信息以及工作项信息，并指定自己将要上传的Dll路径和名称等。在确认并提交自己的操作后，客户端将用户信息发送给WebService服务端，服务端负责将这些信息存入数据库并按照定义的规则（逻辑）进行处理，如设置本次操作工作项在TestCenter中的状态，通知测试人员等。如果所有的程序员都完成了这一批次的操作，服务端将通过邮件服务器向对应的测试人员发送邮件进行通知。
        测试人员同样可以通过TestCenter客户端浏览某项任务对应所有工作项完成情况列表。当所有工作项已完成一批次的更改操作并发送邮件通知测试人员时，测试人员应能够将与这些工作项相关的并上传到服务器端的DLL文件下载到本地进行集成测试。如果出现异常无法完成测试或者测试过程中出现逻辑上的错误则在TestCenter客户端窗口中进行信息填写以及确认操作。此时，客户端也会将相关信息发送给WebService服务端由服务端进行工作项状态更改等设置，并通过邮件服务器向程序员发送异常或错误通知。程序员重新修改代码、编译并登录TestCenter客户端迭代地进行操作。如果测试通过，TestCenter客户端同样会将测试人员提交信息发送给服务端，服务端也会通过邮件服务器通知所有程序员迁入代码。

7. TestCenter系统架构

 

图9 TestCenter系统结构图

XMLConfigurationManager配置管理层
            TestCenter本身要将程序员和测试人员的操作信息记录到数据库中，同时对Team Foundation Server的连接信息以及其他一些配置信息保存在XML配置文件中并进行动态读取或者修改，因此配置管理层也就作为整个系统的最底层为以上各层提供基础信息服务。

DataEntity数据实体层
            该层负责将TestCenter的数据表映射为数据实体，同时也是客户端与服务端进行数据交互的载体。客户端UI层引用该层的dll，将用户的操作信息填充到实体对象中并调用Web Service的方法交由服务端处理。

DataEntity Service/Business Rule实体服务及业务规则层
            该层其实分为并列的两个部分，实体服务部分实际上是对下层数据实体层CRUD操作的实现，当然我们可以利用各种成熟的ORMaping工具具体实现这一部分。而另一部分则要完成具体的业务规则处理，比如判断什么时候通过邮件服务器给测试人员或者程序员发送邮件，邮件的内容如何等等。

Business Facade 业务外观层
             由于业务层包含许多处理逻辑，全部通过Web Service暴露出去显然是不合适的。这样我们有必要在业务层的上面再作一层包装，并暴露为web method。这样客户端只需要调用数量有限的服务接口就可以了，至于具体的处理逻辑则全部交给业务层去做。

UI用户交互层
             显然，TestCenter的客户端界面就构成了UI层，除了刚才提到的负责收集用户操作信息外，还有一个重要的职责就是进行各种信息的验证。比如，异常单及工作项信息是否填写/选择，内容是否符合处理逻辑等等。这样一来，UI层的任务并不轻松，但是有效的保证了服务端各层处理的正确性。

       

本文来自CSDN博客，转载请标明出处： http://blog.csdn.net/blue_sky_blue_heart/archive/2006/10/29/1355589.aspx