软件测试


网站首页 | 软件测试论坛 | 软件测试培训 | 软件测试博客 | 软件测试杂志 | 软件测试沙龙 | 软件测试下载 | 软件测试顾问
业界新闻 | 软件测试人才 | 软件测试技术 | 软件测试工具 | 行业软件测试 | 软件测试管理 | 软件质量专栏 | 软件开发专栏
当前位置:首页>>软件测试技术>>其他相关>>正文
提高测试覆盖度
文章出处:博客 作者:朱少民 发布时间:2006-12-21

测试覆盖度评估是衡量阶段性软件测试执行状态的重要手段之一,来确定测试是否达到事先设定的测试任务完成的标准。测试覆盖率则是测试覆盖度评估中一种量化的表示方法,一般通过被测试的软件产品需求、功能点、测试用例数或程序代码行等来进行计算。

    软件测试覆盖率常用的计算公式:

  1. 功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 功能点)
  2. 需求覆盖率= 被验证到的需求数量 /总的需求数量 (需求)
  3. 覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 (测试用例)
  4. 语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
  5. 判定覆盖率= 判定结果被评价的次数 / 判定结果总数
  6. 条件覆盖率=  条件操作数值至少被评价一次的数量 / 条件操作数值的总数
  7. 判定条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
  8. 上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
  9. 基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)
  10. 分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数
  11. 路径覆盖率=  至少被执行一次的路径数/程序总路径数

 除此之外,覆盖率还包括类覆盖率、函数覆盖率、代码块覆盖率等,如EMMA

测试评估可以说贯穿整个软件测试过程,可以在测试每个阶段结束前进行,也可以在测试过程中某一个时间进行,目的只有一个,提高测试覆盖度,保证测试的质量。通过不断的测试覆盖度评估或测试覆盖率计算,及时掌握测试的实际状况与测试覆盖度目标的差距,及时采取措施,就可以提高测试的覆盖度。

测试覆盖度的评估依赖于不同的测试阶段或不同的测试方法。如在单元测试中,测试覆盖率是建立在被测试的代码行、程序分支和程序路径等的度量之上,从软件质量保证的要求出发,单元测试的覆盖率要达到80%之上。白盒测试方法主要以程序语句、判定-条件、条件组合和(基本)路径等覆盖率来衡量,和单元测试是吻合的。而在系统功能测试中,则以功能点、测试用例、需求数等覆盖率来衡量。

要获得、提高测试覆盖率,常常需要借助测试工具。下面就以两个测试工具为例。

1. EMMA

    EMMA 是一个用于检测和报告 JAVA 代码覆盖率的开源工具,支持许多种级别的覆盖率指标:包,类,方法,语句块(basic block)和行,特别是能测出某一行是否只是被部分覆盖,如条件语句短路的情况。EMMA能生成 textxmlhtml 等形式的报告,以满足不同的需求,其 html 报告提供逐层细化查询功能,能够从 package 开始一步步链接到我们所关注的某个方法。EMMA 能和 Makefile Ant 集成,效率很高,便于应用于大型项目。

    EMMA 是通过向 .class 文件中插入字节码的方式来跟踪记录被运行代码信息的。EMMA 支持两种模式:On the fly Offline 模式。On the fly 模式往加载的类中加入字节码,相当于用 EMMA 实现的 application class loader 替代原来的 application class loaderOn the fly 模式比较方便,缺点也比较明显,如不能为被 boot class loader 加载的类生成覆盖率报告,也不能为像 J2EE 容器那种自己有独特 class loader 的类生成覆盖率报告。这时,必须求助于 Offline 模式,Offline 模式是在类被加载前,加入字节码。EMMA 也支持两种运行方式:Command line Ant

     2. Rational PureCoverage

PureCoverage 是一个面向VC, VB 或者Java 开发的测试覆盖程度检测工具,可以自动检测测试完整性和未被测试的范围,在每一个测试阶段生产详尽的测试覆盖程度报告。PureCoverage 将在一个对话框中列出所有应用程序模块,开发人员只需针对每个应用程序构件,就可以简单地设置基于代码行或函数的代码覆盖级别。不仅可以查看每次程序运行的图形化覆盖数据,还可以直接地、实时地控制覆盖数据的记录。对于最关心或最重要的功能模块,可以详细地收集覆盖数据;而对于不太重要的模块, 只收集较常规的覆盖数据,帮助开发人员进行有效地测试。

         系统的测试活动,依据测试目标,建立在至少一个测试覆盖策略基础上,而覆盖策略帮助进行测试覆盖度的有效评估。覆盖策略有

  1. 基于需求的测试覆盖评估,依赖于对已执行/运行的测试用例的核实和分析,所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率:测试的目标是确保100%的测试用例全部成功地执行。
  2. 基于代码的测试覆盖评估,是对被测试的程序代码语句、路径或条件的覆盖率分析。如果应用基于代码的覆盖,则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

    如果测试需求已经完全分类,则基于需求的覆盖策略可能足以生成测试完全程度评测的量化指标。例如,如果已经确定了所有性能测试需求,则可以引用测试结果来得到评测,如已经核实了90%的性能测试需求。除此之外,如果测试软件的数量较大,还要考虑数据量。

站内搜索
相关文章
◎我从沙龙看测试界
◎软件测试职业发展的各个阶段
◎追求代码质量: 可重复的系统测试
◎软件项目测试管理经验谈
◎软件测试过程和流程区别
◎面试问题积累-新手注意
◎测试员的职责
◎软件质量保证的最佳实践之一:Code review和Case review
◎16个月的工作感想
◎如何增加面试成功的胜算
◎《测试之道》第四篇——胡马大宛名
◎《测试之道》第三篇——吴钩霜雪明
◎《测试之道》第二篇——大道如一,过犹不及
◎《测试之道》第一篇——道可道
◎软件测试方向杂谈
◎程序员实用测试技巧(1)
◎测试小技巧之文档编写
◎软件测试的起源与发展
◎优秀测试工程师应该具有的基本素质
◎关键字驱动测试(keyword-driven)
◎软件测试工程师职业特点
◎浮躁的国内测试界—2006年测试人员招聘感悟
◎测试资源的合理分配
◎桌面检查与同行评分-《软件测试艺术》读书笔记(15)
◎代码走查-《软件测试艺术》读书笔记(14)
◎错误列表-《软件测试艺术》读书笔记(13)
◎代码检查-《软件测试艺术》读书笔记(12)
◎《软件测试艺术》读书笔记(11)_优之共通
◎测试人员的职业发展方向
◎测试资源的合理分配
◎软件测试是提高软件产品质量的必要条件(2)
◎软件测试是提高软件产品质量的必要条件(1)
◎软件测试:不可忽略的阶段
◎自动化测试的优缺点
◎实施IPD
◎软件项目中测试人员的考核
◎走出软件测试的困境
◎加快回归测试的步伐:累积测试分析和目标测试入门
◎《软件测试艺术》读书笔记(10)_人工测试技术
◎《软件测试艺术》读书笔记(9)_原则解析
◎《软件测试艺术》读书笔记(8)_经济学视角解析
◎《软件测试艺术》读书笔记(7)_心理学视角解析(下)
◎《软件测试艺术》读书笔记(6)_心理学视角解析(中)
◎《软件测试艺术》读书笔记(5)_心理学视角解析(上)
◎如何准备软件工程师的面试
◎《软件测试艺术》读书笔记(4)_初次探究
◎测试职业发展生涯
◎《软件测试艺术》读书笔记(3)_一次自我检测
◎《软件测试艺术》读书笔记(2)_前言
◎《软件测试艺术》读书笔记(1)_引子
热门文章
◎软件测试工程师面试问题选登
◎一个初级测试工程师的工作总结
◎软件测试常用术语表
◎测试人员面试三步曲
◎DOS命令大全
◎什么样的测试人员是好的测试人员
◎软件测试基本方法
◎好的测试工程师应具备的素质
◎软件测试入门书籍(2)
◎我在软件公司成长的三年
◎面试官最爱问的问题背后真相
◎软件测试工程师面试题
◎应届毕业生少走弯路的十条忠告
◎有关软件测试的术语定义集锦
◎微软的软件测试方法(一)
◎我的测试经历(1)
◎全景记录:软件测试工程师的一天
◎软件测试步骤
◎谈谈对测试职业的看法
◎漫谈软件测试工程师的角色定位
◎测试需要掌握什么
◎软件测试员自身素质培养
◎测试小技巧集锦之一黑盒测试
◎近10年最强的50本计算机图书,您读过几本?
◎软件测试人员职业发展助手
◎测试要点总结
◎如何制定成功的测试计划
◎测试的主要评测方法(1)
◎什么是ERP,通俗版解释
◎测试经验交流
◎软件测试及其支持工具
◎编写优秀Bug报告的艺术
◎软件产品测试标准
◎从程序员到测试工程师
◎微软的软件测试方法(二)
◎软件测试应遵循的八条原则
◎测试版本大全
◎我的测试经历(2)
◎测试人员的挑战
◎网管和黑客都必须知道的命令
◎QA活动的理解与实施
◎Alpha和Beta测试简介
◎网络最经典命令行
◎想编写出优秀技术文档,先学学这四招
◎个人职业生涯规划发展
◎你适合做测试吗?
◎软件测试的误区
◎我的测试经历(3)
◎软件测试的心理学问题
◎软件测试组织与方法

Google提供的广告