从开发模型可以看出在软件项目实施过程中非常重要并且占项目实施时间最长的过程是迭代过程中的特性开发过程，而特性开发过程中的主线是需求，在特性开发过程中的设计、评审、编码、版本集成、测试等活动都是围绕着需求开展的。QA人员对迭代过程中特性开发过程的检查也是以需求为主线进行的，QA人员通过检查迭代过程中的需求点是否进行了需求分析、是否进行需求评审、是否进行了设计、是否进行设计评审、是否进行了编码、是否进行了测试等来判断项目组过程的实施是否满足软件项目实现的要求，是否有过程缺失，或过程实施流于形式。迭代过程中需求与需求的活动覆盖关系可以通过以下这个矩阵体现：

　　通过上面的矩阵关系我们可以明白只要了解了需求与需求相关活动的覆盖情况就可以掌握迭代过程的实施情况，并且对项目的进度控制也会起到一定的作用。而TD的最大优势就是需求的覆盖功能，即通过测试用例对需求的覆盖以及bug与测试用例的关联关系从而了解和控制需求实现情况。因此我们可以利用TD的这一优势实现我们需要了解迭代过程中需求与需求相关活动覆盖情况的要求，在一定程度上TD可以起到软件项目实现过程控制的作用。

　　一、使用TD对软件中心的过程进行管理

　　使用TD可以代替一些质量记录和技术文档如评审记录、测试大纲等，而且TD有添加附件的功能，可以将相关文档作为某个任务的附件进行评审和管理。

　　requirement页面中二、三级节点主要体现项目计划中的里程碑事件。

　　1.1.2 TestDirector的requirement页面所需的字段：

　　编号字段名字段说明一般使用的节点备注

　　1计划开始时间手工填写二、三级节点

　　2计划完成时间 二、三级节点

　　3创建人自动生成(TD的录入人) 是否需要

　　4责任人 手工填写二、三、四级节点

　　5计划类型计划内计划外二、三、四级节点主要用于需求点

　　6计划版本号 手工填写四级节点

　　7集成版本号 手工填写 四级节点 第一次版本集成的版本号

　　8集成版本时间 根据“集成版本号”填写自动生成 四级节点日志

　　9测试通过版本号 手工填写 四级节点

　　10测试版本时间 根据“测试通过版本号”填写自动生成四级节点日志

　　11变更版本号 手工填写 四级节点 计划变更

　　12变更版本时间 根据“变更版本号”填写自动生成 四级节点日志

　　13交付版本号 手工填写 四级节点

　　14交付版本时间 根据“交付版本时间”填写自动生成 四级节点日志

　　注：QA是requirement analyse的缩写，D是design的缩写，C是code的缩写，

　　EI是edition integration的缩写，T是test的缩写，TR是test review的缩写

　　SI是software issuance 的缩写，PD是product delivery的缩写

　　每一个过程中的任务前面加一个英文缩写前缀，是方便检查需求与需求相关活动覆盖情况用的。

　　1.2.2 TestDirector的testplan页面所需的字段：

　　编号字段名字段说明一般使用的节点备注

　　计划开始时间 手工填写二、三、四级节点

　　计划完成时间

　　二、三、四级节点

　　任务下达者自动生成(任务的创建者)

　　三、四级节点

　　任务接受者手工填写

　　三、四级节点发邮件给任务接受者。

　　预计工作量手工填写三、四级节点

　　实际工作量手工填写三、四级节点

　　实际完成时间手工填写二、三、四级节点二节点的实际完成时间应该是版本上线时间

　　任务接受否是三、四级节点

　　任务接受时间根据“任务接受”填写“是”三、四级节点

　　评审类型评审复审代码审核三、四级节点

　　评审组长手工填写三、四级节点

　　评审方式

　　会议传递个人三、四级节点

　　提交评审未提交提交三、四级节点发邮件给项目经理 (或评审组长)

　　提交评审时间根据“提交评审”变成“提交”自动生成三、四级节点

　　Description 手工填写 三、四级节点

　　Expected Result手工填写三、四级节点

　　1.2.3 Test plan与Requirement的覆盖关系：

　　1、 requirement中项目计划过程、软件发布、产品交付，这些过程或活动是与test plan中项目计划、软件发布、产品交付是一对一的覆盖。

　　2、 requirement中迭代开发过程中的需求点至少被每一个以QR_、D_、C_、EI_、T_前缀的任务覆盖，即多对一的覆盖。如下图：

　　3、 Test plan中的需求分析、设计过程、软件实现过程、版本集成、测试过程(前缀为TR_)、软件发布、产品交付中的任务与requirement中迭代开发过程中的需求点的覆盖关系也可以是一对多的关系。如图

　　通过以上的覆盖关系可以很快地查找到项目过程中有哪些过程缺失，有哪些技术文档和质量记录缺失，并且可以比较快的统计出过程的缺失率和技术文档和质量记录缺失率，还可以方便项目负责人对项目过程和进度的控制。

　　1.3 TestDirector中test lab的设计

　　1.3.1 test lab的命名规则分以下两种：

　　1、 项目代码 + _ + requirement页面中第二级节点名称(项目计划过程、软件发布过程、产品交付过程)

　　2、 项目代码 + _ + 迭代版本号 + _ + TestDirector的testplan页面中第三级节点名称(需求分析、设计过程、程序实现过程、版本集成过程、测试过程)

　　将test plan中的任务加入到对应的test lab中进行运行。

　　1.3.2 在test lab中运行任务所表示的意义如下：

　　1、 项目计划过程、需求分析、设计过程在test lab中任务的运行表示对这些过程中的相关技术文档进行评审，一般是由评审组长和评审记录员执行。与这些test lab含义相同的还有程序实现过程中的代码复审和测试过程中的测试用例等文档的评审(有TR_前缀的任务)。

　　2、 版本集成、软件发布过程、产品交付过程在test lab中任务的运行表示这些过程的完成情况。一般由项目经理和集成人员执行。

　　3、 程序实现过程(不包含代码复审)在test lab中任务的运行结果表示开发人员对所编写的代码进行调试和单元测试的情况，集成人员可以通过运行结果决定是否集成。一般由软件开发人员执行。

　　4、 测试过程在test lab中测试用例的运行结果表示对产品测试的结果，一般由测试人员执行。

　　1.3.3 TestDirector的test lab页面所需的字段：

　　编号字段名字段说明备注

　　执行人

　　自动生成

　　执行时间自动生成

　　任务状态(status)手工填写(pass、failde、no run等)

　　结果(Actual)手工填写记录过程实际操作的情况和相关信息。

　　1.4 TestDirector中defects的操作情况

　　Defects中存在的问题一般都是评审和测试产生的问题，这些问题可以按产品bug管理流程的要求进行管理和操作。

　　二、使用TestDirector7.6的好处

　　1、 TestDirector7.6的使用在一定程度上可以方便QA人员和相关负责人对项目过程和进度的了解和控制，可以较快的发现过程和相关文档的缺失情况，并且帮助可以QA人员和相关负责人了解某一需求点在某一时间处于什么过程中。

　　2、 TestDirector7.6中有些字段的数据可以根据需要自动生成，这样可以保证数据的真实性。如通过一些自动产生的时间字段可以知道哪些过程是按流程进行的，哪些过程是后来补做的。

　　3、 TestDirector7.6的使用有利于度量工作的开展。TestDirector7.6中可以根据需要增加字段，这样有利于数据的采集和统计分析，并且该工具本身也有统计功能。如使用TestDirector7.6可以较快的统计出过程的缺失率和技术文档和质量记录缺失率、以及各种评审方式所占的比例等。

　　4、 TestDirector7.6的使用可以减少QA人员的过程检查时间，这样即使QA人员和测试人员是同一个人，工作量也不会很大，开发组提交测试进行软件测试，没有软件测试时可以做过程检查，这样既对产品质量进行了检查，也对过程质量进行了检查。