第八章 嵌入式系统实施知识

测试

概述

• 经典定义：在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估
• 对象：程序、数据和文档
• 目的：发现软件的错误，验证软件是否满足用户需求，并通过分析软件错误产生的原因，以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。
• 嵌入式软件的测试工作与台式机上的应用软件的测试工作有许多共同之处，但也有很大区别
  • 嵌入式系统的硬件一般采用专门的测试仪器进行测试
  • 由于嵌入式软件自身的特点，其测试过程相对复杂
  • 与PC软件相比，在测试嵌入式软件时，除了逻辑上的正确性之外，还要看重系统的性能和健壮性
  • 嵌入式软件的一个重要特点就是实时性
  • 嵌入式系统的开发是一个软硬件相互协调、互相反馈和互相测试的过程

测试方法

• 动态测试
  • 黑盒测试法
  • 白盒测试法
  • 灰盒测试法
• 静态测试
  • 桌前检查
  • 代码审查
  • 代码走查

测试用例设计

• 黑盒测试法
  • 等价类划分
  • 边界值分析
  • 错误推测
  • 因果图
• 白盒测试法
  • 基本路径测试
  • 循环覆盖测试
  • 逻辑覆盖测试
    • 语句覆盖（SC）：设计足够多的测试用例，使得被测试程序中的每条可执行语句至少被执行一次。
    • 判定覆盖（DC）：设计足够多的测试用例，使得被测试程序中的每个判断的“真”、“假”分支至少被执行一次。
    • 条件覆盖（CC）：设计足够多的测试用例，使得被测试程序中的每个逻辑条件的可能值至少被满足一次。
    • 条件判定覆盖（C/DC）：设计足够多的测试用例，使得被测试程序中的每个判断本身的判断结果（真假）至少满足一次，同时，每个逻辑条件的可能值也至少被满足一次。即同时满足100%判定覆盖和100%条件覆盖的标准。
    • 条件组合覆盖（MCC）：设计足够多的测试用例，使得被测试程序中的每个判断的所有可能条件取值的组合至少被满足一次。
      • 条件组合只针对同一个判断语句内存在多个条件的情况，让这些条件的取值进行笛卡尔乘积组合
      • 不同的判断语句内的条件取值之间无需组合
      • 对于单条件的判断语句，只需要满足自己的所有取值即可
    • 修正的条件判断覆盖（MC/DC）：
      • 要求在一个程序中每一种输入输出至少出现一次，在程序中的每一个条件必须产生所有可能的输出结果至少一次，并且每一个判定中的每一个条件必须能够独立影响一个判定的输出，即在其他条件不变的前提下仅改变这个条件的值，而使判定结果改变。
      • MC/DC首先要求实现条件覆盖、判定覆盖，在此基础上，对于每一个条件C，要求存在符合以下条件的两次计算
        • 条件C所在判定内的所有条件，除条件C外，其他条件的取值完全相同
        • 条件C的取值相反
        • 判定的计算结果相反
    • 路径覆盖：设计足够多的测试用例，使得被测试程序中的每条路径至少被覆盖一次。

测试阶段

调试

概念

• 在开发嵌入式软件时，交叉调试是必不可少的一步。嵌入式的特点决定其调试的特点
  • 调试器和被调试程序运行在不同的机器上
  • 调试器通过某种通信方式与目标机建立联系
  • 在目标机上一般有调试器的某种代理，这种代理能配合调试器一起完成对目标机上运行的程序的调试

调试方法

• 调试器通过某种方式能控制目标机上被调试程序的运行方式，并能查看和修改目标机上的内存、寄存器以及被调试程序中的变量
  • 直接测试法
  • 调试监控器法
  • ROM仿真器法
  • 在线仿真器法
  • 片上调试法
  • 模拟器法

调试与测试的区别

• 测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误
• 调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同
• 测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结果的过程不可预计
• 测试过程可以事先设计，进度可以事先确定；调试不能描述过程或持续时间

软件评审

• 不应以测试代替评审
• 评审人员应关注产品而不应评论开发人员
• 评审人员应关注于实质性问题
• 评审会议不应变为问题解决方案讨论会
• 评审应被安排进入项目计划
• 评审参与者应了解整个评审过程
• 评审人员事先应对评审材料充分了解
• 应重视评审的组织工作

验证与确认的区别

• 验证是指在软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求的过程
• 确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程
• 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一