软件测试BUG描述及管理.ppt

BUG描述及管理 课程介绍 BUG的基本概念 什么是BUG? BUG所带来的危害 BUG是怎样产生的? BUG的类型 BUG的描述方法 BUG描述的基本规则 BUG描述的实用方法 BUG的管理流程 缺陷的严重程度和修改的优先级 BUG的生命周期及其状态 BUG的处理流程 BUG的基本概念 什么是BUG? 所谓BUG，就是软件不能满足用户的期望,也就是软件与用户期望值之间的差异。通常情况下我们认为至少满足下面3个规则之一才称发生了一样软件缺陷: 软件未能实现或错误的实现用户合理的需求。 软件未能实现用户需求未明确提及但应该实现的目标。 软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。 BUG的基本概念 BUG的危害 人们对软件Bug的心态是既敬畏又憎恨，主要是因为软件Bug经常潜藏于无形之中，而一旦发作轻则引起数据丢失，重则物毁人亡，造成生命和财产的巨大损失。 BUG的基本概念 BUG产生的原因 开发人员不太了解软件需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，因此产生了Bug。 软件系统越来越复杂，开发人员不太可能精通所有的技术，如果不能正确地使用技术，将产生Bug。 软件设计文档不清楚，文档本身存在Bug，导致使用者产生更多的Bug。 软件需求、设计说明书、程序经常发生变更，每次变更都可能产生新的Bug。 BUG的基本概念 BUG的类型 需求错误：需求描述错误。 架构缺陷：软件架构在合理性、稳定性、可靠性、效率、可扩展性等方面的不足。 设计错误：需求描述正确，但设计是错误的。 编码错误:数据结构内部算法错误. 文档错误：影响发布和维护，包括注释。如：文档记载系统在条件Y下做X，但是系统做Z（一个有效并且正确的操作）。 不符合标准：不符合各种标准的要求，如行业标准、编码标准、设计符号、UI设计标准、源代码规范、其他设计规范。 测试误解：测试人员描述的错误“不是一个问题”，报告产生的原因是因为测试人员对正确行为的误解。 其他实现错误：根本原因已知，但是与前面的分类不相符。 BUG的描述方法 BUG记录作为测试和开发之间沟通的桥梁,测试人员在报BUG的时候,有效的BUG描述,会更加容易帮助开发解决问题。 BUG的描述方法 有效的BUG=有效的沟通 通常情况下修改BUG并不难，困难在于寻找和定位BUG产生的位置和原因。如果开发人员能够根据BUG描述快速的将BUG重现，我们认为这样的描述是有效的。 BUG的描述方法 如何有效描述BUG？ 它是有关仅用能够表达你观点的用词明白地表述错误的方法；太多的话将会使你的观点陷入茫然无措中；太少的话又会使他人用自己的假设去填补隔阂---通常是对软件有害的部分。描述软件缺陷应遵循一定的规则。 BUG描述的基本规则 Condense简洁——清楚描述但简短； 首先，排除非必要的文字；其次不要加入无关紧要的信息；重要的是要包括所有关联的信息，但是要确保信息是关联的。要记住在不清楚怎样复制问题或难以明确问题的情况下，无关信息与太少的有关信息同样都是问题 BUG描述的基本规则 Accurate正确——这真的是一个缺陷？可不可能是操作错误、安装问题等？ 如果你报告的问题最终发现是由安全问题、操作错误或测试误解引起，你很快就会失去可信性。在报告bug前，需要考虑： 是否可能是安装中的什么问题引起了此问题？例如，是否安装了正确的版本？你是否正确登录，使用了正确的命令/执行顺序…？ 是否由前一版本的不完全清理，不完全结果，或前一版本的手工干涉引发此问题？ 这可不可能是网络或其他环境问题引发的结果？ 你是否真的明白此功能应该怎么工作？ 不要害怕写问题，同时尽你的最大努力确保它们是有效的问题。当最终确认你提交的问题不正确时，确保你会从中学习 BUG描述的基本规则 Neutralize中立——仅仅描述事实，不要使用带感情色彩的表述； 使用带感情色彩的表述对修改问题无益，而且这种陈述对交流与团队工作是一种障碍。表述对研发人员有用的信息，从长远的角度来说会使你显得更职业，并使你赢得尊重与信誉。在提交问题之前，通读一遍问题描述，删除或重写可以被解释为对个人有消极影响的陈述 BUG描述的基本规则 Precise准确——清楚的描述问题是什么； 在任何情况下，尤其是描述很长时，你需要直接在问题描述前概述问题。你的目标是写一个不会被误解的描述，而不是写一个可能被理解的描述。唯一实现上述目标的方式是清晰而简洁的描述问题而不是仅仅给出一个发生什么的描述。 BUG描述的基本规则 Isolate分离——为了分离问题都作了什么？ 每个机构对测试人员分离问题的程度所持的观点与期望是不同的。一个测试人员，不考虑怎样要求的，通常都应当投入适当的精力来分离问题。当分离问题时，考虑以下几点： 当