文章目录
前言
软件测试是软件工程中的重要部分，是确保软件质量的重要手段。随着软件的复杂度不断增强、软件产业的不断发展，软件测试得到越来越广泛的重视，本章主要介绍如何报告发现的软件缺陷，以及有关软件测试评测的相关知识。
一、软件缺陷和软件缺陷种类
1.软件缺陷的定义和描述
按照一般的定义，只要符合下面5个规则中的一条，就叫做软件缺陷。
• 软件未达到软件规格说明书中规定的功能。
• 软件超出软件规格说明书中指明的范围。
• 软件未达到软件规格说明书中指出的应达到的目标。
• 软件运行出现错误。
• 软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。
以下是软件缺陷的有效描述规则。
• 单一准确：每个报告只针对一个软件缺陷。
• 可以再现：提供出现这个缺陷的精确步骤，使开发人员看懂，可以再现并修复缺陷。
• 完整统一：提供完整，前后统一的软件缺陷的修复步骤和信息，如图片信息，log文件等。
• 短小简练：通过使用关键词，使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的现象。
• 特定条件：软件缺陷描述不要忽视那些看似细节但又必要的特定条件（如特定的操作系统，浏览器），这些特定条件能提供帮助开发人员找到产生缺陷原因的线索。
• 补充完善：从发现软件缺陷开始，测试人员的责任就是保证他被正确的报告，并得到应有的重视，继续监视其修复的全过程。
• 不作评价：软件缺陷报告是针对软件产品的，因此软件缺陷描述不要带有个人观点，不要对开发人员进行评价。
2.软件缺陷的种类
（1）功能不正常
（2）软件在使用上不方便
（3）软件的结构来做良好规划
（4）所提供的功能不充分
（5）与软件操作者的互动不良
（6）使用性能不佳
（7）未做好错误处理
（8）边界错误
（9）计算错误
（10）使用一段时间所产生的错误
（11）控制流程的错误
（12）在大数据量压力之下所产生的错误
（13）在不同硬件环境下产生的错误
（14）版本控制不良所产生的错误
（15）软件文档的错误
3.软件缺陷的属性
（1）缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示，一般由软件缺陷追踪管理系统自动生成。
（2）缺陷描述与缺陷注释：指对缺陷的发现过程所进行的详细描述和对缺陷的一些辅助说明信息。
（3）缺陷类型：指根据缺陷的自然属性划分的缺陷类型，一般包括功能缺陷、用户界面缺陷、文档缺陷、软件配置缺陷、性能缺陷、系统/模块接口缺陷等。
• 功能缺陷：影响了各种软件系统功能、逻辑的缺陷。
• 用户界面缺陷：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷等。
• 文档缺陷：指文档影响了软件的发布和维护，包括注释、用户手册、设计文档等。
• 软件配置缺陷：由于软件配置库、变更管理或版本控制引起的错误。
• 性能缺陷：不满足系统可测量的属性值，如执行时间、事务处理速率等。
• 系统/模块接口缺陷：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突等。
（4）缺陷严重程度：严重性表示软件缺陷对软件质量的破坏程度，反映其对产品和用户的影响，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。
一般分为：致命（Fatal）、严重（Critical）、一般（Major）、较小（Minor）。
• 致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危及人身安全。
• 严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响。
• 一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题。
• 较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题。
（5）缺陷产生可能性：指某缺陷发生的频率，一般分为：总是、通常、有时、很少等。
• 总是：总是产生这个软件缺陷，其产生的频率是100%。
• 通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%～90%。
• 有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30%～50%。
• 很少：按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1%～5%。
（6）缺陷的优先级：优先级表示修复缺陷的重要程度和应该何时修复，是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。一般分为：高优先级、高优先级、正常排队、低优先级等。
• 最高优先级：指的是一些关键性错误，缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。
• 高优先级：缺陷严重，影响测试，需要优先考虑修复。
• 正常排队：缺陷需要正常排队等待修复，在产品发布之前必须修复。
• 低优先级：缺陷可以在开发人员有时间的时候被纠正。
软件缺陷的优先级在项目期间是会发生变化的。
（7）缺陷状态：用于描述缺陷通过一个跟踪修复过程的进展情况。一般分为：激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息等。
• 激活或打开：问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。
• 已修正或修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证。
• 关闭或非激活：测试人员验证后，确认缺陷不存在之后的状态。
• 重新打开：测试人员验证后，确认缺陷不存在之后的状态。
• 推迟：这个软件缺陷可以在下一个版本中解决。
• 保留：由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷。
• 不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷再现的步骤。
• 需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等。
（8）软件缺陷的起源：指缺陷引起的故障或事件第一次被检测到的阶段。分为：需求、构架、设计、编码、测试、用户等。
• 需求：在需求阶段发现的软件缺陷。
• 设计：在详细设计阶段发现的软件缺陷。
• 编码：在编码阶段发现的软件缺陷。
• 测试：在测试阶段发现的软件缺陷。
• 用户：在用户使用阶段发现的软件缺陷。
（9）软件缺陷的来源：指引起软件缺陷发生的地方。分为：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码等。
• 需求说明书：需求说明书的错误或不清楚引起的问题。
• 设计文档：设计文档描述不准确。和需求说明书不一致的问题。
• 系统集成接口：系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷。
• 数据流（库）：由于数据字典、数据库中的错误引起的缺陷。
• 程序代码：纯粹在编码中的问题所引起的缺陷。
（10）缺陷根源：指产生软件缺陷的根本因素，以便进一步寻求对软件开发流程的改进和管理水平的提高。一般为：测试策略，过程、工具和方法，团队/人，缺乏组织和通信，硬件，软件，工作环境等。
• 测试策略：错误的测试范围，误解测试目标，超越测试能力等。
• 过程、工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等。
• 团队/人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等。
• 缺乏组织和通信：缺乏用户参与，职责不明确、管理失败等。
• 硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等。
• 软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误等。
工作环境：组织机构调整，预算改变，工作环境恶劣等。
二、软件缺陷的生命周期
下面是一个最简单的软件缺陷生命周期的情况，系统地表示软件缺陷从被发现起经历生存的各个阶段：
（1）发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。
（2）打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证。
（3）修复——关闭：测试人员验证修复过的软件关闭已不存在的缺陷。
在有些情况下，生命周期变得更复杂一些，如下图所示：
可以看到，软件缺陷可能在生命周期中经历数次改动和重申，有时反复循环。上图所示的情况，在实际测试工作中有相当的普遍性。通常，软件缺陷生命周期有两个附加状态：① 审查状态 ② 推迟状态。
三、分离和再现软件缺陷
如果找到的软件缺陷要采取繁杂的步骤才能再现，或者根本无法再现，碰到这种情况，可采取如下的方法来分离和再现软件缺陷，实践证明这些方法对测试人员是有所帮助的。
（1）确保所有的步骤都被记录
（2）注意时间和运行条件上的因素
（3）注意软件的边界条件、内存容量和数据溢出的问题
（4）注意事件发生次序导致的软件缺陷
（5）考虑资源依赖性和内存、网络、硬件共享的相互作用
（6）不要忽视硬件
四、软件测试人员需正确面对软件缺陷
（1）并不是测试人员辛苦找出的每个软件缺陷都是必须修复的
不修复软件缺陷的原因是：
① 没有足够的时间
② 不算真正的软件缺陷
③ 修复的风险太大
④ 不值得修复
（2）发现的缺陷的数量说明不了软件的质量
（3）不要指望找出软件中所有的缺陷
五、报告软件缺陷
1.报告软件缺陷的基本原则
（1）尽快报告软件缺陷
（2）有效地描述软件缺陷
2.IEEE软件缺陷报告模板
ANS/IEEE829—1998标准定义了一个称为软件缺陷报告的文档，用于报告“在测试过程期间发生的任何异常事件”。
（1）软件缺陷报告标识符
指定软件缺陷报告的唯一ID，用于定位和引用。
（2）软件缺陷总结
简明扼要地陈述事实，总结软件缺陷。给出所测试软件的版本引用信息、相关的测试用例和测试说明等信息。对于任何已确定的软件缺陷，都要给出相关的测试用例，如果某一个软件缺陷是意外发现的，也应该编写一个能发现这个意外软件缺陷的测试用例。
（3）软件缺陷描述
软件缺陷报告的编写人员应该在报告中提供足够多的信息，一般修复人员能够理解和再现事件的发生过程。下面是软件缺陷描述中的各个内容。
• 输入
描述实际测试时采用的输入（例如，文件、按键等）。
• 期望得到的结果
此结果来自于发生事件时，正在运行的测试用例的设计结果。
• 实际结果
将实际运行结果记录在这里。
• 异常情况
指的是实际结果与预期结果的差异有多大。也记录一些其他数据（如果这数据显得非常重要的话），例如，有关系统数据量过小或者过大，一个月的最后一天等。
• 日期和时间
软件缺陷发生的日期和时间。
• 规程步骤
软件缺陷发生的步骤。如果使用的是很长的、复杂的测试规程，这一项就特别重要。
• 测试环境
所采用的环境。例如，系统测试环境、验收测试环境、客户的测试环境、测试场所等。
• 再现尝试
为了再现这次测试，做了多少次尝试。
• 测试人员
进行这次测试的人员情况。
• 见证人
了解此次测试的其他人员情况。
（4）影响
软件缺陷报告的“影响”是指出了软件缺陷对用户造成的潜在影响。在报告软件缺陷时，测试人员要对软件缺陷分类，以简明扼要的方式指出其影响。经常使用的方法是给软件缺陷划分严重性和优先级。当然，具体方法各个公司不尽相同，但是通用原则是一样的。测试实际经验表明，虽然可能永远都不能彻底克服在确定严重性和优先级过程中所存在的不精确性，但是通过在定义等级过程中对较小、较大和严重等主要特征进行描述，完全可以把这种不精确性减少到一定程度。
六、软件缺陷的跟踪管理
1.软件缺陷跟踪管理系统
（1）软件缺陷管理系统的作用
在测试工作中应用软件缺陷管理系统具有以下优点：
① 保持高效率的测试过程
② 提高软件缺陷报告的质量
③ 实施实时管理，安全控制
④ 利用该系统还有利于项目组成员间协同工作
（2）缺陷跟踪管理的实现原理
软件缺陷跟踪管理系统可以通过添加、修改、排序、查寻、存储操作来管理软件缺陷。
2.手工报告和跟踪软件缺陷
七、软件测试的评测
1.覆盖评测
覆盖评测指标是用来度量软件测试的完全程度的，所以可以将覆盖用做测试有效性的一个度量。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖，它们分别是指针对需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度评测。
2.质量评测
测试覆盖的评测提供了对测试完全程度的评价，而在测试过程中对已发现缺陷的评测提供了最佳的软件质量指标。
缺陷分析通常以4类形式的度量提供缺陷评测：
• 缺陷发现率。
• 缺陷潜伏期。
• 缺陷密度。
• 整体软件缺陷清除率。
八、测试总结报告
总结
以上就是今天要讲的内容，本文仅仅简单介绍了软件测试的基本概念，希望能够对正在阅读的你有所帮助。如果你也对软件测试感兴趣的话，就跟着我一起学下去吧。
如果您觉得我写的还不错，请多给我点赞鼓励一下，您的支持也是我不断前进的最大动力。同时也欢迎您将本篇文章分享给您的朋友，一起学习。最后，也欢迎大家在私信和评论里与我探讨学习过程中遇到的问题，大家共同进步。