当前位置:主页 > www.789238.com >

第5章软件测试报告与测试评价
* 来源 :http://www.www789238.com * 作者 : * 发表时间 : 2019-10-08 06:35

  东方心经a中特图第5章软件测试报告与测试评价_计算机软件及应用_IT/计算机_专业资料。第5章软件测试报告与测试评价

  第 5 章 软件测试报告与测试评价 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 软件缺陷的概念和种类 正确面对软件缺陷 软件缺陷的生命周期 软件缺陷的严重性和优先级 报告软件缺陷 分离和再现软件缺陷 测试总结报告 测试的评测 软件测试是在软件开发的过程中,对 软件产品进行质量控制,目的是保证软件 产品的最终质量。一般来说软件测试应严 格按照软件测试流程,制定测试计划、测 试方案、测试规范,实施测试,对测试数 据进行记录,并根据测试情况撰写测试报 告。测试报告主要是报告发现的软件缺陷。 测试评价主要包括覆盖评价以及质量和 性能评价。覆盖评价是对测试完全程度的 评测;质量和性能评价是对测试的软件对 象的性能、稳定性以及可靠性的评测。 5.1 软件缺陷的概念和种类 软件缺陷简单说就是存在于软件(文 档、数据、程序)之中的那些不希望,或 不可接受的偏差,而导致软件产生的质量 问题。按照一般的定义,只要符合下面5个 规则中的一个,就叫做软件缺陷。 ? 软件未达到软件规格说明书中规定的功能; ? 软件超出软件规格说明书中指明的范围; ? 软件未达到软件规格说明书中指出的应达到 的目标; ? 软件运行出现错误; ? 软件测试人员认为软件难于理解,不易使用, 运行速度慢,或者最终用户认为软件使用效果 不好。 在软件测试过程中如何判断软件缺陷,软 件缺陷都有哪些种类? (1)功能不正常 (2)软件在使用上不方便 (3)软件的结构未做良好规划 (4)功能不充分 (5)与软件操作者的互动不良 (6)使用性能不佳 (7)未做好错误处理 (8)边界错误 (9)计算错误 (10)使用一段时间所产生的错误 (11)控制流程的错误 (12)在大数据量压力之下所产生的错误 (13)在不同硬件环境下产生的错误 (14)版本控制不良所产生的错误 (15)软件文档的错误 5.2 正确面对软件缺陷 在软件测试过程中,软件测试人员必须确 保测试过程发现的软件缺陷得以关闭。 测试是为了证明程序有错,而不是 证明程序没错。不管测试计划多么完善 和执行测试多么努力,也不能保证所有 软件缺陷发现了就能修复。有些软件缺 陷可能会完全被忽略,还有一些可能推 迟到软件后续版本中修复。有些软件缺 陷不被修复的原因如下。 (1)没有足够的时间 (2)不算线)不值得修复 虽然软件测试人员需要对自己找出 的软件缺陷保持一种平常心态,但同时 又必须坚持有始有终的原则,跟踪每一 个软件缺陷的处理结果,确保软件缺陷 得以关闭。而缺陷是否需要修复的最终 决定权在软件的项目负责人,但使得缺 陷得以关闭的责任在测试人员。 5.3 软件缺陷的生命周期 软件缺陷从被测试人员发现一直到被 修复,也经历了一个特有的生命周期的阶 段。下面是一个最简单的软件缺陷生命周 期的例子,系统地表示软件缺陷从被发现 起经历的各个阶段: ( 1 )测试人员找到并登记软件缺陷, 软件缺陷被移交到程序修复人员。 ( 2 )程序修复人员修复软件中的软件 缺陷,然后移交到测试人员。 ( 3 )测试人员确认软件缺陷被修复, 关闭软件缺陷。 当软件缺陷首先被软件测试人员发现时 。 在许多情况下,软件缺陷生命周期的复 杂程度仅为软件缺陷被打开、解决和关闭。 然而,在有些情况下,生命周期变得更复杂 一些,如图5-1所示。 发现软件缺陷 测试员找到并登记软件缺陷 软件缺陷被移交到程序员 打开 程序员认为软件缺陷微不足道 软件缺陷移交到项目管理员 打开 项目管理员认为软件缺陷不重要 软件缺陷移交到测试员 以不修复 形式解决 测试员不同意,找出 通用失败案例 软件缺陷移交到项目管理员 以修复 形式解决 打开 项目管理员现在同意 软件缺陷需要修复 软件缺陷移交到程序员 程序员修复软件缺陷 软件缺陷移交到测试员 测试员确认 软件缺陷得以修复 测试员关闭软件缺陷 关闭 打开 图5-1 复杂的软件缺陷生命周期 5.4 软件缺陷的严重性和优先级 测试人员要对软件缺陷分类,以简明 扼要的方式指出其影响。经常使用的方法 是给软件缺陷划分严重性和优先级。严重 性表示软件缺陷的恶劣程度,反映其对产 品和用户的影响;优先级表示修复缺陷的 重要程度和应该何时修复。下面给出严重 性和优先级的常用划分方法,将有助于测 试人员更好地理解两者之间的差异。 ? 严重性级别: ① 致命错误,例如,导致系统崩溃、 数据丢失、数据毁坏等; ② 一般性错误,例如,操作性错误、 错误结果、遗漏功能等; ③ 次要错误,例如,错别字、用户接 口布局、罕见故障等。 ? 缺陷优先级: ① 最高优先级,指的是一些关键性错误, 必须立即修复; ② 高优先级,在产品发布之前必须修复; ③ 中优先级,如果时间允许应该修复; ④ 低优先级,可能会修复,但是也能发 布软件。 5.5 报 告 软 件 缺 陷 5.5.1 报告软件缺陷的基本原则 在软件测试过程中,对于发现的大多 数软件缺陷,要求测试人员简捷、清晰地 把发现的问题报告给判断是否进行修复的 小组,使其得到所需要的全部信息,然后 才能决定怎么做。 报告软件缺陷的基本原则如下。 1.尽快报告软件缺陷 2.有效地描述软件缺陷 有效的软件缺陷描述要求如下。 (1)简单与短小 (2)明确指明错误类型 (3)单一 ( 4 )使用 IT 业界惯用的表达术语 和表达方法 3.在报告软件缺陷时不做任何评价 4.补充和完善软件缺陷报告 以上概括了报告测试错误的规范要求, 测试人员应该牢记上面这些关于报告软件缺 陷的原则。这些原则几乎可以运用到任何交 流活动中,尽管有时难以做到,然而,如果 希望有效地报告软件缺陷,并使其得以修复, 这些是测试人员要遵循的基本原则。 随着软件的测试要求不同,测试者积累了 相应的测试经验会,将会逐渐养成良好的 专业习惯,不断补充新的规范书写要求。 此外,经常阅读、学习高级测试工程师的 测试错误报告,结合自己以前的测试错误 报告进行对比和思考,可以不断提高技巧。 5.5.2 IEEE软件缺陷报告模板 ANS/IEEE829—1998 标准定义了一个称为 软件缺陷报告的文档,用于报告“在测试 期间发生的任何异常事件”。简言之,就 是用于登记软件缺陷。模板标准如图5-3所 示。 IE E E 8 2 9 - 1 9 9 8 软 件 测 试 文 档 编 制 标 准 软 件 缺 陷 报 告 模 板 目 录 1. 软 件 缺 陷 报 告 标 识 符 2. 软 件 缺 陷 总 结 3. 软 件 缺 陷 描 述 3 .1 3 .2 3 .3 3 .4 3 .5 3 .6 3 .7 3 .8 3 .9 4. 影 响 输 入 期 望 得 到 的 结 果 实 际 结 果 异 常 情 况 日 期 和 时 间 软 件 缺 陷 发 生 步 骤 测 试 环 境 再 现 测 试 测 试 人 员 图 5 3 IEEE 软 件 缺 陷 报 告 模 板 3 .1 0 见 证 人 5.5.3 软件缺陷数据库跟踪系统 至此,我们了解到软件缺陷报告过程是 很复杂的,需要大量信息、详尽的细节和 很好的组织工作,才能有所成效。在实际 软件测试工作中,为了更高效地记录发现 的软件缺陷,并在软件缺陷的整个生命周 期中对其进行监控,常常运用软件缺陷跟 踪系统。图5-4所示的是一个软件缺陷数据 库跟踪系统。 图 5 4 软 件 缺 陷 数 据 库 跟 踪 系 统 - 软件缺陷跟踪数据库最常用的功能, 除了输入软件缺陷之外,就是通过执行查 询来获得需要的软件缺陷清单。 通过使用软件缺陷跟踪数据库,不但可 以进行查询,还可以找出发现的软件缺陷 类型,发现软件缺陷的速度,以及多少软 件缺陷已经得到了修复,能够提取各种实 用和关心的数据,可以显示测试工作的成 效和项目的进展情况。测试人员或者项目 管理员可以看出数据中是否有趋势显示需 要增加测试的区域,或者测试工作是否符 合预先所制定的测试计划的进程等。 5.5.4 手工报告和跟踪软件缺陷 显然,在软件测试工作中,每个测试 用例的结果都必须进行记录。如果使用软 件缺陷数据库跟踪系统,那么测试工具将 自动记录软件缺陷的相关信息。如果测试 是采用手工记录和跟踪软件缺陷,那么有 关软件缺陷的信息可以直接记录在相应的 文档中。图5-5所示的是根据 ANS/IEEE829—1998标准设计的软件缺陷 报告文档。 图 5 5 软 件 缺 陷 报 告 文 档 - 5.6 分离和再现软件缺陷 测试人员要想有效报告软件缺陷,就要对 软件缺陷以明显、通用和再现的形式进行描述。 分离和再现软件缺陷是考验软件测试人员 专业技能的地方,测试人员应该设法找出缩小 问题范围的具体步骤。对测试人员有利的情况 是,若建立起绝对相同的输入条件时,软件缺 陷就会再次出现,不存在随机的软件缺陷。 如果找到的软件缺陷要采取繁杂的步骤 才能再现,或者根本无法再现,碰到这种 情况,可采取如下的方法来分离和再现软 件缺陷。实践证明这些方法对测试人员是 有所帮助的。 (1)不要想当然地接受任何假设 ( 2 )注意时间和运行条件上的因 素 ( 3)注意软件的边界条件、内存容量 和数据溢出的问题 ( 4)注意事件发生次序导致的软件缺 陷 ( 5)考虑资源依赖性和内存、网络、 硬件共享的相互作用 (6)不要忽视硬件 5.7 测 试 总 结 报 告 测试总结报告的目的是总结测试活动 的结果,并根据这些结果对测试进行评价。 这种报告是测试人员对测试工作进行总结, 并识别出软件的局限性和发生失效的可能 性。在测试执行阶段的末期,应该为每个 测试计划准备一份相应的测试总结报告。 本质上讲,测试总结报告是测试计划的扩 展,起着对测试计划“封闭回路”的作用。 图 5-6 所示的是符合 IEEE 标准 829—1998 软 件测试文档编制标准的测试总结报告模板。 IE E E 标 准 8 2 9 - 1 9 9 8 软 件 测 试 文 档 编 制 标 准 测试总结报告模板 目录 1. 测 试 总 结 报 告 标 识 符 2. 总 结 3. 差 异 4. 综 合 评 估 5. 结 果 总 结 5 .1 5 .2 6. 评 价 7. 建 议 8. 活 动 总 结 9. 审 批 已解决的意外事件 未解决的意外事件 图 5 6 测 试 总 结 报 告 模 板 - 5.8 测 试 的 评 测 测试的评测主要方法包括覆盖评测和 质量评测。测试覆盖评测是对测试完全程度 的评测,它建立在测试覆盖基础上,测试覆 盖是由测试需求和测试用例的覆盖或已执行 代码的覆盖表示的。质量评测是对测试对象 的可靠性、稳定性以及性能的评测。质量建 立在对测试结果的评估和对测试过程中确定 的缺陷及缺陷修复的分析基础上。 5.8.1 覆盖评测 覆盖评测指标是用来度量软件测试的完 全程度的,所以可以将覆盖用做测试有效 性的一个度量。最常用的覆盖评测是基于 需求的测试覆盖和基于代码的测试覆盖, 它们分别是指针对需求(基于需求的)或 代码的设计/实施标准(基于代码的)而言 的完全程度评测。 1.基于需求的测试覆盖 基于需求的测试覆盖在测试过程中要评 测多次,并在测试过程中,每一个测试阶段 结束时给出测试覆盖的度量。例如,计划的 测试覆盖、已实施的测试覆盖、已执行成功 的测试覆盖等。 基于需求的测试覆盖率通过以下公式计算: 测试覆盖率=T (p,i,x,s) / Rf T % 在制定测试计划活动中,将计算计划的 测试覆盖,其计算方法如下: 计划的测试覆盖率=T p / Rf T % 其中: T p 是用测试过程或测试用例表示的 计划测试需求数。Rf?T是测试需求的总数。 在实施测试过程中,计算测试覆盖时 使用以下公式: 已执行的测试覆盖率=T i / Rf T % 其中:T i是用测试过程或测试用例表示 的已执行的测试需求数。 RfT 是测试需求 的总数。 在执行测试活动中,确定成功的测试覆 盖率(即执行时未出现失败的测试,如没 有出现缺陷或意外结果的测试)评测通过 以下公式计算: 成功的测试覆盖率=T s / Rf T % 其中: T s 是用完全成功、没有缺陷的 测试过程或测试用例表示的已执行测试需 求数。RfT是测试需求的总数。 在执行测试过程中,经常使用两个测 试覆盖度量指标,一个是确定已执行的测 试覆盖率,另一个是确定成功的测试覆盖 率,即执行时未出现失败的测试覆盖率。 2.基于代码的测试覆盖 基于代码的测试覆盖评测是测试过程 中已经执行的代码的多少,与之相对应的 是将要执行测试的剩余代码的多少。 许多测试专家认为,一个测试小组在测 试工作中所要做的最为重要的事情之一就是 度量代码的覆盖情况。 基于代码的测试覆盖率通过以下公式计算: 基于代码的测试覆盖率=Ie / TIic% 其中:Ie是用代码语句、代码分支、代码 路径、数据状态判定点或数据元素名表示的 已执行代码数。TIic是代码的总数。 很明显,在软件测试工作中,进行基 于代码的测试覆盖评测这项工作极有意义, 因为任何未经测试的代码都是一个潜在的 不利因素。在一般情况下,代码覆盖运用 于较低的测试等级(例如单元和集成级) 时最为有效。 但是,仅仅凭借执行了所有的代码, 并不能为软件质量提供保证。也就是说, 即使所有的代码都在测试中得到执行, 并不能担保代码是按照客户需求和设计 的要求去做了。 5.8.2 质量评测 测试覆盖的评测提供了对测试完全程 度的评价,而在测试过程中对已发现缺陷 的评测提供了最佳的软件质量指标。 常用的测试有效性度量是围绕缺陷分析 来构造的。缺陷分析就是分析缺陷在与缺 陷相关联的一个或者多个参数值上的分布。 缺陷分析提供了一个软件可靠性指标,这 些分析为揭示软件可靠性的缺陷趋势或缺 陷分布提供了判断依据。 对于缺陷分析,常用的主要缺陷参数有 以下4个。 ? 状态:缺陷的当前状态(打开的、正 在修复的或关闭的等)。 ? 优先级:表示修复缺陷的重要程度和 应该何时修复。 ? 严重性:表示软件缺陷的恶劣程度, 反映其对产品和用户的影响等。 ? 起源:导致缺陷的原因及其位置,或 排除该缺陷需要修复的构件。 缺陷分析通常用以下 3 类形式的度 量提供缺陷评测: ? 缺陷发现率; ? 缺陷潜伏期; ? 缺陷密度。 1.缺陷发现率 缺陷发现率是将发现的缺陷数量作为 时间的函数来评测,即创建缺陷趋势图, 如图5-7所示。 图5-7 缺陷发现率 2.缺陷潜伏期 测试有效性的另外一个有用的度量是 缺陷潜伏期,通常也称为阶段潜伏期。缺 陷潜伏期是一种特殊类型的缺陷分布度量。 在实际测试工作中,发现缺陷的时间越晚, 这个缺陷所带来的损害就越大,修复这个 缺陷所耗费的成本就越多。表5-1显示了一 个项目的缺陷潜伏期的度量。 表 5 -1 一个项目的缺陷潜伏期的度量 发 现 阶 段 试 运 行 产 品 8 7 6 5 缺陷 造成 阶段 需 求 0 总 体 设 计 1 0 详 细 设 计 2 1 0 编 码 3 2 1 0 单 元 测 试 4 3 2 1 集 成 测 试 5 4 3 2 系 统 测 试 6 5 4 3 验 收 测 试 7 6 5 4 发 布 产 品 9 8 7 6 需求 总体 设计 详细 设计 编码 总计 表5-2显示了一个项目的缺陷分布情况 (按缺陷造成阶段和缺陷发现阶段)。 表 5 -2 一个项目的缺陷分布情况 发 现 阶 段 试 运 行 产 品 2 2 1 3 8 缺陷 造成 阶段 需 求 总 体 设 计 8 0 详 细 设 计 4 9 0 编 码 单 元 测 试 0 0 3 62 65 集 成 测 试 0 1 4 16 21 系 统 测 试 5 3 0 6 14 验 收 测 试 6 1 0 2 9 发 布 产 品 1 1 8 20 30 缺陷 总量 需求 总体 设计 详细 设计 编码 总计 0 1 3 15 0 27 20 31 109 187 0 8 13 19 按照缺陷产生阶段和缺陷发现阶段统 计了一个项目的缺陷分布情况后,根据软 件开发生命周期的各个阶段缺陷潜伏期度 量的加权值,可以对缺陷的发现过程有效 性和修复软件缺陷所耗费的成本等进行评 测。这里采用了一个缺陷损耗的概念,缺 陷损耗是使用阶段潜伏期和缺陷分布来度 量缺陷消除活动的有效性的一种度量。 缺陷消耗可使用下面公式计算: 缺陷数量 ? 发现的阶段潜伏期 值 缺陷消耗 ? 缺陷总量 表5-3显示了一个项目的各个缺陷损耗 值,它们依据的是经过缺陷潜伏期加权的 已发现的缺陷数。 这样,在验收测试期间 发现的需求缺陷的加权数值为42(即 6×7=42)。 表 5 -3 一个项目的各个缺陷损耗值 发 现 阶 段 试 运 行 产 品 16 14 6 15 缺陷 造成 阶段 需 求 总 体 设 计 8 0 详 细 设 计 8 9 0 编 码 单 元 测 试 0 0 6 62 集 成 测 试 0 4 12 32 系 统 测 试 30 15 0 18 验 收 测 试 42 6 0 8 发 布 产 品 9 8 42 120 缺陷 损耗 需求 总体 设计 详细 设计 编码 总计 0 3 6 15 0 4 .3 2 .1 2 .6 2 .7 2 .7 一般而言,缺陷损耗的数值越低,说 明缺陷的发现过程越有效(最理想的数值 应该为1)。作为一个绝对值,缺陷损耗几 乎没有任何意义,但是当用缺陷损耗来度 量测试有效性的长期趋势时,它就会显示 出自己的价值。 3.缺陷密度 软件缺陷密度是一种以平均值估算法来 计算出软件缺陷分布的密度值。程序代码 通常是以千行为单位的,软件缺陷密度是 用下面公式计算的: 软件缺陷数量 软件缺陷密度 ? 代码行或功能点的数量 图5-8显示了一个项目的各个模块中每 图 千行代码的缺陷密度。 5 8 各 个 模 块 中 每 千 行 代 码 的 缺 陷 密 度 但是,在实际评测中,缺陷密度这种度 量方法是极不完善的,度量本身是不充分 的。这里边存在的主要问题是:所有的缺 陷并不都是均等构造的。各个软件缺陷的 恶劣程度,及其对产品和用户的影响的严 重程度,以及修复缺陷的重要程度有很大 差别,有必要对缺陷进行“分级、加权” 处理,给出软件缺陷在各严重性级别或优 先级上的分布作为补充度量,这样将使这 种评测更加充分,更有实际应用价值。 因为在测试工作中,大多数的缺陷都记 录了它的严重程度的等级和优先级,所以 这个问题通常都能够很好解决。例如,图 5-9所示的缺陷分布图表示软件缺陷在各优 先级上所应体现的分布方式。 图5-9 各优先级上软件缺陷分布图 5.8.3 性能评测 主要的性能评测包括以下几点。 ? 动态监测:在测试执行过程中,实时获 取并显示正在执行的各测试用例的状态。 ? 响应时间和吞吐量:测试对象针对特定 测试用例的响应时间或吞吐量的评测。 ? 百分比报告:数据已收集值的百分比计 算与评测。 ? 比较报告:代表不同测试执行情况的两 个(或多个)数据集之间的差异或趋势。 ? 追踪和配置文件报告:测试用例和测试 对象之间的消息和会线.动态监测 动态监测通常以柱状图或曲线图的形 式提供实时显示/报告。该报告用于在测试 执行过程中,通过显示当前的情况、状态 以及测试用例正在执行的进度来监测或评 估性能测试执行情况。 例如,在图5-10所示柱状图中 。 图5-10 动态监测柱状图 2.响应时间和吞吐量 响应时间和吞吐量是评测并计算与时间和 吞吐量相关的性能行为。这些报告通常用 曲线 所示。响应时间和 吞吐量在“ y” 轴上,而事件数在“ x” 轴上。 图5-11 响应时间曲线.百分比报告 百分比报告通过显示已收集数据类型的 各种百分比值,提供了另一种性能统计计 算方法,如图5-12所示。 图5-12 数据类型的各种百分比值 4.比较报告 比较不同性能测试的结果,以评估测试 执行过程中所作的变更对性能行为的影响, 这种做法是非常必要的。比较报告应该用 于显示两个数据集(分别代表不同的测试 执行)之间的差异或多个测试执行之间的 趋势。 5.追踪和配置文件报告 当性能行为可以接受时,或性能监测表 明存在可能的瓶颈时(如当测试用例保持 给定状态的时间过长),追踪报告可能是 最有价值的报告。追踪和配置文件报告显 示低级信息。该信息包括主角与测试对象 之间的消息、执行流、数据访问以及函数 和系统调用。

财神爷心水论坛| 王中王三肖中特期期准| 挂牌全篇之最完整篇| 三中三公式计算方法| 香港特区总站同步开奖| 彩库宝典最新开奖记录| 香港最快直播开奖结果| 旺角图库旺角心水论坛| 济民救世网幽默| 香港官方网站开奖结果|