Bug管理

本篇文章,来分享Bug管理的内容。

现在,假设我们已经进入了这么一个阶段,测试用例写完了,可能有人用Excel写,可能也有人用禅道或者其他的管理工具来写。而且,用例已经评审过了,那就开始执行测试用例了。

在执行用例的时候,可能会遇到一个问题,这个测试用例不通过,这就形成一个Bug了。

Bug的定义

电脑程序里的错误,而现在更是将其延伸为漏洞,错误,可改进的细节,或与需求文档存在差异的功能实现等。

那么Bug 与缺陷有什么区别或者联系吗?

Bug是缺陷的一种表现形式,而一个缺陷是可以引起多种Bug的。

Bug的分类

对Bug的划分,可以分为以下:

  1. 功能缺陷:指业务流程未实现
  2. 代码错误:页面跳转时报404、500
  3. 界面优化:UI 问题,图文显示的问题
  4. 安装部署:安装失败或者无法访问等
  5. 性能问题:响应时间久,页面加载慢
  6. 安全问题:用户身份验证,数据备份等
  7. 设计缺陷:需求问题
  8. 其他:易用性及兼容性的问题

Bug 的严重程度

1、致命:系统崩溃(请求直接把服务器搞坏)、死机、死循环等,会导致数据库丢失,与数据库连接错误,主要功能丧失,基本模块缺失,重要的一级菜单功能不可使用等问题。

2、严重:系统主要功能部分丧失,数据保存失败,提交调用错误,功能设计与需求严重不符,自动退出,稳定性差等。

3、一般:功能菜单没有完全实现,存在缺陷但不会影响系统稳定性。如操作时间长、查询时间长、格式错误、边界条件错误、删除没有确认框、数据库表的字段过多等。

4、轻微:兼容性,界面优化,不影响操作功能的执行,错别字,页面显示重叠,提示语丢失等,此类问题在测试初期较多,优先程度低。

Bug的优先级

主要是指开发修复Bug的先后顺序,可以分为:

  • 非常紧急
  • 紧急
  • 一般
  • 不重要

Bug的优先级,最终的决定权还是掌握在开发或者产品经理的手上,测试人员只是起到建议的作用。

Bug的跟踪处理流程

根据Bug的跟踪处理流程,Bug存在以下的状态:

  1. 待处理
  2. 已确认
  3. 已处理
  4. 已修改
  5. 仍处在,代表被重新激活
  6. 拒绝
  7. 挂起,代表暂不处理

Bug的描述概要

发现Bug之后,需要将Bug描述清楚,转交给开发处理。

关于Bug的描述,主要包含以下:

  1. Bug的所属项目
  2. Bug的所属模块
  3. Bug产生的前提条件
  4. 问题类型
  5. 标题:尽量详细,方便后续快速查询
  6. 严重级别
  7. 优先级
  8. 复现步骤
  9. 期望结果
  10. 实际结果
  11. 附件:如有必要,可添加截图与视频等

关于高质量的Bug:

  • 标题:简明扼要地描述Bug,可以让负责修复的人员快速了解,定位问题
  • 测试环境:清晰描述在什么环境下发现Bug,包括软件和硬件系统
  • 前提条件:用户测试步骤前的系统环境信息等
  • 测试步骤:在执行怎么样的操作时,发现问题
  • 预期结果:软件设计所要求达到的需求、预期目标
  • 实际结果:在测试软件的过程中,软件本身表现出的结果,可能会与预期结果有差异

与开发的沟通

1、确保自己提交的Bug是有意义的,并且是可重现的

2、如果开发有疑问,或者认为这不属于Bug时,可以从用户角度进行解析

3、Bug 步骤要写清楚,方便开发人员定位Bug

4、与开发确认,修改Bug后,会影响到哪些模块,重点关注

5、注意沟通技巧

以上就是本篇文章所要分享的内容,欢迎各位大牛指正。你的指正,能让我在测试之路上快速成长。

Leo Never Stop Fighting!

你可能感兴趣的:(测试,转行)