在软件测试工作中,测试工程师与测试管理者都迫切须要获得足够的信息,以考察目前产品测试是否充分或测试已经达到何种程度。然后,基于当前的测试程度,软件测试工程师进行有的放矢地补缺,最终使得目标软件获得最完整的测试;而软件测试管理者则可以通过这项信息反思管理上的得失,进而调配各方面资源,为达到软件的完全测试提供管理上的各类保证。
自动化测试的一个优势就是测试过程更好量化。当我们使用前面介绍的测试工具(Selenium、JUnit等)完成测试时,我们不禁要问:如何度量软件测试的覆盖率呢?这就需要衡量测试覆盖率的工具。
测试覆盖率是评价测试活动的质量、衡量测试执行程度的重要指标之一,它可以看作测试活动所覆盖产品需求与产品所有需求的比率。更准确地说,是测试活动所覆盖软件代码与所有目标软件代码的比率,这包括类、代码块、语句行、分支等。衡量测试覆盖率常用的指标有:
1) 语句覆盖率,或者称代码行覆盖率,用于评价测试代码语句覆盖率;
2) 基本语句块覆盖率是把没有分支的代码块(若干行代码构成的区域)作为一个计量单位,而不是简单的代码行;
3) 决策覆盖率,也称作分支覆盖率,用于评价测试的程序分支覆盖率;
4) 路径覆盖率,用于评价代码从开始到结束所经历的路径中有多少路径被测试;
5) 功能覆盖率,用于评价代码方法被测试的覆盖率。
提高测试覆盖率的传统方法
传统的测试管理与流程虽然没有对测试覆盖率进行良好的量化分析,但依旧可以看到对测试完全程度的追求与尝试。
1. 测试用例的设计与复审
在设计测试用例时,测试工程师遵循的一个原则就是用尽量少的测试用例达到最大的测试覆盖程度。为了尽可能地扩大测试用例的覆盖面,在常规的测试流程中引入复审机制,邀请软件项目的相关人员(如产品经理、开发人员等)共同复审测试用例,以发现问题、提高测试用例的覆盖率。
2. 测试用例的执行与追踪
如果假定所设计的测试用例具有足够高的覆盖率,那么,测试用例能否被软件测试人员严格执行也成为测试管理的关键。在实践中发现,经常有一些测试用例在执行阶段被疏忽,从而导致软件缺陷从用户方反馈回来。从理论上来看,越是具体细微的事务越难于管理监督或准确把握,加上各种资源(如时间、人力等)的约束,每一个软件测试用例及其测试要点的完备执行也同样存在风险。如果又很难获得测试覆盖率的具体信息,这样的风险就很难避免。
3. 软件缺陷的评讲与交流
为了弥补软件测试人员在知识与经验上的不足,许多软件公司都会有典型软件缺陷的评讲与交流,尤其针对在用户那里暴露的软件缺陷。这种活动旨在扩大测试者的眼界,使参与者吸取经验教训,在之后的测试用例设计与执行中,能够提高软件测试的覆盖程度。
常见的测试覆盖率工具
在运用传统方法来提高测试覆盖率的过程中,遇到了很多困难,测试覆盖率工具的使用将是一种有效的解决途径。针对不同编码语言的应用需求,有相应的工具。在测试覆盖率分析上,常见的开源工具有:
1) Cobertura。一个功能比较强的覆盖率分析工具,可以和Ant或maven集成起来使用。它通过检测基本的代码,并观察在测试包运行时执行了哪些代码和没有执行哪些代码,来测量测试覆盖率。除了找出未测试到的代码并发现bug外,Cobertura还可以通过标记无用的、执行不到的代码来优化代码,同时提供API实际操作的内部信息。
2) CodeCover。作为开源的白盒测试工具,可以度量语句、分支、循环和修订的条件/判定覆盖(Modified Condition Decision Coverage,MC/DC)等各方面的测试覆盖率,并且可以针对每个测试用例给出覆盖率报告,目前支持Java a和COBO两种语言。
3) Jcoverage(www.jcoverage.com)。主要用于Java代码的覆盖测试。通过在目标测试类的二进制文件中添加相应指令并与Junit集成,从而完成被测代码覆盖率的分析,并提供具体语句的测试状况。
4) JSCoverage( http://siliconforks.com/jscoverage/)。是一个用于度量Javascrīpt程序的代码覆盖率的工具。它通过度量Web页面使用的Javascrīpt代码,收集被Web浏览器执行的Javascrīpt代码信息来达到统计测试覆盖率的功能,并支持各种流行的浏览器(如IE、Firefox、Opera、Safari等)、不同的操作系统(如Windows、Linux)。
5) Coverlipse是一个易用的、可视化的Eclipse插件,和JUnit无缝集成,能够在一个JUnit运行之后马上显示覆盖结果并把结果导成XML文件,涵盖各种覆盖率数据,包括代码块、分支等覆盖率,并能完成一轮测试覆盖率指标的评估。
6) Clover是一个基本的Java代码覆盖测试分析工具,提供内部测试,即时IDE反馈、交互报告等。
7) rcov是一个用于诊断Ruby代码覆盖率的工具,效率很高,并支持多种模式(standard/标准、bogo-profile、“intentional testing”、dependency analysis/独立分析等),通过简单启发式代码链接推理来获得完全准确的覆盖率信息,以及提供多种前后对照的XHTML和text格式的报告。
EMMA工具概述
EMMA是一个开源的、面向Java代码的测试覆盖率收集与报告工具。它对编译后的Java class文件进行统计代码的测量配置(Instrumentation),在测试执行过程中记录覆盖率信息,并通过多种报表格式对覆盖率结果进行报告。而且EMMA所使用的字节码测量配置(byte instrumentation)可以避免给源代码带来垃圾代码,还确保EMMA摆脱了源代码的束缚,这使得它可以成功应用于功能测试的覆盖率收集工作。
1. EMMA工具的特点
1) 可以和Ant集成,效率很高,适用于大型项目;
2) 支持多种级别的覆盖率数据指标:类、方法、块和行;
3) 支持Java 1.2或更高版本的JVM,且不依赖于任何第三方类库;
4) 提供多种格式(如xml、txt、html等格式)的输出报告,其中html格式还提供逐层深入分析的功能,便于找到未被测试的代码,完成细节分析。
2. EMMA工具的工作原理与模式
实现测试覆盖率统计的测量配置技术有两类:类配置和源码配置。前者把统计代码插入已编译的class文件,而后者则把统计代码插入源代码,然后编译成class文件。EMMA通过向已编译的class文件加入统计测试覆盖率的字节码来生成class文件的测量增强版本,进而来跟踪记录被运行代码信息。EMMA的工作方式,还可以分成两种模式:在线(On the fly)模式和离线(Offline)模式。
1) 在线模式。此模式将测量和执行过程合而为一,即程序一边执行、一边被测量。在线模式下,是先把用于统计的字节码插入到加载的类中,然后生成测量版本。对于这种模式,加入字节码的测量版本并不写入硬盘,其操作发生在JVM内部。虽然运用比较方便,然而缺点也相当明显,如它不能为被Boot ClassLoader加载的类、J2EE容器(具有独特类加载器的类)等生成测试覆盖率报告。
2) 离线模式。此模式将测量与执行予以分离,在类被加载之前,即加入统计字节码。运用这种模式,它从硬盘读入class文件,然后通过测量配置输出带有字节码的测量版本。本模式属于通用模式,而前者主要用于简单的Java应用程序。
3. EMMA工具的运行方式
EMMA共有两种运行方式:命令行方式(Command Line)和Ant集成方式。命令行方式和在线模式一起使用,能够快速产生测试覆盖率报告,适合相对简单的软件项目。而通过Ant任务模式来运行EMMA,更适用于大型的软件项目。
4. EMMA命令行应用方式
在使用命令行方式前,首先必须扩展Java虚拟机,即将emma.jar放到被测组件运行使用的JRE目录下面作为JRE的扩展,以便EMMA可以被调用。emma.jar包含了EMMA核心功能模块的实现和EMMA运行时所需的类文件,这些文件都是使用EMMA所必需的。为了获得emma.jar,需从http://sourceforge.net/project/showfiles.php?group_id=108932下载EMMA的库文件(如emma-2.0.5312-lib.zip),解压后即能得到。
假定示例被测对象在本机运行,并使用默认的JRE,将emma.jar与emma_ant.jar文件复制到JDK路径之下:C:\Program Files\Java\jre6\lib\ext,而实际测试中,将该路径进行相应替换即可。然后进入命令行窗口输入java emma,会获得如下输出结果,表明对于JRE的扩展已经完成。
一次简单的工具实践
先给出简单的源代码(被测试的代码)如下,这段代码的运行结果将会在屏幕上打印“Good Morning!”字符串。
public class GoodMorning {
public GoodMorning() {
System.out.println (”Good”);
}
public static void main (String[] args) {
new GoodMorning();
System.out.println (”Morning!”);
}
}
然后,针对上述程序,运用EMMA测量配置、运行并输出结果,其显示结果如下:
C:\>java emmarun -cp d:\java\GoodMorning
Good
Morning!
EMMA: writing [txt] report to [C:\coverage.txt] ...
从上面显示的结果可以看出,在加载的同时class文件完成了测量配置,程序运行产生的txt格式的report如图所示。
除了上述的txt文件格式的报告,EMMA还提供了多种报告输出形式,这可以通过在“java emmarun”命令后使用不同的参数获得更直观的报告格式。如要了解各参数的使用,可以使用“java emmarun -h”得到相关信息。如使用参数“-r html”生成HTML格式的报告,将以包、类、方法等覆盖率信息有机地组织起来,可以逐步点击直到代码行层次,如图所示。
EMMA报告的组成
EMMA收集的数据包括类(class)覆盖率、方法(method)覆盖率、代码块(block)覆盖率及代码行(line)覆盖率。HTML格式的报告更能清晰地表明这一点。下图是报告的索引(Index)图,显示整个软件包(package)的覆盖率整体状况,包括各个类的情况。
EMMA报告的索引图点击其中一个类(如ShowQuestionStatus.java),进入某个具体类的覆盖率结果。在类覆盖率结果中,显示了类的整体覆盖率情况及该类中各个具体方法(函数)的覆盖率情况。
EMMA报告的类覆盖率图点击其中一个方法(method),可以得到这个方法的代码测试细节。它会以黄色、绿色、红色来标识出代码的执行情况,也就是代码的被测试状况。其中,黄色表示执行不完全,绿色代表已经执行,而红色则表明没有被执行。
EMMA报告的代码行覆盖图测试覆盖率报告中包含了两个方面的内容——测试覆盖的部分和未被覆盖的部分。从经验上看,未被测试所覆盖的部分有如下情况:
1) 测试用例不全,有些功能点或用户使用场景(use case、user scenario)没有考虑到,自然与它们相关的代码就不可能被覆盖;
2) 某些测试用例没有被执行,可能是阶段性测试计划所决定,也可能是人为失误、执行不力;
3) 已被废弃的、或无效的代码;
4)各种异常处理或保护的代码,以及实际测试执行中不容易出现,非常难以覆盖的地方。
有一点要说明的是,即使测试覆盖率(如代码覆盖率)达到了100%,而且测试都通过了,也不能说明软件中不存在缺陷。因为用户需求、测试场景是否被完全覆盖还不能确定,例如某个功能点在代码中没有实现,测试用例也没有,即开发人员和测试人员都忽视了这个功能点,那么代码覆盖率测量是发现不了这个问题的。另外,代码覆盖率对易用性(如操作逻辑、界面是否美观等)问题也是无能为力的。
本文来自朱少民老师的《轻轻松松自动化测试》,如有侵权,请通知后删除
网友评论