《(ppt)-《软件缺陷跟踪与管理》软件质量保障课件(45页)-品质管理》由会员分享，可在线阅读，更多相关《(ppt)-《软件缺陷跟踪与管理》软件质量保障课件(45页)-品质管理（47页珍藏版）》请在金锄头文库上搜索。
1、软件缺陷跟踪与管理,软件缺陷分类 软件缺陷生命周期 软件缺陷报告 软件缺陷管理工具介绍,软件缺陷分类标准 缺陷属性,缺陷类型,缺陷严重等级,缺陷优先级,缺陷状态,缺陷起源,缺陷来源,缺陷根源,缺陷分类适用范围,软件缺陷的生命周期,发现软件缺陷,测试员找到并登记软件缺陷移交给程序员,程序员修复软件缺陷移交给测试员,测试员确认软件缺陷被修复并关闭,打开,解决,关闭,软件缺陷的生命周期（续）,发现缺陷,打开,打开,不修复,打开,打开,修复,修复关闭,测试员发现并登记软件缺陷,软件缺陷移交到程序员,程序员认为软件缺陷微不足道,软件缺陷移交到项目管理员,项目管理员认为软件缺陷不重要,软件缺陷移交到测试员
2、,软件缺陷移交到项目管理员,测试员不同意，找出通用失败案例,项目管理员现在同意软件缺陷需要修复,软件缺陷移交到程序员,程序员修复软件缺陷,软件缺陷移交到测试员,测试员确认软件缺陷得以修复,测试员关闭软件缺陷,软件缺陷的生命周期（续）,发现软件缺陷,打开,解决,关闭,审查,推迟,缺陷报告,报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误，从而有利于分析错误产生的原因，定位错误，然后修正之。因此，报告软件测试错误的基本要求是准确、简洁、完整、规范。,报告软件缺陷的原则,尽快报告软件缺陷 尽可能提交有说服力的缺陷 有效描述软件缺陷：短小、单一、明显和通用、再现 根据缺陷或错误类型，选
3、择图象捕捉的方式 在报告软件缺陷时不作评价 补充完善软件缺陷报告,如何更好的报告缺陷（1）,只有当你确信你已经发现一个bug的时候开始起草bug report，不要在测试结束或每天结束之后。那样，你可能会遗忘掉一些东西。更糟的情况是，我们可能会忘掉那个bug。 花一些时间去诊断你正在报告的缺陷。想想可能存在的原因。可能到最后你会发现更多的缺陷。在你的bug report中说说你的发现。开发人员将不仅仅对你使他们的工作变得轻松而感到高兴。,如何更好的报告缺陷（2）,不要在bug report中夸大缺陷。同样，也不要太轻描淡写了。 不管bug是多么的令人讨厌，别忘了是bug令人讨厌，而不是开发人员
4、。永远不要冒犯开发人员的努力。使用委婉些的说法。“混乱的UI”可以被温和些改为“不正确的UI”。这样开发人员的努力将会得到尊重。 保持简单诚实。你不是在写散文或文章，因此使用简单的语言 在编写bug report的时候记住你的目标读者。他们可能是开发人员，其他的测试人员，经理，或者在一些情况下，甚至是客户。Bug report应该可以被所有的人理解。,如何更好的报告缺陷（3）,“可重现的步骤”的流程应该是合乎逻辑的。 清楚的列出前提条件 写下平常的步骤。例如，如果一个步骤要求用户创建文件并且为它命名，不要要求用户命名为“Mihirs file”。最好命名为好像“Test File”一样的文件名
5、。 “可重现的步骤”应该详尽。例如，如果你想用户在Word里保存一个文件，你可以要求用户到File菜单并且点击Save子菜单项。你也可以只说“保存文件”。但是记住，并不是所有的人都知道如何在Word中保存文件。因此最好遵守第一种方法。 在一个干净的系统里测试你的“可重现的步骤”。你可能会发现有些步骤被遗漏或是毫无关系的。,如何更好的报告缺陷（4）,如果bug是和一组特定的测试数据相关，在你的bug report上附带上它。 如果你要在bug report里附带截屏，要确保那些图片不是太大的，使用jpg或gif的格式，而不是bmp格式 在截屏上写上注释以指出问题所在。这将帮助开发人员一眼就可以马
6、上定位问题。,如何更好的报告缺陷（5）,在设置bug report的严重程序之前应该全面的分析缺陷的影响程序。如果你认为你的bug具有很高的优先级应该被修复，在bug report中证明这点。应该在bug report的描述部分指出这个理由。 如果bug是来自上个内部小版本或版本回归的结果，那么发出警报。象这种bug的严重程度可能是低的，但是优先级别应该是高。,如何更好的报告缺陷（6）,在bug report里附上日志或日志的摘录片断。这将帮助开发人员轻松地分析且调试系统。 如果你在不同的地方遇到相似的问题，且要求同一种修复方法,但是在不同的地方，那么就要为每一个问题书写单独的bug repo
7、rt。每个bug report对应一个修复。,缺陷报告中的屏幕截图处理（1）,截取缺陷的图像可以使用Windows操作系统的快捷键，但是更多的是使用屏幕捕捉工具（Capturing Tools）。虽然截取并附上缺陷图像不太复杂，但是关于截图的类型、工具、编辑、存储格式、命名规则，有不少值得注意的事项，为了准确、有效地截取和编辑缺陷图像，需要测试工程师遵守相同的处理规则。,缺陷报告中的屏幕截图处理（2）,截取缺陷的图像，通常分为截取全屏幕、当前活动窗口、局部图像三种形式。实际测试过程中，根据下列两条原则选择合适的类型： *可以最大程度地表现缺陷的特征。 *尽可能减小图像的大小，以便于传输和查看。
8、 最常见的是截取当前活动窗口，例如包含缺陷的对话框。截取全屏幕用的较少，而且消耗很多的文件存储空间。,缺陷报告中的屏幕截图处理（3）,如果截图运行在Windows操作系统下的软件缺陷，可以使用Windows操作系统自带的快捷键，但是最经常使用的是利用各种截图工具直接截取。 截图工具有很多种，截图静态图像最常使用的是HyperSnap，它的优点是支持各种截图类型，而且截图后可以在HyperSnap中直接编辑。,缺陷报告中的屏幕截图处理（4）,缺陷截图的编辑内容包括： 圈出缺陷的典型表现特征。 添加描述性文字。 利用箭头将圈出的特征和描述性文字相连接。 仅圈选最能表示缺陷特征的区域。,缺陷报告中的
9、屏幕截图处理（5）,比较规范的截图命名形式如下：语言_操作系统_类型_编号.GIF 同一个测试项目中，截图的编辑方式、命名规则、存储类型等信息要保持一致。,为什么所有软件缺陷不一定都能修复,没有足够的时间 不算真正的软件缺陷 修复的风险太大 不值得修复 软件缺陷报告不够有效,分离和再现软件缺陷,分离和再现软件缺陷是非常技巧性的工作 不存在随机软件缺陷的事情 分离和再现软件缺陷的建议： 不要想当然地接受任何假设 查找时间依赖和竞争条件的问题 检查与压迫和负荷相关的边界条件 关注事件发生的次序 考虑资源依赖性和内存、网络、硬件共享的相互作用 不要忽视硬件,偶然性不可重现BUG的处理,尽力去查找出错
10、的原因，比如有什么特别的操作，或者一些操作环境等。 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。 无法重现的问题再次出现后，可以直接叫程序员来看看问题。 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。,Bug追踪过程中需要注意的问题（1）,尽量减少重现的步骤以达到用最少的步骤来重现问题；这对编程人员来说是很有帮助发现问题根源的。 最好由报bug的人验证bug是否可以关闭。任何人都可以修复bug，但只有那个发现bug的人才能够确信bug是否真正的已被修复。,Bug
11、追踪过程中需要注意的问题（2）,在将bug解决时要分清楚解决的方式。一般的bug系统允许你通过例如“fixed(已修复)”, “wont fix (不打算修复)”, “postponed(以后修复)”, “not repro(不可重现)”, “duplicate（重复）”或“by design(设计如此)”方式来解决bug。同时最好写上解决的方式或非正常解决问题（如以上几种类型）的原因。,Bug追踪过程中需要注意的问题（3）,仔细地追踪版本信息。你给测试人员的每一个build都应该有一个build ID编号 当你的bug报告以“not repro(不可重现)”打回给你时，先检查一个步骤是否有遗
12、漏或清晰，再去找编程人员。 如果知道bug出现模块的负责人员或将解决bug的开发人员，请在标题中明确的指出，例如你发现的bug是有关增加人员的，那么在标题中可以指出“增加人员时出现xx错误”。,Bug追踪过程中需要注意的问题（4）,如果用英文报bug，最好使用现在时或过去时，例如用“appears”而不是“will appear”。 不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的词语或符号。 一个好的bug report是不可以细分的, 换句话说就是这个bug是不会让他人觉得你还有些地方需要在测试一下，或许还有其他的问题。,软件缺陷跟踪,对于项目管理，缺陷
13、跟踪是很重要的一个环节，它除了可以对需求的完成度进行控制，同时也可以对软件本身的质量进行控制，以保证软件开发迭代的顺利进行。,手工软件缺陷报告和跟踪,表单可以容纳标识和描述软件缺陷的必要信息 书面表单的问题在于效率比较低,自动软件缺陷报告和跟踪,缺陷跟踪工具,原来的软件项目开发中的缺陷跟踪都是通过EXCEL表格的形式来完成的，这种表格虽然也可以进行项目管理和项目执行度的交互，但效率与实时性不高，同时也不好维护和统计，因此就出现了缺陷跟踪系统，通过软件技术来解决软件项目的管理问题。 目前缺陷跟踪系统还是比较多的，比较有名的像Mercury的TestDirector，Seapine的Test Tr
14、ack Pro，TechExcel的DevTrack，Atlassian的JIRA以及IBM的ClearQuest。,测试跟踪工具Bugzilla介绍（1）,Buzilla作为一个产品缺陷的记录及跟踪工具，它能够为你建立一个完善的Bug跟踪体系，包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。,测试跟踪工具Bugzilla介绍（2）,基于Web方式，安装简单、运行方便快捷、管理安全。 有利于缺陷的清楚传达。系统使用数据库进行管理，提供全面详尽的报告输入项，产生标准化的Bug报告。能根据各种条件组合进行Bug统计。当错误在它的生命周期中变化时，开发人员、测试人员
15、、及管理人员将及时获得动态的变化信息，允许你获取历史纪录。,测试跟踪工具Bugzilla介绍（3）,系统灵活，强大的可配置能力。Buzilla工具可以对软件产品设定不同的模块，并针对不同的模块设定开发人员和测试人员；这样可以实现提交报告时自动发给指定的责任人；并可设定不同的小组，权限也可划分。允许设定不同的严重程度和优先级，使注意力集中在优先级和严重程度高的错误上。 自动发送Email,通知相关人员，有效的帮助测试人员和开发人员进行沟通。,评价成效,软件缺陷跟踪数据库是评价项目状态和回答一些重要问题的基本方式。 频度是用于描述软件项目特定属性度量单位的术语。 使用软件缺陷数据库作为频度的来源是评测项目状态和软件测试员自身进展极其有效的方式。,严重性1 45%,严重性2 32%,严重性3 16%,严重性4 7%,界面26,整算14,浮算14,
