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

1、BUG描述及管理,课程介绍,BUG的基本概念 什么是BUG? BUG所带来的危害 BUG是怎样产生的? BUG的类型 BUG的描述方法 BUG描述的基本规则 BUG描述的实用方法 BUG的管理流程 缺陷的严重程度和修改的优先级 BUG的生命周期及其状态 BUG的处理流程,BUG的基本概念,什么是BUG? 所谓BUG，就是软件不能满足用户的期望,也就是软件与用户期望值之间的差异。通常情况下我们认为至少满足下面3个规则之一才称发生了一样软件缺陷: 软件未能实现或错误的实现用户合理的需求。 软件未能实现用户需求未明确提及但应该实现的目标。 软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户

2、会认为不好。,BUG的基本概念,BUG的危害 人们对软件Bug的心态是既敬畏又憎恨，主要是因为软件Bug经常潜藏于无形之中，而一旦发作轻则引起数据丢失，重则物毁人亡，造成生命和财产的巨大损失。,BUG的基本概念,BUG产生的原因 开发人员不太了解软件需求，不清楚应该“做什么”和“不做什么”，常常做不合需求的事情，因此产生了Bug。 软件系统越来越复杂，开发人员不太可能精通所有的技术，如果不能正确地使用技术，将产生Bug。 软件设计文档不清楚，文档本身存在Bug，导致使用者产生更多的Bug。 软件需求、设计说明书、程序经常发生变更，每次变更都可能产生新的Bug。,BUG的基本概念,BUG的类型

3、需求错误：需求描述错误。 架构缺陷：软件架构在合理性、稳定性、可靠性、效率、可扩展性等方面的不足。 设计错误：需求描述正确，但设计是错误的。 编码错误:数据结构内部算法错误. 文档错误：影响发布和维护，包括注释。如：文档记载系统在条件Y下做X，但是系统做Z（一个有效并且正确的操作）。 不符合标准：不符合各种标准的要求，如行业标准、编码标准、设计符号、UI设计标准、源代码规范、其他设计规范。 测试误解：测试人员描述的错误“不是一个问题”，报告产生的原因是因为测试人员对正确行为的误解。 其他实现错误：根本原因已知，但是与前面的分类不相符。,BUG的描述方法,BUG记录作为测试和开发之间沟通的桥梁,

4、测试人员在报BUG的时候,有效的BUG描述,会更加容易帮助开发解决问题。,BUG的描述方法,有效的BUG=有效的沟通 通常情况下修改BUG并不难，困难在于寻找和定位BUG产生的位置和原因。如果开发人员能够根据BUG描述快速的将BUG重现，我们认为这样的描述是有效的。,BUG的描述方法,如何有效描述BUG？ 它是有关仅用能够表达你观点的用词明白地表述错误的方法；太多的话将会使你的观点陷入茫然无措中；太少的话又会使他人用自己的假设去填补隔阂-通常是对软件有害的部分。描述软件缺陷应遵循一定的规则。,BUG描述的基本规则,Condense简洁清楚描述但简短； 首先，排除非必要的文字；其次不要加入无关紧

5、要的信息；重要的是要包括所有关联的信息，但是要确保信息是关联的。要记住在不清楚怎样复制问题或难以明确问题的情况下，无关信息与太少的有关信息同样都是问题,BUG描述的基本规则,Accurate正确这真的是一个缺陷？可不可能是操作错误、安装问题等？ 如果你报告的问题最终发现是由安全问题、操作错误或测试误解引起，你很快就会失去可信性。在报告bug前，需要考虑： 是否可能是安装中的什么问题引起了此问题？例如，是否安装了正确的版本？你是否正确登录，使用了正确的命令/执行顺序？ 是否由前一版本的不完全清理，不完全结果，或前一版本的手工干涉引发此问题？ 这可不可能是网络或其他环境问题引发的结果？ 你是否真的

6、明白此功能应该怎么工作？ 不要害怕写问题，同时尽你的最大努力确保它们是有效的问题。当最终确认你提交的问题不正确时，确保你会从中学习,BUG描述的基本规则,Neutralize中立仅仅描述事实，不要使用带感情色彩的表述； 使用带感情色彩的表述对修改问题无益，而且这种陈述对交流与团队工作是一种障碍。表述对研发人员有用的信息，从长远的角度来说会使你显得更职业，并使你赢得尊重与信誉。在提交问题之前，通读一遍问题描述，删除或重写可以被解释为对个人有消极影响的陈述,BUG描述的基本规则,Precise准确清楚的描述问题是什么； 在任何情况下，尤其是描述很长时，你需要直接在问题描述前概述问题。你的目标是写一

7、个不会被误解的描述，而不是写一个可能被理解的描述。唯一实现上述目标的方式是清晰而简洁的描述问题而不是仅仅给出一个发生什么的描述。,BUG描述的基本规则,Isolate分离为了分离问题都作了什么？ 每个机构对测试人员分离问题的程度所持的观点与期望是不同的。一个测试人员，不考虑怎样要求的，通常都应当投入适当的精力来分离问题。当分离问题时，考虑以下几点： 当一般来说需要很长步骤才能分离出问题时，努力找到一种最短、最简单的步骤来复制问题。 问问自己此问题是否可能由正在测试的特定外界因素引起？例如，如果出现挂起或延迟，可不可能是网络问题引起？如果你正在做端到端的测试，你是否能够指出是其中的哪个组件出现故

8、障？你是否能做些什么来缩小组件故障范围？ 如果你的测试有多输入，改变输入直到你能够找到哪个输入的具体数值引发了此问题。,BUG描述的基本规则,Generalize概括为了理解此问题有多普遍都作了什么？ 研发人员通常刚好修正你报告的问题，甚至没有意识到此问题是一个更普遍的问题，需要更普遍的修改方式。例如，我可能报告我的word保存功能出现故障，并且在我试图保存文件“我的文档”时异常终止，而且只要我存一个空文件时，此故障就会出现。,BUG描述的基本规则,Re-create重现触发/重现此问题的基本要素是什么？ 如果你无法或怀疑可能无法重现问题时，搜集所有你能搜集到的相关信息，为那些可能不得不试验或

9、修复此问题的人提供有用信息。可能有时你需要考虑询问研发人员他们是否想在系统仍在故障状态下检查系统或者是否在清除此问题状态或恢复系统前，有特定信息需要捕获。如果你没有证实问题可被重现时，不要假定它可被重现。如果你不能或还没有重现此问题，在缺陷描述中注明这点很重要。,BUG描述的基本规则,Impact影响如果此bug出现在客户环境中有什么影响？ 一些bug的影响是不言自明的。例如，你可能发现页面文字错误。这可能看来非常微小，甚至不值一提，除非你指出每个使用你的产品的人都首先看到这些文字并且这个文字错误导致产生一个冒犯性的词汇。在这种情况下，即使它仅仅是一个文字错误，却可能是在运送货物前必须要修正的

10、。做最好的判断。如果你认为这个缺陷不具备足够的优先级，那么声明潜在的影响并出售缺陷。 别过分吹嘘，但要确保缺陷的读者能够准确的理解缺陷对客户可能的影响,BUG描述的基本规则,Debug调试研发人员调试此缺陷需要什么? 研发人员在调试此问题时需要什么？是否有需要被捕获并在此缺陷报告中可用的的堆、日志等内容？记录被捕获的内容和访问它的方法。,BUG描述的基本规则,Evidence证据什么可以证明此错误的存在？文档？ 不要假定每个人看问题的方式都和你一样。不要指望他人的阅读完会和你得出同样的结论。不要假定3个星期之后你仍然记得为什么你认为那是一个bug。想一想是什么说服你这是一个bug并且在报告中涵

11、盖此点。如果你认为有可能这种情况不会被所有人认为是一个有效的bug，你可能不得不提供更多的证据。,BUG描述的实用方法,了解你的听众 选择一个好的标题 书写清楚,步骤明确 解释错误的影响,不只是症状 BUG描述补充,BUG描述的实用方法,了解你的听众 你的第一听众：那个必须修复错误的人需要清楚，明确的步骤以重现错误。信息越多越好，开发人员需要我们操作了什么和我们看见了什么的准确信息。 你的第二听众：决定错误命运的人或团体需要知道如果不修复此错误的后果。这个听众需要精练的语句以抓住他们的注意力并且引发对错误的相关问题的讨论。,BUG描述的实用方法,选择一个好的标题 一般把用于描述错误的短句称为错

12、误的标题或描述。这是bug report中最要的部分。错误审核会成员经常通过它来决定错误是否可以推迟修复。如果标题没有力度，委员会成员可能认为它是不值得花费太多的时间。,BUG描述的实用方法,选择一个好的标题示例： 好的：超时后在退出时崩溃了 太长的：在数据库不可用后你又保存记录的更改,然后从文件菜单中选择退出时程序崩溃了 不足够的信息：程序崩溃了 太模糊：当数据库离线时出现问题,BUG描述的实用方法,书写清楚，明确的步骤 你提交给开发人员的步骤应该提供如何产生错误的信息，这样错误就能够被发现并且修复。它也需要给错误审核委员会提供错误发生的环境,BUG描述的实用方法,示例1： 简洁、正确的：

13、1运行客户端 2找出一个记录 3更改记录但不存盘 4使数据库服务器脱机 5尝试保存记录 6收到一个超时的错误 7退出客户端 结果：崩溃,BUG描述的实用方法,示例2： 太多冗余的信息（不能够指出什么是引发错误的最关键原因） 1运行客户端 2为输入新的条目查询数据库 3打开一个浏览器 4在上浏览新闻 5关闭浏览器 6选择一个条目 7把种类从“蔬菜” 更改到“水果” 8使数据库服务器脱机 9尝试保存记录 10收到一个超时的错误 11退出客户端 结果：崩溃,BUG描述的实用方法,解释错误的影响，不只是症状 BUG描述补充,BUG管理,缺陷严重程度及修改优先级 每个公司或项目小组都有自己的BUG严重程

14、序定义，通常定为3级： 一级缺陷：致命故障。一般代表对软件关键用况的使用有影响的错误。在任何外部发布之前，必须解决此种缺陷。一级缺陷主要包括三种情况：系统运行死机，数据库被破坏，基本功能实现不正确。 二级缺陷：功能模块中存在错误，但不会削弱系统的有用性，存在可以绕过缺陷的解决方案。 三级缺陷：错误是表面化的或微小的，使操作者不便或遇到麻烦，但不影响正常功能的执行。,BUG管理,BUG修改优先级别： 根据BUG的严重程度，BUG的修改优先级通常可分为3个级别： P1：缺陷必须立即被解决； P2：必须在下一个版本中被修复； P3：在将来的某个版本修正也可以；,BUG管理,BUG的生命周期及其状态

15、BUG的生命周期就是指BUG从开始提出到最后完全解决，并通过复查的过程。在此个过程中BUG报告的状态不断发生着变化，记录着BUG的处理进程。,BUG管理,缺陷处理工序状态（缺陷处理周期） 新建状态（ NEW ） Bug创建后的初始状态。 已分拣（Filtered） BUG被确认，并且设置了处理优先级后的状态 已分配状态（ASSIGNED） BUG被分配给修改人员的状态。 已修改状态（RESOLVED） 开发部门对软件问题进行处理或修改后的状态。 解决状态（VERIFIED） 经测试部门对修改后的软件问题进行验证并确认修改正确后的状态。 关闭状态（CLOSED） Bug生命周期的结束。,BUG管

16、理,缺陷处理结果状态即问题解决程度： FIXED:描述的问题已经修改。 INVALID:描述的问题不是一个bug (输入错误后，通过此项来取消) 。 WONTFIX:描述的问题将永远不会被修复。 LATER:描述的问题将不会在产品的这个版本中解决。 DUPLICATE:描述的问题是一个存在的bug的复件。 WORKSFORME:所有要重新产生这个bug的企图是无效的。如果有更多的信息出现，请重新分配这个bug，而现在只把它归档。 REMIND:描述的问题可能不会在产品的这个版本中解决，但是也许会。,BUG生命周期图,BUG管理,岗位与职责 项目经理（项目负责人）：在项目计划制作阶段制定BUG处

17、理流程及时通知项目相关人员，确保BUG信息在合适的时候传递到合适的人员。在项目组中组织实施本流程并在项目组内协调有争议的BUG的处理方法。,BUG管理,修改人员（开发人员、程序员）： BUG分析定位； 修复BUG并实施伙伴测试； 修改BUG处理状态； BUG沟通与处理协同工作； 为增加程序的可测试性而进行的开发活动；,BUG管理,测试经理(测试负责人): 组织协调基于代码执行的测试活动，确保测试活动的有效性和针对性，控制测试质量、进度和成本。 整体监控由测试人员提交的BUG状态，评估测试工程整体进展情况，及时调整测试的执行策略。 控制测试执行启停。 根据项目的进展情况和测试工程的需要组织BUG沟通,BUG管理,测试人员(测试员): 提交BUG，验证BUG，并负责测试提交问题的跟踪管理。 BUG沟通,BUG管理,部署发布人员 根据项目的需要，及时发布正确的版本，执行版本发布测试，保证新版本的基本可测试性。,BUG管理,BUG的处理流程 缺陷处理流程是直至项目结束为止的以下过程的循