Embedded 版 (精华区)
发信人: Zinux (Linux技工), 信区: Embedded_system
标 题: 软件测试与软件测试方案
发信站: 哈工大紫丁香 (2001年10月18日16:24:29 星期四), 站内信件
软件线测试方法与软件测试工具
------------------------------------------------------------------------
----------------------------------------------
摘要:本文简要介绍了软件测试基本理论和基本概念,分析软件测试在在产品研发
过程中的地位与作用,并依据本人多年嵌入式系统开发应用和从事软件测试的经验
,提出了针对我国企业软件测试现状的软件测试解决方案,与此同时向大家介绍了
几种高效,实用的软件测试工具。
关键字:嵌入式软件 软件测试
引言:软件已成为现代智能系统中的核心和灵魂,其规模和复杂性随系统规模增长
不断提高,软件的质量和开发周期对产品的最终质量和上市时间有举足轻重的影响
力,因此软件工程管理、软件分析与测试已成为研究和应用的热点。本文结合软件
工程管理、软件分析与测试在嵌入式软件的开发中应用经验与体会,指出了现今人
们对软件分析与测试应用于产品开发中存在的误区,并针对这一误区,提出了针对
我国企业如何根椐自身现状配置软件测试工具及解决方案。
一. 软件分析与测试的作用
产品开发包括软硬件的设计和调试,而在整个产品设计所涉及到的各个技术层面中
,由于大规模集成电路发展,致使元件的集成度也大大增加,从而为产品硬件设计
的模块化和透明化提供了方便,同时,硬件调试与测试的可操作性为产品性能和可
靠性的提高提供了保证。相反,有关软件调试与测试工作则复杂和困难得多,伴随
着系统规模增长,其软件复杂性指数式增长,隐藏在软件中的问题就越多,这些问
题直接影响了系统性能和可靠性。
一般来讲,软件的开发要经历需求分析、设计、编程和调试、测试几个阶段。由于
分析、设计和编程都由人来完成,软件中的错误在所难免。软件错误往往会导致无
可挽回的、致命的损失,因此软件必须测试,测试必须有效和可行。 软件测试的
目的在于充分暴露软件中存在的问题和缺陷,发现其中的错误并提交测试报告,最
终排除软件中存在的问题,满足和实现用户的需求。
二. 软件检验的手段和流程
目前,软件检验的手段有三类:需求测试,静态测试,动态测试。
静态测试,指无须执行被测代码,而是借助专用的软件测试工具评审软件文档或程
序,度量程序静态复杂度,检查软件是否符合编程标准,借以发现编写的程序的不
足之处,减少错误出现的概率。静态测试在主机上完成,不需目标系统支持,测试
的主要内容有:
(1).编程标准验证
(2).数据流分析技术
(3).质量度量信息
(4).代码结构可视化显示
(5).测试外壳的创建
从以上几点可以看出,静态测试只是对代码进行扫描分析,检测它的语法规则复杂
度等是否符合要求,它主要是为软件的质量保证提供依据,以提高软件的可靠性和
易维护性。
动态测试,是使被测代码在相对真实环境下运行,从多角度观察程序运行时能体现
的功能、逻辑、行为、结构等的行为,以发现其中的错误现象。对于嵌入式系统,
要想保证测试的真实性,就需要将被测代码下载到目标板运行,并且测试系统不要
影响目标系统的运行,就需一定硬件支持。
动态测试方法分为黑盒法和白盒法,黑盒测试是基于功能的测试,只关心软件的功
能,而不考虑其内部,也叫功能测试;白盒测试关心软件内部逻辑结构,测试覆盖
率,是由逻辑驱动的测试。为了较快得到测试效果,通常先进行功能测试,达到所
有功能后,为确定软件的可靠性进行必要的覆盖测试。
在软件开发的不同时期进行动态测试,测试又分为单元测试,集成测试,确认测试
,系统测试。
对于软件动态测试工具需要提供的功能主要有:
1. 功能的测试;
2. 代码覆盖率(CodeCoverage);
3. 性能分析测试;
4. 内存分析;
5. 逻辑触发执行跟踪;
6. 实时多任务操作系统分析。
从动态测试的内容看,动态测试较适用于软件开发末期的软件评测与评估,根据测
试结果对软件代码进行优化,或对软件跟踪分析,从而发现软件中潜在的致命问题
。
静态检查、动态测试和正确性证明都是卓有成效的,软件检验应综合运用以上手段
。
三. 测试策略与测试方案
软件工程中有相当部分是关于软件测试的,软件测试的许多内容是软件工程中关心
的指标,软件工程中对软件项目的管理方法有助于软件测试的实施;软件测试是一
项贯穿于软件开发的系统工程,完备和有效的测试策略可使软件开发的效最大化,
满足测试的各项要求并降低测试成本。只有这样软件测试才有意义.
1: 测试策略:
测试策略描述测试工程的总体方法和目标.描述目前在进行哪一阶段的测试(单元测
试,集成测试,系统测试)以及每个阶段内在进行的测试种类(功能测试,性能测试,覆
盖测试等).
测试策略包括:
(1): 要使用的测试技术和工具;
(2): 测试完成标准;
(3): 影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏,安全性威
胁,测试计划 ,最关键的一步就是将软件分解成单元,按照需求编写测试计划。
把软件分解成单元有几个好处:
(1): 软件需求是测试设计和开发测试用例的基础,分成单元可以更好地进行设计;
(2): 详细的测试需求是用来衡量测试覆盖率的重要指标.
(3): 测试的需求包括各种测试实际的开发所需资源.
测试计划的输入为被测软件,基于需求的测试设计;输出为测试过程和测试用例通过
通过设计测试计划创建可以重用的测试过程和测试用例,同时维护测试过程,测试用
例与相关测试需求的一一对应.
2: 测试方案:
软件测试需要付出成本和代价, 这个成本和代价包括采购测试工具的成本和测试人
员的人工成本,测试越完备,越复杂,测试成本越高; 同时,测试方案要切实可行,测
试内容和结果要有意义; 因此, 测试方案确定需遵循以下原则;
(1): 测试成本最小化;
(2): 测试流程和测试内容完备化;
(3): 测试手段可行化
(4): 测试结果实用化
完备的软件测试要达到各项指标最优几乎不可能,着手软件测试的各单位只能根据
选择折衷软件测试方案。任何人或组织进行嵌入式软件的测试都应深入考虑以上问
题,结合自身实际需要和测试的目的,选定合理测试策略和测试方案。
现阶段,软件测试在我国的大多数企业中尚处在起步阶段,对软件测试缺乏整体的
认识与深入了解,不知道如何根据本企业需求和工程项目的特点配置测试方案, 组
建测试队伍,实施测试工作,因此,在测试工具采购,人员的配备和测试工作中存
在极大盲目性,购置的测试工具束置高阁,不能发挥作用及效益;所做测试工作本
末倒置,测试结果毫无意义。为此,给企业造成的损失不可估量。再者,一部分从
事软件行业的人员对软件测试认识不足,常把测试与调试绞在一起,误认为测试即
调试或将一般性检验工作当成软件测试。更有甚者声称自己编写的软件不需测试。
这种对软件测试工作认识的不足,误解和扭曲严重制约了我国软件产业的发展。为
此,我们提出几种软件测试方案并介绍目前流行的软件测试工具。
(1):需求测试:
由经典的软件工程理论,软件测试是由代码完成后开始的,事实上应从软件的需求
定义开始。软件工程统计结果发现50 以上的系统错误是由于错误的需求或缺少需
求导致的,超过80 的开销花在追踪需求的错误上,这是由于在追踪需求的错误的过
程中,经常会相互纠缠和重复劳动.因此,需求测试是必要的,也是必不可少的。
下面简要介绍一下需求测试工具Caliber-RBT:
Caliber-RBT 是美国TBI集团的产品,它可完成多项对于需求的测试工作,并可通过
需求设计测用例试.让我们看一下Caliber-RBT是怎样工作的: 输入需求: …可以用
一套比较简单的语法定义需求分析, 输入需求定义Caliber-RBT的采用已证明了的
硬件逻辑电路测试的技术.这种算法已证明比软件测试的传统算法可靠成千上万倍.
Caliber-RBT应用了这种算法,并扩展到软件测试,硬件测试的算法用来定义一套必
需的并且充足的测试用例来验证软件逻辑是否正确.
Caliber-RBT有六个优点:
1) Caliber-RBT主要是作为测试用例设计工具,它的输出可以作为测试计划的基础
2) Caliber-RBT可以基于输入生成详细的需求定义.
3) Caliber-RBT可以输出到很多商业工具.
4) Caliber-RBT 直接追踪功能需求和每个测试用例.
5) Caliber-RBT帮助鉴别功能需求是否清析,简明,逻辑一致.
6) Caliber-RBT 基于软件功能逻辑设计测试,这意味着测试独立于语言,硬件,和平
台.
Caliber-RBT使100 需求分析定义的系统功能可以行得到鉴别,相对而言大多数的软
件只达到40-60 的功能覆盖就发行了,并且Caliber-RBT是基于最少的测试用例的,
典型的它可以把测试用例数目缩减到普通方法的10-20分之一,至少4分之一.使用
Caliber-RBT可以以最少的测试用例达到最大的覆盖。
Caliber-RBT把需求分析作为软件的输入,按照一定的格式把输入和输出定义为节
点(NODE),并且说明这些节点之间的相互制约关系,和逻辑关系有了一定的实践.
Caliber-RBT的用户就可以把需求分析直接转换成Caliber-RBT的输入,也可以画出
因果图来表示需求分析的逻辑.通过自动分析因果条件输入, Caliber-RBT找出功能
变化,以保证100 功能覆盖输出逻辑图表表示需求定义之间的关系,测试用例脚本包
含在一个完整的测试集合中功能覆盖矩阵显示哪一个功能被哪一个测试用例测试,
测试用例的矩阵,找出逻辑错误,经过分析可以追踪到原始需求.
Caliber-RBT 可以生成军标498格式(原DODstandard2167A)的测试用例-需求分析追
踪报告:
大多数的测试用例可以在编程之前设计出来!
需求测试贯穿了整个软件开发周期,通过需求测试可指导软件测试的各个阶段,它可
帮助我们设计整个测试的进行,测试计划怎样安排,测试用例怎样选取,软件的确认
要达到哪些要求等等.软件测试,验证,确认只有当具备软件需求分析时才有意义.
(2):单元测试
在软件测试中,尽早进行软件测试发现软件中存在的问题,可减轻系统测试的任务
,大大降低测试成本,单元测试在软件开发哪一个环节进行,是一个值得探讨的问
题,因为这关系到软件测试的效率和测试成本。
从经济上和开发效率上考,单元测试尽可能在软件开发周期中完成,并在主机系统
中进行,这就是说单元测试最好划归研发中心处理,而不全权由测试中心完成。
现阶段,我国着手软件测试的企业,软件测试和研发分属两个不同的部门,彼此独
立。这对于与软件开发紧密相关的单元测试带来了极大的麻烦。因为单元测试测试
内容多,且琐粹,一旦发现测试指标不满足要求,需要回归测试,反复进行,对于
嵌入式软件测试来说,难度更大。因为嵌入式软件编写和测试要求熟悉集成开发环
境和目标系统配置,显然相关项目软件工程师对于开发环境和目标系统了解及测试
自身编写的软件更是得心应手。
这里再次强调最大化地在主机系统环境中进行单元测试,除了特别具体指定了单元
测试直接在目标环境进行外。在主机平台上运行,测试速度比在目标平台上快得多
,当在主机平台上完成测试,可在目标环境上重复作一简单的确认测试。
单元测试静态分析工具一:McCabeQA
McCabeQA是美国McCabe&Association公司的产品。它利用著名学者McCabe的软件结
构化测试理论,使用V(G)圈复杂度=模块内部独立现行路径数来度量软件的复杂
度。
McCabe最大的特点就是可视化,以独特的图形技术表示代码,得到整个软件系统的
结构图,这比语言描述更清楚,同时等到了各种基于工业标准评估代码复杂性,包
括V(g),EV(g), DV(g), Halstead 等数十种静态复杂度度量。用不同的颜色表示
软件模块的复杂性,测试人员的测试重点放在质量差的模块上;提供各种质量模型
深入评价软件质量,纪录软件质量波动曲线和版本变化趋势分析,从而控制软件修
改不同阶段的质量。在单元级McCabe显示模块的流程图,并且相对应标出了代码的
位置,视图与代码相互对应,可很快找出问题所在。分析最终可得到各种可定制的
符合工业标综合报告,包括文本和图形。
McCabe提供了衡量软件的新的方法,提供代码好与坏的标准,鉴别问题代码,评估
测试付出。
单元测试静态分析工具二:Cantata
Cantata是英国IPL公司提供的一种强大的测试工具,主要针对C,C++ 语言的测试
。它的静态分析部分StaticAanlysis 可完成一般的静态测试。Cantata 检查代码
标准,测量并检查代码复杂性,确定软件的可维护性和标准。
McCabe,Myers,Hansen,Halstead,Harrison,检查数据流。最终的静态测试结果可由
EXCEL 处理得到图形化报告。
单元测试动态分析工具三:Cantata
DynamicTestin 动态测试软件是否符合需求,可测C和C++代码,包括嵌入式软件测
试。
DynamicAnalysis 动态分析测试所达到的覆盖率,决定测试是否完成。支持MC/DC
覆盖分析,达到DO178B-A标准。
Cantata提供通过自动分析源代码,得到测试用例模板TCD,应用所提供脚本语言:
Input和Output定义各种输入输出,可模拟现实世界的各种数据,文件,设备等等
。定义可望而不可及模块模拟被测模块所调用的下级模块。模板自动可转换为C语
言的测试脚本。
测试的过程与建立一般的工程一样,利用目标编译器(一般的或嵌入式的),可通
过命令行执行,也可把编译连接过程嵌到工程makefile中 进行自动的测试。
Cantata集成到了VC++或BORLANDC++之IDE环境中,可参与软件的开发过程,做到过
开发边测试,而不用转换开发环境。
Cantata包含以下几个主要部分:
CTH-The Cantata Test Harness,测试功能库, Cantata通过CTH提供的测试函数执
行测试,提供测试所需用例的输入输出,并检查输出结果是否符合要求,给出
PASS/FAIL的确切结果。打桩和动态分析的执行也是利用CTH。
CTS-The Cantata TestScript Generator,测试脚本生成器,可自动完成测试用例
定义文件TCD到测试脚本的转换。对于熟练的用户,可以直接利用CTH提供的库函数
,直接编写C语言测试脚本。
Cantata提供可在主机平台和目标平台重复的和可移植的测试脚本,在主机或目标环
境stub可方便的模拟任何单元,包括一些具体的目标. Cantata可直接把文件,设备
和系统效用当作文件来比较,通过这种手段来测试真实世界的输入输出.
它的测试报告, 以文本文件形式输出到cantata.ctr, 或postscript格式的图表
(3):集成测试
软件集成也可在主机环境上完成,在主机平台上模拟目标环境运行,当然在目标环境
上重复测试也是必须的,在此级别上的确认测试将确定一些环境上的问题,比如内存
定位和分配上的一些错误.
在主机环境上的集成测试的使用,依赖于目标系统的具体功能有多少.有些嵌入式系
统与目标环境耦合的非常紧密,若在主机环境做集成是不切实际的.一个大型软件的
开发可以分几个级别的集成.低级别的软件集成在主机平台上完成有很大优势,越往
后的集成越依赖于目标环境.
(4):系统测试
系统测试是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算
机硬件,外设,操作系统,数据和人员结合在一起,在实际运动的环境下对计算机系统
进行一系列的集成测试和确认测试.由此可知,系统测试必须在目标环境下运行,
当单元测试和集成测试完成之后,系统测试功用则在于评估系统环境下软件的性能
,发现和捕捉软件中潜在的BUG.
下面简要介绍一下可用于系统测试目的实事在线软件测试和分析工具TRACE32,目前
这一工具广泛应用于嵌入式软件在线动态测试中。
Trace32的软件测试功能包括:1:代码覆盖率(CodeCoverage);2:性能分析测试
;3:内存分析;4:逻辑触发执行跟踪;5:实时多任务操作系统分析。以下将简介
Trace32软件集成调试和测试工具。
Trace32由德国Lauterbach公司生产,是全球顶级软件集成调试和测试工具,该系
统具有开放式模块化的系统结构,支持60种以上的编译器,6种编程语言,20种以
上的RTOS, 300种以上的处理器,同时集成了数字示波器,脉冲信号发生器,逻辑
分析仪,软件在线测试,
由于可配置高达4MByte大容量跟踪分析存储器,可捕捉长达一周执行的软件信息。
Trace32强大的逻辑分析触发系统可设置10级嵌套逻辑事件断点,通过对跟踪存
储器中的软件采用正反向跟踪分析,可捕捉软件中隐性偶发的随机性BUG。在软件
测试方面,对被测软件,无需打桩即可对软件进行实时在线测试,对函数执行时间
进行准确计算和统计,从而发现系统存在于软件中的瓶颈,便于提高系统效率。
Trace32亦可分析20种以上的RTOS,可测试RTOS中task和执行时间,唤醒时间,
转换时间,中断的响应时间,并阅读mailbox,semaphore,pipeline,queue的信息,
可监测CPU的负荷和Memory的分配情况。Trace32
--
puke!
技工而已
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.239.152]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间:206.671毫秒