测试基础知识之Bug的定义

常见的步骤：

组织：部门-添加下级部门、用户-添加产品经理，项目经理，开发测试经理，测试和开发

产品：产品-添加产品、模块-维护子模块、计划-创建计划、需求-提需求（不评审）

项目：项目-添加项目、团队-团队管理、版本-创建版本、任务-建任务、需求-关联需求

测试：版本-提交测试、用例-导出模板上传用例、bug-提交bug

后台：后台-发信配置邮件发送

作为一名测试人员，重要的工作内容之一，就是找BUG，提交BUG，验证BUG，推进BUG的解决，直至软件达到发布的标准，提高软件的质量，及研发的工作效率和质量。

 当我们踏入测试这个行业开始，就意味着我们以后基本上天天都要跟bug打交道。要找bug，那么，就要先了解一下bug的定义是什么？

一、bug定义 

   狭义概念：软件程序的漏洞或缺陷

    广义概念：1、漏洞、缺陷；2、不符合需求的；3、发现和提出针对这个产品的可以改进的细节；4、为了提高用户的体验

    测试工程师的职责：发现bug，提交给开发并让开发去修改

二、bug类型 

   代码（功能）错误、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、其他 （功能类、界面类、性能类、易用性类、兼容性类等）

• 1、代码错误：错误页面404、500
• 2、设计缺陷-需求人（需求缺陷）
• 3、界面优化：UI问题、图文显示（折行，重影，宽窄不一）
• 4、性能问题：（响应时间久，加载慢）
• 5、配置相关（配置文件错误，导致报错）
• 6、安装部署：安装失败、无法访问等（漏掉文件更新，数据库初始化）
• 7、安全相关：密码明文显示
• 8、标准规范（所有的导航格式，菜单）
• 9、测试脚本（数据库脚本）
• 10、其他划分：功能类、界面类、性能类、易用性类、兼容性类、不是BUG

三、bug等级判断条件 

（1）致命错误：

1. 常规操作（不是破坏性操作）引起的系统崩溃、死机、死循环
2. 造成数据泄露的安全问题，比如恶意攻击造成的账户私密信息泄露
3. 涉及金钱，如支付类软件，金钱计算错误

（2）严重错误

1. 重要功能不能实现（例如：微信没有实现语音聊天、朋友圈，等）
2. 错误的波及面广，影响到其他重要功能正常实现
3. 非常规操作导致的程序崩溃、死机、死循环(非常规操作：用户使用软件时不会进行的操作）
4. 外观难以接受的缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）
5. 密码明文显示

（3）一般错误：不影响产品运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷

1. 次要功能不能正常实现
2. 操作界面错误（包括数据窗口内列名定义、含义不一致）例如：列名与列名下的内容不一致
3. 查询错误，数据错误显示
4. 简单的输入限制未放在前台进行控制（格式显示，如登录和注册中的格式判断可由前端判断）
5. 删除操作未给出提示

（4）细微错误：程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

1. 界面不规范
2. 辅助说明描述不清楚
3. 提示窗口文字未采用行业术语
4. 界面存在文字错误
5. 改进建议：可以提高产品质量的建议，包括新需求和对现有需求的改进

注：bug的等级判断要根据具体情况做判断，一般不会偏离太多

四、bug生命周期 

 了解bug，就需要知道bug的生命周期中有哪些状态，一个bug从被发现到最后消失会经历什么？ 

重点：发现bug后，------->有可能有bug--------确认实实在在的bug------提交bug

确认bug时不能停留在表面，需要进行深究：

例如：下拉框选择银行，却发现只有3个银行？

1、首先需确认数据库的表信息是否正确

2、如果数据库表只要3个银行 （需要沟通）研发的话只需要添加数据就好了

3、数据库表正常=====直接提bug，代码有问题

指派bug：指派给相关功能模块的开发

     bug生命周期的一般状态：提bug->指派->已解决->待验->关闭 

五、bug状态

5.1、bug状态标准

1、待处理（new）：测试人员或用户发现新问题后提交的状态

2、已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。

3、已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。

4、已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。

5、 仍存在（reopened）：测试人员认为BUG未修复成功，问题仍然存在，由测试人员设置。

6、 不是问题（reject）：研发人员确认不是BUG，或者建议与意见决定不采纳。

7、 暂不处理（hold）：当前版本不做修改，后续版本再考虑，由研发人员或测试人员设置。

5.2、bug状态处理

（1）已经指派给开发的bug，1、要进行跟踪处理、提醒开发；2、已修改的，更新环境验证

（2）已解决的bug，1、更新环境验证；2、验证通过、关闭；3、验证不通过，重新打开；4、回归验证时继续跟进bug，知道关闭bug

（3）重复的bug，查看bug是否重复，如果重复则关闭，如果不重复，要说明原因，重新指派给开发

（4）不是缺陷，确认开发环境和测试环境是否一致，确认不是缺陷则关闭；确认是缺陷，跟开发沟通，沟通不一致，则找产品或者熟悉产品的人员确认，确认是bug并注明情况，再指派给开发

（5）无法重现，确认开发环境和测试环境是否一致，包括操作步骤、浏览器、特定账号等，如果多个版本验证之后，如开发所说重现不了，依据bug的严重程度跟产品、开发一起确认关闭；如果找到重现原因，注明清楚并再次指派给开发（偶现问题要注明）

（6）不予解决，找产品或者熟悉产品的人员确认，确认不予解决则关闭；确认需要解决请备注原因并打开指派给开发

（7）设计如此，找产品或者熟悉产品的人员确认，确认设计如此则关闭；确认是bug，备注原因重新指派给开发

（8）延期修改，确认bug严重程度是否影响当前版本发布，与产品确认，不予延期的请根据情况进行激活与情况说明；确认延期则做好记录，后续版本进行关注

六、常见bug管理系统

  禅道（ZenDao）、bugzilla、jira、bugfree、easybug、QC

七、优先级的定义 

• P0：核心功能测试用例（冒烟测试），确定此版本是否可测的测试用例，此部分测试用例如果fail（失败）会阻碍大部分其他测试用例的验证。
• P1：高优先级测试用例，最常执行以保证功能性是稳定的；基本功能测试，和重要的错误、边界测试。
• P2：中优先级测试用例，更全面的验证功能的各个方面，异常测试，边界、中断、断网、容错、UI等测试用例。
• P3：低优先级测试用例，不常常被执行，性能、压力、兼容性、稳定性、安全、可用性等等。