【测试基础-Bug篇】09-测试用例的评审和测试执行之Bug定义及Bug生命周期及Bug管理流程

补充之前遗留的知识前面我们已经学习过了测试需求分析-测试用例的设计。那现在我们先补充测试用例的评审和执行测试。测试用例的评审对测试用例进行评审评审的目的是什么关于用例的准确性要求我们用例覆盖的需求跟项目的需求一致。关于用例的完整性用例应该覆盖所有的需求尽可能达到最高不要出现漏测试的情况。参与评审的人员是哪些测试人员、开发、产品、项目经理。用例评审的方式组内评审负责该项目的测试人员。组外评审测试组以外的人员进行评审一般包含开发、产品、测试。测试执行测试执行之前的前提条件测试环境要搭建好并且冒烟测试要通过(预测试基本功能要跑过)。怎样进行测试执行运行被测项目根据测试用例执行测试如果实际结果与预期结果不一致可能是Bug。在执行测试中我们重点要学习的就是bug。那什么是bugBug就是缺陷就是错误我们接下来就详细说一下。BugBug的定义软件的bug狭义概念是指软件程序的漏洞或缺陷广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。我们的职责就是发现这些bug并提交给开发让开发去修改。Bug的类型为确定一个Bug的类型需要对项目有比较深的理解。这个划分对于开发定位问题影响很小但对于问题类型的统计就比较重要常见的Bug类型划分为以下几个基于代码功能的错误我们所实现的功能跟需求不一致导致的这类bug这类bug是最多的。基于界面优化界面不美观或者不符合用户使用习惯之类的问题。基于设计缺陷与开发产品需求文档不一致的情况。Bug的等级1、致命的错误(blrocker)常规操作引起的系统崩溃死机死循环闪退。造成数据泄露的安全性问题比如恶意攻击造成的账户私密信息泄露。涉及金钱计算。阻断性测试所有测试工作进行不下去。2、严重错误(critical)重要功能不能实现错误的涉及面广影响到其他重要功能的正常实现。非常规操作导致的程序崩溃死机死循环闪退。外观界面难以接受的缺陷密码明文显示。偶现像的致命性bug。3、一般错误(major) 【最多】这个级别一般不影响产品的运行不会成为故障的起因但对产品外观和下道工序影响较大。次要功能不能正常实现。操作界面错误包括数据窗口内列名定义、含义不一致等。查询错误数据错误显示。简单的输入限制未放在前端进行控制。删除操作未给出提示。偶现的严重性Bug。4、细微错误这个等级一般是程序在一些显示上不美观不符合用户习惯或者是一些文字的错误。界面不规范辅助说明描述不清楚。提示窗口文字未采用行业数据。界面存在文字错误。5、改进与建议可以提高产品质量的建议包括新需求和对需求的改进。做题用户输入正确的用户名和密码不能登录网站。—严重错误客户需求要有充值功能但网站没有做。—他是重要的功能属于严重错误。网站充值后出现金额错误。—此时的分析如果是后面又正常了的话属于偶发现的可以归为严重错误如果后如果延时之后还是错误的话那就是致命错误。在某个app上进行商品搜索的时候闪退回到手机桌面。—致命的。在某购物app上进行商品搜索时手机卡死。—致命的。关闭按钮在弹窗左侧。—细微错误。App某个图标显示太大或者像素失真。—一般错误。某个提示语需要改进一下用户对专业术语不太懂。—细微错误。忘记密码功能没有实现。—分析是次要功能没有实现属于一般错误。Bug的生命周期及流程【重要】Bug的生命周期就是一个bug被发现到这个bug被关闭的过程。那么这个过程有哪些步骤呢Bug生命周期中的状态新建(提Bug)-指派-已解决-待验-关闭。【正常流程】如果待验的bug在验证时没有解决好我们需要重新打开(激活)-指派-已解决-待验循环这个过程。【异常流程】中间其他状态拒绝延、期等。Bug的跟踪管理流程重要注意所有状态变更原则上是谁当前持有 bug谁来操作。1、测试人员发现bug并确认bug提交bug单。**注意事项看是否是你的环境与操作有问题才会导致的bug。然后这时候看你发现bug的这个状态属于什么状态激活/new/新建。2、指派到开发或开发经理此时的状态是指派3、 开发确认bug也就是我们的开发看它是否是bug。如果是bug开发确认bug开发确认bug会有两种情况。如果是正常bug那么此时bug的状态为已确认然后就可以转入4流程。如果该bug不是正常的那么开发去确认bug之后说是重复bug此时开发需要指明重复bug的id。 那么针对重复bug处理操作如下1)开发说是重复bug由开发将 bug 状态改为【重复 / Closed-Duplicate】并关闭开发不要提交。避免提交重复bug的技巧就是先搜索。2)那如果开发说是重复bug而我测试人员觉得这不是bug怎么办呢此时我们(测试人员)要加备注描述不是重复bug然后重新激活这个bug。如果不是bug如果我们的开发觉得这不是bug有以下两种情况开发说这不是bug我们设计就是如此当前不是Bug。那此时我们测试人员怎么办呢测试人员做如下操作a.再次确认问题现象b.对照需求站在用户的角度参考成熟的产品与开发沟通。c.如果上述还没有达成一致那么此时就去找产品或项目经理来进行最后的确认 Bug是否重新激活还是关闭[注意这些过程都需要加备注]开发说这不是bug开发去重现这个bug但是发现当前Bug无法重现那么此时测试人员的做法如下a.测试人员帮助开发去重现bugb.如果我们测试在开发那边复现不出来那我们就在自己测试这边的环境看跟踪3~5个版本他还是不能复现这个bug。那么此时就加备注然后测试人员关闭bug。4、开发受理bug如果此时开发已经确认这是一个bug了那么他就会做出以下对应的解决方案【已解决】 此时我们转入流程5【不予解决】通常是这种情况开发参考bug的优先级比如界面方面的bug可改可不改再加上没时间我就先不予解决。(但是如果我们测试人员又希望去改存在争议的话那么我们测试人员怎么做首先呢尝试跟开发沟通如果沟通无果可以进一步跟产品进行最后的确认加备注他们说可以不改然后进行关闭。)【延期处理】这种是因为我们测试提交的是建议性bug然后优先级又比较低改动太大的话影响有点大涉及面太大此时开发就先延期一下。然后到我测试这边我们测试人员该怎么去处理呢a.首先呢衡量这个bug是否影响用户的使用。其次衡量一下时间修改这个bug时间长不长最后的话我们可以跟产品做最后的确认把确认的结果加到备注。5、测试验证BUG在已经解决的这个版本上进行验证bug是否完美解决测试人员如何验证BUG?在解决的版本上进行bug验证是否已解决验证与该bug相关联的功能是否正常验证结果验证未通过 / 问题未修复 → 重新激活进入循环如果是新的 unrelated bug那么就提新 bug如果测试验证没问题就进入流程6。6、如果上述都做了此时我们的测试人员就关闭bug。补充问题对于偶然出现的bug我们测试人员怎么处理尽可能的复现出现bug(尽可能的还原当初的步骤及当初的数据环境)。我们在测试的时候就要写出bug的复现率即出现bug的次数除以总次数那个的复现率。持续跟踪3~5个版本。Bug的管理工具禅道工具zentaobugzillabugfreejiraeasybugReadmine老铁们如果你觉得这篇文章对你有帮助别忘了点赞⭐ 收藏 关注各位老铁的支持~~