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

1、常用的测试方法一、黑盒测试1. 黑盒测试其实是一种功能测试，主要在软件的接口处进行。主要测试的 以下几类错误：是否有不正确或遗漏的功能在给出的接口处正确的输入是否有正确的输出是否有数据结构错误或外部信息访问错误性能上是否满足要求是否有初始化或终止性错误2. 黑盒测试用例等价类划分等价类即输入域的子集合 ,测试用例设计时应设计出对应的有效等价类和 无效等价类边界值 边界值法是对等价类划分方法的补充，主要是测试发生在输入和输出域边 界上的错误 . 等价类划分和边界值着重考虑输入条件 , 但测试时还应考虑输入条 件之间的关系，各种条件的组合情况，即因果图因果图根据输入条件间的关系生成判定表，根据判定

2、表的每一列来设计测试用例 功能图包括状态迁移图和逻辑模型 二、白盒测试1白盒测试是对软件过程性细节做细致的检查。主要对软件程序模块做以 下检查：对模块的所有路径至少执行一次对模块的所有逻辑判断，取“真”和“假”两种情况各执行一次在循环边界和运行界限内执行循环体测试内部数据结构的有效性 2白盒测试用例1）逻辑覆盖语句覆盖,采用条件组合分支覆盖 对程序模块中的每个取真分支和取假分支执行一遍 条件覆盖 对程序模块中的每个判断的每个条件执行一遍 由于以上的测试用例都有较大的缺陷，所以一般不会使用 覆盖更为合理有效条件组合覆盖（逻辑覆盖的主要方法）2）基本路径测试用例 测试步骤： 根据详细设计或源代码导

3、出程序控制流图 计算程序环路复杂性 ,即独立路径的数目 （一条新的路径必须包含一条新边 ） 生成测试用例 （ 辅助工具：图形矩阵 ）测试策略、单元测试1. 单元测试时主要对模块的以下 5 个方面进行检查：模块接口局部数据结构边界条件独立路径出错处理、集成测试1. 集成测试时主要要考察程序的以下几个方面 :各个模块连接时，穿越模块接口的数据是否会丢失 一个模块是否会对另一个模块的功能产生不利的影响 各个子功能组合起来，能否达到预期的父功能 全局数据结构是否有问题单个模块的误差累积起来，是否会被放大，从而达到不可接受的程度2. 集成测试的组织和实施中考虑的因素 :选用何种系统集成方法来进行集成测试

4、各个模块连接的顺序模块代码编制和测试进度是否集成测试的顺序是否一致测试过程中是否需要有专门的硬件3. 集成测试完成的标志成功执行了测试计划中规定的所有组装测试修正了所发现的错误测试结果通过了专门小组的评审、确认测试1. 确认测试流程 :进行有效性测试，即在模拟的环境下（可能是开发环境），运用黑盒测试 的方法，验证所没软件是否满足需求说明书列出的需求。 对于测试结果与预期结 果不相符进，要提交一份问题报告。软件配置复查 软件配置复查的目的是保证软件配置的所有成份都齐全，各方面的质量 都符合要求。a测试和？测试a测试是一个用户在开发环境下进行的测试， 也可以是开发机构内部的 用户在模拟实际操作环境

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

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

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

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

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

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

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

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

13、对一般人来讲很重要。 很多年前， 一位开发人员为了对嵌入式有更深层次 的理解，向 Oracle 询问了这样的一个问题 : 我怎么才能知道并懂得我的系统到底 在干些什么呢 ? Oracle 面对这个问题有些吃惊，因为在当时没有人这么问过， 而同时代的嵌入式开发人员问的最多的大都围绕 “我怎么才能使程序跑的更快” 、 “什么编译器最好” 等肤浅的问题。 所以，面对这个不同寻常却异乎成熟的问题， Oracle 感到欣喜并认真回复了他 : 你的问题很有深度很成熟， 因为只有不断地去 深入理解才有可能不断地提高水平。并且 Oracle 为了鼓励这位执着的程序员， 把10条关于嵌入式软件开发测试的秘诀告诉

14、了他 ：1. 懂得使用工具2. 尽早发现内存问题3. 深入理解代码优化4. 不要让自己大海捞针5. 重现并隔离问题6. 以退为进7. 确定测试的完整性8. 提高代码质量意味着节省时间9. 发现它，分析它，解决它10. 利用初学者的思维 这十条秘诀在业界广为流传，使很多人受益。本文围绕这十条秘诀展开论述。1. 懂得使用工具通常嵌入式系统对可靠性的要求比较高。 嵌入式系统安全性的失效可能会导 致灾难性的后果，即使是非安全性系统， 由于大批量生产也会导致严重的经济损 失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随 着越来越多的领域使用软件和微处理器控制各种嵌入式设备， 对门益

15、复杂的嵌入 式软件进行快速有效的测试愈加显得重要。就象修车需要工具一样， 好的程序员应该能够熟练运用各种软件工具。 不同 的工具，有不同的使用范围，有不同的功能。使用这些工具，你可以看到你的系 统在干些什么， 它又占用什么资源， 它到底和哪些外界的东西打交道。 让你郁闷 好几天的问题可能通过某个工具就能轻松搞定， 可惜你就是不知道。 那么为什么 那么多的人总是在折腾个半死之后才想到要用呢？原因很多， 主要有两个。 一个 是害怕，另一个是惰性。 害怕是因为加入测试用具或测试模块到代码需要技巧同 时有可能引入新的错误， 所以他们总喜欢寄希望于通过不断地修改重编译代码来 消除 bug, 结果却无济于

16、事。 懒惰是因为他们习惯了使用 printf 之类的简单测试 手段。下面来介绍一些嵌入式常用的。. 源码级调试器 Source-level Debugger这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能， 是嵌入式调试最根本有效的调试方法。 比如 VxWorks TornadoII 提供的 gdb 就属 于这一种。. 简单实用的打印显示工具 printfprintf 或其它类似的打印显示工具估计是最灵活最简单的调试工具。打印代码 执行过程中的各种变量可以让你知道代码执行的情况。但是， printf 对正常的 代码执行干扰比较大（一般printf占用CPU比较长的时间），需

17、要慎重使用，最 好设置打印开关来控制打印。.ICE 或 JTAG调试器In-circuit EmulatorICE是用来仿真CPU核心的设备，它可以在不干扰运算器的正常运行情况下，实 时的检测CPU的内部工作情况。像桌面调试软件所提供的：复杂的条件断点、先 进的实时跟踪、性能分析和端口分析这些功能，它也都能提供。ICE 一般都有一个比较特殊的CPU称为外合（bond-out）CPU。这是一种被打开了封装的CPU并 且通过特殊的连接，可以访问到CPU勺内部信号，而这些信号，在CPU被封装时， 是没法“看到”的。当和工作站上强大的调试软件联合使用时，ICE就能提供你CPI所更换。JTAGJoint

18、 Test Action Group） 虽IC 和电路连接，但是这种串行接口扩展了用途， Blackfin 设计的 Visual Dsp+ 就支持高速的 JTA所能找到的最全面的调试功能。但 ICE 同样有一些缺点：昂贵；不能全速工作； 同样，并不是所有的CPU都可以作为外合CPU的，从另一个角度说，这些外合 C PU也不大可能及时的被新出的 然它最初开发出来是为了监测 包括对调试的支持。AD公司为 G调试。.ROM监视器ROM MonitorROM监控器是一小程序，驻留在嵌入系统 ROM中，通过串行的或网络的连接和运 行在工作站上的调试软件通信。这是一种便宜的方式，当然也是最低端的技术。 它

19、除了要求一个通信端口和少量的内存空间外， 不需要其它任何专门的硬件。 并 提供了如下功能：下载代码、运行控制、断点、单步步进、以及观察、修改寄存 器和内存。因为ROM监控器是操作软件的一部分，只有当你的应用程序运行时， 它才会工作。如果你想检查CPU和应用程序的状态，你就必须停下应用程序，再 次进入ROM监控器。.Data 监视器 Data Monitor这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容，还可以收集 并以图形形式显示各个变量的变化过程。.OS 监视器 Operating System Monitor 操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。一方面

20、，这 些监视器能够为你呈现事件之间的关系和时间联系； 另一方面， 还可以提供对信 号量优先级反转、死锁和中断延时等问题的诊断。. 性能分析工具 Profiler可以用来测试CPU到底耗在那里。Profiler 工具可以让你知道系统的瓶颈在那 里、CPU的使用率以及需要优化的地方。. 内存 Memory Teseter 可以找到内存使用的问题所在，比如内存泄露、内存碎片、内存崩溃等问题。如 果发现系统出现一些不可预知的或间歇性的问题，就应该使用内存测测看。. 运行跟踪器 Execution Tracer可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。这种 工具主要用于测试代码

21、逻辑，可以在大量的事件中发现异常的那些。. 覆盖工具 Coverage Tester主要显示CPU具体执行了那些代码，并让你知道那些代码分支没有被执行到。这样有助于提高代码质量并消除无用代码。.GUIGUI Tester 很多嵌入式应用带有某种形式的图形用户界面进行交互， 有些系统性能测试足根 掘用户输入响应时间进行的。GUI可以作为脚本工具有开发环境中运行测试用 例，其功能包括对操作的记录和回放、 抓取屏幕显示供以后分析和比较、 设置和 管理测试过程 （Rational 公司的 robot 和 Mercury 的 Loadrunner 工具是杰出的 代表）。很多嵌入式设备没有GUI，但常常可

22、以对嵌入式设备进行插装来运行 GU I 测试脚本，虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试 和回归测试的时间。. 自制工具 Home-made tester在嵌入式应用中， 有时候为了特定的目的， 需要自行编写一些工具来达到某种测 试目的。本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了 大忙, 帮公司找到了几个隐藏很深的 bug。2. 尽早发现内存问题内存问题危害很大，不容易排查，主要有三种类型 : 内存泄露、内存碎片和 内存崩溃。对于内存问题态度必须要明确，那就是早发现早“治疗”。在软件设 计中，内存泄露的“名气”最大，主要由于不断分配的内存无法及时地被释放

23、， 久而久之，系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄露问题。 有测试过内存泄露的朋友估计都有深刻地体验， 那就是内存泄露问题一般隐藏很 深，很难通过代码阅读来发现。 有些内存泄露甚至可能出现在库当中。 有可能这 本身是库中的bug,也有可能是因为程序员没有正确理解它们的接口说明文档造 成错用。在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故障。 程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高， 那么重启系统问题也不大；但，如果用户对系统稳定很高，那么这种故障就有 可能使用户对产品失去信心，同时也意味着你的项目是个失败的项目。 由于内 存泄露危

24、害巨大， 现在已经有许多工具来解决这个问题。 这些工具通过查找没有 引用或重复使用的代码块、 垃圾内存收集、库跟踪等技术来发现内存泄露的问题。 每个工具都有利有弊，不过总的来说，用要比不用好。总之，负责的开发人员应 该去测试内存泄露的问题，做到防患于未然。内存碎片比内存泄露隐藏还要深。 随着内存的不断分配并释放， 大块内存不 断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有可能 就会失败。 如果系统内存够大， 那么坚持的时间会长一些， 但最终还是逃不出分 配失败的厄运。在使用动态分配的系统中，内存碎片经常发生。目前，解决这个 问题最效的方法就是使用工具通过显示系统中内存的使用

25、情况来发现谁是导致 内存碎片的罪魁祸首，然后改进相应的部分。由于动态内存管理的种种问题，在嵌入式应用中，很多公司干脆就禁用 ma lloc/free 的以绝后患。内存崩溃是内存使用最严重的结果， 主要原因有数组访问越界、 写已经释放 的内存、指针计算错误、 访问堆栈地址越界等等。 这种内存崩溃造成系统故障是 随机的，而且很难查找，目前提供用于排查的工具也很少。总之，如果要使用内存管理单元的话， 必须要小心， 并严格遵守它们的使用 规则，比如谁分配谁释放。3. 深入理解代码优化讲到系统稳定性， 人们更多地会想到实时性和速度， 因为代码效率对嵌入式 系统来说太重要了。知道怎么优化代码是每个嵌入式软

26、件开发人员必须具备的技 能。就象女孩子减肥一样， 起码知道她哪个地方最需要减， 才能去购买减肥药或 器材来减掉它。 可见，代码优化的前提是找到真正需要优化的地方， 然后对症下 药，优化相应部分的代码。 前面提到的 profile（ 性能分析工具， 一些功能齐全 I DE都提供这种内置的工具）能够记录各种情况比如各个任务的 CPI占用率、各个 任务的优先级是否分配妥当、 某个数据被拷贝了多少次、 访问磁盘多少次、 是否 调用了网络收发的程序、测试代码是否已经关闭等等。但是， profile 工具在分析实时系统性能方面还是有不够的地方。一方面， 人们使用Profile 工具往往是在系统出现问题即C

27、PU耗尽之后，而profile 工具 本身对CPU占用较大，所以Profile 对这种情况很可能不起作用。根据 Heisenb erg 效应，任何测试手段或多或少都会改变系统运行，这个对 profiler 同样适 用！总之，提高运行效率的前提是你必须要知道 CPU到底干了些什么干的怎么 样。4.不要让自己大海捞针大海捞针只是对调试的一种生动比喻。 经常听到组里有人对自己正在调试的代码说 shit ！可以理解，因为代码不 是他写的，他有足够的理由去 shit bug 百出的代码，只要他自己不要写出这种 代码，否则有一天同组的其它人可能同样会 shit 他写的代码。 为何会有大海捞 针呢？肯定是有

28、人把针掉到海里咯； 那针为何会掉在海里呢？肯定是有人不小心 或草率呗。 所以当你在抱怨针那么难找的时候， 你是否想过是你自己草率地丢掉 的。同样，当你调试个半死的时候，你是否想过你要好好反省一下当初为了寻 求捷径可能没有严格地遵守好的编码设计规范、没有检测一些假设条件或算法 的正确性、没有将一些可能存在问题的代码打上记号呢？ 关于如何写高质量请参 考林锐的咼质量C+/C编程指南或关于C的0x8本“经书”（。如果你确实已经把针掉在海里是， 为了防止在找到之前刺到自己， 你必须要 做一些防范工作，比如戴上安全手套。同样，为了尽能地暴露和捕捉问题根源， 我们可以设计比较全面的错误跟踪代码。 怎么来做

29、呢？尽可能对每个函数调用失 败作出处理，尽可能检测每个参数输入输出的有效性包括指针以及检测是否过多 或过少地调用某个过程。错误跟踪能够让你知道你大概把针掉在哪个位置。5.重现并隔离问题如果你不是把针掉在大海了， 而是掉在草堆里， 那要好办写。 因为至少我们 可以把草堆分成很多块， 一块一块的找。 对于模块独立的大型项目， 使用隔离方 法往往是对付那些隐藏极深 bug 的最后方法。如果问题的出现是间歇性的 , 我们 有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这些条 件去重现问题。 如果你确信可以使用记录的那些条件去重现问题， 那么我们就可 以着手去隔离问题。 怎么隔离呢？我们

30、可以用 #ifdef 把一些可能和问题无关的 代码关闭，把系统最小化到仍能够重现问题的地步。 如果还是无法定位问题所在， 那么有必要打开“工具箱” 了。可以试着用ICE或数据监视器去查看某个可疑变 量的变化；可以使用跟踪工具获得函数调用的情况包括参数的传递； 检查内存是 否崩溃以及堆栈溢出的问题。6.以退为进猎人为了不使自己在森林里迷路，他常常会在树木上流下一些标记，以备 自己将来有一天迷路时可以根据这些标记找到出路。 对过去代码的修改进行跟踪 记录对将来出现问题之后的调试很有帮助。 假如有一天， 你最近一次修改的程序 跑了很久之后忽然死掉了，那么你这时的第一反映就是我到底改动了些什么呢， 因为上次修改之前是好的。 那么如何检测这次相对于上次的修改呢？没错， 代码 控制系统 SCS或称版本控制系统 VCS(Concurrent Version Control,CVS是 VCS的演化版本 ) 。将上个版本 check in 下来后和当前测试版本比较。 比较的工具可 以是SCS/VCS/CV自带的diff 工具或其它功能更强的比较工具， 比如BeyondCo mpare和ExamDiff。通过