常用的测试方法和测试工具.docx

1、常用的测试方法和测试工具（总1 0页）-CAL-FENGHAI.-(YICAI)-Company One 1CAL本页仅作为文档封面，使用请直接删除常用的测试方法一、 黑盒测试1黑盒测试其实是一种功能测试，主要在软件的接口处进行。主要测试的 以下儿类错误：是否有不正确或遗漏的功能在给岀的接口处正确的输入是否有正确的输出是否有数据结构错误或外部信息访问错误性能上是否满足要求是否有初始化或终止性错误2.黑盒测试用例等价类划分等价类即输入域的子集合，测试用例设计时应设计出对应的有效等价类和 无效等价类边界值边界值法是对等价类划分方法的补充，主要是测试发生在输入和输出域边 界上的错误等价类划分和边界值

2、着重考虑输入条件，但测试时还应考虑输入条 件之间的关系，各种条件的组合情况，即因果图因果图根据输入条件间的关系主成判定表，根据判定表的每一列来设计测试用例功能图包括状态迁移图和逻辑模型二、 白盒测试1.口盒测试是对软件过程性细节做细致的检查。主要对软件程序模块做以 下检查：对模块的所有路径至少执行一次对模块的所有逻辑判断，取“真”和“假”两种情况各执行一次在循环边界和运行界限内执行循环体测试内部数据结构的有效性2.口盒测试用例1）逻辑覆盖语句覆盖.分支覆盖对程序模块中的每个取真分支和取假分支执行一遍条件覆盖对程序模块中的每个判断的每个条件执行一遍山于以上的测试用例都有较大的缺陷，所以一般不会使

3、用，采用条件组合 覆盖更为合理有效条件组合覆盖（逻辑覆盖的主要方法）2）基本路径测试用例测试步骤：1根据详细设计或源代码导出程序控制流图2计算程序环路复杂性，即独立路径的数LI （一条新的路径必须包含一条新边）3生成测试用例（辅助工具：图形矩阵）测试策略一、 单元测试1.单元测试时主要对模块的以下5个方面进行检查：模块接口局部数据结构边界条件独立路径出错处理二、 集成测试1.集成测试时主要要考察程序的以下儿个方面：各个模块连接时，穿越模块接口的数据是否会丢失一个模块是否会对另一个模块的功能产生不利的影响各个子功能组合起来，能否达到预期的父功能全局数据结构是否有问题单个模块的误差累积起来,是否会

4、被放大，从而达到不可接受的程度2.集成测试的组织和实施中考虑的因素：选用何种系统集成方法来进行集成测试各个模块连接的顺序模块代码编制和测试进度是否集成测试的顺序是否一致测试过程中是否需要有专门的硕件3.集成测试完成的标志成功执行了测试计划中规定的所有组装测试修正了所发现的错误测试结果通过了专门小组的评审三、 确认测试1 确认测试流程：进行有效性测试，即在模拟的环境下（可能是开发环境），运用黑盒测 试的方法，验证所没软件是否满足需求说明书列岀的需求。对于测试结果与预 期结果不相符进，要提交一份问题报告。软件配置复查软件配置复查的U的是保证软件配置的所有成份都齐全，各方面的质量 都符合要求。 a测

5、试和B测试a测试是一个用户在开发环境下进行的测试，也可以是开发机构内部 的用户在模拟实际操作环境下进行的测试。B测试是山软件的多个用户在一个 或多个用户的实际使用环境下进行的测试验收测试验收测试时软件开发人员和QA人员也应参加，山用户参加设计测试用 例，使用用户界面输入测试数据，并分析测试结果。四、系统测试即通过确认测试的软作为整个系统中的一个元素而进行的测试。嵌入式系统测试方法及工具通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能 会导致灾难性的后果，即使是非安全性系统，山于大批量生产也会导致严重的 经济损失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和 验证。一

6、般来说，软件测试有7个基本阶段，即单元或模块测试、集成测试、 外部功能测试、回归测试、系统测试、验收测试、安装测试。嵌入式软件测试 在4个阶段上进行，即模块测试、集成测试、系统测试、硬件/软件集成测试。 前3个阶段适用于任何软件的测试，硬件/软件集成测试阶段是嵌入式软件所特 有的，LJ的是验证嵌入式软件与其所控制的硬件设备能否正确地交互。1.白盒测试与黑盒测试由于严格的安全性和可靠性的要求，嵌入式软件测试同非嵌入式软件测 试相比，通常要求有更高的代码覆盖率。对于嵌入式软件，白盒测试一般不必 在H标硬件上进行，更为实际的方式是在开发环境中通过硬件仿真进行，所以 选取的测试工具应该支持在宿主环境中

7、的测试。因为黑盒测试与需求紧密相关，需求规格说明的质量会直接影响测试的 结果，黑盒测试只能限制在需求的范圉内进行。在进行嵌入式软件黑盒测试 时，要把系统的预期用途作为重要依据，根据需求中对负载.定时.性能的要 求，判断软件是否满足这些需求规范。为了保证正确地测试，还须要检验软硬 件之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境 中，通常要求嵌入式软件的失效过程要平稳，所以，黑盒测试不仅要检查软件 工作过程，也要检查软件换效过程。2、H标环境测试和宿主环境测试在嵌入式软件测试中，常常要在基于目标的测试和基于宿主的测试之间作 出折衷。基于LI标的测试消耗较多的经费和时间，而基于

8、宿主的测试代价较 小，但毕竟是在模拟环境中进行的。LI前的趋势是把更多的测试转移到宿主环 境中进行，但是，H标环境的复杂性和独特性不可能完全模拟。在两个环境中可以岀现不同的软件缺陷，重要的是L1标环境和宿主环境的 测试内容有所选择。在宿主环境中，可以进行逻辑或界面的测试、以及与硬件 无关的测试。在模拟或宿主环境中的测试消耗时间通常相对较少，用调试工具 可以更快地完成调试和测试任务。而与定时问题有关的白盒测试、中断测试、 硬件接口测试只能在H标环境中进行。在软件测试周期中，基于H标的测试是 在较晚的“硬件/软件集成测试”阶段开始的，如果不更早地在模拟环境中进行 白盒测试，而是等到“硬件/软件集成

9、测试”阶段进行全部的白盒测试，将耗费 更多的财力和人力。1常用的嵌入式软件测试工具1） 内存分析工具在嵌入式系统中，内存约束通常是有限的。内存分析工具用来处理在动态内 存分配中存在的缺陷。当动态内存被错误地分配后，通常难以再现，可能导致 的失效难以追踪，使用内存分析工具可以避免这类缺陷进入功能测试阶段。U 前有两类内存分析工具一一软件和硬件的。基于软件的内存分析工具可能会对 代码的性能造成很大影响，从而严重影响实时操作；基于硬件的内存分析工具 价格昂贵，而且只能在工具所限定的运行环境中使用。2） 性能分析工具在嵌入式系统中，程序的性能通常是非常重要的。经常会有这样的要求， 在特定时间内处理一个

10、中断，或生成具有特定定时要求的一帧。开发人面临的 问题是决定应该对哪一部分代码进行优化来改进性能，常常会花大量的时间去 优化那些对性能没有任何影响的代码。性能分析丄具会提供有关的数据，说明 执行时间是如何消耗的，是什么时候消耗的，以及每个例程所用的时间。根据 这些数据，确定哪些例程消耗部分执行时间，从而可以决定如何优化软件，获 得更好的时间性能。对于大多数应用来说，大部分执行时间用在相对少量的代 码上，费时的代码估计占所有软件总量的5%-20%o性能分析工具不仅能指出哪 些例程花费时间，而且与调试工具联合使用可以引导开发人员查看需要优化的 特定函数，性能分析工具还可以引导开发人员发现在系统调用

11、中存在的错误以 及程序结构上的缺陷。3） GUI测试工具很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测 试足根掘用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环 境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分 析和比较、设置和管理测试过程。很多嵌入式设备没有GUI,但常常可以对嵌 入式设备进行插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进 行更改，但是节省了功能测试和回归测试的时间。4）覆盖分析工具在进行白盒测试时，可以使用代码覆盖分析工具追踪哪些代码被执行过。 分析过程可以通过插装来完成，插装可以是在测试环境中嵌入硬件，也可以

12、是 在可执行代码中加入软件，也可以是二者相结合。测试人员对结果数据加以总 结，确定哪些代码被执行过，哪些代码被巡漏了。覆盖分析工具一般会提供有 关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式软件来说，代码覆盖分 析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖 分析工具的侵入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的 数量。嵌入式测试的十大秘诀在嵌入式软件开发过程中，一般来说，花在测试和花在编码的时间比为3： 1（实 际上可能更多）。这个比例随着你的编程和测试水平的提高而不断下降，但不 论怎样，软件测试对一般人来讲很重要。很多年前，一位开发人员为了对嵌入 式有

13、更深层次的理解，向Oracle询问了这样的一个问题:我怎么才能知道并懂 得我的系统到底在干些什么呢？ Oracle面对这个问题有些吃惊，因为在当时 没有人这么问过，而同时代的嵌入式开发人员问的最多的大都圉绕“我怎么才 能使程序跑的更快”、“什么编译器最好”等肤浅的问题。所以，面对这个不 同寻常却异乎成熟的问题，Oracle感到欣喜并认真回复了他:你的问题很有深 度很成熟，因为只有不断地去深入理解才有可能不断地提高水平。并且Oracle 为了鼓励这位执着的程序员，把1 0条关于嵌入式软件开发测试的秘诀告诉了 他：1懂得使用工具2.尽早发现内存问题3.深入理解代码优化4.不要让自己大海捞针.重现并

14、隔离问题6以退为进7.确定测试的完整性8提高代码质量意味着节省时间9发现它，分析它，解决它10.利用初学者的思维这十条秘诀在业界广为流传，使很多人受益。本文围绕这十条秘诀展开论述。1懂得使用工具通常嵌入式系统对可鼎性的要求比较高。嵌入式系统安全性的失效可能会 导致灾难性的后果，即使是非安全性系统，山于大批量生产也会导致严重的经 济损失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验 证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对门益复 杂的嵌入式软件进行快速有效的测试愈加显得重要。就象修车需要工具一样，好的程序员应该能够熟练运用各种软件工具。不 同的工具，有不同的

15、使用范圉，有不同的功能。使用这些工具，你可以看到你 的系统在干些什么，它乂占用什么资源，它到底和哪些外界的东西打交道。让 你郁闷好儿天的问题可能通过某个工具就能轻松搞定，可惜你就是不知道。那 么为什么那么多的人总是在折腾个半死之后才想到要用测述二县呢？原因很 多，主要有两个。一个是害怕，另一个是怖性。害怕是因为加入测试用具或测 试模块到代码需要技巧同时有可能引入新的错误，所以他们总喜欢寄希望于通 过不断地修改重编译代码来消除bug,结果却无济于事。懒旳是因为他们习惯了 使用printf之类的简单测试手段。下面来介绍一些嵌入式常用的测试工具。 源码级调试器Source-level Debugge

16、r 这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功 能，是嵌入式调试最根本有效的调试方法。比如VxWorks TornadoII提供的gd b就属于这一种。简单实用的打印显示工具printfprintf或其它类似的打印显示工具佔讣是最灵活最简单的调试工具。打印代码 执行过程中的各种变量可以让你知道代码执行的情况。但是，printf对正常的 代码执行干扰比较大(一般printf占用CPU比较长的时间)，需要慎重使用，最 好设置打印开关来控制打印。ICE 或 JTAG 调试器In-circuit EmulatorICE是用来仿真CPU核心的设备，它可以在不干扰运算器的正常运行情

17、况下， 实时的检测CFU的内部工作情况。像桌面调试软件所提供的：复杂的条件断 点、先进的实时跟踪、性能分析和端口分析这些功能，它也都能提供。ICE 般都有一个比较特殊的CPU,称为外合(bond-out)CPUo这是一种被打开了封装 的CPU,并且通过特殊的连接，可以访问到CPU的内部信号，而这些信号，在C PU被封装时，是没法“看到”的。当和工作站上强大的调试软件联合使用时， ICE就能提供你所能找到的最全面的调试功能。但ICE同样有一些缺点：昂 贵；不能全速工作；同样，并不是所有的CPU都可以作为外合CPU的，从另一 个角度说，这些外合CPU也不大可能及时的被新岀的CPU所更换。JTAG(

18、Joint Test Action Group)虽然它最初开发出来是为了监测IC和电路连接，但是这种 串行接口扩展了用途，包括对调试的支持。AD公司为Blackfin设计的Visual Dsp卄就支持高速的JTAG调试。ROM 监视器ROM MonitorROM监控器是一小程序，驻留在嵌入系统ROM中，通过串行的或网络的连接和 运行在工作站上的调试软件通信。这是一种便宜的方式，当然也是最低端的技 术。它除了要求一个通信端口和少量的内存空间外，不需要其它任何专门的硬 件。并提供了如下功能：下载代码、运行控制、断点、单步步进、以及观察、 修改寄存器和内存。因为ROM监控器是操作软件的一部分，只有当

19、你的应用程 序运行时，它才会工作。如果你想检查CFU和应用程序的状态，你就必须停下 应用程序，再次进入ROM监控器。Dertci 监视器Data Monitor这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容，还可以收 集并以图形形式显示各个变量的变化过程。OS 监视器Operating System Monitor操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。一方面， 这些监视器能够为你呈现事件之间的关系和时间联系；另一方面，还可以提供 对信号量优先级反转、死锁和中断延时等问题的诊断。性能分析工具Profiler可以用来测试CPU到底耗在那里。profiler工具可

20、以让你知道系统的瓶颈在那 里、CPU的使用率以及需要优化的地方。内存测试工具Memory Teseter可以找到内存使用的问题所在,比如内存泄露、内存碎片、内存崩溃等问题。 如果发现系统岀现一些不可预知的或间歇性的问题，就应该使用内存测试匸具 测测看。运行跟踪器Execution Tracer可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。这 种工具主要用于测试代码逻辑，可以在大量的事件中发现异常的那些。覆盖工具Coverage Tester主要显示CPU具体执行了那些代码，并让你知道那些代码分支没有被执行到。 这样有助于提高代码质量并消除无用代码。GUI 测试工具GUI

21、Tester很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足 根掘用户输入响应时间进行的。GUI测试丄具可以作为脚本工具有开发环境中 运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和 比较、设置和管理测试过程（Rational公司的robot和Mercury的Loadrunner 工具是杰出的代表）。很多嵌入式设备没有GUI,但常常可以对嵌入式设备进行 插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进行更改，但是 节省了功能测试和回归测试的时间。自制工具Home-made tester在嵌入式应用中，有时候为了特定的H的，需要自行编写一些工具来

22、达到某种 测试U的。本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上 帮了大忙，帮公司找到了儿个隐藏很深的bugo2尽早发现内存问题内存问题危害很大，不容易排查，主要有三种类型：内存泄露、内存碎片和 内存崩溃。对于内存问题态度必须要明确，那就是早发现早“治疗” O在软件 设计中，内存泄露的“名气”最大，主要曲于不断分配的内存无法及时地被释 放，久而久之，系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄 露问题。有测试过内存泄露的朋友估计都有深刻地体验，那就是内存泄露问题 一般隐藏很深，很难通过代码阅读来发现。有些内存泄露其至可能岀现在库当 中。有可能这本身是库中的bug,也有可

23、能是因为程序员没有正确理解它们的 接口说明文档造成错用。在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故 障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是 很高，那么重启系统问题也不大；但，如果用户对系统稳定很高，那么这种故 障就有可能使用户对产品失去信心，同时也意味着你的项目是个失败的项目。 山于内存泄露危害巨大，现在已经有许多工具来解决这个问题。这些工具通过 查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存 泄露的问题。每个工具都有利有弊，不过总的来说，用要比不用好。总之，负 责的开发人员应该去测试内存泄露的问题，做到防患于未然。内存碎

24、片比内存泄露隐藏还要深。随着内存的不断分配并释放，大块内存 不断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有 可能就会失败。如果系统内存够大，那么坚持的时间会长一些，但最终还是逃 不岀分配失败的厄运。在使用动态分配的系统中，内存碎片经常发生。H前， 解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现 谁是导致内存碎片的罪魁祸首，然后改进相应的部分。由于动态内存管理的种种问题，在嵌入式应用中，很多公司干脆就禁用ma lloc/free的以绝后患。内存崩溃是内存使用最严重的结果，主要原因有数组访问越界、写已经释 放的内存、指针计算错误、访问堆栈地址越界等等。这

25、种内存崩溃造成系统故 障是随机的，而且很难查找，目前提供用于排查的工具也很少。总之，如果要使用内存管理单元的话，必须要小心，并严格遵守它们的使 用规则，比如谁分配谁释放。3.深入理解代码优化讲到系统稳定性，人们更多地会想到实时性和速度，因为代码效率对嵌入 式系统来说太重要了。知道怎么优化代码是每个嵌入式软件开发人员必须具备 的技能。就象女孩子减肥一样，起码知道她哪个地方最需要减，才能去购买减 肥药或器材来减掉它。可见，代码优化的前提是找到真正需要优化的地方，然 后对症下药，优化相应部分的代码。前面提到的profile（性能分析工具，一些 功能齐全IDE都提供这种内置的工具）能够记录各种情况比如

26、各个任务的CPU占 用率、各个任务的优先级是否分配妥当.某个数据被拷贝了多少次、访问磁盘 多少次、是否调用了网络收发的程序、测试代码是否已经关闭等等。但是，profile!具在分析实时系统性能方面还是有不够的地方。一方 面，人们使用profile工具往往是在系统出现问题即CPU耗尽之后，而profil e工具本身对CPU占用较大，所以profile对这种情况很可能不起作用。根据H eisenberg效应，任何测试手段或多或少都会改变系统运行，这个对profiler 同样适用！总之，提高运行效率的前提是你必须要知道CPU到底干了些什么干的怎么 样。4.不要让自己大海捞针大海捞针只是对调试的一种生

27、动比喻。经常听到组里有人对自己正在调试的代码说shit!可以理解，因为代码不 是他写的，他有足够的理由去shit bug百出的代码，只要他自己不要写出这 种代码，否则有一天同组的其它人可能同样会shit他写的代码。为何会有大 海捞针呢肯定是有人把针掉到海里咯：那针为何会掉在海里呢肯定是有人不小 心或草率呗。所以当你在抱怨针那么难找的时候，你是否想过是你自己草率地 丢掉的。同样，当你调试个半死的时候，你是否想过你要好好反省一下当初为 了寻求捷径可能没有严格地遵守好的编码设计规范、没有检测一些假设条件或 算法的正确性、没有将一些可能存在问题的代码打上记号呢？关于如何写高质 量请参考林锐的高质量C+

28、/C编程指南或关于C的0x8本“经书” ()。如果你确实已经把针掉在海里是，为了防止在找到之前刺到自己，你必须 要做一些防范工作，比如戴上安全手套。同样，为了尽能地暴露和捕捉问题根 源，我们可以设计比较全面的错误跟踪代码。怎么来做呢？尽可能对每个函数 调用失败作岀处理，尽可能检测每个参数输入输岀的有效性包括指针以及检测 是否过多或过少地调用某个过程。错误跟踪能够让你知道你大概把针掉在哪个 位置。5.重现并隔离问题如果你不是把针掉在大海了，而是掉在草堆里，那要好办写。因为至少我 们可以把草堆分成很多块，一块一块的找。对于模块独立的大型项使用隔 离方法往往是对付那些隐藏极深bug的最后方法。如果问

29、题的岀现是间歇性的, 我们有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这 些条件去重现问题。如果你确信可以使用记录的那些条件去重现问题，那么我 们就可以着手去隔离问题。怎么隔离呢？我们可以用#ifdef把一些可能和问题 无关的代码关闭，把系统最小化到仍能够重现问题的地步。如果还是无法定位 问题所在，那么有必要打开“工具箱” To可以试着用ICE或数据监视器去查 看某个可疑变量的变化；可以使用跟踪工具获得函数调用的情况包括参数的传 递；检查内存是否崩溃以及堆栈溢出的问题。6 .以退为进猎人为了不使自己在森林里迷路，他常常会在树木上流下一些标记，以备 自己将来有一天迷路时可以根据

30、这些标记找到出路。对过去代码的修改进行跟踪记录对将来岀现问题之后的调试很有帮助。假如有 一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你这时的第一反 映就是我到底改动了些什么呢，因为上次修改之前是好的。那么如何检测这次 相对于上次的修改呢？没错，代码控制系统SCS或称版本控制系统VCS （Concur rent Version Control, CVS是VCS的演化版本）。将上个版本check in下来后 和当前测试版本比较。比较的工具可以是SCS/VCS/CVS自带的diff工具或其它 功能更强的比较匸具，比如BeyondCompare和ExamDiff。通过比较，记录所有 改动的代

31、码，分析所有可能导致问题的可疑代码。7确定测试的完整性你怎么知道你的测试有多全面呢？覆盖测试（coverage testing）可以回答 这个问题。覆盖测试工具可以告诉你CPU到底执行了那些代码。好的覆盖丄具 通常可以告诉你大概20%到40%代码没有问题，而其余的可能存在bug。覆盖工 具有不同的测试级别，用户可以根据自己的需要选择某个级别。即使你很确信 你的单元测试已经很全面并且没有dead code,覆盖工具还是可以为你指出一些 潜在的问题，看下面的代码：辻（i = 0 & （almostAlwaysZero = 0 | （last = i）如果almostAlwaysZero为非0 ,那么last二i赋值语句就被跳过，这可能不是你 所期望的。这种问题通过覆盖工具的条件测试功能可以轻松的被发现。总之，覆盖测试对于提高代码质量很有帮助。8提高代码质虽意味着节省时间有研究表明软件开发的时间超过80%被用在下面儿个方面：调试自己的代码（单元测试）调试自己和其他相关的代码（模块间测试）调试整个系统（系统测试）更糟糕的是你可能需要花费10-200倍的时间来找一个bug,而这个bug在开始 的时候可能很容易就能找到。一个小bug可能让你付出巨大的代价，即使这个 bug对整个系统的性能没有太大的影响，但很可能会影响让那