缺陷管理工具手册

目 录

1. 登陆TestDirector8.0 3

2．修改BUG显示列表  5

3. 提交缺陷  8

4. 处理缺陷  13

4.1 PM处理缺陷... 14

4.2 DevLeader处理缺陷... 14

4.3 Dev处理缺陷... 14

4.4 TesterLeader处理缺陷... 15

4.5 Tester处理缺陷... 15

 

TestDirector 使用手册

1. 登陆TestDirector8.0

打开浏览器，输入TestDirector所在的URL地址

点击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对话框，添加所有必输项其中“*红字”代表必填项。

（图需修改）

1. *Defect ID （缺陷编号）

当添加一个BUG时，TD自动分配一个Defect ID，在Add Defect页面上不显示此字段，在添加成功后在Defect列表中显示此字段。

1. *Summary（标题）

标题的书写关系到查询效率，从而影响到整个工作期间的工作效率。所以标题的书写一定要规范。描述部分应该保持简短、准确，提供缺陷的本质信息。例：修改认证方式提交后，认证方式更改无效。

1. *Project （项目）

            下拉选择填写项目名称。[个人网银 企业网银 内部管理]

1. *Subject （模块）

            点击Subject下拉列表框，显示所有Project的Subject，选择BUG存在的子模块，注意，在选择模块时只能选择叶子节点模块。

1. *Detected in Ver （软件版本）

            点击Detected in Ver下拉列表框，选择缺陷发现的当前版本编号。

1. *Severity （缺陷级别）

            下拉选择填写缺陷严重级别。（注：级别判断标准依据缺陷级别分类表）

[1-Low   2-Medium   3-High   4-Very High   5-Urgent]

• Urgent —— 严重错误，包括：

1. 由于程序所引起的死机,非法退出
2. 死循环
3. 导致数据库发生死锁
4. 数据通讯错误
5. 严重的数值计算错误
6. 阻挡构建或下一步功能测试，影响平行测试的功能

• Very High —— 较高级错误，包括：

1. 功能不符
2. 数据流错误
3. 程序接口错误
4. 文档中定义的步骤不可行，缺少所记录的功能

• High —— 高级错误，包括：

1. 次要功能或过程被中断，结果或行为与预期结果不符
2. 界面错误(详细文档)
3. 打印内容、格式错误
4. 简单的输入限制未放在前台进行控制
5. 删除操作未给出提示

• Medium —— 一般错误，包括：

1. 系统满足主要页面要求，对功能有较小影响
2. 辅助说明描述不清楚
3. 显示格式不规范
4. 长时间操作未给用户进度提示
5. 提示窗口文字未采用行业术语
6. 可输入区域和只读区域没有明显的区分标志
7. 系统处理未优化

• Low —— 测试建议

1. 建议性的意见或者建议，未来的增强功能

*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 （修改日期）

 

1. Planned Closing Ver （计划关闭版本）Add Bug时不需要填写此项（当开发人员修复完成bug，测试人员验证完成后填写）
2. Estimated Fix Time （预估修复时间）Add Bug时不需要填写此项（开发人员打开此bug时填写预估修复时间）
3. Closed in Ver （关闭版本）Add BUG时不需要填写此项（当此bug验证已解决后选择关闭版本，一般为验证时的版本）
4. Actual Fix Time （实际修复时间）Add Bug时不需要填写此项（当修复完成后由开发人员填写实际修复时间）
5. Closing Date （关闭日期）此项为可见项但不需要手动输入，当缺陷状态改为closed时系统自动写入当前日期
6. *Description （描述）此项为缺陷的具体描述信息，应按照以下步骤填写：

前提约束：（可选，出现该缺陷有前提条件的情况下填写）

操作步骤：
操作步骤是描述如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，操作步骤的信息必须是完整的、准确的、简明的、可复现的。操作步骤应遵循以下原则： 

1)简单地一步一步地引导复现该缺陷；

2)每一个步骤只记录一个操作；

3)每一个步骤前，使用数字对步骤进行编号；

4)没有缺漏任何操作步骤；

5)没有任何多于的步骤；

6)实际测试中使用的数据，在操作过程中详细描述；

7)对于操作过程中，出现的提示信息，在操作步骤中，用英文半角双引号描述；

8)按钮用[ ]中括号进行描述；

9)链接用英文半角单引号描述。

预期结果：

在需求文档中所描述的执行操作步骤后，软件的现象和产生的行为。

实际结果：

执行操作步骤后，软件的实际现象和产生的行为。实际结果描述是对标题描述的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。 如果一个动作产生多个彼此不同的缺陷结果。为了易于阅读，这些结果应该使用数字序列分隔开来。

建议：相同的操作步骤，产生多个缺陷结果，一个缺陷结果提出一个Bug，而不是把多个不同的缺陷结果写到一个Bug中。

补充说明/注释：

应该包括复现步骤中可能引起混乱的补充信息，是对操作步骤的进一步描述，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。测试人员个人的建议性信息也可写于此处。

1. Comments （评论） Add Bug时不需要填写此项（当bug状态变更时必须要添加comments）
2. 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中添加本次操作的说明。

 

 

4.4 TesterLeader处理缺陷

       测试组长查看BUG，此时开发人员处理完成的BUG状态为Fixed和Rejected。

4.5 Tester处理缺陷

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中添加本次操作的说明。