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

上传人:无*** 文档编号:241672735 上传时间:2024-07-14 格式:PPTX 页数:43 大小:647.34KB
返回 下载 相关 举报
第十二章QC的使用和缺陷管理课件_第1页
第1页 / 共43页
第十二章QC的使用和缺陷管理课件_第2页
第2页 / 共43页
第十二章QC的使用和缺陷管理课件_第3页
第3页 / 共43页
点击查看更多>>
资源描述
第十二章第十二章QC的使用和缺陷管理的使用和缺陷管理ITANY.22本课程的主要内容QCQC的使用(重点)的使用(重点)缺陷管理(重点)缺陷管理(重点)缺陷的管理流程缺陷的管理流程缺陷的基本要素缺陷的基本要素缺陷的缺陷的书写写规范范缺陷的度量与分析缺陷的度量与分析编写写测试报告(重点)告(重点).33本章目标l会熟会熟练使用使用QCQC进行行测试过程管理程管理 (重点)(重点)l能能够准确的表达并准确的表达并记录缺陷缺陷 (重点)(重点)l能能够编写写测试报告告 (重点)(重点).44第一部分QCQC的使用的使用缺陷管理缺陷管理缺陷的管理流程缺陷的管理流程缺陷的基本要素缺陷的基本要素缺陷的缺陷的书写写规范范缺陷的度量与分析缺陷的度量与分析编写写测试报告告.55QC的使用下下载地址地址 http:/ 密密码:wuye123 2.QC10.0 2.QC10.0:运行在windows 2003 sp2环境上,windows xp 不能安装.66QC安装注意事项1.安装前需要先安装Oracle数据库2.安装时需要注意数据库的配置.77QC的使用介绍1.QC是一款集测试版本控制、测试需求、测试用例、测试执行、测试度量为一体的测试管理工具。2.针对每一个模块的使用进行介绍,重点在于使用QC进行测试用例设计和测试执行.88第二部分QC的使用的使用缺陷管理缺陷管理缺陷的管理流程缺陷的管理流程缺陷的基本要素缺陷的基本要素缺陷的缺陷的书写写规范范缺陷的度量与分析缺陷的度量与分析编写写测试报告告.99软件失败的术语缺点(缺点(defectdefect)偏差(偏差(variancevariance)故障(故障(faultfault)失失败(failurefailure)问题(problemproblem)矛盾(矛盾(inconsistencyinconsistency)错误(errorerror)特殊(特殊(featurefeature)事件(事件(incidentincident)缺陷(缺陷(bugbug)异常(异常(anomalyanomaly)故障、失故障、失败、缺点:、缺点:非常严重,甚至致命的情况异常、事件、偏差:异常、事件、偏差:不是很尖锐,主要指未按预料运行,而不是说完全失败问题、错误、缺陷:、缺陷:最常用的术语.1010缺陷管理工具开源免开源免费的的BugZilla、Mantis、JIRA、BugFree商商业的的QC、IBM Rational ClearQuest、Compuware TrackRecord.1111软件缺陷生命周期软件缺陷的生命周件缺陷的生命周期:期:从发现缺陷到解决缺陷并关闭的整个过程.1212软件缺陷在整个生命周期中的状态关于关于软件缺陷在整个生命周期中的状件缺陷在整个生命周期中的状态,跟每个公司的开,跟每个公司的开发流程有关,流程有关,每个公司都有不同的定每个公司都有不同的定义,下面是一个大致的流程,可在此基,下面是一个大致的流程,可在此基础上上进行伸行伸缩:1.1.测试人人员发现并并记录缺陷(缺陷(new/open)2.2.测试人人员将缺陷提交将缺陷提交给项目目经理,理,项目目经理会理会对该缺陷缺陷进行确行确认2.12.1 如果确认为是是一个缺陷,那么项目经理会将该缺陷进行分配(assignedassigned)2.22.2 如果项目经理认为这不是不是一个缺陷,那么会将该缺陷打回给测试人员(rejecctedrejeccted),或者直接关闭(closedclosed)3.3.开开发人人员在接到在接到这个缺陷后,也需要先个缺陷后,也需要先对缺陷缺陷进行判断行判断3.13.1 如果是缺陷,就对缺陷进行处理(In Progress),处理完成(resolved/fixed)后将缺陷重新返回给测试人员3.23.2 如果不是缺陷,可直接返回给测试人员(rejected)4.4.测试人人员接收到开接收到开发人人员返回的缺陷后,需要做如下返回的缺陷后,需要做如下处理理4.14.1 对于开发人员修复的缺陷(resolved/fixed)进行回归测试,如果测试通过则置为(Testd/Closed),测试不通过可以重开(Reopen),重新将缺陷打回给开发人员4.14.1 对于开发人员拒绝的缺陷(Rejected),一般是存在争议的缺陷,经过项目组讨论或评定后,确认不是缺陷可以直接对其进行关闭(Closed),如果确认是缺陷,需要对其进行重开(Reopen,如果该缺陷可暂缓修复或修复成本较高,需另行找时间修复,可将缺陷挂起(Suspened).1313软件缺陷在整个生命周期中的状态主要状主要状态有:有:Open/New、Assigned、In Progress、Resloved、Rejected、Reopen、Tested/ClosedBug状状态走向:走向:Open-ClosedOpen-Rejected-ClosedOpen-Assigned-In Progress-Resolved-ClosedOpen-Assigned-In Progress-Resolved-Reopen ClosedOpen-Assigned-Rejected-Closed.1414软件缺陷处理流程及状态变化.1515缺陷的处理流程-示例1.1616缺陷管理综合流程-示例2.1717缺陷的基本要素缺陷的基本信息缺陷的基本信息*缺陷ID(由系统自动生成,唯一的)*缺陷的标题测试的软件和硬件环境(特殊环境下可注明)*测试的软件版本(缺陷发现版本和修复版本,发现版本是指当前版本,修复版本一般由项目经理确认)*缺陷的类型(功能的、性能的、使用方面、安全的等等)*缺陷的严重程度(由测试人员确定)缺陷的处理优先级(一般由项目经理确定)*复现缺陷的操作步骤(操作步骤)复现缺陷的测试数据(特定数据需要注明,比如特定的账号)*缺陷的实际结果描述(错误描述)*期望的正确结果描述(期望结果)缺陷产生的原因分析(如果测试人员能判定原因就给出,不能判定就无需给出,以免误导开发人员)注释文字和截取的缺陷图像缺陷缺陷处理信息理信息缺陷提交者(系统默认)缺陷处理者(1.项目经理指派,2.已知模块的缺陷可由测试人员直接分配给开发人员)缺陷解决方案(一般由开发者总结问题原因并给出修改方案)缺陷提交时间缺陷处理时间(一般情况下缺陷的提交时间和处理时间由缺陷管理工具自动生成).1818缺陷的严重等级-按5类划分分分类严重等重等级等等级描述描述A致命性的(Critical)不能不能执行正常工作功能或重要功能,或者危及人身安全的,主行正常工作功能或重要功能,或者危及人身安全的,主要表要表现在:在:1.由于程序所引起的死机,非法退出2.死循环3.导致数据库发生死锁4.数据通讯错误5.严重的数值计算错误B严重的(Major)严重影响系重影响系统要求或基本功能要求或基本功能实现的,主要表的,主要表现在:在:1.功能不符2.数据流错误3.程序接口错误4.轻微的数值计算错误C一般的(Generic)一般性一般性错误,比,比较容易修复的,主要表容易修复的,主要表现在:在:1.界面错误(详细文档)2.打印内容、格式错误3.简单的输入限制未放在前台进行控制4.删除操作未给出提示.1919缺陷的严重等级-按5类划分分分类严重等重等级等等级描述描述D轻微的(Minor)比比较轻微的微的错误,一般是使用方面的,一般是使用方面的问题,主要表,主要表现在:在:1.辅助说明描述不清楚2.显示格式不规范3.长时间操作未给用户进度提示4.提示窗口文字未采用行业术语5.可输入区域和只读区域没有明显的区分标志6.系统处理未优化E建议性的(Suggestion)从从测试人人员角度提出的一些建角度提出的一些建议性的性的问题,不一定是缺陷,不一定是缺陷.2020缺陷的严重等级-按4类划分分分类严重等重等级等等级描述描述A严重的重的系统崩溃、数据丢失、数据损坏B较严重的重的操作性错误、错误结果、遗漏功能C一般的一般的小问题、错别字、UI布局、罕见故障D建建议性的性的不影响使用的瑕疵或更好的实现备注:注:缺陷的缺陷的严重等重等级大体分大体分为这么几么几类,要么是,要么是5类,要么是,要么是4类,跟每个公,跟每个公司司对缺陷的定缺陷的定义有关,面有关,面试时请注意按注意按实际情况活学活用情况活学活用.2121缺陷的优先级缺陷的缺陷的优先先级描述描述1最高优先级需要停止进一步测试,立即修复的缺陷2次高优先级缺陷需要正常排队等待修复或列入软件发布清单,但需要在产品发布之前必须修复3中等优先级如果时间允许应该修复的缺陷4最低优先级缺陷可能被修复,也可能不被修复就直接发布备注:注:缺陷的缺陷的优先等先等级大体分大体分为,跟每个公司,跟每个公司对缺陷的定缺陷的定义有关,面有关,面试时请注注意按意按实际情况活学活用情况活学活用.2222缺陷的书写规范缺陷缺陷标题(Title)标题应该保持简短短、准确准确,提供缺陷的本提供缺陷的本质信息信息,并便于便于读者搜者搜索索查寻 良好的缺陷良好的缺陷标题应该按照下列方式按照下列方式书写:写:尽量按缺陷发生的原因与结果的方式书写(“执行完A后,发生B,”或者“发生B,当A执行完后”)避免使用模糊不清的词语,例如“功能中断,功能不正确,行为不起作用,”等。应该使用具体文字说明功能如何中断,如何不正确,或如何不起作用为了方便搜索和查询,请使用关键字为了便于他人理解,避免使术语、俚语或过分具体的测试细节举例:例:品红网站后台使用管理员账号登录失败.2323缺陷的书写规范复复现步步骤(Reproducible Steps)复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求,复现步骤的信息必须是完整的完整的、准确的准确的、简明的明的、可复可复现的的。不友好的重不友好的重现步步骤:复现步骤包含了过多的多余步骤,而且句子结构混乱,可读性很差,难于理解复现步骤包含了过少的信息,丢失操作的必要步骤。由于提供的步骤不完整,开发人员经常需要种种猜测,努力尝试复现的步骤,浪费了大量时间。由于缺少关键步骤,这些缺陷通常被工程师以“不能复现”为由RejectedRejected给测试人员 测试人员没有对软件缺陷发生的条件和影响区域进行隔离,软件开发人员无法判断该缺陷影响的软件部分,不能进行彻底修正。.2424缺陷的书写规范正确的重正确的重现步步骤(Reproducible Steps):准确无误的重现操作步骤,步骤不多余,无遗漏 每一个步骤尽量只记录一个操作 每一个步骤前使用数字对步骤编号 尽量使用短语和短句,避免复杂句型和句式 将常见步骤合并为较少步骤,例如:1.Create text frame.2.Add text.可以简单的合并成一步:1.Create a new text frame and add text.只记录各个操作步骤是什么,不要包括每个操作步骤执行后的结果说明:明:重现步骤可参考测试用例中的步骤举例:例:Login_Bug_001:品红网站后台使用管理员账号登录失败操作步操作步骤:1.进入品红网站后台管理界面2.输入正确的用户名和密码,点【登录】按钮.2525缺陷的书写规范实际结果果 (也就是(也就是错误描述描述)尽可能将缺陷分解成多个缺陷报告,并使用交叉引用说明彼此之间的联系。这些动作的结果通常比较相似但缺陷不同。首先进行更多的隔离测试,缩小产生缺陷的范围,查看是否产生多个缺陷在实际结果部分,仅列出缺陷的一到两个表现特征。使用注释(Notes)部分列出缺陷的其它问题;在缺陷的第一个表现特征后,将随后的步骤和缺陷表现特征移到注释部分。重要的信息几乎总是包含在第一个断言或错误里,其它错误都是第一个错误的变种。举例:例:001:品红网站后台使用管理员账号登录失败操作步操作步骤:1.进入品红网站后台管理界面2.输入正确的用户名和密码,点【登录】按钮错误描述:描述:1.登录失败,系统给出错误提示.2626缺陷的书写规范自我自我检查和提和提问 缺陷报告已经向读者包含完整、准确、必要的信息了吗?一个缺陷报告中是否之报告了一种缺陷?读者是否能容易的搜索该缺陷?步骤是否可以完全复现而且表达清楚吗?是否包含了复现该缺陷需要的环境变量或测试所用的数据文件?缺陷的标题是按照原因与结果的方式书写的吗?实际结果和期望结果是否描述不够清楚而容易引起歧义吗?.2727缺陷的书写规范避免常避免常见的的错误用“User(用户)”代替使用者,避免使用“I(我)”、“You(你)”等人称代词客观地反映出缺陷的现象和完整信息,不要对软件的质量优劣做任何主观性强烈的批评、嘲讽,避免使用情绪化的语言和强调符号,例如黑体、全部字母大写、斜体、感叹号、问号等对实际结果的描述要清晰,避免使用含义模糊的词汇,诸如“Seems(似乎)”、“Appears to be(看上去可能)”等等客观地描述缺陷的信息,避免包含自认为比较幽默的内容,因为不同读者的文化和观念不同,很多幽默内容在别人看来,往往难以准确理解,甚至可能引起误解对于无法确定的缺陷,应该先将问题记录下来,然后通过电子邮件或口头交流,确认是缺陷后再报告到缺陷库中,避免查询和统计结果的不准确性对于偶发性的缺陷,先将缺陷记录在缺陷库中,视缺陷发生频率进行处理,频率高的必须要求修改,频率低的可先将缺陷挂起,待日后修复,避免不重现就直接提交缺陷.2828完整缺陷记录示例001001(Bug ID,系统自动生成)品品红网站后台使用管理网站后台使用管理员账号登号登录失失败(BUG标题)缺陷缺陷发现版本:版本:ph_20100801_01(当前版本)缺陷修复版本:缺陷修复版本:默认(由项目经理统一分配)测试环境:境:(需要特殊说明时给出)严重等重等级:严重(视缺陷具体情况给出)优先先级:默认(由项目经理统一分配)操作步操作步骤:1.进入品红网站后台管理界面2.输入正确的用户名和密码,点【登录】按钮测试数据:数据:用户名:bass 密 码:bass错误描述描述:(实际结果)1.管理员账号登录失败,系统给出错误提示(主要缺陷)2.错误提示信息中“登陆”使用错误(次要缺陷)期望期望结果:果:1.管理员账号能够成功登录品红网站后台系统2.提示信息中的“登陆”应改为“登录”分配分配给:项目经理或开发人员姓名(新建的BUG默认给项目经理)测试人人员:测试人员姓名缺陷状缺陷状态:new(默认新建缺陷时的状态).2929缺陷统计分析按错误类型按严重等级按优先级别按问题状态按问题类型与严重程度组合按发现人员与严重程度组合.3030缺陷统计分析按模块分布.3131缺陷统计分析按对象分布.3232缺陷统计分析按缺陷类型分布.3333缺陷密度分析缺陷密度缺陷密度软件缺陷件缺陷分为通过评审的或测试等方法发现的已知缺陷已知缺陷和尚未发现的潜在缺陷潜在缺陷两种缺陷密度=已知缺陷数量/产品规模.3434缺陷注入-发现矩阵缺陷移除率缺陷移除率 =(本(本阶段段发现的缺陷数的缺陷数/本本阶段注段注入的缺陷入的缺陷总数)数)*100%100%缺陷泄漏率缺陷泄漏率=(下游(下游发现的本的本阶段的缺陷数段的缺陷数/本本阶段注入的缺陷段注入的缺陷总数)数)*100%100%计算缺陷移除率的意算缺陷移除率的意义可以有效的衡量测试用例是否充分测试效率是否充足分析出软件开发各个环节的质量,找到最需要改进的环节.3535缺陷注入-发现矩阵 缺陷注入缺陷注入阶段段缺陷缺陷发现阶段段需求需求设计编码注入注入总数数需求需求阶段段5 5设计阶段段1365 78编码、单元元测试阶段段4101832系系统测试阶段段4397104验收收测试阶段段001919发现总计2678134238阶段缺陷移除率段缺陷移除率19.23%83.33%13.43%矩矩阵的每行表示的每行表示该阶段或活段或活动发现的各的各阶段段产生的缺陷数生的缺陷数矩矩阵的每列表示的每列表示该阶段或活段或活动注入的缺陷泄漏到后注入的缺陷泄漏到后续各各环节的缺陷数。的缺陷数。.3636缺陷注入-发现矩阵 缺陷注入缺陷注入阶段段缺陷缺陷发现阶段段需求需求设计编码注入注入总数数需求需求阶段段5 5设计阶段段1365 78编码、单元元测试阶段段4101832系系统测试阶段段4397104验收收测试阶段段001919发现总计2678134238阶段缺陷移除率段缺陷移除率19.23%83.33%13.43%矩矩阵的每行表示的每行表示该阶段或活段或活动发现的各的各阶段段产生的缺陷数生的缺陷数矩矩阵的每列表示的每列表示该阶段或活段或活动注入的缺陷泄漏到后注入的缺陷泄漏到后续各各环节的缺陷数。的缺陷数。.3737缺陷收敛趋势分析.3838第三部分QC的使用的使用缺陷管理缺陷管理缺陷的管理流程缺陷的管理流程缺陷的基本要素缺陷的基本要素缺陷的缺陷的书写写规范范缺陷的度量与分析缺陷的度量与分析编写写测试报告告.3939编写测试报告引言引言编写目的读者对象术语与缩写解释参考资料测试概要概要测试依据背景说明和时间安排测试步骤测试数据准备测试人员测试范范围已测试的范围未测试的范围测试环境要求(必要时可画出网络拓扑图).4040编写测试报告测试类型型测试方法和途径功能实现界面测试兼容性测试性能测试测试工具测试评估估系统当前状态评估退出系统测试状态分析测试工作量统计系系统缺陷分析缺陷分析问题类型比例图表每周BUG增长率每周BUG解决率各模块缺陷率问题状态比例图表测试结论功能覆盖情况风险分析总体结论.4141Q&A1.说说你所理解的QC?2.如何清晰的描述一个软件缺陷?软件缺陷包含哪些要素?3.软件缺陷的严重等级有哪几级?优先级怎么划分?两者之间什么关系?4.软件缺陷生命周期中缺陷的状态有哪些?5.请根据你的理解画出软件的缺陷的处理流程图?6.测试报告的要点有哪些?.4242下节预告lSVN与配置管理与配置管理lSVN的基本的基本概念概念lSVN的安装配置与基本的安装配置与基本使用使用l分支分支与合并与合并.4343谢谢谢谢结束.
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 管理文书 > 施工组织


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!