软件工程评测方法

测试的主要评测方法 简介 如果需求已经完全分类 则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测 例如 如 果已经确定了所有性能测试需求 则可以引用测试结果来得到评测 如已经核实了 75 的性能测试需求 如果应用基于代码的覆盖 则测试策略是根据测试已经执行的源代码的多少来表示的 这种测试覆盖 策略类型对于安全至上的系统来说非常重要 两种评测都可以手工得到 公式如下所示 或通过测试自动化工具计算得到 基于需求的测试覆盖 基于需求的测试覆盖在测试生命周期中要评测多次 并在测试生命周期的里程碑处提供测试覆盖的标 识 如已计划的 已实施的 已执行的和成功的测试覆盖 在执行测试活动中 使用两个测试覆盖评测 一个确定通过执行测试获得的测试覆盖 另一个确定成 功的测试覆盖 即执行时未出现失败的测试 如没有出现缺陷或意外结果的测试 这些覆盖评测通过以下公式计算 这一关于测试覆盖的陈述是有意义的 可以将其与已定义的成功标准进行对比 如果不符合该标准 则此陈述将成为预测剩余测试工作量的基础 基于代码的测试覆盖 基于代码的测试覆盖评测测试过程中已经执行的代码的多少 与之相对的是要执行的剩余代码的多少 代码覆盖可以建立在控制流 语句 分支或路径 或数据流的基础上 控制流覆盖的目的是测试代码行 分支条件 代码中的路径或软件控制流的其他元素 数据流覆盖的目的是通过软件操作测试数据状态是否 有效 例如 数据元素在使用之前是否已作定义 基于代码的测试覆盖通过以下公式计算 质量评测 测试覆盖的评估提供对测试完全程度的评测 在测试过程中已发现缺陷的评估提供了最佳的软件质量 指标 因为质量是软件与需求相符程度的指标 所以在这种环境中 缺陷被标识为一种更改请求 该更改 请求中的测试对象与需求不符 缺陷评估可能建立在各种方法上 这些方法种类繁多 从简单的缺陷计数到严格的统计建模不一而足 严格的评估假定测试过程中缺陷达到的比率或发现的比率 常用模型假定该比率符合泊松分布 则有 关缺陷率的实际数据可以适用于这一模型 生成的评估将评估当前软件的可靠性 并且预测继续测试并排 除缺陷时可靠性如何增长 该评估被描述为软件可靠性增长建模 这是一个活跃的研究领域 由于该类型 的评估缺乏工具支持 所以应该慎重平衡成本与其增加价值 缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布 缺陷分析提供了一个软件可 靠性指标 对于缺陷分析 常用的主要缺陷参数有四个 状态 缺陷的当前状态 打开的 正在修复或关闭的等 优先级 必须处理和解决缺陷的相对重要性 严重性 缺陷的相关影响 对最终用户 组织或第三方的影响等等 起源 导致缺陷的起源故障及其位置 或排除该缺陷需要修复的构件 可以将缺陷计数作为时间的函数来报告 即创建缺陷趋势图或报告 也可以将缺陷计数作为一个或多 个缺陷参数的函数来报告 如作为缺陷密度报告中采用的严重性或状态参数的函数 这些分析类型分别为 揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据 例如 预期缺陷发现率将随着测试进度和修复进度而最终减少 可以设定一个阈值 在缺陷发现率低 于该阈值时才能部署软件 也可根据执行模型中的起源报告缺陷计数 以允许检测 较差的模块 热点 或需要再三修复的软件部分 从而指示一些更基本的设计缺陷 这种分析中包含的缺陷必须是已确认的缺陷 不是所有已报告的缺陷都报告实际的缺陷 这是因为某 些缺陷可能是扩展请求 超出了项目的规模 或描述的是已报告的缺陷 然而 需要查看并分析一下 为 什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷 这样做是有价值的 缺陷报告 Rational Unified Process 以三类形式的报告提供缺陷评估 缺陷分布 密度 报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示 缺陷龄期报告是一种特殊类型的缺陷分布报告 缺陷龄期报告显示缺陷处于特定状态下的时间长 短 如 提出的 在龄期类别中 缺陷还可以按其他属性分类 如 拥有者 缺陷趋势报告按状态 新的 已打开的或关闭的 将缺陷计数作为时间的函数显示 趋势报告可以 是累计的 也可以是非累计的 测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果 许多此类报告对于评估软件质量具有很高的价值 一般测试标准中包括有关特定类别 如严重性级别 中 打开的缺陷数的陈述 通过缺陷分布评估可以轻松地核对该标准 对测试需求进行过滤或分类 该评估可 以侧重于不同的需求集 要有效生成此类报告 一般需要工具支持 缺陷密度报告 缺陷状态与优先级 应该给定所有缺陷的优先级 通常可行的做法是设定四种优先级中的一种 1 立即解决 2 高优先级 3 正常排队 4 低优先级 一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式 例如 对于一个成功的测 试标准来说 可能不存在优先级为 1 的打开的缺陷 而且优先级为 2 的打开的缺陷要少于 5 个 例如 下面的缺陷分布图 很明显该图显示的情况没有达到标准 请注意 该图需要通过过滤器才能只显示需要的打开的缺陷 缺陷状态与严重性 缺陷严重性报告显示每种严重性级别的缺陷个数 例如致命错误 未执行主要功能 次要错误等严重 性级别 缺陷状态与在实施模型中的位置 缺陷起源报告显示缺陷在实施模型元素上的分布情况 缺陷龄期报告 缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈 例如 如果大部分龄期较长的 未 解决的缺陷处于有待确认的状态 则可能表明没有充足的资源应用于再次测试工作 缺陷趋势报告 趋势报告确定缺陷率并提供了一个出色的测试状态视图 在测试生命周期中 缺陷趋势遵循着一种比 较好预测的模式 在生命周期的初期 缺陷率增长很快 在达到顶峰后 就随时间以较慢的速率下降 要发现问题 可以根据这一趋势复审项目时间表 例如 在四个星期的生命周期中 如果缺陷率在第 三个星期中仍然增长 则项目很明显没有按时间表进行 这一简单的趋势分析假定 缺陷是立即关闭的 且在随后的工作版本中对修复进行测试 这样关闭缺 陷的速率应该遵循与打开缺陷的速率相同的增减趋势 如果情况并非如此 则表明缺陷解决流程发生了问 题 缺陷修复所需的资源或再次测试和确认修复所需的资源可能不足 该报告反映的趋势显示 在项目开始时 发现和打开新缺陷的速率很快 但随着时间推移 该速率不 断降低 打开的缺陷的趋势与新缺陷的趋势相似 但稍微滞后一些 关闭的缺陷的趋势随着打开的缺陷的 修复和核实而不断增长 这些趋势描述的是成功的工作 如果您的趋势与这些趋势差别显著 则表明存在问题 并可以确定可能需要附加资源以应用于开发或 测试特定区域的时间 当与测试覆盖评测结合起来时 缺陷分析可提供出色的评估 测试完成的标准也可以建立在此评估基 础上 性能评测 评估测试对象的性能行为时 可以使用多种评测 这些评测侧重于获取与行为相关的数据 如响应时 间 计时配置文件 执行流 操作可靠性和限制 这些评测主要在评估测试活动中进行评估 但是也可以 在执行测试活动中使用性能评测评估测试进度和状态 主要的性能评测包括 动态监测 在测试执行过程中 实时获取并显示正在执行的各测试脚本的状态 响应时间 吞吐量 测试对象针对特定主角和 或用例的响应时间或吞吐量的评测 百分位报告 数据已收集值的百分位评测 计算 比较报告 代表不同测试执行情况的两个 或多个 数据集之间的差异或趋势 追踪报告 主角 测试脚本 和测试对象之间的消息 会话详细信息 软件作为一种纯数字化商品 在没有权威的第三方进行监督认证的情况下 软件供应商和用户在软件产品 是否达到目标需求的问题上 往往各执一词 关于软件质量标准和认证 国内虽然制定了有限的几个软件技术标准 但无法从根本上对软件这种特 殊商品实施有效的质量监督和认证 在国际上通行的做法是 软件的质量标准和认证工作 由独立的软件 测试机构来完成 这些测试机构的行为是市场化的 但因为测试能力和权威性将直接关系到它们的市场影 响力 所以他们的测试行为极其严格 力求将垃圾软件扼杀在摇篮中 樱花西街一座不太显眼的大厦里 迈捷实验室技术总监武友文从软件测试说起 以第三方的视角分析 了制约国内软件发展的瓶颈 发表了不同意见 提出了自己的建议 为什么需要软件测试 我是清华大学 77 级的学生 在国内做了 3 年软件开发 随后就去了加拿大读研 专业是网络协议测 试 毕业后我在北电 惠普等公司做软件质量的控制和测试项目 武友文轻声细语地说着自己的经历 1998 年我回到国内 在对金融和电信行业进行考察时 发现他们买的硬件设备都是顶级的 可惜软件应 用这一块跟不上 导致了硬件功能得不到充分的发挥 硬件设备低下的运行效率 造成了资源与资金的隐 性浪费 不客气地说 实际上 是国内软件在拖硬件的后腿 在武友文回国期间 国内一些软件开发商通过朋友的引见 邀请武友文与公司研发人员交流时 武友 文发现当时国内的软件开发普遍存在 重开发 轻测试 的现象 常常是在项目开发完成之后 才发现软件 有严重缺陷问题 不得不全部推倒从头再来 推倒重来则意味着前期人 财 物的投入全部浪费了 即大 大增加了软件的开发成本 又会因为超出了客户的委托时间 付出的代价就更高了 武友文以自己在国际公司的实践经验 一再强调 软件测试是软件开发过程中的一个重要步骤 或者 说测试应该贯穿在软件开发过程的每一个阶段 软件测试所起到的作用就是 能够确保在软件开发的过程 中 随时发现问题 方便开发人员及时修改 在国内对于消费类软件来说 经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退 货的局面 而对于定制的行业软件来说 则是一再的返工 绵绵无绝期的修改和维护 既拖死了软件提供 商 也耽误了客户的正常业务 这一系列现状使用户对国内软件提供商失去信心 因此我们经常听到有人抱怨 国内软件没法用 对 于正在成长的国内软件市场来说 这一结论无疑是灭顶之灾 武友文告诉记者 因为国外软件的成熟度高 开发商对软件质量的控制力度很强 所以国外软件测 试外包的不是太多 不过在国外有些软件需要比较专业的质量认证 例如软件的本地化测试 就必须借助 第三方机构来完成了 拿微软来说吧 微软的产品要翻译成欧洲的 6 种文字 如果是自己来做这些本地化 测试工作 成本就会很大 所以外包给别的公司来做就很合适 另外还有一种情况也会外包的 例如对一 些大型软件的测试 不一定每家开发商都有专业的测试队伍和测试的工具 从成本上来说 某些软件测试 工作外包是经济的 相反 国内软件的成熟度比较低 软件开发商基本没有能力来做测试 我指的是专业 的 职业的测试 所以从目前来说 国内软件测试的市场空间很大 凭着对软件测试行业的深刻理解 武友文意识到要解决国内软件应用滞后于硬件的问题 就必须提高 国内软件的质量 而要提高软件质量 就必须加强软件开发过程中的测试力量 而独立的第三方测试机构 正是一个市场空白点 于是专业从事软件测试的迈捷实验室就应运而生 软件测试如何做 迈捷成立之初 主营业务只是受客户委托 测试已经开发完毕的软件 更多的是事后验收工作 后 来我们慢慢的从事后测试 向质量控制上转型 例如开始介入软件开发前的需求评审 以及开发时的文档 评审 代码走查等等 我们最终的发展方向就是做软件监理 但是不能不承认 目前我们与国际上通行的 软件监理还有一定的距离 说到迈捷的发展方向 武友文沉稳中略显激昂 武友文接着说 美国实际是在软件规模的扩大和结构的不断复杂的情况下 开始建立软件测试制度 和规矩的 我想美国在软件开发的起步阶段 也不会自己主动去做 是在现实的压力下 才去实施这些流 程规范的 国内一定要有这种意识 意识到软件开发过程中一定要引进这些规章制度 另外 意识到了还 不行 一定要实践 软件测试现状 武友文向记者提供的一个市场调查报告说明 目前国内做软件测试的机构 还没有发现与迈捷公司商 业形态相同的企业 只是有某些政府部门下属的机构做一些软件产品验收工作 但完全商业化操作的机构 没有 另外就是开发商临时承接的一些软件测试项目 当记者问到迈捷实施软件测试时遇到的最大障碍是 什么时 武友文很爽快的回答到 一是客户的意识 二是我们派出的项目实施人员的素质问题 实施软件评测项目时 客户要有接受管理软件开发流程的意识 客户交给开发商一个项目 通过测试等质量掌控流程 可以将产品的质量保证在一个相对较高的水准 减少后续工作的成本 但是现在很多开发商和客户很短视 觉得只要现在没有出问题 就可以了 不愿意 在软件开发过程中 让测试介入的程度不深 这导致测试不完全 埋下了隐患 无论是对软件开发商还是对客户来说 忽视软件测试 必将导致上的软件开发项目越多 将来会被这 些有问题的项目给拖死的概率越高 武友文说 有独立的软件测试第三方的出现 好处就是严格地掌控软件质量 减少维护成本 这不 光对客户有好处 对开发商也有好处 所以一个项目 在我们实施很长一段时间 大约是半年至两年后 客户才意识到这样做是有用的 这很正常 因为软件开发一定会有大大小小的问题 包括我们评测也有一 些问题查不出来 迈捷对派出的项目实施人员的标准很高 要求既有综合素质 又要有专业素质 目前国内这种复合型 的人才太少了 于是迈捷只能自己培养 而人才培训 则令武友文最为头痛 人才培养是迈捷在资金和力量上投入最大的一块 其中专业素质 的培训最难 因为需要实践 这如同医生一样 从医学校毕业了 虽然有很多理论上的积累 但是缺乏临 床经验 你还不是一个合格的医生 更别谈做一个好医生了 项目实施管理者也一样 既要有理论基础 更要有经验积累 而一个优秀的项目实施管理者重要的素质是 能在按流程做的基础上 发挥个人的主观 能动性 这个要求就太高了 但这又是项目实施成否的关键 国内软件业和国外相比 最大的差异就在 质量和质量控制应该是最重要的一项内容 但是 无论在 消费类软件还是大型软件的测试领域 与国外相比 国内软件产品的质量掌控体系和标准都是模糊的 国 内软件提供商的质量承诺 既没有相应机构的监督 质量水平也没有第三方来认证 承诺显得极其苍白而 无力 可喜的是 软件测试机构在我国正逐渐成长起来 并且 它们在软件市场上的影响力正逐步得到提升 因缺乏游戏规则导致整个软件行业的市场行为不规范 并且严重制约软件行业健康成长的局面 一定会有 所改善 采访后记 软