缺陷管理

什么是缺陷

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

缺陷识别方法

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

注意不得站在自己主观意识去判断缺陷

缺陷出现的原因：

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

常见软件缺陷术语

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

为什么引入缺陷

缺陷的类型

功能遗漏：规定的时间或功能未在产品系统中体验，如缺少忘记密码功能

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

额外的功能

尽早引入测试

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

缺陷的重现

可以重现的缺陷，存在一系列明确的重现操作步骤，条件和数据使得缺陷可以稳定的反复出现。

不可复现的缺陷，无法找到明确的步骤，缺陷出现是随机的，只做记录，不做报告。

不可重现的缺陷，后续再深入的挖掘，尝试转为可再现的缺陷，再进行缺陷报告。

缺陷报告

缺陷报告指的是测试执行过程中，发现软件缺陷，进行书写记录的文档，提供给开发人员或者测试负责人作为定位缺陷的依据，也用作缺陷数量统计的重要依据。

提供准确、完整、简洁的缺陷报告是软件测试专业性、高质量的评价标准

撰写缺陷报告5c原则

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

缺陷报告结构

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

撰写缺陷报告注意点

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

常见软件缺陷

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）
• 禅道（中文、优秀！）

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

测试执行过程

执行测试的主要任务

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

测试准入标准

没有经过自测的代码，就是在耍流氓

通过冒烟测试

测试范围已明确

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

测试停止

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

测试准出标准

原文：https://www.cnblogs.com/Neroi/p/13159502.html