一、缺陷的基本概述
缺陷的定义【非常重要】
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指出不应该出现的功能
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提及但应该实现的目标
- 软件难以理解、不易使用、运行缓慢（从测试角度看）最终用户会认为不好
缺陷的属性
- 缺陷类型：根据缺陷的自然属性划分的缺陷种类
- 缺陷严重程度：因缺陷引起的故障对软件产品的影响程度
- 缺陷优先级：缺陷必须被修复的紧急程度
- 缺陷状态：缺陷通过一个跟踪修复过程的进展情况
- 缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段
- 缺陷来源：缺陷的起因
- 缺陷根源：发生错误的根本因素
缺陷类型
- 一般在需求分析、设计阶段、文档类型的缺陷多；集成测试阶段，一般接口类缺陷多一些；系统测试阶段，功能、界面类型的缺陷多一些；验收测试阶段，更多的关注性能缺陷；实施过程，可能会遇到一些软件包的缺陷
缺陷的严重程度
- 注意：结合缺陷的影响，结合软件的具体功能（业务或者流程）
缺陷的修复优先级
- 优先级很大程度上取决于缺陷对测试工作的影响程度
- 优先级衡量：一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决；软件的备选流、基本功能测试中的反向测试内容，优先级较低，甚至有些可改可不改
面试题目：缺陷的严重程度和缺陷的优先级之间有什么关系？
- 二者之间没有任何直接关系
- 不要认为严重的缺陷修复优先级就高
- 如果碰到优先级和严重程度都高的缺陷，也只是偶然
面试题目：提交缺陷时能不能夸大或降低缺陷的严重程度或优先级
- 答：作为测试人员必须做到公平公正
缺陷的状态
缺陷的起源
缺陷的来源
缺陷的根源
二、缺陷的生命周期
- 发现缺陷：由测试人员自己发现
- 提交缺陷：由测试人员提交
- 确认缺陷：一般由测试主管，或者质量保证（QA）、或者是产品经理进行确认
- 分配缺陷：经确认后，有效的缺陷会指派给相关人员进行处理，一般由谁确认的去缺陷，就由谁分配；分配的对象可能是开发、也可能是UI、也可能是产品经理
- 修复缺陷：主要由开发完成，也有可能是产品经理修复问题，也有可能是UI修复问题
- 验证缺陷：测试人员验证缺陷有没有修复成功
- 关闭缺陷：只能是测试人员进行，否则出了问题测试人员一律不背锅
面试问题：针对你工作中发现的一个bug，说说这个bug的处理过程（缺陷的生命周期中，每一个环节由谁做什么？）
三、缺陷的识别
识别依据
客观依据：需求文档、设计文档、产品原型、测试用例都是客观的依据；
主观依据：同行业的类似成熟软件；和开发人员沟通；跟有经验的测试人员沟通；同行业隐式需求
测试人员在识别缺陷的时候，需要很灵活的对待
- 通过测试用例中的预期结果进行识别
- 通过需求规格说明书进行识别
- 通过用户手册以及其他文档进行识别
- 通过同行业类似成熟的商业软件来识别
- 通过和开发人员的沟通进行识别
- 通过和有经验的测试人员沟通进行识别
- 参照同行业隐式需求进行识别
四、缺陷报告
缺陷报告模板
缺陷报告要写的通俗易懂，让别人容易读懂和理解
缺陷报告编写目的【展现缺陷的详细信息、展现缺陷的影响程度和方式】
- 易于搜索软件测试报告的缺陷
- 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确
- 软件开发人员希望获得缺陷的本质特征和复现步骤
- 市场和技术等部门希望获得缺陷类型分布以及对市场和用户的影响程度
预期读者
- 开发人员、质量管理人员、市场人员、运维人员
缺陷报告编写准则
- Correct（准确）：每个组成部分的描述准确、不会引起误解
- Clear（清晰）：每个组成部分描述清晰，易于理解
- Concise（简洁）：只包含必不可少的信息、不包括多余的内容
- Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息
- Consistent（一致）：按照一致的格式书写全部缺陷报告
缺陷描述的准则
- 单一准确
- 可以再现【针对绝大多数缺陷都是如此，但是有小部分缺陷是难以做到的（类似闪退、崩溃、不可再现的缺陷，无需做到）】
- 完整统一
- 短小简练
- 特定条件
- 补充完善
- 不做评价【不对缺陷的出现的严重程度和缺陷表现出来的效果进行主观臆断】
缺陷跟踪系统
- Bugzilla（英文），安装比较繁琐
- Bugfree 中文，安装简单、用例 缺陷的跟踪 功能单一
- 禅道 中文，国产 项目 产品 测试齐全 组织机构 人员 开源 免费
- QC （ALM）外国 英文 功能齐全
- JIRA 国外的软件 JAVA环境 主流（商业）
- 企业自己开发
测试需求和测试用例、缺陷报告的关系
- 测试基本流程：获取测试需求----编写测试计划----制定测试方案----设计和开发测试用例----执行测试----提交缺陷----测试分析和评审----测试总结----准备下一版本的测试
- 获取测试需求是测试工作的重点，也是第一步，通过需求的分析，了解和掌握测试的方向和内容。例如：1、分析出系统的模块和组织结构；2、分析出软件的基本功能和运行流程，包括可能会有哪些人或者哪些角度要用；3、识别出软件的重要功能和次要功能
- 获取测试需求的过程中，测试人员就要有相应的分析成果；一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析
- 当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计。也就是每一个需求点，都要被测试，因此，衡量需求的覆盖程度【使用被测试用例覆盖的需求数/需求点总数】就非常重要，如果需求覆盖度小于100%，那一定说明测试的覆盖度不够
测试中，最能体现测试工作人员的指标就是缺陷的数量和测试用例的数量
- 设计的测试用例总量 TC
- 执行的测试用例数量 EC
- 未执行的测试用例数量 WC
- 执行通过的测试用例总量 SC
- 执行失败的测试用例总量 FC
- 提交的缺陷的总量 BC
这五个数据要符合下面的数量关系 - TC>=EC
- TC=EC+WC
- EC=SC+FC
- BC>=FC 提交的bug数量多于执行未通过的用例数。一条用例的预期结果数量是固定（甚至是唯一的）。测试中发现的缺陷，除一部分是用例执行失败带来的，还有一部分是测试人员自身的经验和直觉带来的
- 通过SC/EC可以体现出系统的质量是否合格
- 通过EC/TC可以体现出系统的需求是否得到满足