第十二章qc的使用和缺陷管理

第十二章QC的使用和缺陷管理IT@ANY本课程的主要内容QC的使用（重点）缺陷管理（重点）缺陷的管理流程缺陷的基本要素缺陷的书写规范缺陷的度量与分析编写测试报告（重点）本章目标会熟练使用QC进行测试过程管理（重点）能够准确的表达并记录缺陷（重点）能够编写测试报告（重点）第一部分QC的使用缺陷管理缺陷的管理流程缺陷的基本要素缺陷的书写规范缺陷的度量与分析编写测试报告QC的使用下载地址

备注：1.用户名密码:wuye1232.QC10.0：运行在windows2003sp2环境上，windowsxp不能安装QC安装注意事项1.安装前需要先安装Oracle数据库2.安装时需要注意数据库的配置QC的使用介绍1.QC是一款集测试版本控制、测试需求、测试用例、测试执行、测试度量为一体的测试管理工具。2.针对每一个模块的使用进行介绍，重点在于使用QC进行测试用例设计和测试执行第二部分QC的使用缺陷管理缺陷的管理流程缺陷的基本要素缺陷的书写规范缺陷的度量与分析编写测试报告软件失败的术语缺点（defect）

偏差（variance）故障（fault）

失败（failure）问题（problem）矛盾（inconsistency）错误（error） 特殊（feature）事件（incident）

缺陷（bug）

异常（anomaly）故障、失败、缺点：非常严重，甚至致命的情况异常、事件、偏差：不是很尖锐，主要指未按预料运行，而不是说完全失败问题、错误、缺陷：最常用的术语缺陷管理工具开源免费的BugZilla、Mantis、JIRA、BugFree商业的QC、IBMRationalClearQuest、CompuwareTrackRecord软件缺陷生命周期软件缺陷的生命周期：从发现缺陷到解决缺陷并关闭的整个过程软件缺陷在整个生命周期中的状态关于软件缺陷在整个生命周期中的状态，跟每个公司的开发流程有关，每个公司都有不同的定义，下面是一个大致的流程，可在此基础上进行伸缩：1.测试人员发现并记录缺陷（new/open）2.测试人员将缺陷提交给项目经理，项目经理会对该缺陷进行确认2.1

如果确认为是一个缺陷，那么项目经理会将该缺陷进行分配（assigned）2.2

如果项目经理认为这不是一个缺陷，那么会将该缺陷打回给测试人员（rejeccted），或者直接关闭（closed）3.开发人员在接到这个缺陷后，也需要先对缺陷进行判断3.1

如果是缺陷，就对缺陷进行处理（InProgress），处理完成（resolved/fixed）后将缺陷重新返回给测试人员3.2

如果不是缺陷，可直接返回给测试人员（rejected）4.测试人员接收到开发人员返回的缺陷后，需要做如下处理4.1

对于开发人员修复的缺陷（resolved/fixed）进行回归测试，如果测试通过则置为（Testd/Closed），测试不通过可以重开（Reopen），重新将缺陷打回给开发人员4.1

对于开发人员拒绝的缺陷（Rejected），一般是存在争议的缺陷，经过项目组讨论或评定后，确认不是缺陷可以直接对其进行关闭（Closed），如果确认是缺陷，需要对其进行重开（Reopen,如果该缺陷可暂缓修复或修复成本较高，需另行找时间修复，可将缺陷挂起（Suspened）软件缺陷在整个生命周期中的状态主要状态有：Open/New、Assigned、InProgress、Resloved、Rejected、Reopen、Tested/ClosedBug状态走向：Open-ClosedOpen-Rejected-ClosedOpen-Assigned-InProgress-Resolved-ClosedOpen-Assigned-InProgress-Resolved-Reopen…ClosedOpen-Assigned-Rejected-Closed软件缺陷处理流程及状态变化缺陷的处理流程-示例1缺陷管理综合流程-示例2缺陷的基本要素缺陷的基本信息*缺陷ID（由系统自动生成，唯一的）*缺陷的标题测试的软件和硬件环境（特殊环境下可注明）*测试的软件版本（缺陷发现版本和修复版本，发现版本是指当前版本，修复版本一般由项目经理确认）*缺陷的类型（功能的、性能的、使用方面、安全的等等）*缺陷的严重程度（由测试人员确定）缺陷的处理优先级（一般由项目经理确定）*复现缺陷的操作步骤（操作步骤）复现缺陷的测试数据（特定数据需要注明，比如特定的账号）*缺陷的实际结果描述（错误描述）*期望的正确结果描述（期望结果）缺陷产生的原因分析（如果测试人员能判定原因就给出，不能判定就无需给出，以免误导开发人员）注释文字和截取的缺陷图像缺陷处理信息缺陷提交者（系统默认）缺陷处理者（1.项目经理指派，2.已知模块的缺陷可由测试人员直接分配给开发人员）缺陷解决方案（一般由开发者总结问题原因并给出修改方案）缺陷提交时间缺陷处理时间（一般情况下缺陷的提交时间和处理时间由缺陷管理工具自动生成）缺陷的严重等级-按5类划分分类严重等级等级描述A致命性的(Critical)

不能执行正常工作功能或重要功能，或者危及人身安全的，主要表现在：

1.由于程序所引起的死机,非法退出

2.死循环

3.导致数据库发生死锁

4.数据通讯错误

5.严重的数值计算错误B严重的

(Major)严重影响系统要求或基本功能实现的，主要表现在：

1.功能不符

2.数据流错误

3.程序接口错误

4.轻微的数值计算错误C一般的

(Generic)一般性错误，比较容易修复的，主要表现在：

1.界面错误(详细文档)

2.打印内容、格式错误

3.简单的输入限制未放在前台进行控制

4.删除操作未给出提示缺陷的严重等级-按5类划分分类严重等级等级描述D轻微的

(Minor)比较轻微的错误，一般是使用方面的问题，主要表现在：

1.辅助说明描述不清楚

2.显示格式不规范

3.长时间操作未给用户进度提示

4.提示窗口文字未采用行业术语

5.可输入区域和只读区域没有明显的区分标志

6.系统处理未优化

E建议性的

(Suggestion)从测试人员角度提出的一些建议性的问题，不一定是缺陷缺陷的严重等级-按4类划分分类严重等级等级描述A严重的系统崩溃、数据丢失、数据损坏B较严重的操作性错误、错误结果、遗漏功能C一般的小问题、错别字、UI布局、罕见故障D建议性的不影响使用的瑕疵或更好的实现备注：缺陷的严重等级大体分为这么几类，要么是5类，要么是4类，跟每个公司对缺陷的定义有关，面试时请注意按实际情况活学活用缺陷的优先级

缺陷的优先级描述1最高优先级需要停止进一步测试，立即修复的缺陷2次高优先级缺陷需要正常排队等待修复或列入软件发布清单，但需要在产品发布之前必须修复3中等优先级如果时间允许应该修复的缺陷4最低优先级缺陷可能被修复，也可能不被修复就直接发布备注：缺陷的优先等级大体分为，跟每个公司对缺陷的定义有关，面试时请注意按实际情况活学活用缺陷的书写规范缺陷标题（Title）标题应该保持简短、准确，提供缺陷的本质信息，并便于读者搜索查寻

良好的缺陷标题应该按照下列方式书写：

尽量按缺陷发生的原因与结果的方式书写（“执行完A后，发生B，”或者“发生B，当A执行完后”）避免使用模糊不清的词语，例如“功能中断，功能不正确，行为不起作用，”等。应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用为了方便搜索和查询，请使用关键字为了便于他人理解，避免使术语、俚语或过分具体的测试细节举例：品红网站后台使用管理员账号登录失败缺陷的书写规范复现步骤（ReproducibleSteps）

复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。不友好的重现步骤：复现步骤包含了过多的多余步骤，而且句子结构混乱，可读性很差，难于理解复现步骤包含了过少的信息，丢失操作的必要步骤。由于提供的步骤不完整，开发人员经常需要种种猜测，努力尝试复现的步骤，浪费了大量时间。由于缺少关键步骤，这些缺陷通常被工程师以“不能复现”为由Rejected给测试人员

测试人员没有对软件缺陷发生的条件和影响区域进行隔离，软件开发人员无法判断该缺陷影响的软件部分，不能进行彻底修正。缺陷的书写规范正确的重现步骤（ReproducibleSteps）：准确无误的重现操作步骤，步骤不多余，无遗漏每一个步骤尽量只记录一个操作每一个步骤前使用数字对步骤编号尽量使用短语和短句，避免复杂句型和句式将常见步骤合并为较少步骤，例如：1.Createtextframe.2.Addtext.可以简单的合并成一步：1.Createanewtextframeandaddtext.只记录各个操作步骤是什么，不要包括每个操作步骤执行后的结果

说明：重现步骤可参考测试用例中的步骤举例：Login_Bug_001:品红网站后台使用管理员账号登录失败操作步骤：进入品红网站后台管理界面输入正确的用户名和密码，点【登录】按钮缺陷的书写规范实际结果（也就是错误描述）尽可能将缺陷分解成多个缺陷报告，并使用交叉引用说明彼此之间的联系。这些动作的结果通常比较相似但缺陷不同。首先进行更多的隔离测试，缩小产生缺陷的范围，查看是否产生多个缺陷在实际结果部分，仅列出缺陷的一到两个表现特征。使用注释（Notes）部分列出缺陷的其它问题；在缺陷的第一个表现特征后，将随后的步骤和缺陷表现特征移到注释部分。重要的信息几乎总是包含在第一个断言或错误里，其它错误都是第一个错误的变种。举例：001:品红网站后台使用管理员账号登录失败操作步骤：进入品红网站后台管理界面输入正确的用户名和密码，点【登录】按钮错误描述：1.登录失败，系统给出错误提示缺陷的书写规范自我检查和提问•

缺陷报告已经向读者包含完整、准确、必要的信息了吗？•

一个缺陷报告中是否之报告了一种缺陷？•

读者是否能容易的搜索该缺陷？•

步骤是否可以完全复现而且表达清楚吗？•

是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？•

缺陷的标题是按照原因与结果的方式书写的吗？•

实际结果和期望结果是否描述不够清楚而容易引起歧义吗？缺陷的书写规范避免常见的错误用“User（用户）”代替使用者，避免使用“I（我）”、“You（你）”等人称代词客观地反映出缺陷的现象和完整信息，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽，避免使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等对实际结果的描述要清晰，避免使用含义模糊的词汇，诸如“Seems（似乎）”、“Appearstobe（看上去可能）”等等客观地描述缺陷的信息，避免包含自认为比较幽默的内容，因为不同读者的文化和观念不同，很多幽默内容在别人看来，往往难以准确理解，甚至可能引起误解对于无法确定的缺陷，应该先将问题记录下来，然后通过电子邮件或口头交流，确认是缺陷后再报告到缺陷库中，避免查询和统计结果的不准确性对于偶发性的缺陷，先将缺陷记录在缺陷库中，视缺陷发生频率进行处理，频率高的必须要求修改，频率低的可先将缺陷挂起，待日后修复，避免不重现就直接提交缺陷完整缺陷记录示例001(BugID，系统自动生成)品红网站后台使用管理员账号登录失败（BUG标题）缺陷发现版本：ph_20100801_01(当前版本）缺陷修复版本：默认（由项目经理统一分配）测试环境：（需要特殊说明时给出）严重等级：严重（视缺陷具体情况给出）优先级：默认（由项目经理统一分配）操作步骤：1.进入品红网站后台管理界面2.输入正确的用户名和密码，点【登录】按钮测试数据：用户名：bass密码：bass错误描述：（实际结果）1.管理员账号登录失败，系统给出错误提示（主要缺陷）2.错误提示信息中“登陆”使用错误（次要缺陷）期望结果：

1.管理员账号能够成功登录品红网站后台系统2.提示信息中的“登陆”应改为“登录”分配给：项目经理或开发人员姓名（新建的BUG默认给项目经理）测试人员：测试人员姓名缺陷状态：new（默认新建缺陷时的状态）缺陷统计分析按错误类型按严重等级按优先级别按问题状态按问题类型与严重程度组合按发现人员与严重程度组合缺陷统计分析按模块分布缺陷统计分析按对象分布缺陷统计分析按缺陷类型分布缺陷密度分析缺陷密度软件缺陷分为通过评审的或测试等方法发现的已知缺陷和尚未发现的潜在缺陷两种缺陷密度=已知缺陷数量/产品规模缺陷注入-发现矩阵缺陷移除率=（本阶段发现的缺陷数/本阶段注入的缺陷数）*100%缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）100%计算缺陷移除率的意义可以有效的衡量测试用例是否充分测试效率是否充足分析出软件开发各个环节的质量，找到最需要改进的环节缺陷注入-发现矩阵

缺陷注入阶段缺陷发现