测试理论（7）

BUG提交和BUG生命周期管理

缺陷概述

1）缺陷（Defect）：是指存在于软件之中偏差，可被激活，以静态形式存在于软件内部，相当于Bug。

2）故障（Fault）：当缺陷被激活后，软件运⾏中出现的状态，可引起意外情况，若不加处理，可产⽣失效，是⼀ 个动态⾏为。

3）失效（Failure）：软件运⾏时产⽣的外部异常⾏为结果，表现与⽤户需求不⼀致，功能能⼒终⽌，⽤户⽆法完 成所需要的应⽤。

4）Bug：电脑系统或者程序中存在的任何⼀种破坏正常运转能⼒的问题或者缺陷，都可以称之为“Bug”；有时也泛 指因软件产品内部引起的软件产品最终运⾏时和预期结果的偏离。

5）缺陷报告单：指测试执⾏过程中，发现缺陷失效后，提出书⾯的报告，提供给开发⼈员作为定位缺陷的依据。

建议：针对一个产品的，提出自己的建议，这个建议只能给产品经理，不能说是问题，产品经理可以接收，也可以不接收

优化：优化是提交给程序员和产品经理，不一定非要修改，如果衡量不修改，也可以拒绝修改，也可以遗留到后期修改，也可以由优化来产生新的需求

BUG/缺陷/Issus：指的就是产品的期望结果与实际结果不符合 故障：一般指的是生产环境中产品出现严重的问题，导致产品不可用或者是雪崩（当雪崩的时候，没有一片雪花是漂亮的）

缺陷状态

主要描述缺陷当前的状态。状态如下：

新建：测试⼈员新提交的bug、优化或者建议的状态。

进⾏中：开发⼈员确认是bug，在修复bug过程的状态。

已解决：开发⼈员已修复bug的状态。

已关闭：测试⼈员验证修复的bug，确定已解决问题的状态。

不解决：开发⼈员认为不是bug，拒绝解决问题的状态或者⽆法解决问题的状态

重开：测试⼈员验证修复的bug，发现没有完全修复好bug，重新打回开发⼈员的状态。

暂缓：开发⼈员认为该bug不急于修复，可以放置⼀段时间再修复的状态。

缺陷类型

能正确分清缺陷类型需要测试⼯程师对需求和业务有深⼊了解，能考验测试⼯程师业务知识。

bug：测试⼈员通过测试发现的问题能称为bug。

需求：需要产品经理对需求进⼀步梳理。

建议：是软件产品改进建议

优化：功能已实现，需要优化问题。可以是⽤户体现优化、性能优化。

缺陷生命周期

流程：

1、风险问题后提交问题给具体的开发人员

2、开发人员核对问题后，如果是问题，进行修改

3、开发把修改后的问题反馈给测试，测试这边验证，如果通过。就关闭问题

4、开发人员核对问题不是问题，反馈给测试，拒绝修改，测试这边核对不是问题，撤销该问题

5、开发把修改后的问题反馈给测试，测试这边验证还是没通过，再次反馈给测试

缺陷级别

致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。

严重：操作性错误、结果错误、功能遗漏。

⼀般：小问题、拼写错误、UI布局、罕见错误。

建议：对产品的改进建议。

严重问题：

1、逻辑问题

2、影响流程功能

一般：

1、页面交互

2、浏览器兼容性

3、错误提示信息不合理

故障：

1、系统崩溃

2、数据丢失

3、系统雪崩

缺陷优先级

优先级表示修复缺陷的重要程度和紧迫程度。

紧急：影响进⼀步测试，需要⽴即修复。

高：必须在版本发布前修复。 中：必须要修复，不⼀定⻢上修复，可以讨论确定在某个时间节点修复好。

低：对产品影响⽐较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。

BUG的要素：

1、前提条件 2、测试步骤 3、实际结果 4、期望结果

eg：前提条件：首页可以访问

测试步骤：

1、在登录的手机号输入框里面输入了11111111111

2、输入后就自动获取验证码

实际结果：

1、输入不规范的手机号码依然能够获取验证码

期望结果：

1、输入不规范的手机号码，不能自动获取手机验证码

BUG注意：

1、BUG步骤一定要具备可操作性（操作步骤要清晰，通俗易懂）

2、提交的BUG最好有错误的截图信息以及日志信息

举例：

（1）页面交互/错误提示信息：最好有错误截图

（2）如后台错误（一码通扫描二维码出不来，一直加载）：加载不出来的截图 2、加载不出来这个时候后台的错误log（扫描时候的日志一直到加载不出来的日志信息）

（3）单纯的后台服务：从后台获取错误日志信息（出问题那个时刻的日志上下文，如出问题是09:50:55，那么获取的日志是55（53-57）秒的下上文）

面试题：

1、刚入职智联负责登录界面测试，发现一个一直存在BUG，要不要提出？

原则：

1、是问题必须反馈（提交BUG），这是一个价值观的问题

2、如果像这样的问题，大家都认为没有必要（包含测试负责人也是这样认为），那么你以后提单就需要注意： A、不管后面是否遇到同样的问题，即使遇到也是提单，修改不修改问测试负责人 B、针对每次这样的事最好有记录

3、质量是公司所有的人来负责的，但是现实生活中，遇到问题，测试肯定得有责任

2、请教大家一个问题，我身边出现了很难搞的开发，就是那种技术流，有些不服测试的那种，这时候该怎么面对呢

（1）在公司有的事情你是不能够改变的，你唯一能够改变的就是自己做事的风格

（2）该是问题还是问题，你继续提交BUG，至于不修改的情况下，问题再找人解决

（3）再职场里面，不要和人去计较一些东西

3、当你提了一个 bug，开发认为这不是 bug，该怎么处理？

该问题主要考核的是推动解决问题的能力以及定位问题的能力，找领导是最次的解决方案，如果因为一个开发不承认就找领导，那领导一天就什么都不需要干了，这个时候领导还是领导嘛。所以可以这样说：

首先我会再次检查问题是否存在（也存在你测试的时候问题存在，但是开发偷偷的解决了的情况），如果问题存在，那么提交的BUG步骤一定能要非常清晰，通俗易懂，同时要在提交的BUG里面附加上错误信息的日志上下文，以及尽可能的提供错误的截图信息。首先开发不承认不是和测试作对，也不是为难测试的，可能就是反馈的问题让对方看不清楚，或者看不懂，当然也存在某些开发很差劲，但是我建议不要这样去想开发，毕竟是一个团队的，信任，认可是很重要的。这样调整后，可以再找开发，比如打扰下，麻烦看看这个问题，是否是我的姿势不对等等，总之友好沟通，让对方来解决问题 如果真的发生是问题，并且提供的信息都是非常全的，但是开发不是不承认，各种不配合，这个时候需要思考下，对方为什么不承认，难道专门为难自己还是自己的沟通方式存在问题。比如你这代码差劲的，开发大概率就会很反感，也就不会配合了。所以这个时候也自己需要反思，然后改变沟通的策略和方式方法。

4、新功能晚上上线，结果上线后就有了问题，此时你会？

（1）先在测试环境验证问题是否存在（排查是开发的责任还是测试的责任）

（2）测试环境验证问题存在，那么就说明测试环境测试这边没测试出来，那么在群里面反馈给大家，然后再次评估今天晚上上线是否继续？

（3）测试环境验证问题不存在，也需要反馈出来，下一步@开发，让开发检查各个中间件(RabbitMQ,Kafka,Redis等)的配置参数以及其他的配置

（4）开发在3的基础上更新代码解决问题后，测试协助开发验证，然后把验证的结果反馈出来

复盘时你如何称述：

（1）测试问题，复盘怎么说？

A、这个问题首先测试这边是责任的，之前设计测试用例不仅仅测试没考虑到，评审的时候大家也没考虑到，所以导致这个场景没有测试到

B、所以下次编写测试用例，测试这边会增加XX维度的测试点，评审的时候大家也需要沿着这个维度来考虑

（2）开发问题，复盘怎么说？

A、建议开发这边每次上线前专门写一个关于上线的checklist，这样防治下次也犯同样的问题

序号       检查项               负责人

1     Redis参数修改为...    赵四

5、从测试开始到测试结束，测试总共测试几轮？ 在一个迭代中，你是怎么保障质量的？你是怎么测试保障本次迭代是没问题的？

（1）第一轮的测试：主要是测试本次迭代转测的所有功能，包含了正常，异常，性能，容错，等等（周一）

（2）第二轮的测试：先回归验证所有的问题单，问题单验证完毕后，再针对本次迭代的核心流程再次测试（周二）

（3）第三轮的测试：再次回归问题，以及进行系统测试（周三）

（4）下来接着就是验收测试以及探索性的测试

6、版本合并后，测试还需要测试吗？为什么？

版本代码合并后，测试需要针对系统的所有功能（新的功能+系统之前已有的功能）都需要进行测试

为什么需要测试？

开发在合并代码的时候，可能会出现冲突，也可能会出现代码的丢失