嵌入式软件测试.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 嵌入式软件测试方法（4） 交叉测试（Host/Target测试） 与目标环境无关的部分在PC机上完成 充分利用高级语言的可移植性 借鉴常规的软件测试方法 与模拟测试不同 与硬件密切相关的部分在Target上完成 需要调试环境支持 测试工具需要支持目标环境 最后在目标环境中确认 主机平台 嵌入式系统 调试环境 * * 嵌入式软件测试方法（5） 交叉测试的特点 将大部分工作转移到PC平台上，在硬件环境未建好或调试工具缺乏时就可以开展 可以充分地“拿来主义” 适用于高级语言，如C，C++ 操作方便，测试成本较低。 实时性受调试环境的制约 目标环境中测试时要占用一定的目标资源 注意目标环境和主机环境的差异：目标编译器的bug 目标码的验证 * * 如何开展交叉测试（Host/Target测试） 选用带有目标支持包(Target Package)的软件测试工具 确定哪些模块与硬件无关，哪些与硬件相关 配置相应的调试环境和目标环境 分别进行Host和Target测试 Host：源代码+测试用例-编译连接-执行-测试结果 Target：源代码+测试用例+目标包-编译连接-下载-执行-反馈测试结果 交叉测试的嵌入式调试环境 Simulator Emulator BDM/JTAG Emulator 嵌入式软件测试方法（6） * * “拿来主义” 静态分析很重要 Watts S. Humphrey的说法 很多软件工程师认为动态测试比静态测试更重要——并非如此 有经验的软件工程师平均每写1000行代码将会出现100个错误 80%的软件错误归咎于对于编写语言的错误使用,而这些错误往往不是功能测试能解决的 因此,软件工程师应该消除错误,找出根源,预防再次发生同样的问题 静态分析的重要内容——代码规则检查 实施简单、方便 无需执行程序，与嵌入式环境无关 早期介入，代价小，见效快 有利于降低动态测试的难度 有利于养成良好的编程习惯 可以执行自定的规范 嵌入式软件测试方法（7） * * “拿来主义” 动态测试不可少 动态测试是验证软件功能最直接、最有效的手段 通过运行被测程序验证其功能、性能，检查代码的执行情况 与静态分析相辅相成 需要事先设计详细、完备的测试用例 可用白盒、黑盒等方法 工作量较大、较枯燥 动态测试的主要内容 功能、性能验证，是否符合需求定义 代码覆盖。哪些代码执行了，哪些没有执行，其比例如何 嵌入式软件测试方法（8） * * “拿来主义” 白盒黑盒相辅成 白盒测试与黑盒测试是软件测试最常用、最常规的两种技术 白盒测试 把测试对象看作一个透明的盒子，测试人员从其逻辑结构入手，设计和选择测试用例，对路径、控制结构、数据流等进行测试 通过插装检查程序的状态，确定是否与预期的状态一致 侧重于代码运行的过程 黑盒测试 把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构，只依据其需求定义，检查程序运行的结果 多用于功能测试和性能分析 在程序的接口上进行 需要设计“驱动”和“打桩” 嵌入式软件测试方法（9） * * “拿来主义” 单元集成两步走 单元测试和集成测试是软件测试的两个阶段 单元测试 将被测软件分解为单元，逐个测试 单元测试需要从程序的内部结构和功能出发设计测试用例。 多个模块可以平行地独立进行单元测试 可用白盒、黑盒等方法 集成测试 在单元测试的基础上，将所有模块按照设计要求组装起来测试 主要测试内容 接口间参数传递 集成的功能实现 模块间的影响 嵌入式软件测试方法（10） * * 先静后动，从小到大，由黑到白 先静态，后动态 从代码规则检查做起 测试开展得越早，付出的代价就越小 静态分析简单、方便，成本低、见效快 静态分析为动态测试打下良好基础 大大降低了测试的成本 先单元，后集成 单元测试是集成测试的基础 单元测试得越好，集成测试的工作量就越小 先黑盒后白盒 先验证软件功能是否满足需求 后验证程序覆盖率，补充测试 软件测试策略（1） * * 质量分析，事半功倍 通过改善代码的结构来分析、改进软件的质量——充分应用结构化测试技术 软件模块的圈复杂度和逻辑结构能客观地反映软件的质量 逻辑越“复杂”，就越容易出错。 结构越“良好”，代码就越可靠 代码质量分析的好方法——结构化测试 从结构入手分析代码的复杂程度 逻辑复杂度定量化 客观 有理论基础 复杂度与代码出错的关联性非常强 指导测试的执行 指出代码质量改进的方向 嵌入式软件测试策略（2） * * 交叉测试，因地制宜 ——嵌入式软件测试 Compilation / Link Edition Tar