测试理论-bug缺陷

一、缺陷概述

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

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

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

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

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

建议：针对一个产品提出自己建议给产品经理 优化：提交给程序员和产品经理，不一定非要修改，如果拒绝或遗在后期修改，也可由优化产生新的需求 BUG/缺陷/Issus：产品的期望结果与实际结果不符合 故障：生产环境中产品出现严重的问题，导致产品不可用或雪崩

二、缺陷状态

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

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

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

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

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

重开：测试验证修复bug发现没有完全修复好，重新交给开发。

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

 

流程

1、风险问题后提交问题给开发

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

3、开发把修改后的问题反馈给测试，测试验证通过后关闭问题

4、开发核对反馈无问题拒绝修改，测试核对无问题撤销该问题

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

缺陷级别

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

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

⼀般：⼩问题、拼写错误、UI布局、罕⻅错误。

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

缺陷优先级

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

⾼：必须在版本发布前修复。

中：必须要修复不⼀定⻢上修复，可确定在某个时间节点修复

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

BUG要素：前提条件、测试步骤、实际结果、期望结果

 

举例

前提条件： 首页可以访问

测试步骤： 登录输入框输入11111111111 ；输入后就自动获取验证码

实际结果： 输入不规范手机号码依然能够获取验证码

期望结果： 输入不规范手机号码，不能自动获取手机验证码

BUG注意： BUG步骤一定要具备可操作性（操作步骤要清晰，通俗易懂 ；提交的BUG最好有错误的截图信息，日志信息，url

 

 

页面交互/错误提示信息： 1、错误截图

如后台错误（一码通扫描二维码出不来，一直加载）： 1、加载不出来的截图 2、加载不出来后台错误log

单纯的后台服务： 1、从后台获取错误日志信息（出问题时刻的日志上下文，如出问题是09:50:55，获取的志是55秒的下上文）

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

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

2、测试环境验证问题存在，说明测试环境没测试出来，群里反馈给大家，询问评估今是否继续上线？

3、测试环境验证问题不存在，@开发让其检查各个中间件(RabbitMQ,Kafka,Redis等)配置参数及其他配置

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

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

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

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

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

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

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

1、版本代码合并后，测试需要针对系统的所有功能（新旧功能）进行测试 为什么需要测试？

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