6.1软件缺陷——bug

软件测试生命周期

 测试计划、测试设计、测试执行、缺陷跟踪、测试评估

缺陷基本概述

缺陷定义

 1）软件未实现说明书要求实现的功能——要
 2）软件实现了不应该实现的功能——不要
 3）软件实现了需求说明书中未提及的功能——有
 4）软件未实现说明书中未提及但应该实现的功能——没有
 5）软件难以理解，不易使用，运行缓慢(从测试角度来说)最终用户会认为不好——好不好

缺陷属性

属性	描述
类型	自然属性划分缺陷种类
严重程度	故障的影响程度，各公司标准略不同(影响、功能)
优先级	被修复的紧急程度(正向>反向)(对测试工作的影响程度)
状态	跟踪修复过程的进展情况,处理结果
起源	第一次被检测到的阶段 (软件生命周期，包括用户使用)
来源	起因(直接原因，需求、代码)
根源	总结中关注，错误的根本因素(测试策略、过程工具方法、团队、缺乏组织和通讯、硬件、软件、工作环境)

过程	缺陷	举例
需求分析、设计阶段	文档缺陷	用户注册、使用手册
集成测试	接口缺陷	分享，荣耀微信登录
系统测试	功能和界面缺陷	登录功能，界面缺失
验收测试	性能缺陷	时间缓慢，卡顿
实施过程	可能遇到软件包	安装包错误，sql server

严重程度	描述
致命性	任何一个功能完全丧失、系统崩溃、悬挂、死机
严重	主要功能部分丧失、数据不保存
一般	次要功能没有完全实现，不影响正常使用；
较小	不影响功能操作和执行，错别字、排列不整齐

修复优先级	描述
立即P1	基本功能缺陷；对测试影响大；eg无法登录，后续无法进行；404页面；样式丢失；数据错误
高优先P2	缺陷严重：功能错误，有临时解决方案；
正常排队P3	新版本发布之前完成修复：兼容、文案、UI错误、文字
低优先级P4	开发有时间再修改，或者下个迭代优化
软件的备选流、基本功能测试中的反向测试，优先级较低，甚至有些可改可不改。
缺陷严重程度和修复优先级关系(身高和体重)：
1）没有任何直接关系。严重程度——软件影响；修复优先级——测试工作的影响。
2）不要认为严重缺陷，修复优先级高；帮助按钮，闪退——严重程度很高，优先级很低；企业logo错误，不影响功能，必须优先修复。
3）二者都高，也只是偶然；
提交缺陷，能否夸大和低估缺陷严重程度或者优先级。
不能，不能搞“狼来了”；也不能私人关系帮助好友减少不良影响；测试人员需公平公正，客观

缺陷状态(处理进度)	描述
激活或打开(新建)	测试人员标注
确认	一般测试主管确认新提交的缺陷是一个真实有效的缺陷，经确认后，有效缺陷指派给相关人员进行处理
已解决	在缺陷被修复后，一般由开发人员进行
已关闭	缺陷被修复后，测试人员验证后，没有问题
重新打开reopen	经测试人员验证，缺陷没有修复成功，需重新打开进行再次处理
保留	缺陷暂时不可修复，一般由开发设定 ，测试人员确认
偶现	开发按照缺陷复现步骤不能再次发现缺陷。一般闪退、崩溃具有类似特征；操作系统差异，浏览器缓存出现的问题。测试人员，提交bug之前，再三确认
重复	测试避免和其他测试人员重复。尤其在软件的某一个模块(不同测试人员)频繁被多个模块调用情况下
否决bug	避免被开发标注缺陷状态不是bug
已测试待上线	测试人员确认后，等待线上回归后再关闭

缺陷生命周期

 发现缺陷(测试)
 提交缺陷(测试)
 确认缺陷(产品经理)
 分配缺陷(确认的进行分配：开发、UI、产品经理)
 修复缺陷(开发、产品经理)
 验证缺陷(测试)
 关闭缺陷(只能测试，否则出了问题，与测试人员无关)
 针对工作中的bug,bug的处理过程。(缺陷生命周期，谁干)

缺陷识别，灵活对待

 1）需求文档、设计文档、产品原型、测试用例——客观依据
 2）同行业类似成熟软件、与开发沟通、有经验的前辈沟通，同行业隐式需求——带有主观色彩依据

缺陷报告

目的：

 展现缺陷的详细信息；展现缺陷的影响程度和方式(读者：开发、质量管理、市场、运维)；缺陷报告直白、清晰、不进行主观臆断

模板

 1)缺陷编号。bug_项目名_模块名_功能名_0001
 2)所属迭代、模块。
 3)优先级。缺陷修复紧急程度。P1>P2>P3>P4
 4)严重程度。S1>S2>S3>S4
 5)缺陷概述。一句话描述缺陷基本情况(时间、地点、事件(目前的错误实现))
 6)将缺陷的复现步骤(可以再现)、测试环境、预期结果、实际结果
 7)提交人、经办人(开发、产品、设计)
 8)备注(bug截图、录屏)

缺陷跟踪系统

 禅道、Jira

测试bug原因分类

 影响点未评估到；测试人员未评估；测试用例评审过程中开发和产品也未评估到；
 测试遗漏：有测试用例，测试人员遗漏；无测试用例，需要补充；
 测试错误：操作路径或场景错误；测试理解错误；发版问题；
 性能问题；
 兼容性问题；
 偶现bug；
 运维发版错误：运维人员的操作影响；
 改bug引起：改动一方面影响了另外的功能；
 旧有问题：之前旧有的bug;新的引用的旧有的产生的问题；
 需求优化/变更：优化或产品变更(被动需求或主动优化)
 特殊场景：特定场景下
 其他业务线的影响

原则

1>问题描述清晰，有复现路径、预期结果、实际结果
2>一个bug只能描述一个问题
3>按照优先级解决
4>bug有异议时，需要测试、开发和产品共同商议
5>仅测试人员有权限关闭bug
6>注明测试环境和测试账号