嵌入式软件测试 清华大学.pptVIP

四、传统“白盒”测试工具的局限性 传统“白盒”测试工具共同的缺陷之一是： 所有的结构测试都要求插桩 被测软件代码膨胀，使本来就匮乏的系统资源更加紧张 尤其是汇编程序，由于它是低级语言，即它的结构化能力弱，指令功能低级，要构造复杂的算法，需要大量的汇编子程序调用、条件判断以及程序跳转指令，插桩后代码膨胀更为明显 代码膨胀有可能导致： 系统错误(被测程序设计中的代码和数据分配受到影响) 时序错误(被测程序的中断与端口输入/输出的时序延时) 甚至逻辑错误(汇编程序中相对调用或跳转的目的地址可能越界) 影响软件运行的真实性和实时性 无法对软件运行起来后进行实时跟踪 四、传统“白盒”测试工具的局限性(续) 传统“白盒”测试工具共同的缺陷之二是： 外部事件的激励很难引入 中断事件、输入/输出事件以及其它相关事件无法按逻辑时序产生 无法构造能使被测软件闭环运行的测试环境 传统“白盒”测试工具共同的缺陷之三是： 基于宿主机/目标机的工作方式的“白盒”测试工具其目标机的地址空间难以做到对用户全部开发（部分被占用） 五、传统“黑盒”测试工具的局限性 传统“黑盒”测试工具的共同缺陷之一是： 被测软件的运行环境目标硬件必须存在 这在目标硬件还没有开发出来，或目标硬件发生变化，甚至被测方不提供目标硬件的情况下是无法测试的 传统“黑盒”测试工具的共同缺陷之二是： 价格非常昂贵 外部逻辑信号的产生程序员编程，需