05-缺陷管理

缺陷管理

什么是缺陷

• 软件中任何不满足用户需求的问题，都可以识别为软件缺陷。
• 从产品内部看，缺陷是产品开发或维护中存在的错误，异常等问题。
• 从产品外部看，缺陷是违背了某种功能的实现。

缺陷识别方法 

• 用户体验差，进行反馈
• 界面上有明显错误信息
• 功能缺失，与需求说明书不符
• 程序运行崩溃，停止运行程序
• 逻辑不正确，与用户使用手册不符
• 程序性能差，不能够承载压力访问

与专业人员沟通识别缺陷，注意不得站在自己主观意识去判断缺陷

缺陷出现的原因

• 需求不断变化
• 工期短，软件复杂
• 编码中出错
• 设计文档不完善
• 沟通交流少
• 软硬件不支持

常见软件缺陷术语

• bug：泛指软件程序的漏洞和缺陷。
• Debug：调试是发现和减少计算机程序或电子仪器设备中程序错误的一个过程。
• 错误(mistake)：人为造成软件的故障
• 缺陷(bug&defect)：软件产品中存在的错误
• 故障(Fault)：某个组件功能不能完成所有任务的一个意外情况
• 失效(Failure)：软件功能完全损坏，无法使用

为什么引入缺陷

缺陷的类型

功能遗漏

规定的时间或功能未在产品系统中体现出来，如缺少忘记密码功能

程序错误

没有按照用户需求正确实现，可能需求理解出错，可能编码出错

额外的功能

出现了需求以外的功能

尽早引入测试

尽早引入测试，可以更早的发现缺陷，减少修复成本

缺陷的重现

• 可以重现的缺陷，存在一系列明确的重现操作步骤，条件和数据使得缺陷可以稳定的反复出现。
• 不可复现的缺陷，无法找到明确的步骤，缺陷出现是随机的，只做记录，不做报告。
• 不可重现的缺陷，后续再深入的挖掘，尝试转为可再现的缺陷，再进行缺陷报告。

缺陷报告

缺陷报告指的是测试执行过程中，发现软件缺陷，进行书写记录的文档，提供给开发人员或者测试负责人作为定位缺陷的依据，也用作缺陷数量统计的重要依据。提供准确、完整、简洁的缺陷报告是软件测试专业性、高质量的评价标准。

撰写缺陷报告5C原则

5c原则

• Correct(准确)：每个组成部分的描述准确，不会引起误解
• Clear(清晰)：每个组成部分的描述清晰，易于理解
• Concise(简洁)：只包含必不可少的信息，不包括任何多余的内容
• Complete(完整)：包含复现该缺陷的完整步骤和其他本质信息
• Consistent(一致)：按照一致的格式书写全部缺陷报告

缺陷报告结构

• 报告的缺陷信息具体、准确
• 缺陷特征描述与复现缺陷步骤
• 缺陷类型以及严重级别
• 缺陷标题
• 缺陷基本信息
• 测试环境描述
• 缺陷严重程度

撰写缺陷报告注意点

• 按照缺陷发生的因、果进行书写
• 避免模糊不清的词语，比如功能不对、登录不起作用，应该具体描述某一个功能如何不对、 登录具体流程如何不正确
• 中立评价，公正表达自己对软件缺陷的理解，对软件错误以及造成的事实进行描述

常见软件缺陷 

bug学习目标

• bug类型
• bug等级
• bug生命周期

bug是什么 

bug泛指软件程序的漏洞和缺陷。bug是测试工程师或用户发现与提出的，软件可以改进的细节部分、或者与需求文档存在功能偏差的实现。测试工程师职责就是发现bug，提交bug信息给研发人员，研发人员修复bug。

bug案例 

例如登录时，要求输入账号密码。输入正确的账号密码后，结果提示：用户名/密码不存在，再三确认账号密码是否错误，并重新再注册一个账号进行登录，此时新账号也是账号不存在，此登录已经是bug了!

bug的类型 

想要确定bug的类型，就需要对产品有较深的理解。
禅道系统中对bug定义划分如下：

• 代码错误(指的是研发代码有误，功能未实现)
• 设计缺陷
• 界面优化
• 性能问题
• 配置相关
• 安装部署
• 安全相关
• 标准规范
• 测试脚本
• 其他(功能类、界面类、性能类、易用性类、兼容性类、其他)

bug严重程度 

顾名思义就是软件缺陷对软件质量造成的破坏程度，将会给软件的使用带来怎样的影响。
Bug等级越高，可能被修复的等级也越高，公司也会根据测试提交的bug数量以及bug等级作为绩效考核标准。
判断bug的等级，如下分类:

1、致命错误

• 常规操作却引起系统崩溃、死机、死循环
• 造成数据库泄露的安全问题，如恶意攻击造成的账户私密信息泄露
• 涉及金钱隐患，金钱计算bug(如金额不足，还可以购买产品，对公司金额造成重大损失）

2、严重错误

• 重要功能未实现，如点击注册无反应，无法登录
• 非常规操作(误操作)导致程序崩溃、死机、死循环
• UI界面的严重问题
• 密码明文显示，数据库泄露

3、普通错误

• 不影响产品运行，不会影响故障，但对产品外观界面影响较大，如删除了好友，好友却未消失
• 功能无法正常使用
• 操作界面错乱
• 查询数据错误
• 页面未做输入格式限制
• 删除错误未给与提示.

4、错误提示

• 网页UI错误
• 错别字
• 标点符号

bug处理优先级

优先级(Priority)指的是缺陷被修复的紧急程度。

• 立即解决：软件缺陷已导致软件系统崩溃，需立即修复
• 高优先级：缺陷比较严重，已经影响用户正常使用
• 普通优先级：缺陷排队，等待修复
• 低优先级：等待开发人员闲时进行修复，缺陷影响很小

常见bug管理状态

在不同的缺陷管理系统中，对bug的标记状态有如下种类:

• New：缺陷初始状态
• Open：缺陷修复中
• Fixed：缺陷修复完毕
• Closed：缺陷已通过回归测试，关闭缺陷
• Reopen：缺陷未通过回归测试，重新修复
• Postpone：推迟修改缺陷
• Rejected：开发拒绝修复缺陷
• Duplicate：重复提交的缺陷
• Abandon：开发与测试经过讨论，确定不是缺陷，可以标记缺陷关闭

bug生命周期图

缺陷跟踪管理系统

早期缺陷管理大多是以缺陷记录表单形式完成，如今也有很多项目使用此方法，但是随着用户需求提升，软件复杂度提升，缺陷缺陷也随之增长，管理也就愈加麻烦。

软件行业发展，出现大量缺陷管理系统：

• JIRA
• BUGZILLA
• HP Quality Center (QA)
• 禅道
• Coding

实力雄厚的公司还会自研缺陷跟踪管理系统，大部分公司则是选择禅道来缺陷跟踪以及项目管理。

测试执行系统

执行测试的主要任务：

• 确定测试用例的优先级
• 创建测试数据，准备测试工具以及编写自动化测试脚本
• 根据测试流程创建测试套件，提升测试执行效率
• 搭建测试环境
• 根据测试计划的执行顺序，通过功能或是代码进行测试
• 记录测试结果，编写测试报告
• 将测试结果和预期结果进行比较，将结果的差异提交上报，分析差异原因
• 缺陷修复后，进行回归测试，验证产品

测试准入标准 

1、没有经过自测的代码，就是在耍流氓
2、通过冒烟测试
3、测试范围已明确

• 开发编码结束，并且在开发环境完成单元测试
• 开发需求规定的功能均实现，如没有完全实现，请提供测试范围
• 已经完成集成测试，被测系统的基本流程已经走通，界面上功能均实现，经过代码评审并符合软件编码规范
• 开发提交最新版本代码，告知测试组进行测试
• 测试环境兼容性确认
• 安全测试与性能测试的要求确认

测试停止

• 测试人员首次冒烟测试，若是发现重大缺陷或缺陷过多，导致测试卡壳基本流程无法进行，可以暂停测试回馈开发。
• 被测项目由于需求调整，被迫暂停测试
• 存在更高级的测试任务，需要暂停测试
• 被测系统达到系统准出标准，测试流程结束，可以停止测试 

测试准出标准