1.缺陷的基本概念

1.1.缺陷的定义

1. 软件未实现产品说明书要求的功能
2. 软件出现了产品说明书指明不应该出现的功能
3. 软件实现了产品说明书未提到的功能
4. 软件未实现产品说明书虽未明确提及但应该实现的目标
5. 软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好

1.2.缺陷的属性

1.3.缺陷的类型

缺陷类型是根据缺陷的自然属性划分的缺陷种类

需求分析、设计阶段，文档类型缺陷多
集成测试阶段，一般接口类型缺陷多
系统测试阶段，功能、界面类型缺陷多
验收测试阶段，更多关注性能缺陷
实施过程，遇到一些软件包的缺陷

1.4.缺陷的严重程度

缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度

1.5.缺陷修复优先级

缺陷的优先级指缺陷必须被修复的紧急程度

优先级衡量小技巧：一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决，软件的备选项，基本功能测试中的反向测试功能，优先级较低，甚至有些可改可不改
问题：缺陷的严重程度和缺陷修复优先级有什么关系？

二者没有任何关系
不要认为严重的缺陷，修复优先级就高
如果碰到，优先级和严重程度都高的缺陷，一般较少遇见。比如，QQ的帮助按钮，会经常闪退，严重程度很高，但优先级低；企业logo错误，不影响任何功能，但必须优先修复

问题：提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级

不能，也不能因为私人关系减少错误报告

1.6.缺陷的状态

缺陷状态指缺陷通过一个跟踪修复过程的进展情况

1.7.缺陷起源

缺陷起源指缺陷引起的故障或事件第一个被检测到的阶段

1.8.缺陷来源

缺陷来源指缺陷的起因

1.9.缺陷根源

起源、来源、根源，一般关注较多的是缺陷的来源（直接原因），在测试总结的时候，关注缺陷的根源。
缺陷根源指发生错误的根本因素

2.缺陷的生命周期

1. 发现缺陷
   • 测试人员进行，开发也可能知道自己哪里写错了
2. 提交缺陷
   • 测试人员进行，开发也会提交bug
3. 确认缺陷
   • 一般由测试主管、或者质量保证（QA），由产品经理进行确认
4. 分配缺陷
   • 经确认后，有效的缺陷会指派给相关人员进行处理，一般由谁确认的缺陷，就由谁分配，分配的对象可能是开发，也可能是UI，可能是产品经理
5. 修复缺陷
   • 主要由开发修复，也有可能是产品经理修复问题，也可能是UI修复问题
6. 验证缺陷
   • 测试去验证缺陷有没有修复成功，如果不成功，回到步骤2进行提交
7. 关闭缺陷
   • 只能是测试人员进行

问题：针对工作中发现的一个bug，说说这个bug的处理过程（缺陷的生命周期中每个环节由谁做什么）

3.缺陷的识别

1. 通过测试用例中的预期结果进行识别
2. 通过需求规格说明书进行识别
3. 通过用户手册及其他文档进行识别
4. 通过同行业相类似成熟的商业软件来识别
5. 通过和开发人员的沟通进行识别
6. 通过和有经验的测试人员沟通进行识别
7. 参考同行业隐式需求进行识别

4.缺陷报告

4.1.编写目的和预期读者

1. 缺陷报告编写目的
   • 易于搜索软件测试报告的缺陷
   • 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确
   • 软件开发人员希望获得缺陷的本质特征和复现步骤
   • 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度
2. 预期读者
   • 开发人员、质量管理人员、市场人员、运维人员等等
   • 由于缺陷报告的读者很多，所以缺陷报告要写的很直白，清晰明了

4.2.报告编写准则

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

缺陷编号，Bug_项目名称_模块名称_功能名称_0001
所属模块，一级模块/二级模块/三级模块
优先级，缺陷的修复紧急程度，P1>P2>P3>P4（缺陷优先级）
严重程度，S1>S2>S3>S4
缺陷概述，用一句话去描述缺陷的基本情况
缺陷描述，将缺陷的复现步骤，预期结果和实际结果列出来
提交人，写上提交人的名字
备注，一般写产生该缺陷的特殊情况，将bug截图作为备注信息

4.3.缺陷描述准则

1. 单一准则
2. 可以再现
3. 完整统一
4. 短小简练
5. 特定条件
6. 补充完善
7. 不做评价

缺陷跟踪系统

1. Bugzilla，英文，安装比较繁琐
2. Bugfree，中文，安装简单，用例缺陷的跟踪，功能单一
3. 禅道，中文，国产，项目，产品，测试，功能齐全，开源免费
4. QC（ALM），英文，功能齐全
5. JIRA，Java环境，主流（商业）
6. 企业自己开发

问题

测试需求和测试用例，缺陷报告的关系？
测试的基本流程：获取测试需求->编写测试计划->指定测试方案->设计和开发测试用例->执行测试->提交缺陷->测试分析和评审->测试总结->准备下一版本测试。
获取测试需求是测试工作的重点，也是第一步，通过需求的分析，了解和掌握测试的方向和内容。例如：分析出系统的模块和组织结构；分析出软件的基本功能和运行流程，（业务分析）包括可能会有哪些人或者哪些角色要用；识别出软件的重要功能和次要功能。
获取测试需求的过程中，测试人员就要有相应的分析成果，一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。
设定测试中需求的正、反向和优先级。
有了测试需求之后，就开始针对每一个需求点进行测试用例的设计，也就是，每一个需求点，都要被测试。
因此测试的过程中，衡量需求的覆盖程度，就非常的重要。
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数，进行计算和说明，如果需求覆盖度<100%，那一定说明了测试的覆盖度不够。
在测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量：
（1）设计的测试用例总量，TC
（2）执行的测试用例数量，EC
（3）未执行的测试用例数量，WC
（4）执行通过的测试用例总量，SC
（5）执行失败的测试用例总量，FC
（6）提交的缺陷的总量，BC
以上数据，要符合以下的数量关系：TC>=EC，TC=EC+WC，EC=SC+FC，BC>=FC（提交bug数量多于执行未通过的用例数，一条测试用例的预期结果数量固定甚至唯一，说明了，测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉带来的）。
通过SC/EC可以表现出系统的质量是否合格。
通过EC/TC可以表现出整个系统的需求是否得到满足。