缺陷管理
什么是缺陷
- 软件中任何不满足用户需求的问题，都可以识别为软件缺陷。
- 从产品内部看，缺陷是产品开发或维护中存在的错误，异常等问题。
- 从产品外部看，缺陷是违背了某种功能的实现。
缺陷识别方法
- 用户体验差，进行反馈
- 界面上有明显错误信息
- 功能缺失，与需求说明书不符
- 程序运行崩溃，停止运行
- 程序逻辑不正确，与用户使用手册不符
- 程序性能差，不能够承载压力访问
- 与专业人员来沟通识别缺陷
注意不得站在自己主观意识去判断缺陷
缺陷出现的原因：
- 需求不断变化
- 工期短，软件复杂
- 编码中出错
- 设计文档不完善
- 沟通交流少
- 软硬件不支持
常见软件缺陷术语
- bug 泛指软件程序的漏洞和缺陷。
- Debug 调试（英语：Debug）是发现和减少计算机程序或电子仪器设备中程序错误的一个过程。
- 错误(mistake) 人为造成软件的故障
- 缺陷(bug&defect) 软件产品中存在的错误
- 故障(Fault) 某个组件功能不能完成所有任务的一个意外情况
- 失效(Failure) 软件功能完全损坏，无法使用
为什么引入缺陷
缺陷的类型
功能遗漏：规定的时间或功能未在产品系统中体验，如缺少忘记密码功能
程序错误没有按照用户需求正确实现，可能需求理解出错，可能编码出错
额外的功能
尽早引入测试
单位时间内，尽早引入测试，可以更早的发现缺陷，减少修复成本
缺陷的重现
可以重现的缺陷，存在一系列明确的重现操作步骤，条件和数据使得缺陷可以稳定的反复出现。
不可复现的缺陷，无法找到明确的步骤，缺陷出现是随机的，只做记录，不做报告。
不可重现的缺陷，后续再深入的挖掘，尝试转为可再现的缺陷，再进行缺陷报告。
缺陷报告
缺陷报告指的是测试执行过程中，发现软件缺陷，进行书写记录的文档，提供给开发人员或者测试负责人作为定位缺陷的依据，也用作缺陷数量统计的重要依据。
提供准确、完整、简洁的缺陷报告是软件测试专业性、高质量的评价标准
撰写缺陷报告5c原则
- Correct（准确）：每个组成部分的描述准确，不会引起误解；
- Clear（清晰）：每个组成部分的描述清晰，易于理解；
- Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
- Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
- Consistent（一致）：按照一致的格式书写全部缺陷报告。
缺陷报告结构
- 报告的缺陷信息具体、准确
- 缺陷特征描述与复现缺陷步骤
- 缺陷类型以及严重级别
- 缺陷标题
- 缺陷基本信息
- 测试环境描述
- 缺陷严重程度
撰写缺陷报告注意点
- 按照缺陷发生的因、果进行书写
- 避免模糊不清的词语，比如
功能不对、登录不起作用，应该具体描述某一个功能如何不对、登录具体流程如何不正确 - 中立评价，公正表达自己对软件缺陷的理解，对软件错误以及造成的事实进行描述
常见软件缺陷
| 编号 | 问题描述 |
|---|---|
| 中文英统一 | 不要使用中英文混合提示，不要去挑战用户的英文能力.. |
| 容错性 | 例如用户注册，需要限制手机号长度，年龄范围等，输入错误需要有醒目提示 |
| 用户体验 | 比如某高校学生信息登记网，填写一堆信息后，由于一个信息填写错误，内容全部被清空，还得重新输入，用户体验极差 |
| 兼容性 | 需要考虑操作系统、浏览器类型、版本，网络类型 |
| 错别字 | 例如网站的”登录”写成”登陆” |
| 安全性 | 注意SQL注入，XSS攻击 |
| UI友好度 | 比如删除、保存按钮离得太近，用户手指头难以正确点击… |
| ….. | 未完待续 |
 |
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）
- 禅道（中文、优秀！）
实力雄厚的公司还会自研缺陷跟踪管理系统，大部分公司则是选择禅道来缺陷跟踪以及项目管理。
测试执行过程
执行测试的主要任务
- 确定测试用例的优先级
- 创建测试数据，准备测试工具以及编写自动化测试脚本
- 根据测试流程创建测试套件，提升测试执行效率
- 搭建测试环境
- 根据测试计划的执行顺序，通过功能测试或是代码测试
- 记录测试结果，编写测试报告
- 将测试结果和预期结果进行比较，将结果的差异提交上报，分析差异原因
- 缺陷修复后，进行回归测试，验证产品
测试准入标准
没有经过自测的代码，就是在耍流氓
通过冒烟测试
测试范围已明确
- 开发编码结束，并且在开发环境完成单元测试
- 开发需求规定的功能均实现，如没有完全实现，请提供测试范围
- 已经完成集成测试，被测系统的基本流程已经走通，界面上功能均实现，经过代码评审并符合软件编码规范
- 开发提交最新版本代码，告知测试组进行测试
- 测试环境兼容性确认
- 安全测试与性能测试的要求确认
测试停止
- 测试人员首次冒烟测试，若是发现重大缺陷或缺陷过多，导致测试卡壳基本流程无法进行，可以暂停测试回馈开发。
- 被测项目由于需求调整，被迫暂停测试
- 存在更高级的测试任务，需要暂停测试
- 被测系统达到系统准出标准，测试流程结束，可以停止测试
测试准出标准
| 序号 准出标准 | 是 | 否 | 时间 |
|---|---|---|---|
| 1 | 北侧项目是否满足需求原型？ | ||
| 2 | 所有测试用例是否通过评审 | ||
| 3 | 所有测试用例都已执行 | ||
| 4 | 测试覆盖率是否100％ | ||
| 5 | 所有发现的软件缺陷是否记录在缺陷管理系统（禅道）？ | ||
| 6 | 一二级缺陷修复率是否100% | ||
| 7 | 三四级缺陷修复率是否95%？ | ||
| 8 | 所有遗留问题是否有解决方案？ | ||
| 9 | 性能指标是否达标？ | ||
| 10 | 兼容测试是否达标？ | ||
| 11 | 安全性测试是否达标? | ||
| 12 | 是否填写测试总结报告？ |