Testbed安装说明及单元测试指导书

1、精选优质文档-倾情为你奉上Testbed工具单元测试指导书1 目的本文档用于指导测试人员在项目过程中使用Testbed工具进行单元测试，主要包括单元测试介绍、工具的安装、单元测试相关操作，以及在工程项目中使用Testbed工具进行单元测试常见问题处理和注意事项。2 说明该指导书针对的Testbed工具版本为8.2 的Windows 7版本，编译器采用GCC。3 单元测试介绍3.1 测试对象软件单元。GJB2786的定义：计算机软件部件设计中确定的能单独测试的部分GJB2786A的定义：计算机软件配置项设计中的一个元素；例如，CSCI的一个主要构成部分、这种构成部分的一个部件、一个类、对象、模块

2、、函数、子程序或者数据库。软件单元可以出现在层次结构的不同层上，并可以由其他软件单元组成。设计中的软件单元与实现他们的代码和数据实体（子程序、过程、数据库、数据文件等）之间，或与包含这些实体的计算机文件之间并不一定有一一对应的关系。3.2 测试目的检查每个单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求，发现单元内可能存在的各种错误。3.3 测试依据软件设计文档。3.4 为什么进行单元测试1. 确保软件单元的正确性2. 确保单元之间交互的正确性3. 明确函数的目的4. 便于定位错误5. 利于代码的重构6. 可以实现自动化回归测试3.5 单元测试工具ü 流行的测试软件

3、： Tburn、C+Test、Cantata+、VectorCAST、 Visual Unit、Tessyü 优点： 一般都拥有自动化用例生成功能，具有方便的可视化功能，可以统计各类型的代码覆盖率信息。ü 缺点： 都是商业软件，测试环境和开发环境完全脱离。3.6 覆盖率类型 语句覆盖：又称行覆盖(Line Coverage)，是最常用也是最常见的一种覆盖方式，就是度量被测代码中每个可执行语句是否被执行到了。这里说的是“可执行语句”，因此就不会包括像C+的头文件声明，代码注释，空行等非可执行语句。 判定覆盖(Decision Coverage)：又称分支覆盖(Branch C

4、overage)。它度量程序中每一个判定的每一个分支是否都被测试到了。 条件覆盖(Condition Coverage)：它度量判定中的每个子表达式结果true和false是否被测试到了。 MC/DC覆盖：MC/DC(Modified Condition Decision Coverage)是修订的条件/判定覆盖，判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次，每个判定中的每个条件都曾独立的影响判定的结果至少一次， (独立影响意思是在其他的条件不变的情况下，改变一个条件)。 路径覆盖：又称断言覆盖(Predicate Coverage)。它度量了是否CSU的

5、每一个路径分支都被执行了。有多个分支嵌套时，需要对多个分支进行排列组合。3.7 单元测试需要注意的地方1. 若对软件单元进行必要的静态测试，应先于动态测试。2. 理论上讲，单元测试除了被测单元外都应该打桩。3. 应逐项测试软件设计文档规定的软件单元的功能、性能等特性； 单元测试的直接依据是软件设计文档 从功能的角度出发，而不是从程序的角度出发4. 软件单元的每个特性应至少被一个正常的测试用例和一个被认可的异常测试用例覆盖 正常与异常是相对于功能来说的 因此在软件的设计文档中，应明确软件功能，以及对应的有效输入 进行单元测试时，用例需要同时包含有效范围之内的和有效范围之外的输入 空指针、异常值5

6、. 测试用例的输入应至少包括有效等价类值、无效等价类值和边界等价类值 若软件的设计文档有明确的功能输入范围描述则可以进行等价类划分 若没有明确输入范围，则可以根据被测单元的参数类型、用到的全局变量类型，取相应的极 大值与极小值6. 测试用例应达到要求的测试覆盖率，对未达到所要求覆盖率的情况需要说明原因 语句覆盖 条件覆盖 判定覆盖 MC/DC覆盖 路径覆盖7. 应测试软件单元输出数据及其格式 确认软件单元的返回值数据类型与内容是否与设计相一致4 软件安装4.1 Testbed工具安装解压Testbed 8.2（Win 7）.zip，进入安装包目录，双击setup.exe 进行软件安装，安装流程

7、如下所示。出现如下界面，选择“是”，单击“Next”。出现如下界面，点击“Standard Workstation”，选择“Typical”，点击“Next”，默认安装在“C:LDRA_Toolsuite”目录，可根据实际情况更改目录。，出现如下界面，可选择工作空间目录，默认为“C:LDRA_Workarea”，此处建议修改为具有较大空间目录，后续创建用例默认都在该目录，点击“Next”。出现如下界面，采用默认设置，点击“Next”。出现如下界面，选择最后一个选项“Install Minimalist GNU for Win32 2.0.0.3”，点击“Next”。出现如下界面，选择“是”，点

8、击“Next”。出现如下界面，可根据实际情况安装所需要的额外工具，默认不安装，点击“Next”。如果安装过程中 出现错误，忽略。出现如下界面，点击“Next”。等待安装完成，出现如下界面，选择“否”。出现如下界面，选择“否”。出现如下界面，安装完成。安装完成后，桌面会出现如下四个图标。4.2 Testbed工具破解安装进入Testbed 8.2（Win 7）Testbed8.2破解目录，拷贝Contestbed.exe、Testbed.exe、Toolsuite.ctl三个文件到Testbed的安装目录“C:LDRA_Toolsuite”下，直接覆盖原文件。4.3 Testbed工具汉化安装进

9、入Testbed 8.2（Win 7）Testbed8.2汉化目录，拷贝CPEN.dat文件到目录“C:LDRA_ToolsuiteC”下，直接覆盖原文件；拷贝CPPPEN.dat文件到目录“C:LDRA_ToolsuiteCPP”下，直接覆盖原文件。5 单元测试操作5.1 被测对象选择在Testbed中C码中的“单元”就是一个函数，每次对一个函数的代码进行测试，测试时每次需打开一个源文件。双击桌面“LDRA Testbed - C_C+ Static and Dynamic Analysis”图标，打开程序LDRA Testbed，点击Testbed的菜单File-> Select F

10、ile， 通过文件浏览窗口，选择要测试单元所在的源文件。本文以Testbed示例代码为例来逐步介绍单元测试过程。 如C:LDRA_WorkareaExamplesC_tbrun_examplesGgrocers.c。点击“打开”之后，可以在工具快捷按钮栏的下方看见目前选择的文件。5.2 编译器的确认与切换在使用TBrun 进行单元测试前需要先确认当前使用的编译器是否是正确的，如果不是正确的编译器可以切换为正确的编译器，其操作如下：1. 确认编译器是否为目标编译器在Testbed 中右上角的“Options”窗口中要确认“Current Compiler”和“Default Compiler”所

11、显示的内容，需要注意两点，“Current”和“Default”是否是目标编译器“Current”和“Default”是否是一样的，应该相同才可以。2. 切换编译器如果编译器不是用户想要的目标编译器需要切换，切换方法如下：点击Testbed菜单Configure->Switch Compiler ，在弹出窗口的编译器列表中选择目标编译器，然后点击Select 按钮即可。如果Other Compilers列表中没有找到需要的编译器，可以通过“Add Compiler”添加所需要的编译器。点击“Add Compiler”,弹出的窗口中点击“是”，进入编译工具安装向导，如下图所示。点击“Nex

12、t”，弹出的向导中选择需要安装的编译器，本文以安装“Wind River Tornado”编译器为例，如下图所示。点击“Next”，编译器安装成功，如下图所示。点击Testbed菜单Configure->Switch Compiler，在弹出的窗口中，当前默认编译器为安装的新的编译器，如下图所示。如果“Current Compiler”和“Default Compiler”不一致，需要设置为一致，如下图所示。设置方式为点击Testbed 菜单Configure->Switch Compiler ，在弹出窗口中点击ResetCurrent File按钮来设置。5.3 打开单元测试模块

13、Tbrun由Testbed 进入Tbrun 有三种模式，每种模式对应不同的测试类型，三种模式分别为：“Integration Unit/Module Test”（集成测试，所有的函数都集成起来）、“Isolation Unit/Module Test”（集成测试，适合增量测试，只有选定的函数集成，未选中的将被打桩）和“Unit Test Only”。C代码的单元测试使用“Unit Test Only”模式，CPP的单元测试使用另外两种模式皆可。点击Testbed 菜单TBrun-> Unit Test Only，即可进入Tbrun 模块。5.4 创建测试序列(Sequence)在TBru

14、n 中是使用测试序列(sequence)来容纳测试用例和测试数据的，进入Tbrun 后第一步需要做的就是创建测试序列。建议每一个函数对应一个测试序列，便于用例管理。在TBrun 的菜单Sequence-> New 点击，弹出测试序列创建窗口，在“Sequence name”下面需要用户写入Sequence 的名字（最好与函数名称对应）；窗体下面的选项卡设置如下，在“Code Coverage”选项卡中把选择框“Code Coverage”选上，此项可自动计算覆盖率信息， 在“Test Enviroment”选项卡中把选择框“Create Dicitoary”、“Create User G

15、lobals”、“Create Stubs”，注意“Test build”选择框不要选，其他保持默认设置即可；然后点击“Continue”按钮即可。5.5 创建测试用例在Tbrun窗体的右上角，点击文件名能够展开显示文件中所包含的函数，把鼠标放到某个函数名上，右键弹出菜单点击“Create New Test Case”，如下图所示。弹出测试用例创建向导窗口，如下图所示。在此窗口中会显示函数的基本信息，可不用关注，直接点击按钮“Continue”向下进行，这样一个用例创建完成， 可在左下角窗口中显示已经创建的用例， 以数字编号用例；在右下角窗口中会显示此函数的输入输出参数。5.6 设定测试用例的

16、IO值测试用例的输入输出参数值的设定是测试的核心， 在这一步决定了有什么样的输入和用例运行之后应该有什么样的输出(预期输出)，从而实现了函数功能的验证。对于函数的输入输出不只有函数的参数，还包含函数内部使用的全局变量。在右下角窗口中工具会显示出函数的参数和内部使用的全局变量， 并会显示每个参数是输入还是输出，用户给每个参数赋值即可，注意输入以“I”标识的，输出是以“O”标识的，此处的输出是指预期的输出值。对于标识为“I”的变量一定要有一个确定的值，否则用例无法执行。5.7 设定测试用例中桩函数桩使用一个函数原型相同的空函数来代替原函数。如果被测函数中调用了其他函数， 则被调用函数会被打桩， 如

17、果被调用函数的返回值影响了被测函数的分支流程， 或被调用函数的动作影响了被测函数的分支流程，则需要对桩进行设置，一般设置桩的返回值即可满足。在Tbrun 的右下角窗口中，双击“Double-click to access”图标即可打开桩的属性设置其返回值等。在桩函数右键，弹出菜单，选择“Set Return Value On Exit”，弹出返回值设定窗口。在图中的“Value”设定返回值，点击“OK”。5.8 执行测试用例测试用例的IO 设置和桩的设定之后，此用例就构造完成了，接下来要做的就是执行用例，有两种运行方式，操作方法如下：a. 一键式运行用例；在测试用例管理窗口中的空白处右键可弹出

18、菜单，点击“Run Test Case Driver”即可运行用例。b. 分步式执行用例；在测试用例管理窗口中的空白处右键可弹出菜单，按顺序点击“Generate Driver”、 “Build Driver”、 “Execute Driver”、(“Split Regression DriverOutput”)、“Process Regression Driver Output”，每执行一步如果执行成功则会在旁边以“”提示，如果不成功则没有“” ，请排查原因。5.9 查看执行结果单元测试其测试结果由两部分构成：函数功能验证和函数覆盖率信息；函数功能的验证是通过用例的执行之后的用例确认对话框中

19、的Pass/Fail结果反应的。5.10 查看测试覆盖率方式一：函数的覆盖率信息可通过动态覆盖率分析报告来查看， 在Tbrun 的菜单Result->Dynamic Coverage Analysis Report 点击即可，此报告中包含整个文件中所有函数的语句、分支、MC/DC 覆盖率信息。如下图所示，该函数语句覆盖率为67%，分支覆盖率为50%。点击buy_fruit_ex函数，进入语句、分支覆盖详细信息。其中“1”表示已覆盖，“0”表示该语句或分支未覆盖。如下图所示。方式二：函数的覆盖率信息可通过TBrun直接查看，如下图所示，buy_fruit_ex函数语句覆盖率为67%，分支覆

20、盖率为50%。 方式三：一种图形化的方式显示函数的覆盖率信息，在Tbrun的用例管理窗口，选中用例然后右键在弹出的菜单中选择“View Flowgraph ”即可打开覆盖率图形化显示窗体，图中蓝色的代表已经覆盖了的，红色的代码未覆盖的。5.11 保存测试用例通过设计多个测试用例执行，函数的功能全部验证通过，并且覆盖率的值也达到了测试规范中的要求的值，此函数的测试就可以结束了，以便于以后对此函数进行回归测试，需要用户把用例保存起来，保存的操作如下：在Tbrun 的菜单Sequense Exprot Test Case(TCF) 点击， 通过文件浏览窗体选择一个目录来保存对应的TCF文件。至此单元

21、测试的主要操作流程结束。6 单元测试常见问题处理6.1 如何选择编译器类型？单元测试，考虑到测试的效率以及内存分配使用问题，如果使用相应的编译环境和仿真器进行运行单元测试可能导致用例运行时报内存分配错误，以及由于是使用仿真器跑用例导致用例运行效率过低。因此在单元测试除了Tornado开发环境可以选择使用本身的仿真环境外（应为Tornado的内分配机制和仿真器相对和桌面程序类似，仿真运行速度可以接受，并且比较不容易出错）其他的程序都建议将被测代码改造为gcc下可以编译的程序进行测试。6.2 如何解决编译器找不到错误？执行用例，如果遇到找不到编译器的错误，可通过TBrun工具菜单Configure

22、->Driver Build & Execution Options中查看当前编译器，如下图所示。弹出下面界面，当前使用编译器为cl，当前环境未安装。如果切换为gcc编译器，可参考如下配置，如下图所示。6.3 如何解决编译找不到头文件错误？ 单元测试每次通过Testbed 来选择一个文件，而我们每个用例是针对一个函数的，所以在编译的时候会出现无法打开*.h的错误。解决该问题，有如下步骤：1. 首先需要在工作区域中增加头文件所在路径。通过Testbed工具，点击菜单“Configure->Static Options”进入静态分析选项页面，如下图所示。点击“Search Op

23、tions”，弹出包括分析的文件，如下图所示。点击文件浏览按钮，选择工程头文件所在路径，点击“Add Search Path”，新增路径会出现在“Search Paths”列表中，如下图所示。2. 排查找不到头文件是否为平台相关头文件，如果是，选择屏蔽此类头文件。（屏蔽后部分已定义的类型可能无法找到，需要我们自定义头文件，定义这些类型）。3. 部分环境通过步骤一添加头文件所在路径后，仍然找不到头文件，排查文件中include的头文件是否为相对路径，如#include “./xx/xx.h”,如果不为相对路径，修改为相对路径。6.4 如何排查程序异常奔溃或无反应？1. 排查代码中是否有死循环，如

24、果有死循环，执行用例会出现无反应情况；2. 排查代码中是否使用了空指针（可能情况为全局指针变量），访问空指针，会导致程序奔溃；3. 排查代码中是否直接访问了内存地址，直接访问内存地址，会导致程序崩溃。6.5 测试用例中如何增加用户全局变量？单元测试每次通过Testbed 来选择一个文件，而我们每个用例是针对一个函数的，所以在编译的时候只编译用户代码中的一个函数，如果此函数中使用了全局变量， 且恰好此变量是用“extern”声明的，即全局变量身体的声明(定义)不在此文件内部， 就需要用户自己在Tbrun中添加此全局变量的声明(定义)。操作如下：在Tbrun的菜单“Global Variables

25、->Create User Global”点击即可弹出用户全局变量定义窗口，在窗口中添入“Name”和“Declaration Type”，如果全局变量为数组，则需要填写“Array Bounds”和“Initial Value”,点击“完成”，创建完成。6.6 测试用例创建向导中对全局数组和指针的处理创建用例过程中，可采用默认步骤，暂不对全局数组或指针做任何处理。用例创建完成后，可按照如下操作，对全局数组赋值，或插入代码，定义临时变量并赋值，然后将该变量赋值给输入指针。6.7 如何对Main函数进行单元测试？对main函数进行单元测试，创建用例时会报错冲突，解决方法为修改源码，重命名m

26、ain函数名称为其他名称，如main_test。6.8 导出测试用例，提示文件没有写权限？导出测试用例的文件路径中有中文，会提示没有权限。6.9 如何为未识别的函数打桩首先在call view视图中，选中该函数，点击右键菜单create Mnanaged Stud ，设置其为桩函数。然后在call view中，选中该函数，依次点击菜单 Managed Stud Properties->parameters、Return type 设置输入参数，和函数返回类型。6.10 测试用例丢失了怎么办用例丢了怎么办？testbed有很好的备份机制，可以到备份文件夹中寻找。如下图所示，备份文件夹在 L

27、DRA_workarea下的tbwrkfls下，文件夹以tbtcffiles结尾。6.11 误删除了用户全局变量怎么办？误删除了用户全局变量，点击工具条上的 按钮，系统自动会将误删除的变量补充回来，。7 Testbed单元测试注意事项7.1 TESTBED测试程序处理过程程序编译的大概过程，先生成桩文件(instrument file)，然后编译生成测试驱动文件.桩文件同源文件一个目录,名称为ixxx.c或inszt_xxx.c驱动文件在Tbwrkfls文件夹下，名称为 s_xxx_seq.c7.2 函数中使用到的指针，要确保值有效例如，使用p->name，那么p所指向的结构体struc

28、t student需要时存在的，否则程序会跑飞。修改的方法是，定义一个用户全局变量aaa ，类型为struct student，设置p的值为 & aaa。7.3 testbed中用例的输入参数是有顺序的。不合适的顺序可能导致结果不正确或者程序异常例如，pstudent参数应当在pstudeng->name之前赋值。否则可能由于pstudent尚未设置有效值，就去取成员变量，而异常。7.4 testbed 的。若同时在用例的输入界面和initial code中定义输入参数值，清一定注意顺序。例如，在initial code 中设置全局变量 pNode->next = NULL

29、，而用例输入界面上设置 .pNode = &g_my_code,由于initial code先执行，程序会异常。7.5 桩函数可以设置多个值，值用逗号分隔，各次调用取一个值例如， 2，第三次使用3。7.6 程序跑飞的调试先看序列文件夹下是否生成exh文件（执行历史文件），如果没有，说明用例参数有问题，删除不必要的参数，检查参数顺序是否正确。如果有exh文件，查看代码的执行情况，了解到执行了那些块，最后出错时执行的代码是哪个快。可大致分析问题出现的范围后，通过注释桩文件中的代码，逐步缩小范围。具体方法：找到.exh最后一行编号值，在源程序同目录下找到对应的桩文件inszz_xxx.c 文

30、件，查找该编号值，该编号到下个编号之间的代码就是程序跑飞的范围。7.7 测试用例有问题时，可设置为suspend，先处理其他测试用例7.8 测试用例可以复制粘贴多份，修改参数后，通过resequence来执行指定参数及其后的测试用例7.9 桩程序和驱动程序待会测试桩程序和源文件在同一个目录，主要用于进行覆盖率的统计。名称通常为ixxx.c或 ixxx.cpp；驱动程序在序列文件夹（xxx_seqwrkfls）测试用例执行就是在执行该程序先生成桩程序，创建测试用例时，生成驱动程序。7.10 tonado模拟器异常后，再执行用例结果会有问题使用 vxworks 的tonado环境进行嵌入式程序测试

31、时，清注意观察模拟器的状态。例如是否已经有异常等，有问题了及时重启。7.11 用例执行出错，原因可能是：a 某个全局变量可能被误删除掉了 ，这个在日志视图可以看到相应的错误。点击工具条上G，恢复全局变量。b 用例参数值设置的顺序不对，导致程序跑飞。例如，pstudent为结构体类型的指针，如果用例中先设置 pstudent->name=“aaa”,再设置pstudent=&student1, 由于设置顺序的问题，程序会跑飞。解决办法：调整输入顺序。c 被测函数中使用到的指针未被初始化，导致执行异常。例如，被测代码中 pstudent->sex=1;由于pstudent为初始化，程序跑飞。解决办法，定义一个类型为student的用户全局变量student1，在测试用例中将pstudent 设置为&student1，这样指针指到一个有效地址，程序就不跑飞了。7.12 testbed的编译器环境配置使用 vxworks 的tonado环境进行嵌入式程序测试时，清注意观察模拟器的状态。例如是否已经有异常等，有问题了及时重启。1.安装tbc