软件测试


网站首页 | 软件测试论坛 | 软件测试培训 | 软件测试博客 | 软件测试杂志 | 软件测试沙龙 | 软件测试下载 | 软件测试顾问
业界新闻 | 软件测试人才 | 软件测试技术 | 软件测试工具 | 行业软件测试 | 软件测试管理 | 软件质量专栏 | 软件开发专栏
当前位置:首页>>软件测试技术>>其他相关>>正文
测试的主要评测方法(1)
文章出处:转载 作者:贺炘(摘自RUP) 发布时间:2005-12-31

简介

  测试的主要评测方法包括覆盖和质量。

  测试覆盖是对测试完全程度的评测,它建立在测试覆盖基础上,测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

  质量是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)的分析的基础上。

覆盖评测

  覆盖指标提供了"测试的完全程度如何?"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之,测试覆盖是就需求(基于需求的)或代码的设计/实施标准(基于代码的)而言的完全程度的任意评测,如用例的核实(基于需求的)或所有代码行的执行(基于代码的)。

  系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的,指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。

  如果需求已经完全分类,则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如,如果已经确定了所有性能测试需求,则可以引用测试结果来得到评测,如已经核实了 75% 的性能测试需求。

  如果应用基于代码的覆盖,则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

  两种评测都可以手工得到(公式如下所示)或通过测试自动化工具计算得到。

基于需求的测试覆盖

  基于需求的测试覆盖在测试生命周期中要评测多次,并在测试生命周期的里程碑处提供测试覆盖的标识(如已计划的、已实施的、已执行的和成功的测试覆盖)。


  在执行测试活动中,使用两个测试覆盖评测,一个确定通过执行测试获得的测试覆盖,另一个确定成功的测试覆盖(即执行时未出现失败的测试,如没有出现缺陷或意外结果的测试)。

  这些覆盖评测通过以下公式计算:

  这一关于测试覆盖的陈述是有意义的,可以将其与已定义的成功标准进行对比。如果不符合该标准,则此陈述将成为预测剩余测试工作量的基础。

基于代码的测试覆盖

  基于代码的测试覆盖评测测试过程中已经执行的代码的多少,与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效,例如,数据元素在使用之前是否已作定义。

  基于代码的测试覆盖通过以下公式计算:

质量评测

  测试覆盖的评估提供对测试完全程度的评测,在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标,所以在这种环境中,缺陷被标识为一种更改请求,该更改请求中的测试对象与需求不符。

  缺陷评估可能建立在各种方法上,这些方法种类繁多,从简单的缺陷计数到严格的统计建模不一而足。

  严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性,并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模,这是一个活跃的研究领域。由于该类型的评估缺乏工具支持,所以应该慎重平衡成本与其增加价值。

  缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。

  对于缺陷分析,常用的主要缺陷参数有四个:

  · 状态:缺陷的当前状态(打开的、正在修复或关闭的等)。
  · 优先级:必须处理和解决缺陷的相对重要性。
  · 严重性:缺陷的相关影响。对最终用户、组织或第三方的影响等等。
  · 起源:导致缺陷的起源故障及其位置,或排除该缺陷需要修复的构件。

  可以将缺陷计数作为时间的函数来报告,即创建缺陷趋势图或报告;也可以将缺陷计数作为一个或多个缺陷参数的函数来报告,如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

  例如,预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值,在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数,以允许检测"较差的模块"、"热点"或需要再三修复的软件部分,从而指示一些更基本的设计缺陷。

  这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷,这是因为某些缺陷可能是扩展请求,超出了项目的规模,或描述的是已报告的缺陷。然而,需要查看并分析一下,为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷,这样做是有价值的。

缺陷报告

  Rational Unified Process 以三类形式的报告提供缺陷评估:

  · 缺陷分布(密度)报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。

  · 缺陷龄期报告是一种特殊类型的缺陷分布报告。 缺陷龄期报告显示缺陷处于特定状态下的时间长短,如"提出的"。在龄期类别中,缺陷还可以按其他属性分类,如"拥有者"。

  · 缺陷趋势报告按状态(新的、已打开的或关闭的)将缺陷计数作为时间的函数显示。趋势报告可以是累计的,也可以是非累计的。

  · 测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。
许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别(如严重性级别)中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类,该评估可以侧重于不同的需求集。

  要有效生成此类报告,一般需要工具支持。


站内搜索
相关文章
◎如何用正确的方法来写出质量好的软件的75条体会
◎Word安全保护技巧大搜罗
◎如何更好地与开发工程师沟通-给测试工程师的建议
◎第三方模拟测试环境的搭建
◎软件外包测试处理流程
◎建议有效的软件度量过程
◎嵌入式软件的覆盖测试
◎我眼中的自动化测试水平等级
◎联合测试
◎高可靠性软件测试方案探讨
◎QA活动的理解与实施
◎从六个角度分析流程建模
◎故障硬盘数据拯救全攻略
◎测试版本大全
◎程序员修身养性的十大原则
◎建模过程的盲点:软件集成中的软知识
◎ASP+SQL Server构建网页防火墙
◎基于嵌入式DSP的流媒体编解码器
◎软件开发全过程检测及测试自动化
◎PDCA循环小知识
◎想编写出优秀技术文档,先学学这四招
◎Tcl脚本的历史
◎Alpha和Beta测试简介
◎测试人员的挑战
◎测试要点总结
◎本地化测试寻找软件缺陷的方法
◎软件本地化测试类型解析与测试要领
◎全景记录:软件测试工程师的一天
◎破解软件外包人才匮乏困局
◎外包测试:雷声大 雨点急
◎URL欺骗的惯用招式
◎网络最经典命令行
◎近10年最强的50本计算机图书,您读过几本?
◎提高团队与个人的尽职度
◎从程序员到测试工程师
◎软件测试组织与方法
◎编写优秀Bug报告的艺术
◎基于模块化设计的嵌入式软件测试方法
◎一个初级测试工程师的工作总结
◎创建移动Web应用程序
◎Web服务器上防范基于ASP程序的木马
◎ASP网站漏洞解析及黑客入侵防范方法
◎防范ASP木马的十大基本原则
◎V模型问题分析
◎测试人员面试三步曲
◎软件测试的误区
◎谁背上了猴子-时间管理
◎开放源码有利于系统安全
◎软件测试的心理学问题
◎嵌入式软件测试策略
热门文章
◎软件测试工程师面试问题选登
◎一个初级测试工程师的工作总结
◎软件测试常用术语表
◎测试人员面试三步曲
◎DOS命令大全
◎什么样的测试人员是好的测试人员
◎软件测试基本方法
◎好的测试工程师应具备的素质
◎软件测试入门书籍(2)
◎我在软件公司成长的三年
◎面试官最爱问的问题背后真相
◎软件测试工程师面试题
◎应届毕业生少走弯路的十条忠告
◎有关软件测试的术语定义集锦
◎微软的软件测试方法(一)
◎我的测试经历(1)
◎全景记录:软件测试工程师的一天
◎软件测试步骤
◎谈谈对测试职业的看法
◎漫谈软件测试工程师的角色定位
◎测试需要掌握什么
◎软件测试员自身素质培养
◎测试小技巧集锦之一黑盒测试
◎近10年最强的50本计算机图书,您读过几本?
◎软件测试人员职业发展助手
◎测试要点总结
◎如何制定成功的测试计划
◎什么是ERP,通俗版解释
◎测试经验交流
◎软件测试及其支持工具
◎编写优秀Bug报告的艺术
◎软件产品测试标准
◎从程序员到测试工程师
◎微软的软件测试方法(二)
◎软件测试应遵循的八条原则
◎测试版本大全
◎我的测试经历(2)
◎测试人员的挑战
◎网管和黑客都必须知道的命令
◎QA活动的理解与实施
◎Alpha和Beta测试简介
◎网络最经典命令行
◎想编写出优秀技术文档,先学学这四招
◎个人职业生涯规划发展
◎你适合做测试吗?
◎软件测试的误区
◎我的测试经历(3)
◎软件测试的心理学问题
◎软件测试组织与方法
◎浮躁的国内测试界—2006年测试人员招聘感悟

Google提供的广告