【软件测试】7_测试理论 _软件缺陷管理

一、缺陷介绍

1.1 缺陷的定义

软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。

IEEE 1983 of IEEE Standard 729中对软件缺陷作了一个标准的定义：

从产品内部看： 软件缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；
从产品外部看： 软件缺陷是系统所需要实现的某种功能的失效或违背。在软件开发生命周期的后期，修复检测到的软件错误的成本较高。

软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。

1.2 缺陷的判定标准

1、软件未实现需求(规格)说明书中明确要求的功能 —少功能

2、软件出现了需求(规格)说明书中指明不应该出现的错误 —功能错误

3、软件实现的功能超出需求(规格)说明书指明的范围—多功能

4、软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求—隐性功能错误

5、软件难以理解，不易使用，运行缓慢，用户体验不好—不易使用（软件测试人员专业⻆度）

1.2.1 软件缺陷示例

1、计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。

• 软件未达到软件需求规格说明书表明的功能

2、若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。

• 软件的功能超出了软件需求规格说明书指明的范围

3、若在测试过程中发现，因为电池没电而导致了计算不正确，但软件需求规格说明书未能指出在此情况下应如何进行处理。

• 软件未达到软件需求规格说明书未指明而应该达到的目标

4、假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器停止接受输入或没有了反应。

• 软件出现了软件需求规格说明书指明不会出现的错误

5、测试人员或最终用户发现计算器某些地方不好用，比如，按键太小、显示屏在亮光下无法看清等。

• 软件测试人员认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好

1.3 缺陷产生的原因

软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：

1、需求文档
2、架构设计
3、编码实现
4、环境（硬件、软件）

1.4 软件缺陷的生命周期

1、回归测试：
①常规项⽬回归：项⽬本次发布新增2个模块，最基本要测新增模块功能及新增模块关联的旧模块。
②⾮常规项⽬（银⾏、部队、航天）：新增功能，必须全部复测。
2、回归bug：上⼀个版本发现的缺陷，开发修复完毕，在下个版本进⾏重新验证。

1.5 软件缺陷的核心内容

1.6 缺陷提交要素

1.6.1 缺陷的信息

编号	属性名称	描述
1	缺陷ID	唯一的缺陷ID，可以根据该ID追踪缺陷
2	缺陷状态	缺陷状态指缺陷通过一个跟踪修复过程的进展情况
3	缺陷标题	描述缺陷的标题
4	缺陷的严重程度	对软件产品的影响程度，分致命、较严重、严重、一般、低
5	缺陷的优先级	缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正
6	缺陷所属模块	缺陷所属的项目和模块，要能较精确的定位至模块
7	缺陷记录者	提交缺陷的人员姓名
8	缺陷提交时间	缺陷提交的时间
9	缺陷处理人	处理缺陷的处理人
10	处理结果描述	对处理结果的描述，描述处理情况和代码修改说明
11	缺陷处理时间	缺陷处理的时间
12	缺陷验证人	对被处理缺陷验证的验证人（回测者）
13	验证结果描述	对验证结果的描述（通过、不通过）
14	缺陷详细描述	缺陷的重现步骤
15	缺陷环境说明	对测试环境的描述
16	必要的附件	如涉及到附件的或错误现象的图片等。

1.6.2 缺陷的严重程度

严重等级	描述
5-Critical	系统瘫痪、异常退出、死循环、严重的计算错误等
4-VeryHigh	频繁的死机，系统大部分功能不可用
3-High	a.功能点没有实现，或不符合用户需求 b.数据丢失
2-Medium	a.影响一个相对独立的功能　 b.仅仅在特定条件上发生 c.与产品需求定义不一致 d.断断续续的出现问题
1-Low	表面性错误（如错别字）

1.6.3 缺陷的优先级

优先级别	描述
5-Urgent	最高优先级。 在这个错误影响下，系统几乎不可用。
4-VeryHigh	高优先级。 错误对这套系统的能力产生严重的影响。
3-High	中优先级。 如果这个错误存在与系统中，会制约开发和测试的活动进行，如果先前没有修复它，那么需要在发布前修复它。
2-Medium	低优先级。 不会延迟发布，但是会在以后修正这个错误。
1-Low	最低优先级。 时间和资源允许时修正。

1.6.4 缺陷类型

1、功能错误
2、 UI页面错误
3、兼容性
4、数据（数据库）
5、易用性
6、改进建议
7、架构缺陷

缺陷类型	内容说明	备注
系统缺陷	1.由于程序所引起的死机，异常退出 2.程序死循环 3.程序错误，不能执行正常工作或重要功能，使系统崩溃或资源不足	不能执行正常工作或重要功能，使系统崩溃或资源不足
数据缺陷	1.数据计算错误 2.数据约束错误 3.数据输入、输出错误	严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启不属更正方法）
数据库缺陷	1.数据库发生死锁 2.数据库的表、缺省值未加约束条件 3.数据库连接错误 4.数据库中的表有过多的空字段
接口缺陷	1.数据通信错误 2.程序接口错误	程序与程序之间要有协议和接口
功能缺陷	1.功能无法实现 2.功能实现错误	严重地影响系统要求或基本功能的实现，但有合理的办法更正（重新安装或重新启动不属更正方法）
安全性缺陷	1.用户权限无法实现 2.超时限制错误 3.访问控制错误 4.加密错误
兼容性缺陷	与需求规定配置兼容性不符合
性能缺陷	1.未达到预期的性能目标 2.性能测试中出错，导致无法继续进行测试
界面缺陷	1.操作界面错误 2.打印内容、格式错误 3.删除操作未给出提示 4.长时间操作未给出提示 5.界面不规范	操作者不方便或遇到麻烦，但不影响执行工作功能的实现
建议	1.功能建议 2.操作建议	建议性的改进要求

1.6.5 缺陷状态

编号	缺陷状态	描述
1	提交（Submited）	已提交的缺陷
2	打开（Open）	确认“提交的缺陷”，等待处理
3	拒绝（Rejected）	拒绝“提交的缺陷”，不需要修复或不是缺陷、重复缺陷、无法重现
4	修复（Resolved）	缺陷被修复
5	关闭（Closed）	确认修复的缺陷，将其关闭
6	推迟（Later）	可在以后解决，但要确定修复日期或版本

1.7 缺陷跟踪

1、新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。

• 如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开；
• 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。

2、还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。

• 对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。

二、缺陷编写

2.1 缺陷报告示例

缺陷ID	缺陷标题	缺陷状态	严重程度	优先级	所属模块	缺陷描述	附件
/	/	/	/	/	/	/	/

2.2 缺陷跟踪流程

2.3 缺陷编写规范和提交缺陷注意事项

⾯试题：发现缺陷后，首先怎么办？ --确定Bug可复现、确定是Bug。
提交时，要检查缺陷是否已存在。

三、缺陷管理工具

3.1 禅道的介绍

1、地址：https://demo.zentao.net/user-login.html

2、特点：

• 国产、免费、开源、简单、轻量级
• 三管融合(产品管理、项目管理、质量管理)

3.2 禅道使用流程

3.2.1 创建缺陷

3.2.2 关闭缺陷

3.3 Jira

JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域

四、缺陷统计（管理层做）

1、对软件问题的功能域分布进行分析，找出系统的薄弱环节。

• 要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。
• 二八定理：80%的软件问题总是发生在大约20%的功能模块中。

2、对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集缺陷的数据。

3、应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。

4、应动态采集每个测试周期中发现的缺陷数，并有效地控制缺陷的修复率。

5、应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况。

4.1 bug统计

五、缺陷密度

基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。

可按照以下步骤来计算一个程序的缺陷密度：

• 累计开发过程中每个阶段发现的缺陷总数。
• 统计程序中新开发的和修改的代码行数。
• 计算每千行的缺陷数=1000*缺陷总数/代码行数。

例如：

• 一个29.6万行的源程序总共有145个缺陷，则缺陷密度为：
• 缺陷密度＝1000*145/296000=0.49 个／KLOC。

六、缺陷数据分析

1）缺陷数据分析关注的问题

2）缺陷数据分析的重要性

3）缺陷数据分析的数据指标

6.1 缺陷数据分析关注的问题

• 正在测试的软件哪个模块的问题最多
• 测试人员中谁报告的软件缺陷最多
• 各类缺陷所占的数量百分比分别是多少
• 开发人员能及时修复软件缺陷吗
• 开发人员一次正确修复缺陷的百分比是多少
• 正在开发的软件能否在计划的时间内正常发布

6.2 缺陷数据分析的重要性

• 统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。
• 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。
• 根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。
• 根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。

6.3 缺陷数据分析的数据指标

• 每天/周报告的新缺陷数目；
• 每天/周修复的缺陷数；
• 累计报告的缺陷数目；
• 累计修复的缺陷数；
• 不同严重性类型的缺陷数；
• 程序模块与发现的缺陷的对应关系；

七、寻找缺陷的方法

7.1 UI用户界面（UI设计师决定）

色彩：

• 色彩的搭配无序、混乱是软件图形界面设计的大忌，图形界面应尽量设计得温和些。这类缺陷主观类强，个人美感占据主动，所提交的缺陷一般严重程度不可定得太高。

例如：

• 整体页面色彩单调，无变化，仅使用一种色彩，且篇幅较大，可提交建议性的缺陷，即使是简单的界面，宁可采用无色，也不可使用鲜艳的单色，如红色，黄色、绿色等。
• 背景色与界面字体色彩相近，不能清晰区分，色彩搭配混乱、复杂，且不符合软件标准。

7.2 功能结构布局（UI设计师决定）

功能结构布局：

• 功能结构布局主要从界面的功能区域划分来考虑。相同的、类似的功能应该放在邻近的区域。

例如：

• 记录添加功能界面，添加按钮未放在醒目的位置；
• 导航功能位于界面的右则；
• 整体功能区域分布混乱；

7.3 图片（UI设计师决定）

图片：

• 图片选用不合理，与当前软件类型不符，无法正确体现当前界面功能性含义。图片不规范、不清晰。

例如：

• 图片色彩过于艳丽或黯淡，模糊不清；
• 图片变形；
• 图片不符合当前界面的主题，图片与描述性文字不符；

7.4 字体（UI设计师决定）

字体：

• 字体在软件界面中尤其重要，字体的使用要符合软件开发规范。

例如：

• 字体过大，与其他页面信息脱节，无法形成主体；
• 字体过小，无法看清楚；
• 字体不符合当前界面风格；

7.5 窗体大小（UI设计师决定）

窗体大小：

• 窗体的设计要有层次感，父窗口、子窗口应该有所区别。窗口不应该有太多空白处，功能区域充实。

例如：

• 窗口太大，功能按钮分散，间隔太大；
• 窗口太小，功能按钮过于集中，间隔太小，或控件显示不全；
• 弹出窗口未能定于屏幕居中位置；

7.6 页面大小

页面大小：

• 在B/S结构的软件系统中，当一个页面元素太多，未作精简时，在打开该页面时可能需要较长的加载时间，这对于软件性能是一个不小的影响，既增加了服务器的压力，又容易引起用户的反感。

例如：

• 图片未经压缩、格式不正确。比如采用BMP；
• 代码冗余，存在太多无用代码；
• 页面元素太多，太过复杂；

7.7 界面文字

页面信息描述不清楚，有语病，错别字。简单语言复杂化，描述不正确，不符合当前页面。错误的帮助信息，乱码等。

7.8 容错处理（功能缺陷）

容错处理（功能缺陷）：

• 容错处理在软件系统中占据十分重要的地位。所谓容错，就是容忍错误的能力。当用户在使用软件过程中发生错误后，软件应该能给出引导信息，指应用户进行正确的操作。

例如：

• 用户输入错误，系统无提示，无响应，用户不能清晰知道系统不处理的原因；
• 给出信息提示，用户接受后无法继续操作，不给用户“改过自新”的机会；
• 用户输入不合法的信息后，系统给出提示，用户确定后，系统仍能处理错误的信息。
• 取消功能不能取消，比如删除，系统给出提示，是否确定删除，用户否认后仍执行了删除。

7.9 数据转换

数据转换：

• 软件中的功能主体一般由等组成。

例如：增加、修改、删除、查询

• 无法增加记录，比如点击新增，页面自动关闭。
• 增加记录后无显示，但提示增加成功；
• 增加记录后显示不正确，显示为乱码，信息显示不全。
• 增加记录后多出记录；
• 无法修改记录；
• 修改后不能自动更新，需手工更新；
• 无法删除记录，无法全部删除；
• 删除不成功，但相应的记录已被删除；
• 无法查询、查询结果错误；

7.10 性能缺陷

性能缺陷：

• 这里所说的性能问题不需专业的工具就能发现的问题，这类问题在平常做黑盒测试的时候就能发现。

例如：

• 打开文档，10秒应该可以完成的，却花了3分钟；
• 启动软件，CPU长时间100%，内存消耗过多；
• 5个用户可以正常使用，20个用户使用时系统崩溃；
• 打开一个登录页面花了1分钟；
• 完成一个查询功能，花了2分钟；

八、不同软件组织的缺陷管理过程

8.1 个体行为

• 处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。
• 所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。

8.2 项目行为

–在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：

（1）提交缺陷

（2）分析和定位缺陷

（3）提请修改相应的软件

（4）修改相应的软件

（5）验证修改

–项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。

8.3 组织行为

• CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。
• 从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。

8.4 持续优化

• 与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。
• 就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。
• 缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。

九、拒绝修改缺陷的原因

9.1 开发人员拒绝修改的缺陷

• 程序员无法重现或者现象难以捕捉
• 没有明确的报告以说明重现缺陷的步骤
• 程序员无法读懂的缺陷报告
• 用户很少使用或者不符合用户使用习惯的操作出错
• 由不受信任的测试人员提出

9.2 拒绝缺陷修改说明

• 市场的压力使得产品最终发行有时间限制
• 测试人员错误理解或者不正确操作引出的缺陷(FAQ)
• 错误的修改影响的模块较多，带来的风险较大(遗留)
• 修改性价比太低
• 缺陷报告中提出的问题很难重现