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

第十二章QC的使用和缺陷管理IT@ANY2本课程的主要内容QC的使用（重点）缺陷管理（重点）缺陷的管理流程缺陷的基本要素缺陷的书写规范缺陷的度量与分析编写测试报告（重点）3本章目标会熟练使用QC进行测试过程管理（重点）能够准确的表达并记录缺陷（重点）能够编写测试报告（重点）4第一部分QC的使用缺陷管理缺陷的管理流程缺陷的基本要素缺陷的书写规范缺陷的度量与分析编写测试报告5QC的使用下载地址=https%3A//h10078.=quicktest&type=HPR&pos=2&key=quicktest&alias=Software+Testing备注：1.用户名:[e-mail]密码:wuye1232.QC10.0：运行在windows2003sp2环境上，windowsxp不能安装6QC安装注意事项1.安装前需要先安装Oracle数据库2.安装时需要注意数据库的配置7QC的使用介绍1.QC是一款集测试版本控制、测试需求、测试用例、测试执行、测试度量为一体的测试管理工具。2.针对每一个模块的使用进行介绍，重点在于使用QC进行测试用例设计和测试执行8第二部分QC的使用缺陷管理缺陷的管理流程缺陷的基本要素缺陷的书写规范缺陷的度量与分析编写测试报告9软件失败的术语缺点（defect）偏差（variance）故障（fault）失败（failure）问题（problem）矛盾（inconsistency）错误（error）特殊（feature）事件（incident）缺陷（bug）异常（anomaly）故障、失败、缺点：非常严重，甚至致命的情况异常、事件、偏差：不是很尖锐，主要指未按预料运行，而不是说完全失败问题、错误、缺陷：最常用的术语10缺陷管理工具开源免费的BugZilla、Mantis、JIRA、BugFree商业的QC、IBMRationalClearQuest、CompuwareTrackRecord11软件缺陷生命周期软件缺陷的生命周期：从发现缺陷到解决缺陷并关闭的整个过程12软件缺陷在整个生命周期中的状态关于软件缺陷在整个生命周期中的状态，跟每个公司的开发流程有关，每个公司都有不同的定义，下面是一个大致的流程，可在此基础上进行伸缩：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）13软件缺陷在整个生命周期中的状态主要状态有：Open/New、Assigned、InProgress、Resloved、Rejected、Reopen、Tested/ClosedBug状态走向：Open-ClosedOpen-Rejected-ClosedOpen-Assigned-InProgress-Resolved-ClosedOpen-Assigned-InProgress-Resolved-Reopen…ClosedOpen-Assigned-Rejected-Closed14软件缺陷处理流程及状态变化15缺陷的处理流程-示例116缺陷管理综合流程-示例217缺陷的基本要素缺陷的基本信息*缺陷ID（由系统自动生成，唯一的）*缺陷的标题测试的软件和硬件环境（特殊环境下可注明）*测试的软件版本（缺陷发现版本和修复版本，发现版本是指当前版本，修复版本一般由项目经理确认）*缺陷的类型（功能的、性能的、使用方面、安全的等等）*缺陷的严重程度（由测试人员确定）缺陷的处理优先级（一般由项目经理确定）*复现缺陷的操作步骤（操作步骤）复现缺陷的测试数据（特定数据需要注明，比如特定的账号）*缺陷的实际结果描述（错误描述）*期望的正确结果描述（期望结果）缺陷产生的原因分析（如果测试人员能判定原因就给出，不能判定就无需给出，以免误导开发人员）注释文字和截取的缺陷图像缺陷处理信息缺陷提交者（系统默认）缺陷处理者（1.项目经理指派，2.已知模块的缺陷可由测试人员直接分配给开发人员）缺陷解决方案（一般由开发者总结问题原因并给出修改方案）缺陷提交时间缺陷处理时间（一般情况下缺陷的提交时间和处理时间由缺陷管理工具自动生成）18缺陷的严重等级-按5类划分分类严重等级等级描述A致命性的(Critical)不能执行正常工作功能或重要功能，或者危及人身安全的，主要表现在：1.由于程序所引起的死机,非法退出2.死循环3.导致数据库发生死锁4.数据通讯错误5.严重的数值计算错误B严重的(Major)严重影响系统要求或基本功能实现的，主要表现在：1.功能不符2.数据流错误3.程序接口错误4.轻微的数值计算错误C一般的(Generic)一般性错误，比较容易修复的，主要表现在：1.界面错误(详细文档)2.打印内容、格式错误3.简单的输入限制未放在前台进行控制4.删除操作未给出提示19缺陷的严重等级-按5类划分分类严重等级等级描述D轻微的(Minor)比较轻微的错误，一般是使用方面的问题，主要表现在：1.辅助说明描述不清楚2.显示格式不规范3.长时间操作未给用户进度提示4.提示窗口文字未采用行业术语5.可输入区域和只读区域没有明显的区分标志6.系统处理未优化E建议性的(Suggestion)从测试人员角度提出的一些建议性的问题，不一定是缺陷20缺陷的严重等级-按4类划分分类严重等级等级描述A严重的系统崩溃、数据丢失、数据损坏B较严重的操作性错误、错误结果、遗漏功能C一般的小问题、错别字、UI布局、罕见故障D建议性的不影响使用的瑕疵或更好的实现备注：缺陷的严重等级大体分为这么几类，要么是5类，要么是4类，跟每个公司对缺陷的定义有关，面试时请注意按实际情况活学活用21缺陷的优先级缺陷的优先级描述1最高优先级需要停止进一步测试，立即修复的缺陷2次高优先级缺陷需要正常排队等待修复或列入软件发布清单，但需要在产品发布之前必须修复3中等优先级如果时间允许应该修复的缺陷4最低优先级缺陷可能被修复，也可能不被修复就直接发布备注：缺陷的优先等级大体分为，跟每个公司对缺陷的定义有关，面试时请注意按实际情况活学活用22缺陷的书写规范缺陷标题（Title）标题应该保持简短、准确，提供缺陷的本质信息，并便于读者搜索查寻良好的缺陷标题应该按照下列方式书写：尽量按缺陷发生的原因与结果的方式书写（“执行完A后，发生B，”或者“发生B，当A执行完后”）避免使用模糊不清的词语，例如“功能中断，功能不正确，行为不起作用，”等。应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用为了方便搜索和查询，请使用关键字为了便于他人理解，避免使术语、俚语或过分具体的测试细节举例：品红网站后台使用管理员账号登录失败23缺陷的书写规范复现步骤（ReproducibleSteps）复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。不友好的重现步骤：复现步骤包含了过多的多余步骤，而且句子结构混乱，可读性很差，难于理解复现步骤包含了过少的信息，丢失操作的必要步骤。由于提供的步骤不完整，开发人员经常需要种种猜测，努力尝试复现的步骤，浪费了大量时间。由于缺少关键步骤，这些缺陷通常被工程师以“不能复现”为由Rejected给测试人员测试人员没有对软件缺陷发生的条件和影响区域进行隔离，软件开发人员无法判断该缺陷影响的软件部分，不能进行彻底修正。24缺陷的书写规范正确的重现步骤（ReproducibleSteps）：准确无误的重现操作步骤，步骤不多余，无遗漏每一个步骤尽量只记录一个操作每一个步骤前使用数字对步骤编号尽量使用短语和短句，避免复杂句型和句式将常见步骤合并为较少步骤，例如：􀂗1.Createtextframe.􀂗2.Addtext.可以简单的合并成一步：1.Createanewtextframeandaddtext.只记录各个操作步骤是什么，不要包括每个操作步骤执行后的结果说明：重现步骤可参考测试用例中的步骤举例：Login_Bug_001:品红网站后台使用管理员账号登录失败操作步骤：1.进入品红网站后台管理界面2.输入正确的用户名和密码，点【登录】按钮25缺陷的书写规范实际结果（也就是错误描述）尽可能将缺陷分解成多个缺陷报告，并使用交叉引用说明彼此之间的联系。这些动作的结果通常比较相似但缺陷不同。首先进行更多的隔离测试，缩小产生缺陷的范围，查看是否产生多个缺陷在实际结果部分，仅列出缺陷的一到两个表现特征。使用注释（Notes）部分列出缺陷的其它问题；在缺陷的第一个表现特征后，将随后的步骤和缺陷表现特征移到注释部分。重要的信息几乎总是包含在第一个断言或错误里，其它错误都是第一个错误的变种。举例：001:品红网站后台使用管理员账号登录失败操作步骤：1.进入品红网站后台管理界面2.输入正确的用户名和密码，点【登录】按钮错误描述：1.登录失败，系统给出错误提示26缺陷的书写规范自我检查和提问•缺陷报告已经向读者包含完整、准确、必要的信息了吗？•一个缺陷报告中是否之报告了一种缺陷？•读者是否能容易的搜索该缺陷？•步骤是否可以完全复现而且表达清楚吗？•是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？•缺陷的标题是按照原因与结果的方式书写的吗？•实际结果和期望结果是否描述不够清楚而容易引起歧义吗？27缺陷的书写规范避免常见的错误用“User（用户）”代替使用者，避免使用“I（我）”、“You（你）”等人称代词客观地反映出缺陷的现象和完整信息，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽，避免使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等对实际结果的描述要清晰，避免使用含义模糊的词汇，诸如“Seems（似乎）”、“Appearstobe（看上去可能）”等等客观地描述缺陷的信息，避免包含自认为比较幽默的内容，因为不同读者的文化和观念不同，很多幽默内容在别人看来，往往难以准确理解，甚至可能引起误解对于无法确定的缺陷，应该先将问题记录下来，然后通过电子邮件或口头交流，确认是缺陷后再报告到缺陷库中，避免查询和统计结果的不准确性对于偶发性的缺陷，先将缺陷记录在缺陷库中，视缺陷发生频率进行处理，频率高的必须要求修改，频率低的可先将缺陷挂起，待日后修复