TD操作手册(DETECTS管理).doc

概述 TestDirector 是 Mercury Interactive 公司推出的基于WEB的测试管理工具，简称TD。TD会指导测试员进行需求定义、测试计划、测试执行和缺陷跟踪，即整个测试过程的各个阶段，通过整合所有的任务到应用程序测试中来确保客户收到更高质量的产品。 根据测试员在推广软件测试规范的过程中碰到的种种问题，特意编写出项目经理（或者测试组长）、程序员、测试员这三种角色的人员从登陆TD以后，在DEFECTS管理区应该做到的事情。 下面简要的介绍一下在TD中对BUG的追踪管理流程，以及项目经理（或者测试组长）、程序员、测试员这三种角色的人员应该完成的工作。 BUG从产生到最后被关闭的整个流程如下图： 登陆 打开IE，在地址栏输入http://[TD服务器地址]/TDBIN/default.htm；就可以打开TD的主页面，首次登陆TD会提示你安装一些TD的插件，如图所示： 在这里我们要选择“是”；就可以安装TD的插件，如下图所示： 插件安装完成后，就可以打开TD的主页面，如下图： 登陆成功后，就可以进入到这个项目中。在菜单栏一共有四个LAB分别是：REQUIREMENTS（需求管理）；TEST PLAN（测试计划）；TEST LAB（测试执行）；DEFECTS(缺陷管理)。在这里只谈如何对BUG进行记录，点击DEFECTS管理区，就会打开如下的窗口： 测试员提交BUG 点击窗口左上角的Add Defects按钮，弹出记录BUG信息的窗口，如下图： 测试员在Add Defect页面将BUG信息录制完成后，点击submit按钮，就可以完成BUG的提交。 注：一条Bug记录最基本应包含：编号、Bug所属模块、Bug描述、Bug级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等。 提交完成后，TD的缺陷管理中就会出现一条新的BUG，见下图： 项目经理（或测试组长）对BUG的操作 由于测试员和程序员没有把BUG的状态直接从“NEW”置为“FIXED”的权限，因此项目经理（或测试组长）对BUG的操作主要是对BUG的审核，审核确定后项目经理（或测试组长）将BUG的状态从“NEW”置为“OPEN”，同时将BUG分配给程序员修复。操作过程如下： 项目经理登陆后，打开DEFECTS管理区，双击BUG的信息，弹出如下界面： 项目经理根据Description和Attachments两个部分的内容来审核BUG。 注：本文档主要是针对不采用IIS邮件服务的TD的操作，若采用了IIS邮件服务，项目经理可以根据收到的邮件中对BUG的描述来进行审核，审核完成后再登陆TD修改BUG的状态，并分配给程序员。 确定是BUG后，把BUG状态改为OPEN，程序员就有权限修改BUG的状态了。 注：当项目经理审核BUG，发现不是软件存在的BUG时，直接修改为REJECTED的状态即可。 程序员对BUG的操作 当BUG状态变成OPEN后，程序员就有权限修改BUG的状态了。 注：本文档主要是针对不采用IIS邮件服务的TD的操作，若采用了IIS邮件服务，程序员可以根据收到的邮件中对BUG的描述来进行修复，修复完成后再登陆TD修改BUG的状态。 程序员登陆TD后，打开DEFECTS管理区，双击BUG的信息，查看Description和Attachments两个部分的内容，根据BUG信息对BUG进行修复。如下图： 当程序员将BUG修改完成后，可以在TD中将BUG的状态从“OPEN”改为“FIXED”。 同时要强调一点的是：当程序员把BUG的状态修改完成后，填写修改BUG的信息后，一定要打开Description栏，将修改BUG的一些信息标注上，以备今后对BUG的追踪。见下图： 上述操作也可以在DEFECTS管理区的主页面直接进行。如下图： 6.回归测试 程序员修复完BUG，并将BUG状态修改成“FIXED”后，测试员要进行回归测试，确定BUG是否已经修复。 若还存在问题，就把BUG状态修改成“REOPEN”，此时，测试员必须点击Add Comment按钮,添加BUG的标注信息，以备今后对BUG的追踪。接着重复程序员修复BUG--回归测试--关闭BUG的过程。 若BUG已经修复，则把BUG状态修改成“CLOSED”。 经过以上的操作，我们就完成了对一条BUG的全程跟踪操作，在这个操作过程中涉及到的三个角色：测试员、项目经理、程序员，对记录下来的每一条BUG都有历史记录，如： 7.结束语 上述过程就是一个BUG的全程跟踪过程，下面总结一下测试员、项目经理、程序员在TD的DEFECTS管理中各个角色的具体工作： 测试员：NEW BUG，回归测试，CLOSED BUG，REOPEN BUG； 项目经理：审核BUG，OPEN BUG,分配BU