补充之前遗留的知识：
前面我们已经学习过了测试需求分析->测试用例的设计。
那现在我们先补充测试用例的评审和执行测试。
测试用例的评审
对测试用例进行评审
评审的目的是什么？
- 关于用例的准确性：要求我们用例覆盖的需求跟项目的需求一致。
- 关于用例的完整性：用例应该覆盖所有的需求，尽可能达到最高，不要出现漏测试的情况。
参与评审的人员是哪些？
测试人员、开发、产品、项目经理。
用例评审的方式？
- 组内评审：负责该项目的测试人员。
- 组外评审：测试组以外的人员进行评审，一般包含开发、产品、测试。
测试执行
测试执行之前的前提条件
测试环境要搭建好，并且冒烟测试要通过(预测试，基本功能要跑过)。
怎样进行测试执行
运行被测项目，根据测试用例执行测试，如果实际结果与预期结果不一致，可能是Bug。
在执行测试中，我们重点要学习的就是bug。
那什么是bug？
Bug就是缺陷，就是错误，我们接下来就详细说一下。
Bug
Bug的定义
软件的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.测试人员帮助开发去重现bug
- b.如果我们测试在开发那边复现不出来，那我们就在自己测试这边的环境看，跟踪3~5个版本，他还是不能复现这个bug。那么此时就加备注，然后测试人员关闭bug。
- 开发说这不是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的管理工具
- 禅道工具zentao
- bugzilla
- bugfree
- jira
- easybug
- Readmine
老铁们，如果你觉得这篇文章对你有帮助，别忘了👍点赞⭐ 收藏👀 关注，🦀🦀各位老铁的支持~~