目 录
TestDirector 使用手册
1. 登陆TestDirector8.0
打开浏览器，输入TestDirector所在的URL地址 <http://[server name]/[Virtual Directory Name]/default.htm>
点击TestDirector链接进入缺陷管理软件主页面，点击Domain下拉列表框选择域 ，点击Project下拉列表框选择项目名称，User ID输入自己的UserName ，Password 默认为空 ，点击Login按钮
进入主页面，登录后请大家及时修改自己的Password ，方法： 主页 -> Tools -> Change Password
2．修改BUG显示列表
进入TD页面
点击Select Columns按钮，页面弹出Select Columns对话框，选择Available Columns列表中的可用项添加到Visible Columns列表中，若要调整显示位置，在Visible Columns列表中选中调整的项，点击
按钮调整选项在页面显示的位置，调整完毕后点击OK按钮
3. 提交缺陷
用户点击
按钮，页面弹出Add Defect对话框，添加所有必输项其中“*红字”代表必填项。
（图需修改）
- *Defect ID （缺陷编号）
当添加一个BUG时，TD自动分配一个Defect ID，在Add Defect页面上不显示此字段，在添加成功后在Defect列表中显示此字段。
- *Summary（标题）
标题的书写关系到查询效率，从而影响到整个工作期间的工作效率。所以标题的书写一定要规范。描述部分应该保持简短、准确，提供缺陷的本质信息。例：修改认证方式提交后，认证方式更改无效。
- *Project （项目）
下拉选择填写项目名称。[个人网银 企业网银 内部管理]
- *Subject （模块）
点击Subject下拉列表框，显示所有Project的Subject，选择BUG存在的子模块，注意，在选择模块时只能选择叶子节点模块。
- *Detected in Ver （软件版本）
点击Detected in Ver下拉列表框，选择缺陷发现的当前版本编号。
- *Severity （缺陷级别）
下拉选择填写缺陷严重级别。（注：级别判断标准依据缺陷级别分类表）
[1-Low 2-Medium 3-High 4-Very High 5-Urgent]
- Urgent —— 严重错误，包括：
- 由于程序所引起的死机,非法退出
- 死循环
- 导致数据库发生死锁
- 数据通讯错误
- 严重的数值计算错误
- 阻挡构建或下一步功能测试，影响平行测试的功能
- Very High —— 较高级错误，包括：
- 功能不符
- 数据流错误
- 程序接口错误
- 文档中定义的步骤不可行，缺少所记录的功能
- High —— 高级错误，包括：
- 次要功能或过程被中断，结果或行为与预期结果不符
- 界面错误(详细文档)
- 打印内容、格式错误
- 简单的输入限制未放在前台进行控制
- 删除操作未给出提示
- Medium —— 一般错误，包括：
- 系统满足主要页面要求，对功能有较小影响
- 辅助说明描述不清楚
- 显示格式不规范
- 长时间操作未给用户进度提示
- 提示窗口文字未采用行业术语
- 可输入区域和只读区域没有明显的区分标志
- 系统处理未优化
- Low —— 测试建议
- 建议性的意见或者建议，未来的增强功能
*By Case （依据用例）若提交的BUG在用例中有描述，则在此处选择Y；若提交的BUG在用例中没有描述，则在此处选择N。
Case No （用例编号）当By Case选择为Y时，Case No为必填项，需要提交人员手动填写用例编号；当By Case选择为N时，Case No为非必输项，此时可以为空。
*Assigned To （缺陷解决人）点击下拉列表框选择指定的开发组组长
Reproducible （可复现的）提交的BUG应验证是否可以在此版本中复现，若可以复现BUG则选择Y；若不可以复线此BUG则选择N。
Root Cause （根源）在Add Defect时不需要选择Root Cause，当开发人员修复BUG时由开发人员选择此选项。
Priority （优先级）
在Add时，不需要填写优先级，由开发组长分配BUG时进行添加。
*Status （缺陷状态）
默认显示NEW状态
*Detected By （缺陷提交人）
默认显示为当前登录名
*Detected on Date （缺陷提交日期）
默认显示为当天
Open Date （缺陷打开日期）
此项为可见项但不需要手动输入，当缺陷状态改为Open时系统自动写入当前日期。
Fixed Date （缺陷修复日期）
此项为可见项但不需要手动输入，当缺陷状态改为Fixed时系统自动写入当前日期。
Modified （修改日期）
- Planned Closing Ver （计划关闭版本）Add Bug时不需要填写此项（当开发人员修复完成bug，测试人员验证完成后填写）
- Estimated Fix Time （预估修复时间）Add Bug时不需要填写此项（开发人员打开此bug时填写预估修复时间）
- Closed in Ver （关闭版本）Add BUG时不需要填写此项（当此bug验证已解决后选择关闭版本，一般为验证时的版本）
- Actual Fix Time （实际修复时间）Add Bug时不需要填写此项（当修复完成后由开发人员填写实际修复时间）
- Closing Date （关闭日期）此项为可见项但不需要手动输入，当缺陷状态改为closed时系统自动写入当前日期
- *Description （描述）此项为缺陷的具体描述信息，应按照以下步骤填写：
前提约束：（可选，出现该缺陷有前提条件的情况下填写）
操作步骤：
操作步骤是描述如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，操作步骤的信息必须是完整的、准确的、简明的、可复现的。操作步骤应遵循以下原则：
1)简单地一步一步地引导复现该缺陷；
2)每一个步骤只记录一个操作；
3)每一个步骤前，使用数字对步骤进行编号；
4)没有缺漏任何操作步骤；
5)没有任何多于的步骤；
6)实际测试中使用的数据，在操作过程中详细描述；
7)对于操作过程中，出现的提示信息，在操作步骤中，用英文半角双引号描述；
8)按钮用[ ]中括号进行描述；
9)链接用英文半角单引号描述。
预期结果：
在需求文档中所描述的执行操作步骤后，软件的现象和产生的行为。
实际结果：
执行操作步骤后，软件的实际现象和产生的行为。实际结果描述是对标题描述的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。 如果一个动作产生多个彼此不同的缺陷结果。为了易于阅读，这些结果应该使用数字序列分隔开来。
建议：相同的操作步骤，产生多个缺陷结果，一个缺陷结果提出一个Bug，而不是把多个不同的缺陷结果写到一个Bug中。
补充说明/注释：
应该包括复现步骤中可能引起混乱的补充信息，是对操作步骤的进一步描述，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。测试人员个人的建议性信息也可写于此处。
- Comments （评论） Add Bug时不需要填写此项（当bug状态变更时必须要添加comments）
- Attach（添加附件）
缺陷需有其他文件辅助说明时，测试人员要添加相关文件。如：截图、导入文件等。
当所有Add项都填写完整后点击Submit按钮，添加BUG成功，查看BUG列表状态为New
4. 处理缺陷
（缺陷处理流程图）
（Defect Details）
4.1 PM处理缺陷
TD管理员登录后可以做所有BUG的处理操作。
注：PM登陆对BUG进行任何操作，不需要在comments添加本次操作的说明。
4.2 DevLeader处理缺陷
各开发组长登陆TD后，查看相应负责系统的所有BUG，此时BUG状态为New
1：New状态的缺陷处理：
- 各开发组组长过滤缺陷，更改Assigned To到指定开发工程师，修改Status为“Open”；
- 缺陷责任人分析缺陷原因，选择Root Cause和Priority ，并且填写Comments。
4.3 Dev处理缺陷
开发人员接到BUG，此时BUG状态为Open
1：Open状态的缺陷处理：
- 已解决：Planned Closing Ver中选择“应验证的版本号”，Status更改为“Fixed”，Comments中点击『添加注释』填写“缺陷已经修复，并简单描述缺陷出现的原因。”；
- 下期修复：Status更改为“Rejected”，Comments中点击『添加注释』填写“Hold,后期修复，说明推迟解决理由。”；
- 不是缺陷：Status更改为“Rejected”，Comments中点击『添加注释』填写“不是缺陷，并描述出理由。”。
- 提交重复：Status更改为“Rejected”，Comments中点击『添加注释』填写“重复缺陷，Bug ID： XXXX”；
2：Reopen状态的缺陷处理方法同Open状态。
3：Hold状态的缺陷处理：
- 已达到修复条件：Status更改为“Reopen”，Comments中点击『添加注释』填写“并简单描述原因。”；
注：对TD中的Bug进行任何操作，均需在Comments中添加本次操作的说明。
测试组长查看BUG，此时开发人员处理完成的BUG状态为Fixed和Rejected。
1：Fixed 状态的缺陷验证：验证版本参考Planned Closing Ver
- 验证未通过：Status更改为“Reopen”，Comments中点击『添加注释』填写“验证未通过，描述的问题仍存在，并指明验证版本。”；
- 验证通过：Status更改为“Closed”，Closed in ver中选择“验证版本编号”，Comments中点击『添加注释』填写“XX版本验证通过，关闭。”。
2：Rejected 状态的缺陷验证：
Rejected原因：Not Bug
- 开发工程师认为缺陷不是缺陷，测试人员认同：Status更改为“Not Bug”，Closed in ver中选择“验证版本编号”，Comments中点击『添加注释』填写“同意意见，关闭。”；
- 开发工程师认为缺陷不是缺陷，测试人员不认同：Status更改为“Reopen”，Comments中点击『添加注释』填写“测试人员描述详细原因”；
Rejected原因：Duplicate
- 开发工程师认为缺陷是重复缺陷，测试人员认同，并验证通过：Status更改为“D-Closed”，Closed in ver中选择“验证版本编号”，Comments中点击『添加注释』填写“同意意见，验证通过，关闭。”；
- 开发工程师认为缺陷是重复缺陷，测试人员不认同，或验证未通过：Status更改为“Reopen”，Comments中点击『添加注释』填写“测试人员描述详细原因”；
Rejected原因： Hold
- 开发工程师认为缺陷是缺陷，但因为特殊原因延期进行修改，本次测试过程中不进行处理，测试人员认同：Status保留为“Hold”，Comments中点击『添加注释』填写“同意意见，待审核。”；
- 开发工程师认为缺陷是缺陷，但因为特殊原因延期进行修改，本次测试过程中不进行处理，测试人员不认同：Status更改为“Reopen”，Comments中点击『添加注释』填写“测试人员描述详细原因”；
3：Closed 状态的缺陷验证：
- 验证未通过：Status更改为“Reopen”，Comments中点击『添加注释』填写“描述问题重新复现，缺陷打开。”。
注：对TD中的Bug进行任何操作，均需在Comments中添加本次操作的说明。
