通用软件测试技术之缺陷

1. 缺陷的定义

• 软件未实现产品说明书中要求的功能；
• 软件未实现产品说明书中未明确提及但应该实现的目标；
• 软件实现了产品说明书中未提到的功能；
• 软件出现了产品说明书中指明不应该出现的功能。
• 软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户会认为不好

2. 缺陷的属性

缺陷属性	描述
缺陷类型（type）	缺陷类型是根据缺陷的自然属性划分的缺陷种类
缺陷严重程度（Severity）	缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度
缺陷优先级（Priority）	缺陷的优先级指缺陷必须被修复的紧急程度
缺陷状态（Status）	缺陷状态指缺陷通过一个跟踪修复过程的进展情况
缺陷起源（Origin）	缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段
缺陷来源（Source）	缺陷来源指缺陷的起因
缺陷根源（Root Cause）	缺陷根源指发生错误的根本因素

3. 缺陷类型

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

缺陷类型	描述
功能	影响了各种系统功能、逻辑的缺项
用户界面	影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷
文档	影响发布和维护，包括注释、用户手册、设计文档
软件包	由于软件配置库、变更管理或版本控制引起的错误
性能	不满足系统可测量的属性值，如执行时间、事务处理速率等
系统/模块接口	与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突

功能（Function）、界面（UI）、文档（Documentation）、软件包（Package）、性能（Performance）、接口（Interface）

注意：需求分析、设计阶段，文档类型的缺陷多；

集成测试阶段，一般接口类型的缺陷多一点；

系统测试阶段，功能、界面类型的缺陷多一些；

验收测试阶段，更多的关注性能缺陷；

实施过程，可能会遇到一些软件包的缺陷。

4. 缺陷严重程度

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

缺陷严重等级	描述
致命（Fatal）	系统任何一个主要功能完全丧失，用户数据收到破坏，系统奔溃、悬挂、死机，或者危机人身安全
严重（Critical）	系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响
一般（Major）	系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题
较小（Minor）	是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题

5. 缺陷优先级

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

缺陷优先级	描述
立即解决（P1级）	缺陷导致系统几乎不能使用或测试不能继续，需立即修复
高优先级（P2级）	缺陷严重，影响测试，需要优先考虑
正常排队（P3级）	缺陷需要正常排队等待修复
低优先级（P4级）	缺陷可以在开发人员有时间的时候被纠正

缺陷的严重程度和优先级有什么联系？

1. 没有任何的直接联系

严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。

优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

2. 缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

6. 缺陷状态

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

缺陷状态	描述
激活或打开	问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷
已修正或修复	已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证
关闭或非激活	测试人员验证后，确认缺陷不存在之后的状态
重新打开	测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复
推迟	这个软件缺陷可以在下一个版本中解决
保留	由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷
不能重现	开发不能再现这个软件缺陷，需要测试人员检查缺陷复现的步骤。例如：闪退，奔溃
需要更多信息	开发能再现这个软件缺陷，但开发人员需要一些信息，例如切线的日志文件、图片等
重复	这个缺陷已经被其他测试人员发现
不是缺陷	这个问题不是软件缺陷
需要修改软件规格说明书	由于软件规格说明书对软件设计的要求，必须要修改软件规格说明书

7. 缺陷起源

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

缺陷来源	描述
需求说明书	需求说明书的错误或不清楚引起的问题
设计文档	设计文档描述不准确，和需求说明书不一致的问题
系统集成接口	系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷
数据流（库）	是编码中的问题所引起的缺陷

8. 缺陷根源

缺陷根源指发生错误的根本因素

缺陷根源	描述
测试策略	错误的测试范围，误解了测试目标，超越测试能力等
过程，工具和方法	无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等
团队/人	项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等
缺乏组织和通讯	缺乏用户参与，职责不明确，管理失败等
硬件	硬件配置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫的问题等
工作环境	组织机构调整，预算改变，工作环境恶劣，如噪音过大

9. 缺陷的生命周期

——每个公司、每一个工具对bug生命周期的定义都是不一致的，下面仅是一个常见的例子：

测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。

10. 缺陷的生命周期

• 发现缺陷：由测试人员。开发也能知道自己哪里写错了，但是不会广而告之。
• 提交缺陷：由测试人员。开发更不可能提交bug。
• 确认缺陷：一般由测试主管、或者质量保证（QA）、由产品经理进行确认。
• 分配缺陷：经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、也可能是UI、也可能是产品经理。
• 修复缺陷：主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题。
• 验证缺陷：测试去验证缺陷有没有修复成功。
• 关闭缺陷：只能是测试人员进行。否则出了问题，测试人员一律不背锅。

状态	描述
New	新建
Open	打开
Assign	指派
Test	测试
Verified	确认
Deferred	延期
Reopened	重新打开
Duplicate	重复
Rejected	拒绝
Closed	关闭

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

10. 缺陷的识别

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

缺陷的识别

依据

需求文档、设计文档、产品原型、测试用例，都是客观的依据。

同行业的类似成熟软件，和开发人员沟通，跟有经验的测试人员沟通，同行业隐形需求，都是带有主观色彩的依据。

测试人员在识别缺陷的时候，要很灵活的对待。

11. 报告模板

1.编写目的和预期读者

1. 缺陷报告编写目的

• 易于搜索软件测试报告的缺陷
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确
• 软件开发人员希望获得缺陷的本质特征和复现步骤
• 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度

2. 预期读者

• 开发人员、质量管理人员、市场人员、运维人员·······

2. 报告编写准则

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

3. 缺陷描述准则

• 单一准确
• 可以再现
• 完整统一
• 短小简练
• 特定条件
• 补充完善
• 不做评价

4. 缺陷管理方式和模版

缺陷编号	所属模块	优先级	严重程度	缺陷概述	缺陷描述	提交人	备注
Bug_OA_CJGL_ZZJG_0001	一级模块/二级模块	P1/P2/P3/P4	S1/S2/S3/S4	一句话描述（时间、地点、人物、事件）	复现步骤、实际结果、预期结果	XXX	特殊条件、产生该缺陷的测试用例编号

注意：

缺陷报告模板

• 缺陷编号：Bug_项目名称 _功能名称 _0001。
• 所属模块：一级模块/二级模块/三级模块。例如：上课所用的直播软件，如果想要查看签到历史记录，需要进入直播界面——互动应用——签到——签到历史记录。
• 优先级：缺陷的修复紧急程度。P1>P2>P3>P4。
• 严重程度：S1>S2>S3>S4。
• 缺陷概述：用一句话描述缺陷的基本情况。
• 缺陷的描述：缺陷的复现步骤、预期结果和实际结果列出来。
• 提交人：是谁就写谁的名
• 备注：一般写产生该缺陷的特殊情况。将bug的截图作为备注信息。

缺陷报告的编写目的

1. 展现缺陷的详细信息

2. 展现缺陷的影响程度和方式

由于缺陷报告的读者很多：开发、质量管理、市场人员、运维人员，所以缺陷报告要写的很直白、清晰、明了。

报告编写的准则：准确、清晰、一致、简洁、完整。

缺陷描述的规则：

可以再现。针对绝大多数的缺陷都是如此。但是有一些小部分的缺陷是难以做到（类似闪退、崩溃这种不可再现缺陷，无需做的。针对一些可以重复出现的闪退缺陷，也要进行步骤的详细描述）

不做评价。不对缺陷的出现的严重程度和缺陷表现出来的效果进行主观臆断。

缺陷报告本身要保证没有任何表述性的错误。

测试需求和测试用例、缺陷报告的关系？

测试的基本流程：获取测试需求——编写测试计划——制定测试方案——设计和开发测试用例——执行测试——提交缺陷——测试分析和评审——测试总结——准备下一版本的测试。

获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。例如：

1. 分析出系统的模块和组织结构

2. 分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用。

3. 识别出软件的重要功能和次要功能。获取测试需求的过程中，测试人员就要有相应的分析成果。一般用Xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。

设定测试中需求的正、反向，和优先级。

当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计。也就是，每一个需求点，都要被测试。

因此测试的过程中，衡量需求的覆盖程度，就非常的重要。使用： 需求的覆盖程度=被测试用例覆盖的需求数/需求点总数 进行计算和说明。

如果需求覆盖度<100%,那一定说明了测试的覆盖度不够。

测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。

1. 设计的测试用例总量 TC。

2. 自信的测试用例数量 EC。

3. 为执行的测试用例数量 WC。

4. 执行通过的测试用例总量 SC。

5. 执行失败的测试用例总量 FC。

6. 提交的缺陷的总量 BC（Bug Counts）。

以上几个数据，他们要符合如下的数量关系。
  
    1. TC大于等于EC。
  
    2. TC=EC+WC。
  
    3. EC=SC+FC。
  
    4. BC大于等于FC。提交的bug数量，多于执行未通过的用例数。一条用例的预期结果数量是固定（甚至是唯一的）。说明了，测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分应该是测试人员自身经验和直觉（其他知识）带来的。
  
    5. 通过 SC/EC 可以表现出系统的质量是否合格。
  
    6. 通过 EC/TC 可以表现出系统的需求是否得到满足。