工具比较

1、软件在系统中的作用

计算机应用在系统中越来越广泛，从系统层到其组成部件都可能嵌入各种不同的计算机组成成分。在这样的系统中，无论硬件、软件还是操作人员发生故障，都可能引起系统失效，其中可能造成严重损失，要保证系统质量就必须保证这三方面都达到相应的质量水平，软件质量不能不考虑。

过去系统设计和指挥人员考虑质量问题主要考虑硬件质量和人的因数，现在系统嵌入了大量的计算机系统与软件，如果不考虑软件质量因数，认为软件100%可靠，是不现实的。软件故障在复杂的指挥、控制等程序中，在一定的输入和运行环境下就会显露出来从而造成系统失效。此类事件举不胜举。

尤其要注意的是软件往往是系统可靠性的簿弱环境，需要格外重视。例如，70年代美国军用计算机硬件的平均故障间隔时间MTBF约为2000小时，而软件仅为448小时；1986年的IBM 3080类的CPU的MTBF达80000小时，而当时新开发的软件的MTBF只有160~200小时。D.L.Parnas指出：“软件系统的状态数要比计算机非重复部分的状态数大许多数量级。这一差别是软件系统相对不可靠的一个原因”。因此，“当代许多系统中软件不可靠是系统失效的主要原因”。

因此，我们要充分认识软件质量对整个系统质量的重要意义，在工程实践中不仅要重视硬件质量，也要重视软件质量，加强软件质量保证工作和相关技术研究，提高软件质量，进而提高整个系统质量。

2、软件测试的意义

软件测试在整个软件开发过程中占有非常突出的重要位置，无论怎样强调软件测试的重要性以及它对软件质量的影响都不会过分。

1）、在软件开发的一系列阶段和步骤中，都可能引入错误，软件需求的描述可能有错或不完善；软件的设计可能有错；就是简单的程序输入也会出错。随着计算机应用的不断深入，软件技术不断发展，软件的规模和复杂度也相应增加，这使得错误更可能发生。

2）、其次，软件测试开销在软件开发总成本中占有很大的比例，根据Boehm统计，这个数值一般在30%至50%，在极端情况下如使命苛刻性或安全苛刻性软件，测试费用可能相当于软件工程所有其它步骤费用总和的三到五倍。由此可见，要成功地在资源限制内开发一个软件，必须重视软件测试管理和技术手段的有效性。

3）、在目前软件工程开发方法学指导下开发软件，软件测试是保证软件质量和可靠性的重要手段，可在软件开发各个阶段查找软件缺陷或错误。

无论从软件开发方法学还是软件测试自身的效益看，软件测试都是保证软件产品质量的重要手段。

3、国内、外软件标准

鉴于软件测试的重要性，国际上的标准化和认证组织已经制定出了一些软件标准（在ISO-9001以及SEI CMM框架中）。对于软件的开发过程即可通过这些标准进行约束和度量。我国军方对软件也制定了系统的标准和规范如“武器系统软件开发”（GJB 2786-96）、“军用软件测试与评估通用要求”（GJB 2434-95）、“武器系统软件开发文档”（GJB 438A-97）、“软件可靠性和安全性设计准则”（GJB／Z 102-97）、“海军装备软件质量测试实施细则”等。

目前所内项目绝大多数承担了国家重点型号研制任务，这些项目中的软件皆为任务苛刻性或安全苛刻性软件或系统，必须按照国家相应的软件开发与测试标准来进行，因此从标准依从性来看，开展软件测试工作也成为必要。

1

二、 软件测试方法

软件测试方法从实现技术角度可分为静态测试与动态测试两种，从过程来看分为单元测试、集成测试与系统测试。不同的方法与工具在软件开发的不同阶段能有效的发现不同软件缺陷与错误。

1、静态分析方法

静态分析方法不需执行被测软件，在程序开发初期即可进行，可有效地辅助代码评审与走查，从而查找软件缺陷与错误。一般静态分析方法有：

1) 编码规则检查

在项目开发过程中制定并实施一套行之有效的编码规则对软件系统的质量提高很有帮助，编程规则的制订需从多方面考虑，主要需要了解语言与编译器如何影响软件错误的发生，一般地具有下列几方面的因数：

编程语言与标准缺陷

编程语言发展至今已有数十年历史，但仍不存在有效的算法与技术能验证编程语言能100%实现编程的意图，多数编程语言具有各种问题，如类型定义不严格、缺乏运行时刻检查等。

编译器问题

许多编译器声称遵循某编程语言标准，但经验表明由于缺乏足够的测试与验证，编译器在许多方面不同情况下存在问题。

编程人员问题

大多数编程人员没有很好地了解编程语言，更没有很好地阅读编译器手册，往往对语言结构或使用方法缺乏足够的认识，再加上没有经过良好的系统编程设计训练，误用情况经常发生。

编程规则是用于帮助编程人员避免编写缺陷代码的一系列规则，此规则定义了可接受的与不可接受的语言结构或使用方法，不可接受的语言结构或使用方法易于出错或误解，而可接受的语言结构或使用方法可避免错误的发生。往往编程规则是编程语言的子集，其清除了编程语言中易于出错或误解的部分。

2) 数据流分析

数据流分析是用控制流图来分析数据发生的异常现象（数据异常），这些异常包括初始化、赋值或引用过程中行为序列的异常。

研究结果表明这种数据流分析技术（Data Flow Analysis），是查找软件错误最有效的途径或方法之一。数据流分析技术可查找程序中典型的数据引用错误及程序接口错误。

3) 软件度量分析

对于软件开发工程师、项目负责人及高级管理者来说，软件质量的管理与监控是非常困难的且费时。需在项目开发过程中根据项目开发的特点制定相关的软件质量模型，此软件质量模型由一系列软件度量指标组成，一旦软件质量模型确定后可按此模型进行检查，从而很好地控制软件产品的质量。

2

2、动态测试方法

动态测试方法主要是通过对被测动态执行从而发现软件错误，在动态测试实施过程中主要验证被测软件的功能（黑盒测试法）和代码覆盖率（白盒测试法）。动态测试按照步骤分为单元测试、集成测试与系统测试。不同测试阶段要求不一样。

1) 单元测试/集成测试

单元级软件测试已经被公认为行之有效的软件测试方法，使用单元级软件测试可在软件开发早期发现软件故障或缺陷，从而提高软件可靠性同时减少软件测试开销。

传统的用于单元级软件测试采用人工方式编写测试驱动与桩模块，因此具有测试程序可靠性低、开销大、依赖于测试人员经验等问题，同时由于大都测试时间花费在编写测试程序上，因此测试人员积极性不高，给软件测试效果带来影响。

因此借助于工具自动生成测试驱动与桩模块可提高测试效率，并保证测试可靠性。

在单元/集成测试阶段需同时进行代码覆盖率以验证测试的有效性，一般地单元/集成测试阶段覆盖率指标要求高。

2) 系统测试

系统测试阶段需针对被测系统特点搭建系统测试平台，并借助代码覆盖率分析工具对系统测试用例验证测试有效性，从而优化测试。在系统测试时进行代码覆盖率分析需考虑代码插装对被测软件的影响。

1) 编码规则检查

对于程序员来说，能工作的代码并不等于“好”的代码。“好”代码的指标很多，包括易读、易维护、易移植和可靠等。其中，可靠性非常重要，尤其是在那些对安全性要求很高的系统中，如飞行器、汽车和工业控制中。这些系统的特点是：只要工作稍有偏差，就有可能造成重大损失或者人员伤亡。一个不容易出错的系统，除了要有很好的硬件设计（如电磁兼容性），还要有很健壮或者说“安全”的程序。

然而，很少有程序员知道什么样的程序是安全的程序。很多程序只是表面上可以干活，还存在着大量的隐患。当然，这其中也有C/C++语言自身的原因。因为C/C++语言是一门难以掌握的语言，其灵活的编程方式和语法规则对于一个新手来说很可能会成为机关重重的陷阱。同时，C/C++语言的定义还并不完全，即使是国际通用的C/C++语言标准，也还存在着很多未完全定义的地方。要求所有的嵌入式程序员都成为C/C++语言专家，避开所有可能带来危险的编程方式，是不现实的。最好的方法是有一个针对安全性C/C++语言编程规范，告诉程序员该如何做。

C程序设计中存在的风险可能由5个方面造成：程序员的失误、程序员对语言的误解、程序员对编译器的误解、编译器的错误和运行出错(runtime errors)。

程序员的失误是司空见惯的。程序员是人，难免会犯错误。很多由程序员犯下的错误可以被编译器及时地纠正（如键入错误的变量名等），但也有很多会逃过编译器的检查。相信任何一个程序员都曾经犯过将“= =”误写成“=”的错误，编译器可能不会认为

if(x=y)

是一个程序员的失误。

C语言非常灵活，它给了程序员非常大的自由。但事情有好有坏，自由越大，犯错误的机会也就越多。 如果说有些错误是程序员无心之失的话，那么因为程序员对C语言本身或是编译器特性的误解而造成的错误就是“明”知故犯了。C语言有一些概念很难掌握，非常容易造成误解，如表达式的计算。

3

另外，不同编译器对同一语句的处理可能是不一样的。例如整型变量的长度，不同编译器的规定就不同。这就要求程序员不仅要清楚C语言本身的特性，还要了解所用的编译器，难度很大。

还有些错误是由编译器（或者说是编写编译器的程序员）本身造成的。这些错误往往较难发现，有可能会一直存留在最后的程序中。

有句话说得好，“正确的观念重于一切”。编程规范对于程序员来讲，一个很重要的意义就是提供给他们一些建议，让他们逐渐树立一些好的编程习惯和编程思路，慢慢摒弃那些可能存在风险的编程行为，编写出更为安全、健壮的代码。比如，很多程序员都会忽略注释的重要性，但这样的做法会降低程序的可读性，也会给将来的维护和移植带来风险。程序员经常要接触到各种的编译器，而很多C程序在不同编译器下的处理是不一样的。

鉴于编码规则的重要性，无论是国内还是国外相关组织、行业或企业都制定了相应的软件编码规则，这些规则限制了编程随意性，提高编码的安全性，大大提高软件代码的质量。

国内、外编码标准主要有：       

MISRA C—汽车行业安全性C编码规则（最新版本为MISRA C-2004）； DERA C—英国防务软件编程规则；

EADS C/C++--欧洲宇航与防务系统公司C/C++规则； AV C++--洛克希德-马丁公司航空飞行器C++规则； High Integrity C++规则

GJB5369-2005航天型号C语言安全子集； 海军装备软件质量测试实施细则。

市面上编码规则检查工具有：LDRA公司Testbed、Programming Research公司QA C/C++、Telelogic公司Logiscope等。表一详细列出这几种工具比较情况，通过综合评估LDRA Testbed在编码规则检查功能方面具有如下优势：

   

支持多种国内、外软件编码规则，直接支持GJB-5369安全C编码规则； 支持所有C/C++编译器； 图形化界面，易用性强；

使用TBaudit具有代码评审能力，并可自动生成中文报告。

4

表1—编码规则检查工具比较表

比较项目 LDRA Testbed C/C++ PRQA C/C++ Telelogic Logiscope 对编码规则支支持MISRA C，MISRA 持程度 C-2004，EADS C/C++，DERA C/C++，AV C++，High Integrity C++，GJB5369-2005，海军实施细则； 支持MISRA C，MISRA 支持MISRA C，MISRA C-2004，High Integrity C-2004，C++ C++； 通过添加国军标模块号称可以支持GJB5369-2005，但与国军标对应关系很不一LDRA公司Mike Hennell先致，比方说国军标某条编码生是MISRA组织编码规则制规则必须对应到PRQA C定者，目前又参与MISRA 中几条规则，反过来，PRQA C++规则制定； C中某条规则可能对应GJB中几条规则。这样标准依从LDRA公司与洛克希德-马丁性检查起来很麻烦，特别是公司共同为JSF联合攻击战报告这一部分。另外，GJB斗机项目制定Air Vehicle 中有6条规则PRQA不支C++编码规则制定，并且持。 LDRA公司Testbed产品被指定为整个JSF项目编码规PRQA C/C++号称比则检查工具； TESTBED规则多，但细分析下来发现很多规则是GJB5369-2005是由航天软C/C++词法与语法规则（即件评测中心制定，由于此标属于编译器检查范围）。另准制定完全参照LDRA 外一个规则多的原因是分类TESTBED编码规则集，因此过细，比如函数返回类型不从编码规则名称、对应关系一致本来可以用一条规则来上看完全一致，我们国内军定义，但PRQA分解成很多品研制单位大都采用此标种组合，每一种规则作为一准。 条规则。 支持编译也比较多，但对编写的程序有要求，要严格按照ANSI C，否则经常分析不下去。 图形界面 适应编译器能采用自主语言解析器，并且不详。 力 解析器接口开放，可以适应所有国内使用的编译器环境。 易用性 中文报告 图形界面 图形界面 通过TBAUDIT自动生成编可以生成中文报告，但不能可以生成中文报告，但码规则检查报告，并且使用辅助将评审意见保存到数据不能辅助将评审意见保存到数据库或报告中。 TBAUDIT可以辅助人工评审库或报告中。 工作，并将评审意见保存到数据库或评审报告中。 5

2) 数据流分析

静态数据流分析技术可以用来查找软件中数据流异常及软件模块接口方面的问题，一般地，静态分析工具如如LDRA Testbed、McCabe、PRQA及Logiscope都能分析简单的DD、UR、DU等数据流问题，除了这些数据流问题问题外，LDRA Testbed工具在数据流分析上具有强大的优势，能查找50多种数据流问题，同时Testbed对所有路径情况下数据流进行异常分析，因此分析层次更深入。

另外，LDRA Testbed数据流分析功能还可以用于对软件模块（子程序）做接口分析，并自动生成每个软件模块（子程序）的头注释，可以辅助用户编写软件文档。这一功能对用户很实用，其它工具都不具备。

表2—LDRA Testbed静态数据流分析一览标 LDRA Testbed静态数据流分析规则 总结：1. clear path 关于return 的，编译器能检测出，并以警告提示。 变量和参数的clear path，编译器检查不出 Static Data Flow Analysis 1 D : Unused Procedure Parameter Static Data Flow Analysis 2 D : Function does not return a value on all paths Static Data Flow Analysis 3 D : Actual Parameter is also global to procedure Static Data Flow Analysis 4 D : Variables declared but not used in code analysed. Static Data Flow Analysis 5 D : data flow anomalies found. Static Data Flow Analysis 6 D : Recursion in Procedures calls found. Static Data Flow Analysis 7 D : DU data flow anomalies found. Static Data Flow Analysis 8 D : DD data flow anomalies found. Static Data Flow Analysis 9 D : Defined parameter has possible clear path Static Data Flow Analysis 10 D : Globals used inside procedure Static Data Flow Analysis 11 D : Parameters do not match expected actions Static Data Flow Analysis 12 D : Referenced parameter has possible clear path Static Data Flow Analysis 13 D : Global used in procedure matches local parameter Static Data Flow Analysis 14 D : Attempt to change parameter passed by value Static Data Flow Analysis 15 D : Unused Procedural parameter Static Data Flow Analysis 16 D : Identical Actual Parameters in Call Static Data Flow Analysis 17 D : Identifier exceeds *** sig chars Static Data Flow Analysis 18 D : Identifier name reused Static Data Flow Analysis 19 D : Procedure called before being defined Static Data Flow Analysis 20 D : No declaration for variable found before use Static Data Flow Analysis 21 D : Procedure declared in an inner block Static Data Flow Analysis 22 D : Function has global variable side effects Static Data Flow Analysis 23 D : Function has parameter side effects Static Data Flow Analysis 24 D : Procedure definition has no associated prototype Static Data Flow Analysis 25 D : Scope of variable could be reduced Static Data Flow Analysis 26 D : Variable should be defined once in only 1 file Static Data Flow Analysis 27 D : Variable should be declared static

MSVC编译器 未报警 警告 未报警 警告 警告 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 警告 报错 未报警 未报警 未报警 未报警 未报警 警告 未报警 6

LDRA Testbed静态数据流分析规则 Static Data Flow Analysis 28 D : Potentially Infinite loop found Static Data Flow Analysis 29 D : partially used structured procedure parameter Static Data Flow Analysis 31 D : Parameter Structure mismatch Static Data Flow Analysis 33 D : No real declaration for external variable Static Data Flow Analysis 34 D : Procedure name re-used in different files Static Data Flow Analysis 35 D : Expression has side effects Static Data Flow Analysis 36 D : Prototype and Definition name mismatch Static Data Flow Analysis 37 D : Function has persistent local side effects Static Data Flow Analysis 38 D : More than one control variable for loop Static Data Flow Analysis 39 D : More than one entry to a loop Static Data Flow Analysis 40 D : More than one exit from a loop Static Data Flow Analysis 41 D : Procedure call has no prototype declared Static Data Flow Analysis 42 D : Local pointer returned in function result Static Data Flow Analysis 43 D Divide by 0 found Static Data Flow Analysis 45 D Pointer not checked for null before use Static Data Flow Analysis 47 D Unused inspect annotation Static Data Flow Analysis 48 D Attempt to write to unopened file Static Data Flow Analysis 49 D File pointer not closed on exit Static Data Flow Analysis 50 D Memory not freed Static Data Flow Analysis 51 D Attempt to read from freed memory Static Data Flow Analysis 52 D Not used Static Data Flow Analysis 53 D Attempt to use uninitialised pointer Static Data Flow Analysis 54 D Unsafe use of function pointer variable Static Data Flow Analysis 55 D Modification of loop counter in loop body MSVC编译器 未报警 未报警 报错 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 警告 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 未报警 7

3) 软件度量分析

软件产品的质量跟软件产品本身特性、软件产品外部特性及软件产品开发过程直接相关，为了控制与跟踪软件产品的质量必须建立一个软件质量模型，并在软件开发过程中对模型中每个度量指标进行客观度量与统计分析，正如爱因斯坦所说“如果你不能测量它，就很难控制它”，软件质量需要软件度量。

往往很多软件工程师对软件度量存在误区，认为软件度量不能发现软件中错误，不像编码规则检查或数据流分析技术那样能“立竿见影”，因此没有必要做软件度量分析。NASA专门有一个部门从事这方面研究，通过对大量的软件项目进行统计分析，发现软件产品质量与软件本身一些特性指标如McCabe圈复杂度是相关的（相关系数位0.96），如果说编码规则检查、数据流分析技术是从微观上对软件的缺陷与错误进行检测的话，软件度量则是从宏观上对软件产品的开发进行跟踪与控制。

软件内部特性指标很多，但真正能反映软件产品质量的代码本省的内部特性指标不多，IEEE公布的已被广泛使用并得到业界认可的代码本身特性指标有两个即McCabe圈复杂度指标与Halstead软件科学度量指标，NASA软件保证技术中心提出的软件度量模型也只用了McCabe圈复杂度、基本McCabe圈复杂度、代码行大小、注释行比例等指标。

软件项目开发特别是大型软件项目开发不进行软件度量是不可行的，但过分的软件度量则是一种资源浪费，会增加软件开发负担。因此合理地选择软件度量指标构成软件度量模型很有必要，国内很多标准对这方面都有明确的要求，比如《海军装备软件质量测试实施指南》中对单元级、集成级及系统级软件度量指标都有明确的要求，国外NASA专门有一个部门从事这方面的研究。

能进行软件度量分析的工具很多，主流产品有Testbed、PRQA、McCabe、Cantata及Logiscope，比较这方面的功能主要考虑的软件度量指标种类。从指标种类来看，针对C语言各个产品指标种类差不多，C++方面Logiscope要多很多，很多是无关痛痒的非关键性指标，在实际软件工程中没有得到广泛使用。 LDRA Testbed支持软件工程度量活动中必须的软件度量指标，具有现实的工程意义，LDRA Testbed针对C语言支持的软件度量指标有：

        

控制流结点度量(Control Flow Knots)； LCSAJ 密度度量(LCSAJ Density)； 扇入/扇出度量； 循环深度度量； McCabe 圈复杂度； Halstead软件科学度量； McCabe Essential复杂度； 注释行度量； 代码可达性度量；

等等。

同时使用TBaudit工具可以由用户自定义软件度量模型，并生成WORD中文软件度量报告。

8

4) 单元与集成测试

单元测试是对软件基本组成单元进行的测试，单元测试可以在软件开发早期发现软件缺陷或错误，在单元测试阶段除了使用静态测试技术（编码规则检查、数据流分析等）外，同时可以采用动态测试技术。一般所指的单元测试为动态单元测试。

动态单元测试需要搭建单元测试环境，即测试驱动(Test Driver)与桩模块（Stub），同时单元测试时需要进行代码覆盖率分析。

目前支持单元测试的工具有LDRA公司Testbed/TBrun、IPL公司Cantata++、Parasoft公司C++Test及Vector Software公司VectorCAST，这些工具都可以用来搭建单元测试环境并进行代码覆盖率分析，但从实现方式上来看不尽相同。

从表2可以看出LDRA Testbed/TBrun在单元测试方面具有很强的优势，国内大多数客户单元测试工具选择LDRA TBrun。

9

表2-单元测试工具比较表 比较项目 测试驱动 TBrun C++Test VectorCAST Cantata++ 测试驱动实采用图形化界面采用图形化界面采用图形化界面比较老的版本采现方式 输入测试数据与输入测试数据与输入测试数据与用测试脚本，新版输出结果比较。 输出结果比较。 输出结果比较。 本采用C或C++语言编写测试驱动，Cantata++可以先自动生成一个测试模板，然后测试人员在此测试模板基础上编写测试程序。 测试输入/输对指针、数组、结出数据 不能对指针、数不能对指针、数不能支持范围测构等复杂数据可组、结构等复杂数组、结构等复杂数试，对指针、数组、以自动处理； 据自动进行处理； 据自动进行处理； 结构等复杂数据不能自动进行处理，需要手工编写测试输入程序，效率很低。 可以自动根据数可以自动根据数不能自动根据数不能自动根据数据类型自动生成据类型自动生成据类型自动生成据类型自动生成最大、最小及中间值测试数据； 最大、最小及中间最大、最小及中间最大、最小及中间值测试数据； 值测试数据； 值测试数据； 支持范围测试输不能支持范围测不能支持范围测不能支持范围测入； 试； 试； 试； 测试计划 支持MC/DC及LCSAJ基本路径测试计划。 不支持 不支持 不支持。 必须辅助使用McCabe工具补充这一功能，McCabe可以生成基本路径与MC/DC测试计划。 负向测试支持。 （negative） 单元测试除了需要做正向测试，即被测单元执行后输出值应该是什么期望值外；同时

10

不支持 不支持 支持 比较项目 TBrun 需要做负向测试，即被测单元执行后不因该改变哪些变量值。 C++Test VectorCAST Cantata++ 桩模块 实现方式 图形界面方式进图形界面方式进手工编写桩模块。 手工编写桩模块。 行桩模块设计，同时支持手工编写桩模块。 行桩模块设计。 桩模块管理 具有桩模块管理没有桩模块管理没有桩模块管理必须采用测试脚功能，可以设定何功能，所以很难实功能，所以很难实本语言或C/C++种情况下模拟何现不同情况下桩现不同情况下桩语言方式编写桩种输出数据，使用模块输出。 模块输出。 模块管理功能，所灵活。 以很难使用。 桩模块验证 支持桩模块输入不支持桩模块输支持桩模块输入支持桩模块输入参数验证、桩执行验证。 入参数验证、桩执参数验证，但不支参数验证、桩执行行验证。 持桩执行验证。 验证。 只能保存测试驱老版本支持以测动源程序（C/C++试用例脚本文件代码），不支持测（TCD）方式保试用例文件方式存测试用例。 保存。 新版本好像只以C/C++测试驱动源程序方式保存。 测试用例管理 测试用例保支持以测试用例不详。 存 脚本文件（TCF）方式保存测试用例，便于回归测试。 测试用例复既可以在图形化不支持 制、删除功能 界面方式直接复制与删除测试用例（使用非常方便），也可在测试用例脚本文件上实现。 只能在C/C++测老版本必须在测试驱动源程序中试用例脚本文件实现，很不方便。 上实现，很不方便； 新版本只能在C/C++测试驱动源程序中实现，更不方便。 自动隔离子在做单元测试时不支持此功能。需不支持此功能。需不支持此功能。需程序 经常需要隔离某要用户将被测程要用户将被测程要用户将被测程些子程序，TBrun序中子程序进行序中子程序进行序中子程序进行采用图形化界面拆分。 拆分。 拆分。 方式自动隔离子程序，不需修改被 11

比较项目 TBrun 测源程序。使用非常灵活，在实际工程中经常会用到此功能。 C++Test VectorCAST Cantata++ 回归测试 使用脚本方式进必须在图形界面基于C/C++源码老版本基于脚本行回归测试。 方式下做回归测方式加批处理方方式进行回归测试。 式进行回归测试。 试； 但新版本基于C/C++源码方式加批处理方式进行回归测试。 覆盖率分析 支持覆盖率语句、分支、语句、分支、语句、分支、语句、分支、种类 MC/DC、LCSAJ、MC/DC MC/DC MC/DC、调用等。 调用等。 显示方式 同时支持动态控只支持文本方式。 只支持文本方式。 支持文本方式。 制流程图（反标注显示分支判断条件，辅助测试数据设计）与文本、HTML报告两种方式。 支持平台 由于Testbed/ 只支持GCC、测试模板不开放，由于其功能测试只支持现有的平报告与覆盖率测台，很难移植到新试报告的生成都的平台（需要厂家是在目标平台生支持）。 成并通过端口回送到主机平台，因此需要连接一很大目标库，对资源有限的平台如8031、TI TMS320C3x就没法支持。 TBrun实现单元MSVC、测试采用开放的GREENHILL。 模板，因此很容易集成各种被测试平台，国内、外碰到的平台都可以支持。 通过Target Package可以与各种平台自动集成。

12

5) 代码覆盖率分析

在软件测试过程中需要评估软件测试的充分性，软件测试充分性可以从两个方面的指标来评估，即软件需求覆盖率指标与代码覆盖率指标。通过需求覆盖率指标可以验证“系统或软件是不是做了其应该做的事”，通过代码覆盖率指标可以验证“系统或软件是否做了其不应该做的事”，代码覆盖做的越充分软件或系统中“不该做的事”就越少，因此通过代码覆盖率分析可以增强对代码的信心。

代码覆盖充分性是通过代码覆盖率指标来体现的，有语句覆盖、分支覆盖率、调用覆盖、基本路径覆盖、MC/DC覆盖等，不同关键程度的软件需要不同的代码覆盖率指标要求，不同阶段（单元、集成、系统）指标也不一样，不同的项目或组织要求也不一样。比如航天对A、B级软件在单元级测试时要求语句覆盖率、分支覆盖率要求100%，在集成与系统级测试时语句覆盖率要求100%，而分支覆盖率要求95%；海装软件质量实施指南对A级软件单元测试时要求语句覆盖率、分支覆盖率及MC/DC100%，在集成与系统级测试时模块间调用覆盖率要求100%，B级软件单元测试时要求语句覆盖率、分支覆盖率100%（没有要求MC/DC100%），在集成与系统级测试时模块间调用覆盖率要求100%。

市面上可以支持的代码覆盖率工具有Testbed、VectorCAST、Cantata、McCabe、Logiscope及CodeTEST。可以从覆盖率分析实现方式、覆盖率指标、支持嵌入式程度及图形化等几个方面对这些工具做比较，见表4-覆盖率分析工具比较表。

通过综合评估分析，LDRA Testbed在代码覆盖率分析方面具有如下优势： a) 同时支持单元、集成与系统级测试代码覆盖率分析； b) 具有图形化调用图/控制流程图方式显示代码覆盖率； c) 支持BITMAP方式，代码插装后执行效率最高； d) 代码插装模板开放，适应所有主机与嵌入式平台。

13

表4-覆盖率分析工具比较表 比较内容 覆盖率指标 Testbed Logiscope VectorCAST CodeTEST Cantata++ McCabe 语句、分支、MC/DC、语句、分支、MC/DC、调用、LCSAJ基本路调用。 径。 没有基本路径覆盖Testbed独特之处是率。 提供LCSAJ基本路径覆盖率分析，此覆盖率列入英国STAN-DEF 00-55标准。国内客户不用做路径覆盖。 语句、分支、MC/DC、语句、分支、MC/DC、语句、分支、MC/DC、语句、分支、MC/DC、调用。 调用。 调用。 调用、McCabe基本路径。 没有基本路径覆盖没有基本路径覆盖没有基本路径覆盖率。 率。 率。 McCabe基本路径覆盖（说NIST美国国家标准局建议用此指标），国内标准没有强调基本路径覆盖率。 图形化支持 可以使用动态调用调用图与控制流程图没有调用图与控制流图、控制流程图显示显示代码覆盖率功能程图显示代码覆盖率代码覆盖情况，并在很弱。 功能。 控制流程图上反标注显示每个分支判定条件，方便测试数据选择。 可以自动生成没有此功能。 MC/DC与LCSAJ基本路径测试计划。 没有此功能 没有调用图与控制流没有调用图与控制流可以使用动态调用程图显示代码覆盖率程图显示代码覆盖率图、控制流程图显示功能。 功能。 代码覆盖情况。 有没有在控制流程图上反标注显示分支判定条件功能不详。 没有此功能 没有此功能 可以自动生成MC/DC与McCabe基本路径测试计划。 测试计划 代码插装与嵌入式支持 插装模板开放，可根插装模板开放，可根插装模板不开放，可据各种平台（包括嵌据各种平台（包括嵌移植性很差； 插装模板不开放，只支持清单列表中编译插装模板不开放，可插装模板开放，可根移植性很差； 据各种平台（包括嵌 14

比较内容 Testbed Logiscope VectorCAST CodeTEST 器； 支持固定内存地址方式（硬件打点）； Cantata++ McCabe 入式平台）进行移植； 入式平台）进行移植； 入式平台）进行移植； 支持文件方式、端口支持文件方式、端口支持文件方式、端口方式、BITMAP方式方式； 方式； 及固定内存地址方式（硬件打点）； 支持文件方式、端口支持文件方式、端口方式； 方式； 采用纯软件方式情况下，实时性Testbed由于可以采用BITMAP方式，所以实时性最好； 只有Testbed/RTInsight与CodeTEST支持硬件方式进行覆盖率分析，其他工具都不支持。 单元测试覆盖率分析 集成TBRUN，无缝自己不带单元测试工支持单元级覆盖率分支持单元级覆盖率分具，须与其它单元测析； 析。 试工具配合使用，而其它单元测试工具本身带覆盖率分析功能。 自己不带单元测试工具，须与其它单元测试工具配合使用，而其它单元测试工具本身带覆盖率分析功能。 支持单元级覆盖率分自己不带单元测试工析； 具； 15