本篇文章,来分享Bug管理的内容。
现在,假设我们已经进入了这么一个阶段,测试用例写完了,可能有人用Excel写,可能也有人用禅道或者其他的管理工具来写。而且,用例已经评审过了,那就开始执行测试用例了。
在执行用例的时候,可能会遇到一个问题,这个测试用例不通过,这就形成一个Bug了。
Bug的定义
电脑程序里的错误,而现在更是将其延伸为漏洞,错误,可改进的细节,或与需求文档存在差异的功能实现等。
那么Bug 与缺陷有什么区别或者联系吗?
Bug是缺陷的一种表现形式,而一个缺陷是可以引起多种Bug的。
Bug的分类
对Bug的划分,可以分为以下:
- 功能缺陷:指业务流程未实现
- 代码错误:页面跳转时报404、500
- 界面优化:UI 问题,图文显示的问题
- 安装部署:安装失败或者无法访问等
- 性能问题:响应时间久,页面加载慢
- 安全问题:用户身份验证,数据备份等
- 设计缺陷:需求问题
- 其他:易用性及兼容性的问题
Bug 的严重程度
1、致命:系统崩溃(请求直接把服务器搞坏)、死机、死循环等,会导致数据库丢失,与数据库连接错误,主要功能丧失,基本模块缺失,重要的一级菜单功能不可使用等问题。
2、严重:系统主要功能部分丧失,数据保存失败,提交调用错误,功能设计与需求严重不符,自动退出,稳定性差等。
3、一般:功能菜单没有完全实现,存在缺陷但不会影响系统稳定性。如操作时间长、查询时间长、格式错误、边界条件错误、删除没有确认框、数据库表的字段过多等。
4、轻微:兼容性,界面优化,不影响操作功能的执行,错别字,页面显示重叠,提示语丢失等,此类问题在测试初期较多,优先程度低。
Bug的优先级
主要是指开发修复Bug的先后顺序,可以分为:
- 非常紧急
- 紧急
- 一般
- 不重要
Bug的优先级,最终的决定权还是掌握在开发或者产品经理的手上,测试人员只是起到建议的作用。
Bug的跟踪处理流程
根据Bug的跟踪处理流程,Bug存在以下的状态:
- 待处理
- 已确认
- 已处理
- 已修改
- 仍处在,代表被重新激活
- 拒绝
- 挂起,代表暂不处理
Bug的描述概要
发现Bug之后,需要将Bug描述清楚,转交给开发处理。
关于Bug的描述,主要包含以下:
- Bug的所属项目
- Bug的所属模块
- Bug产生的前提条件
- 问题类型
- 标题:尽量详细,方便后续快速查询
- 严重级别
- 优先级
- 复现步骤
- 期望结果
- 实际结果
- 附件:如有必要,可添加截图与视频等
关于高质量的Bug:
- 标题:简明扼要地描述Bug,可以让负责修复的人员快速了解,定位问题
- 测试环境:清晰描述在什么环境下发现Bug,包括软件和硬件系统
- 前提条件:用户测试步骤前的系统环境信息等
- 测试步骤:在执行怎么样的操作时,发现问题
- 预期结果:软件设计所要求达到的需求、预期目标
- 实际结果:在测试软件的过程中,软件本身表现出的结果,可能会与预期结果有差异
与开发的沟通
1、确保自己提交的Bug是有意义的,并且是可重现的
2、如果开发有疑问,或者认为这不属于Bug时,可以从用户角度进行解析
3、Bug 步骤要写清楚,方便开发人员定位Bug
4、与开发确认,修改Bug后,会影响到哪些模块,重点关注
5、注意沟通技巧
以上就是本篇文章所要分享的内容,欢迎各位大牛指正。你的指正,能让我在测试之路上快速成长。
Leo Never Stop Fighting!