嵌入式软件测试.ppt

《嵌入式软件测试.ppt》由会员分享，可在线阅读，更多相关《嵌入式软件测试.ppt（35页珍藏版）》请在三一文库上搜索。

1、1/35 1 第15讲 嵌入式软件测试 2/35 一、嵌入式软件测试概念 嵌入式系统的自身特点，使得嵌入式软件很难测试 l如实时性(Real-timing)，内存不丰富，I / O通道少，开发工具昂 贵，并且与硬件紧密相关CPU种类繁多，等等 l嵌入式软件的开发和测试与一般商用软件的开发和测试策略有很大的 不同，可说嵌入式软件是最难测试的一种软件 嵌入式软件开发采用“宿主机目标机”交叉方式 l即相应的测试也为host-target测试或cross-testing l所有测试如放在目标平台上会有很多不利的因素： 1.测试软件，可能会造成与开发者争夺时间的瓶颈，避免它只有提供更多 的目标环境 2.

2、目标环境可能还不可行 3.比起主机平台环境，目标环境通常是不精密的和不方便的 4.提供给开发者的目标环境和联合开发环境通常是很昂贵的 5.开发和测试工作可能会妨碍目标环境已存在持续的应用 3/35 一、嵌入式软件测试概念（续） 交叉测试环境下应关注的问题： l测试需要多少人员（单元测试，软件集成，系统测试）? l多少软件应该测试，测试会花费多长时间？ l在主机环境和目标环境有哪些测试软件工具，价格怎样，是 否适合? l多少目标环境可以提供给开发者，什么时候? l主机和目标机之间的连接怎样？ l被测软件下载到目标机有多快? l使用主机与目标环境之间有什么限制（如软件安全标准）? 管理者在进行嵌入

3、式软件测试时都应深入考虑以上问 题，结合自身实际情况，选定合理测试策略和方案 4/35 一、嵌入式软件测试概念（续） 嵌入式软件测试各个阶段的通用策略 l单元测试 l所有单元级测试都可以在主机环境上模拟目标环境进行，除非少数 情况，特别具体指定了单元测试直接在目标环境进行 l集成测试 l软件集成也可在主机环境上完成，在主机平台上模拟目标环境运行 ，当然在目标环境上重复测试也是必须的，在此级别上的确认测试 将确定一些环境上的问题，比如内存定位和分配上的一些错误 l在主机环境上的集成测试的使用，依赖于目标系统的具体功能有多 少。有些嵌入式系统与目标环境耦合的非常紧密，若在主机环境做 集成是不切实际

4、的 l一个大型软件的开发可以分几个级别的集成。低级别的软件集成在 主机平台上完成有很大优势，越往后的集成越依赖于目标环境 5/35 一、嵌入式软件测试概念（续） 嵌入式软件测试各个阶段的通用策略（续） l系统测试和确认测试 l所有的系统测试和确认测试必须在目标环境下执行 l当然在主机上开发和执行系统测试，然后移植到目标环境重复执行 是很方便的 l对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系 统上，况且只有少数开发者会卷入系统测试，所以有时放弃在主机 环境上执行系统测试可能更方便 l确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真 实系统之下测试，而不能在主机环境下模拟。

5、这关系到嵌入式软件 的最终使用。 l包括恢复测试、安全测试、强度测试、性能测试 好的交叉测试策略能提高嵌入式软件测试水平和效率 6/35 一、嵌入式软件测试概念（续） “白盒”测试的插桩概念 7/35 一、嵌入式软件测试概念（续） 嵌入式软件测试的一般流程 A.使用测试工具的插装功能（主机环境）执行静态测试分析 ，并且为动态覆盖测试准备好一插装好的软件代码 B.使用源码在主机环境执行功能测试，修正软件的错误和 测试脚本中的错误 C.使用插装后的软件代码执行覆盖率测试，添加测试用例或 修正软件的错误，保证达到所要求的覆盖率目标 D.在目标环境下重复（B），确认软件在目标环境中执行测 试的正确性

6、E.若测试需要达到极端的完整性，最好在目标系统上重复 （C），确定软件的覆盖率没有改变 8/35 一、嵌入式软件测试概念（续） 嵌入式软件测试的一般流程（续） l通常在主机环境执行多数的测试，只是在最终确定测试结果 和最后的系统测试才移植到目标环境，这样可以避免发生访 问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿 真器上的费用 l另外，若目标系统的硬件由于某种原因而不能使用时，最后 的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的 开发测试提供了弹性 l设计软件的可移植性是成功进行交叉的先决条件，它通常可 以提高软件的质量，并且度软件的维护大有益处 l很多测试工具，都可以通过各自的

7、方式提供测试在主机与目 标之间的移植，从而使嵌入式软件的测试得以方便的执行 9/35 二、嵌入式软件测试的典型工具 嵌入式“白盒”测试工具 l白盒测试是以源代码为测试对象，除对软件进行通常的结构分析和质量 度量等静态分析外，主要是进行动态测试 l代表了当今软件自动化测试领域最高水平的高级语言单元测试工具 VectorCAST l瑞典Telelogic公司的logiscope和美国IBM公司的Rational的Test Realtime，通过串口以太网对应被测软件运行的目标机上进行连接，在 对软件进行插桩后下载到目标机上运行进行准实时的或事后的分析 l美国Freesacle公司的Codetest

8、与被测目标机通过总线或飞线方式进行 连接，将被测软件进行插桩，当被测软件在目标机上运行时对其进行实 时的监测 l国内有通过总线监听手段进行覆盖测试，当CPU采用指令预取方式工作 时这种方式就有问题了 10/35 二、嵌入式软件测试的典型工具(续) 嵌入式“黑盒”测试工具 l“黑盒”测试是将嵌入式软件当作一个黑盒子,只关注系统的输入输出 l目前的测试做法是以硬件方式将被测系统的输入输出端口用硬件对应连 接，使用实时处理机和宿主机对被测系统进行激励和输入，进行驱动， 然后获取输出结果进行分析，进行开环或闭环测试 l优点是实时性强 l缺点是这种测试实际上是对整个被测系统的测试，是一种确认性测试， 如

9、发生问题，不知道是硬件还是软件发生的问题，还是软硬件耦合发生 的问题 l如果目标机未设计制造出或无法得到，这种测试无法进行 l代表性的公司和产品是德国Tech SAT的ADS2系统。价格比较昂贵。国 内的是北航的GESTE嵌入式系统测试环境 11/35 嵌入式“灰盒”测试工具 l“灰盒”测试是指嵌入式软件即能做“白盒”测试，又能做 “黑盒”测试的测试工具，目前主要是基于全数字仿真或半 实物仿真技术的应用 l欧洲航天局的SPACEBEL、SHAM等产品 l国内北京奥吉通有限公司的科锐时系列产品CRESTS/ATAT和 CRESTS/TESS等 二、嵌入式软件测试的典型工具(续) 12/35 嵌入

10、式软件仿真工具 l空间飞行器、卫星等工作在太空中，空间飞行器、 卫星控制软件即嵌入式软件的调式与测试必须 在一个等价太空环境下的仿真环境里进行 l仿真环境的建立需要仿真工具的支持。 l欧洲航天实时仿真产品Eurosim以及网络资源透明 访问工具SPINEware是最具典型的嵌入式软件仿真 工具 二、嵌入式软件测试的典型工具(续) 13/35 单元测试工具美国Vector公司的VectorCAST lVectorCAST用于高级语言的单元测试、组装测试及集成测试 。它代表了当今软件自动化测试领域最高水平，它能够： l自动插桩（Stub）及针对被测程序单元自动生成驱动程序 l与主流编译程序器，目标

11、机板，以及实时操作系统(RTOS)的相结合 l自动生成从小、中、大三种参数取值的测试用例，自动生成测试用 例的范围值 l允许顾客采用图像化的点击界面或直观手写（Scripting）界面来设 计测试用例 l允许完整的自动回归测试 l提供图像化说明、分支(Branch)和MC/DC代码覆盖率 l在主机上、仿真器和嵌入式目标机系统上执行测试 l支持Ada语言和C/C+等语言 三、嵌入式软件测试的典型工具举例 14/35 三、嵌入式软件测试的典型工具举例(续) IBM Rational Test RealTime(RTRT) lRTRT是一个针对单元测试和实时分析的交叉平台解决方案 lRTRT是特别为

12、那些嵌入式、实时软件和其它类型的交叉平台 软件产品而开发设计的 lRTRT使得你在调试过程中能更多的了解代码的执行情况，让 你能够在程序运行前修改你的代码 l使用RTRT，你能够： l在开发过程中测试，分析和解决问题 l在主机和目标机上测试和调试 l构造模型驱动测试工具 15/35 白盒测试工具美国FreeScale公司Metroworks的CodeTest lCodeTest是专为嵌入式系统软件测试而设计的工具套件 l为追踪嵌入式应用程序，分析软件性能，测试软件的覆盖率以及监控内 存动态分配等提供了一个实时在线的高效率解决方案 lCodeTest还是一个可共享的网络工具，它将给整个开发和测试

13、团队带来 高品质的测试手段 lCodeTest可同时监视整个应用程序，这就避免了在选择程序的哪部分来 观测以及如何配置相应工具来对各部分进行测试时带来的困难 l即便是在程序超出高速缓存(cache)或被动态再分配时，CodeTest仍 能生成可靠的追踪及测试结果 l在进入连续运行模式时，CodeTest能够同时测试出软件的性能，代码覆 盖以及存储器动态分配，捕获函数的每一次运行。 l无论是在检测一个局部的软件模块还是整个软件系统测试，工程师只须 简单地将CodeTest的仿真探头(probe)插到目标系统的处理器上，预处 理待测的源程序，启动CodeTest，运行测试处理软件 l测试结果在测试

14、进行过程中或在测试结束后均可随时观看 三、嵌入式软件测试的典型工具举例(续) 16/35 比利时SPACEBEL公司产品全数字仿真测试工具 lERC32/1750/ADSP Target Simulator用于航天设计,仿真应用等方面 l目标机模拟器能够模拟ERC32/1750/ADSP计算机 l能够模拟CPU指令、各种硬件动作和I/O模拟 l所提供的功能比仿真器更加丰富 l能够进行中断和错误注入 l当程序执行到断点处，仿真硬件全部“冻结”，从而便于实时调试 l支持如IU、FPU、UART、timers、DMA、ATAC以及各类I/O活动 l时间性能比较理想 l给出被测试代码执行的覆盖情况 l

15、完全不需要实施插装 lERC32/1750/ADSP Target Emulator能够与配备了Jtag接口的ERC32目标 板相连，能够访问所有的IU, FPU和MEC寄存器，及目标板上所有的存储 单元 三、嵌入式软件测试的典型工具举例(续) 17/35 荷兰CHESS公司产品SHAM半实物仿真测试工具 l星载软件验证设备SHAM是专门针对航天工业中卫星上的姿轨控制系统和数据管 理系统的嵌入式软件验证(确认)开发的专用系统 l该系统是一个多计算机环境，由宿主机系统和仿真处理模块SHAM组成 lSHAM包含一个目标处理器和支持与控制系统 l目标处理器执行被测汇编语言程序，Ada语言程序，汇编语

16、言、Ada语言混合 语言程序的最终二进制代码 l支持与控制系统控制目标处理器的行为并仿真低级硬件接口 l宿主机用于应用测试和全面控制,并提供更复杂环境的仿真模拟 l被测汇编语言程序，Ada语言程序，混合语言程序最终二进制代码无需任何 修改，直接执行于真实目标处理器中，应用于被测软件真实的外界感知环境 的仿真系统中 l支持运行在真实目标处理器基础上的覆盖率分析 lSHAM已经几次检测出严重的星载软件的缺陷，及时发现了被测星载软件的失 效过程，防止了整个卫星的损失 三、嵌入式软件测试的典型工具举例(续) 18/35 “黑盒”测试工具GESTE lGESTE(General Embedded Sys

17、tem Testing Environment)为嵌入式系统 提供仿真测试环境，实现对嵌入式系统进行实时、闭环的、非侵入式的 系统测试 l该产品的主要功能有：测试环境与测试仿真模型开发、测试脚本图形化 生成/调试、测试环境配置、实时测试、测试数据收集定制、测试数据 事后分析及日志管理等 lGESTE采用当前主流嵌入式操作系统VxWorks，定时精度为1ms，根据仿 真环境复杂程度不同，可以满足工作周期不小于5ms 的实时嵌入式系统 测试 l针对用户的不同需求，本软件具有较强的适应能力，可针对不同的用户 进行定制，提供开放的测试脚本描述语言及仿真建模环境，充分满足用 户在系统测试、开发中的各种需

18、求 三、嵌入式软件测试的典型工具举例(续) 19/35 欧洲航天局实时仿真产品Eurosim lEurosim是一个可构造的模拟仿真系统工具，应用于太空项目和工业项 目生存周期所有阶段的人机交互和设备交互实时仿真。应用Eurosim可 以使已有的模型软件重用 l每个模拟过程都可以分解成多个可重用的部件工具，然后对每个部件工 具的功能细节进行仿真 l详细设计的工具部件可重复应用到小规模，以及规模庞大的仿真应用中 lEurosim可以帮助用户减少模拟仿真所花费的费用，使在工程项目中可 以尽早和更广泛的进行模拟仿真活动（如可行性评估阶段、设计阶段、 原型构造阶段、生产/测试阶段、操作/培训阶段） l

19、EuroSim提供一个开放的系统结构 l与MATLAB、PVWAVE、VEGA、Satellite Tool Kit(STK)集成使用，可以更好 的发挥EuroSim及相关工具的功效 l相关应用涉及从子系统到整个系统的系统设计、系统分析、可视化设计 、系统仿真设计 lEuroSim已经应用与多个太空项目，工业项目 l如：全球导航卫星的性能验证，自动导航水下交通工具、 Euromoon 2000-月球登陆车、臭氧监控器等的仿真模拟、TVE-软件验证设备、 战斗机飞行员模拟仿真训练系统 三、嵌入式软件测试的典型工具举例(续) 20/35 网络资源透明访问工具SPINEware l当前每个用户面临着

20、和越来越复杂，越来越多样化的计算机系统打交道 ，并且要求这些计算机系统在一个分布式的网络环境下工作 l在空间科学的研究中,在系统仿真阶段面临着和各种仿真工具打交道,处 理、应用和转换网络中各种各样的数据，形成工作产品的难度越来越大 l规范仿真工作中的工作流程，为工作流程建模成为一种自然而然的需要 lSPINEware是一个中间件系统，它通过提供一组集成工具和中间件支持 用户在由不同计算机平台所组成的计算机网络中构建工作环境，并在工 作环境中运用一致的、完整的、可视化的操作使用有关资源(对象资源) lSPINEware的工作环境为用户提供了访问网络资源的能力，这些资源就 象存放在一台虚拟的计算机

21、中，在该计算机中，计算、存储、输入/输 出以及信息(如软件、数据与文档)等资源都是通过树结构以对象的形式 提供给用户进行访问的，用户通过图形用户界面能方便地操作这些对象 l当前的仿真工作可能需要大量的不同性质的资源，仿真设计人员可能并 不是某个领域或者某个软件的使用专家，但构建特定的仿真过程需要这 些资源。 SPINEWARE的工作流程建模器，提供简单的方式定义工作流程 ，应用工作流程的能力，使特定的业务流程规范化，模型化 三、嵌入式软件测试的典型工具举例(续) 21/35 四、传统“白盒”测试工具的局限性 传统“白盒”测试工具共同的缺陷之一是： l所有的结构测试都要求插桩 l被测软件代码膨胀

22、，使本来就匮乏的系统资源更加紧张 l尤其是汇编程序，由于它是低级语言，即它的结构化能力弱，指令功能 低级，要构造复杂的算法，需要大量的汇编子程序调用、条件判断以及 程序跳转指令，插桩后代码膨胀更为明显 l代码膨胀有可能导致： l系统错误(被测程序设计中的代码和数据分配受到影响) l时序错误(被测程序的中断与端口输入/输出的时序延时) l甚至逻辑错误(汇编程序中相对调用或跳转的目的地址可能越界) l影响软件运行的真实性和实时性 l无法对软件运行起来后进行实时跟踪 22/35 四、传统“白盒”测试工具的局限性(续) 传统“白盒”测试工具共同的缺陷之二是： l外部事件的激励很难引入 l中断事件、输入

23、/输出事件以及其它相关事件无法按逻辑时 序产生 l无法构造能使被测软件闭环运行的测试环境 传统“白盒”测试工具共同的缺陷之三是： l基于宿主机/目标机的工作方式的“白盒”测试工具其目标机 的地址空间难以做到对用户全部开发（部分被占用） 23/35 五、传统“黑盒”测试工具的局限性 传统“黑盒”测试工具的共同缺陷之一是： l被测软件的运行环境目标硬件必须存在 l这在目标硬件还没有开发出来，或目标硬件发生变化，甚至被测方 不提供目标硬件的情况下是无法测试的 传统“黑盒”测试工具的共同缺陷之二是： l价格非常昂贵 l外部逻辑信号的产生程序员编程，需要计算机处理(专用计 算机) l多路信号的配置可能满

24、足不了我们实际应用变化的要求 传统“黑盒”测试工具的共同缺陷之三是： l维护困难，易损坏 24/35 六、全数字仿真用于测试的解决方案 全数字仿真的概念 l嵌入式软件的全数字仿真就是脱离目标机，用数字 模拟硬件或电路的信号结果并交给嵌入式软件计算 和处理 l更为特别的是还模拟或解释了CPU的指令和相关时 序从而避免了插桩 lSPACEBEL公司的ERC32 Target Simulator和奥吉通 CRESTS/ATAT和CRESTS/TESS就是嵌入式软件全数字 仿真的典型代表 25/35 嵌入式软件全数字仿真测试支撑平台总体结构图 26/35 六、全数字仿真用于测试的解决方案(续) 全数字

25、仿真的产品CRESTS/ATAT和CRESTS/TESS l通过虚拟目标机解释执行嵌入式软件和对外围电 路和外部事件进行全数字化仿真 l很好地解决了前面我们提到的代码膨胀问题和硬 件环境无法搭建问题 l嵌入式软件在虚拟目标机环境的运行效率要低 l现在计算机配置越来越高，性能越来越好，速度 越来越快，内存越来越大运行效率要低已不是主 要问题了 27/35 CRESTS/ATAT和CRESTS/TESS（续） l针对汇编语言和高级语言的分析与测试工具 l为嵌入式系统提供全数字仿真测试环境或测试平台 ，实现对嵌入式系统进行实时、闭环的、非侵入式 (不插桩)的系统测试 l在该平台上能够对被测软件进行静

26、态分析、模拟运行、 高级调试和综合测试 l实现了嵌入式软件外部事件的全数字仿真，嵌入式软件 就像在真实硬件环境下连续不中断地运行 六、全数字仿真用于测试的解决方案(续) 28/35 CRESTS/ATAT和CRESTS/TESS的工作流程 l装载在开发环境中交叉编译后的被测软件 l对被测程序进行静态分析,生成程序理解和质量度量的数据 l对被测嵌入式软件程序进行测试和调试 l通过全数字仿真模拟端口、中断等外部事件，使被测嵌入式软件程序能 够“闭环”运行，实现测试的自动化 l对测试结果进行分析，生成测试报告 依据上述的工作流程 lCRESTS/ATAT和CRESTS/TESS能够满足嵌入式软件开发

27、阶段的内部测试和 调试以及验收阶段的验收测试的要求， l能够为测试方、被测方及上级主管单位提供可以信赖和再现测试过程与 测试问题的测试报告 六、全数字仿真用于测试的解决方案(续) 29/35 CRESTS/ATAT l目前支持Intel 8031/8051/8052、8096/80196、80x86, DSP TMS320 C2X/C3X/C4X/C5X及Mil-1750等CPU l为汇编语言的测试提供了有效的，统一的协同工作平台。在 该平台下能够完成： l汇编程序的分析与检查、汇编代码的运行与调试、汇编单元的配置 与测试、汇编系统的仿真与测试、中文测试报告生成 l有效的结合了测试与调试的能力

28、 l规范了汇编语言的测试流程 六、全数字仿真用于测试的解决方案(续) 30/35 CRESTS/ATAT（汇编程序分析与检查功能） lCRESTS/ATAT汇编程序分析与检查功能支持代码编程规则检 查，并对影响程序结构化的代码进行警告 l提供程序控制流图、程序控制流轮廓图、程序调用树、程序 被调用树和程序危害性递归等 l给出度量程序质量的多种度量元（如McCabe的圈复杂度，程 序跳转数，程序扇入/扇出数、程序注释率、程序调用深度 ，程序长度，程序体积，程序调用及被调用描述等） 六、全数字仿真用于测试的解决方案(续) 31/35 CRESTS/ATAT(汇编代码运行与调试功能) lCRESTS

29、/ATAT的汇编代码运行与调试功能为汇编用户提供了 不需真实硬件的CPU模拟运行环境 l在该环境下，解释执行所有的CPU指令，模拟所有指令的时 序，模拟定时中断等； l支持汇编程序的各种调试，包括：控制程序运行方式、修 改程序运行状态、观察程序运行结果等 CRESTS/ATAT(汇编单元配置与测试功能) lCRESTS/ATAT的CPU上下文场景的自编程配置能力解决了对 汇编程序进行单元测试的需求 l用户可根据单元测试的要求，灵活方便地对CPU上下文场景 进行配置，形成汇编程序单元执行的驱动 六、全数字仿真用于测试的解决方案(续) 32/35 CRESTS/ATAT(汇编系统仿真与测试功能)

30、l汇编系统仿真与测试功能提供了对汇编程序进行功能测试 与覆盖测试的手段。 l其中覆盖测试支持汇编程序的语句、分支和调用覆盖测试 ，并支持图形化显示 l而外部事件的编程仿真方式，解决了外部激励、系统闭环 运行和功能测试的要求 CRESTS/ATAT(中文测试报告) l中文测试报告以超文本形式给出了被测汇编程序的静态分 析和动态测试的各种结果及结果统计 l提出了汇编编程风格约定和汇编程序质量度量建议 六、全数字仿真用于测试的解决方案(续) 33/35 CRESTS/ATAT(外部事件仿真技术) l用TCL高级脚本编程模拟I/O与中断事件的产生 l被测汇编程序在模拟环境运行过程中，尽管存大量的I/O

31、与中断事件产生的 要求，也能够与真实硬件环境一样连续不中断地运行。 l在设计初期,在真正的硬件制造出来之前,或设计要进行变化,以及进行维护 等,这一点非常重要。 l端口I/O与中断事件产生的自编程模拟功能很好地解决了汇编程序在模拟运 行环境下的闭环测试问题，实现了测试过程的自动化 l被测汇编程序的测试用例可用Tcl脚本语言编写和管理 CRESTS/ATAT(各种测试需求的支持) l端口I/O与中断事件产生的自编程模拟功能以及CPU上下文场景的自编程 配置能力为用户提供了“黑盒”测试及单元测试的手段 l支持汇编程序检查分析、汇编代码运行调试、“白盒”测试、“黑盒” 测试以及单元与集成测试等 l支

32、持“灰盒”测试技术的应用 六、全数字仿真用于测试的解决方案(续) 34/35 CRESTS/TESS l技术含量最大的是程序分析技术和符号解释技术 l虚拟目标机 l通过软件模拟的方式实现TI公司的DSP TMS320 C3X/C4X的虚拟目标机 l虚拟目标机要完成的任务有：CPU指令集的解释、CPU时序的模拟、CPU端口 动作的仿真、CPU中断机制以及CPU流水、缓冲和并行指令等 l程序理解 lTESS在程序理解方面要做的工作是解决C语言函数之间的调用关系、被调用 关系以及函数内部的控制流程关系的表示和图形显示 l软件质量度量 lTESS在国际软件质量标准ISO/IEC 9126和权威理论基础

33、上，给出那些严重影 响程序整体质量的度量元，实现McCabe的圈复杂性度量，FP功能点度量方及 Halstead源代码复杂性度量等 六、全数字仿真用于测试的解决方案(续) 35/35 CRESTS/TESS（续） l软件测试 l支持软件测试常用的覆盖测试、功能测试、单元测试、系统测试及回归测试 l支持测试用例或测试脚本的应用，支持“闭环”测试和测试过程的自动化 l对于覆盖测试要支持调用覆盖、分支覆盖以及语句覆盖的图形显示。 l软件调试 l高级符号调试器要具备控制程序运行，观察或改变程序运行状态的功能 lTESS实现程序的单步运行，连续运行，设置断点等手段控制程序的运行，实现代码、 数据、寄存器内容以及高级符号变量的读写或改变程序的运行状态 l全数字仿真 lTESS提供模拟外部设备产生外部激励信号的机制(全数字仿真)，即用TCL脚本语言编写 端口事件、中断事件以及其它外部事件的逻辑流程 l软件分析与测试总结报告 lTESS的软件分析与测试总结报告是超文本的，它要给出被测程序的程序理解信息、质 量度量信息、程序运行信息以及测试结果统计信息等 六、全数字仿真用于测试的解决方案(续)