QC的使用和缺陷管理.pptx

第十二章 QC的使用和缺陷管理,ITANY,本课程的主要内容,QC的使用（重点） 缺陷管理（重点） 缺陷的管理流程 缺陷的基本要素 缺陷的书写规范 缺陷的度量与分析 编写测试报告（重点）,本章目标,会熟练使用QC进行测试过程管理 （重点） 能够准确的表达并记录缺陷 （重点） 能够编写测试报告 （重点）,第一部分,QC的使用 缺陷管理 缺陷的管理流程 缺陷的基本要素 缺陷的书写规范 缺陷的度量与分析 编写测试报告,QC的使用,下载地址 /redirect.html?url=https%3A//cda/hpdc/navigation.do%3Faction%3DdownloadBinStart%26zn%3Dbto%26cp%3D54_4012_100_%26caid%3D40593%26jumpid%3Dhpr_R1002_USEN&qt=quicktest&type=HPR&pos=2&key=quicktest&alias=Software+Testing 备注： 1. 用户名:testing_ 密码:wuye123 2. QC10.0：运行在windows 2003 sp2环境上，windows xp 不能安装,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、 IBM Rational ClearQuest、Compuware TrackRecord,软件缺陷生命周期,软件缺陷的生命周期： 从发现缺陷到解决缺陷并关闭的整个过程,软件缺陷在整个生命周期中的状态,关于软件缺陷在整个生命周期中的状态，跟每个公司的开发流程有关，每个公司都有不同的定义，下面是一个大致的流程，可在此基础上进行伸缩： 1. 测试人员发现并记录缺陷（new / open） 2. 测试人员将缺陷提交给项目经理，项目经理会对该缺陷进行确认 2.1 如果确认为是一个缺陷，那么项目经理会将该缺陷进行分配（assigned） 2.2 如果项目经理认为这不是一个缺陷，那么会将该缺陷打回给测试人员（rejeccted），或者直接关闭（closed） 3. 开发人员在接到这个缺陷后，也需要先对缺陷进行判断 3.1 如果是缺陷，就对缺陷进行处理（In Progress），处理完成（resolved / fixed）后将缺陷重新返回给测试人员 3.2 如果不是缺陷，可直接返回给测试人员（rejected） 4. 测试人员接收到开发人员返回的缺陷后，需要做如下处理 4.1 对于开发人员修复的缺陷（resolved / fixed）进行回归测试，如果测试通过则置为（Testd / Closed），测试不通过可以重开（Reopen），重新将缺陷打回给开发人员 4.1 对于开发人员拒绝的缺陷（Rejected），一般是存在争议的缺陷，经过项目组讨论或评定后，确认不是缺陷可以直接对其进行关闭（Closed），如果确认是缺陷，需要对其进行重开（Reopen,如果该缺陷可暂缓修复或修复成本较高，需另行找时间修复，可将缺陷挂起（Suspened）,软件缺陷在整个生命周期中的状态,主要状态有： Open/New、Assigned、In Progress、Resloved、Rejected、Reopen、Tested/Closed Bug状态走向： Open - Closed Open - Rejected - Closed Open - Assigned - In Progress - Resolved - Closed Open - Assigned - In Progress - Resolved - Reopen Closed Open - Assigned - Rejected - Closed,软件缺陷处理流程及状态变化,缺陷的处理流程-示例1,缺陷管理综合流程-示例2,缺陷的基本要素,缺陷的基本信息 *缺陷ID（由系统自动生成，唯一的） *缺陷的标题 测试的软件和硬件环境（特殊环境下可注明） *测试的软件版本（缺陷发现版本和修复版本，发现版本是指当前版本，修复版本一般由项目经理确认） *缺陷的类型（功能的、性能的、使用方面、安全的等等） *缺陷的严重程度（由测试人员确定） 缺陷的处理优先级（一般由项目经理确定） *复现缺陷的操作步骤（操作步骤） 复现缺陷的测试数据 （特定数据需要注明，比如特定的账号） *缺陷的实际结果描述（错误描述） *期望的正确结果描述（期望结果） 缺陷产生的原因分析 （如果测试人员能判定原因就给出，不能判定就无需给出，以免误导开发人员） 注释文字和截取的缺陷图像 缺陷处理信息 缺陷提交者（系统默认） 缺陷处理者（1.项目经理指派，2.已知模块的缺陷可由测试人员直接分配给开发人员） 缺陷解决方案（一般由开发者总结问题原因并给出修改方案） 缺陷提交时间 缺陷处理时间（一般情况下缺陷的提交时间和处理时间由缺陷管理工具自动生成）,缺陷的严重等级-按5类划分,缺陷的严重等级-按5类划分,缺陷的严重等级-按4类划分,备注： 缺陷的严重等级大体分为这么几类，要么是5类，要么是4类，跟每个公 司对缺陷的定义有关，面试时请注意按实际情况活学活用,缺陷的优先级,备注： 缺陷的优先等级大体分为，跟每个公司对缺陷的定义有关，面试时请注 意按实际情况活学活用,缺陷的书写规范,缺陷标题（Title） 标题应该保持简短、准确，提供缺陷的本质信息，并便于读者搜索查寻 良好的缺陷标题应该按照下列方式书写： 尽量按缺陷发生的原因与结果的方式书写（“执行完A后，发生B，”或者“发生B， 当A执行完后”） 避免使用模糊不清的词语，例如“功能中断，功能不正确，行为不起作用，”等。应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用 为了方便搜索和查询，请使用关键字 为了便于他人理解，避免使术语、俚语或过分具体的测试细节 举例：品红网站后台使用管理员账号登录失败,缺陷的书写规范,复现步骤（Reproducible Steps） 复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。 不友好的重现步骤： 复现步骤包含了过多的多余步骤，而且句子结构混乱，可读性很差，难于理解 复现步骤包含了过少的信息，丢失操作的必要步骤。由于提供的步骤不完整，开发人员经常需要种种猜测，努力尝试复现的步骤，浪费了大量时间。由于缺少关键步骤，这些缺陷通常被工程师以“不能复现”为由Rejected给测试人员 测试人员没有对软件缺陷发生的条件和影响区域进行隔离，软件开发人员无法判断该缺陷影响的软件部分，不能进行彻底修正。,缺陷的书写规范,正确的重现步骤（Reproducible Steps） ： 准确无误的重现操作步骤，步骤不多余，无遗漏 每一个步骤尽量只记录一个操作 每一个步骤前使用数字对步骤编号 尽量使用短语和短句，避免复杂句型和句式 将常见步骤合并为较少步骤，例如： 1. Create text frame. 2. Add text. 可以简单的合并成一步： 1. Create a new text frame and add text. 只记录各个操作步骤是什么，不要包括每个操作步骤执行后的结果 说明：重现步骤可参考测试用例中的步骤 举例： Login_Bug_001: 品红网站后台使用管理员账号登录失败 操作步骤： 进入品红网站后台管理界面 输入正确的用户名和密码，点【登录】按钮,缺陷的书写规范,实际结果 （也就是错误描述） 尽可能将缺陷分解成多个缺陷报告，并使用交叉引用说明彼此之间的联系。这些动作的结果通常比较相似但缺陷不同。首先进行更多的隔离测试，缩小产生缺陷的范围，查看是否产生多个缺陷 在实际结果部分，仅列出缺陷的一到两个表现特征。使用注释（Notes）部分列出缺陷的其它问题； 在缺陷的第一个表现特征后，将随后的步骤和缺陷表现特征移到注释部分。重要的信息几乎总是包含在第一个断言或错误里，其它错误都是第一个错误的变种。 举例： 001: 品红网站后台使用管理员账号登录失败 操作步骤： 进入品红网站后台管理界面 输入正确的用户名和密码，点【登录】按钮 错误描述： 1. 登录失败，系统给出错误提示,缺陷的书写规范,自我检查和提问 缺陷报告已经向读者包含完整、准确、必要的信息了吗？ 一个缺陷报告中是否之报告了一种缺陷？ 读者是否能容易的搜索该缺陷？ 步骤是否可以完全复现而且表达清楚吗？ 是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？ 缺陷的标题是按照原因与结果的方式书写的吗？ 实际结果和期望结果是否描述不够清楚而容易引起歧义吗？,缺陷的书写规范,避免常见的错误 用“User（用户）”代替使用者，避免使用“I（我）”、“You（你）”等人称代词 客观地反映出缺陷的现象和完整信息，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽，避免使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等 对实际结果的描述要清晰，避免使用含义模糊的词汇，诸如“Seems（似乎）”、“Appears to be（看上去可能）” 等等 客观地描述缺陷的信息，避免包含自认为比较幽默的内容，因为不同读者的文化和观念不同，很多幽默内容在别人看来，往往难以准确理解，甚至可能引起误解 对于无法确定的缺陷，应该先将问题记录下来，然后通过电子邮件或口头交流，确认是缺陷后再报告到缺陷库中，避免查询和统计结果的不准确性 对于偶发性的缺陷，先将缺陷记录在缺陷库中，视缺陷发生频率进行处理，频率高的必须要求修改，频率低的可先将缺陷挂起，待日后修复，避免不重现就直接提交缺陷,完整缺陷记录示例,001(Bug ID，系统自动生成) 品红网站后台使用管理员账号登录失败 （BUG标题） 缺陷发现版本：ph_20100801_01 (当前版本） 缺陷修复版本：默认 （由项目经理统一分配） 测试环境： （需要特殊说明时给出） 严重等级：严重 （视缺陷具体情况给出） 优先级：默认 （由项目经理统一分配） 操作步骤： 1.进入品红网站后台管理界面 2.输入正确的用户名和密码，点【登录】按钮 测试数据： 用户名：bass 密 码：bass 错误描述： （实际结果） 1.管理员账号登录失败，系统给出错误提示 （主要缺陷） 2. 错误提示信息中“登陆”使用错误 （次要缺陷） 期望结果： 1. 管理员账号能够成功登录品红网站后台系统 2. 提示信息中的“登陆”应改为“登录” 分配给：项目经理或开发人员姓名 （新建的BUG默认给项目经理） 测试人员：测试人员姓名 缺陷状态：new （默认新建缺陷时的状态）,缺陷统计分析,按错误类型 按严重等级 按优先级别 按问题状态 按问题类型与严重程度组合 按发现人员与严重程度组合,缺陷统计分析,按模块分布,缺陷统计分析,按对象分布,缺陷统计分析,按缺陷类型分布,缺陷密度分析,缺陷密度 软件缺陷分为通过评审的或测试等方法发现的已知缺陷和尚未发现的潜在缺陷两种 缺陷密度=已知缺陷数量/产品规模,缺陷注入-发现矩阵,缺陷移除率 = （本阶段发现的缺陷数/本阶段注入的缺陷总数）*100% 缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数） * 100% 计算缺陷移除率的意义 可以有效的衡量测试用例是否充分 测试效率是否充足 分析出软件开发各个环节的质量，找到最需要改进的环节,缺陷注入-发现矩阵,矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数 矩阵的每列表示该阶段或活动注入的缺陷泄漏到后续各环节的缺陷数。,缺陷注入-发现矩阵,矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数 矩阵的每列表示该阶段或活动注入的缺陷泄漏到后续各环节的缺陷数。,缺陷收敛趋势分析,第三部分,QC的使用 缺陷管理 缺陷的管理流程 缺陷的基本要素 缺陷的书写规范 缺陷的度量与分析 编写测试报告,编写测试报告,引言 编写目的 读者对象 术语与缩写解释 参考资料 测试概要 测试依据 背景说明和时间安排 测试步骤 测试数据准备 测试人员 测试范围 已测试的范围 未测试的范围 测试环境要求（必要时可画出网络拓扑图）,编写测试报告,测试类型 测试方法和途径 功能实现 界面测试 兼容性测试