《嵌入式软件测试》.ppt

四、传统“白盒”测试工具的局限性 传统“白盒”测试工具共同的缺陷之一是： 所有的结构测试都要求插桩 被测软件代码膨胀，使本来就匮乏的系统资源更加紧张 尤其是汇编程序，由于它是低级语言，即它的结构化能力弱，指令功能低级，要构造复杂的算法，需要大量的汇编子程序调用、条件判断以及程序跳转指令，插桩后代码膨胀更为明显 代码膨胀有可能导致： 系统错误(被测程序设计中的代码和数据分配受到影响) 时序错误(被测程序的中断与端口输入/输出的时序延时) 甚至逻辑错误(汇编程序中相对调用或跳转的目的地址可能越界) 影响软件运行的真实性和实时性 无法对软件运行起来后进行实时跟踪 四、传统“白盒”测试工具的局限性(续) 传统“白盒”测试工具共同的缺陷之二是： 外部事件的激励很难引入 中断事件、输入/输出事件以及其它相关事件无法按逻辑时序产生 无法构造能使被测软件闭环运行的测试环境 传统“白盒”测试工具共同的缺陷之三是： 基于宿主机/目标机的工作方式的“白盒”测试工具其目标机的地址空间难以做到对用户全部开发（部分被占用） 五、传统“黑盒”测试工具的局限性 传统“黑盒”测试工具的共同缺陷之一是： 被测软件的运行环境目标硬件必须存在 这在目标硬件还没有开发出来，或目标硬件发生变化，甚至被测方不提供目标硬件的情况下是无法测试的 传统“黑盒”测试工具的共同缺陷之二是： 价格非常昂贵 外部逻辑信号的产生程序员编程，需要计算机处理(专用计算机) 多路信号的配置可能满足不了我们实际应用变化的要求 传统“黑盒”测试工具的共同缺陷之三是： 维护困难，易损坏 六、全数字仿真用于测试的解决方案 全数字仿真的概念 嵌入式软件的全数字仿真就是脱离目标机，用数字模拟硬件或电路的信号结果并交给嵌入式软件计算和处理 更为特别的是还模拟或解释了CPU的指令和相关时序从而避免了插桩 SPACEBEL公司的ERC32 Target Simulator和奥吉通CRESTS/ATAT和CRESTS/TESS就是嵌入式软件全数字仿真的典型代表 嵌入式软件全数字仿真测试支撑平台总体结构图 六、全数字仿真用于测试的解决方案(续) 全数字仿真的产品CRESTS/ATAT和CRESTS/TESS 通过虚拟目标机解释执行嵌入式软件和对外围电路和外部事件进行全数字化仿真 很好地解决了前面我们提到的代码膨胀问题和硬件环境无法搭建问题 嵌入式软件在虚拟目标机环境的运行效率要低 现在计算机配置越来越高，性能越来越好，速度越来越快，内存越来越大运行效率要低已不是主要问题了 CRESTS/ATAT和CRESTS/TESS（续） 针对汇编语言和高级语言的分析与测试工具 为嵌入式系统提供全数字仿真测试环境或测试平台，实现对嵌入式系统进行实时、闭环的、非侵入式(不插桩)的系统测试 在该平台上能够对被测软件进行静态分析、模拟运行、高级调试和综合测试 实现了嵌入式软件外部事件的全数字仿真，嵌入式软件就像在真实硬件环境下连续不中断地运行 六、全数字仿真用于测试的解决方案(续) CRESTS/ATAT和CRESTS/TESS的工作流程 装载在开发环境中交叉编译后的被测软件 对被测程序进行静态分析,生成程序理解和质量度量的数据 对被测嵌入式软件程序进行测试和调试 通过全数字仿真模拟端口、中断等外部事件，使被测嵌入式软件程序能够“闭环”运行，实现测试的自动化 对测试结果进行分析，生成测试报告 依据上述的工作流程 CRESTS/ATAT和CRESTS/TESS能够满足嵌入式软件开发阶段的内部测试和调试以及验收阶段的验收测试的要求， 能够为测试方、被测方及上级主管单位提供可以信赖和再现测试过程与测试问题的测试报告 六、全数字仿真用于测试的解决方案(续) CRESTS/ATAT 目前支持Intel 8031/8051/8052、8096/80196、80x86, DSP TMS320 C2X/C3X/C4X/C5X及Mil-1750等CPU 为汇编语言的测试提供了有效的，统一的协同工作平台。在该平台下能够完成： 汇编程序的分析与检查、汇编代码的运行与调试、汇编单元的配置与测试、汇编系统的仿真与测试、中文测试报告生成 有效的结合了测试与调试的能力 规范了汇编语言的测试流程 六、全数字仿真用于测试的解决方案(续) CRESTS/ATAT（汇编程序分析与检查功能） CRESTS/ATAT汇编程序分析与检查功能支持代码编程规则检查，并对影响程序结构化的代码进行警告 提供程序控制流图、程序控制流轮廓图、程序调用树、程序被调用树和程序危害性递归等 给出度量程序质量的多种度量元（如McCabe的圈复杂度，程序跳转数，程序扇入/扇出数、程序注释率、程序调用深度，程序长度，程序体积，程序调用及被调用描述等） 六、全数字仿真用于测试的解决方案(续) CREST