第八章——嵌入式系统实施知识
第八章——嵌入式系统实施知识
前言:
计算机第八章节主要知识点。
1 知识点介绍
- 软件测试
- 软件调试
- 软件评审
- 验证与确认
- 下午题专题训练
2 嵌入式系统实施知识
2.1 测试概述
- 经典定义:在规定的条件下对程序进行操作,以发现错误,对软件质量进行评估。
- 对象:程序、数据和文档。
- 目的:发现软件的错误,验证软件是否满足用户需求,并通过分析软件错误产生的原因,以帮助发现当前开发工作所采用的软件过程的缺陷,以便进行软件过程改进。
嵌入式软件的测试工作与台式机上的应用软件的测试工作有许多共同之处,但也有很大区别。
- 嵌入式系统的硬件一般采用专门的测试仪器进行测试;
- 由于嵌入式软件自身的特点,其测试过程相对复杂;
- 与PC软件相比,在测试嵌入式软件时,除了逻辑上的正确性之外,还要看重系统的性能和健壮性;
- 嵌入式软件的一个重要特点是实时性;
- 嵌入式系统的开发是一个软硬件相互协调、互相反馈和互相测试的过程;
2.1 例题
- 软件测试的目的是(B)。
A. 评价软件的质量
B. 发现软件的错误
C. 证明软件是正确的
D. 找出软件中的所有错误
2.2 测试方法
- 动态测试
- 黑盒测试
- 白盒测试
- 灰盒测试
- 静态测试
- 桌前检查
- 代码审查
- 代码走查
2.3 测试用例设计
- 黑盒测试法
- 等价类划分
- 边界值分析
- 错误推测
- 因果图
- 白盒测试法
- 基本路径测试
- 循环覆盖测试
- 逻辑覆盖测试
- 语句覆盖(SC)
- 判定覆盖(DC)
- 条件覆盖(CC)
- 条件判定覆盖(C/DC)
- 条件组合覆盖(MCC)
- 修正的条件判断覆盖(MC/DC)
- 路径覆盖
2.4 例题
- 用边界值分析法,假定 $10 \leq X \leq 30$,那么X在测试中应取的边界值是(D)。
A. X = 11, X = 29
B. X = 9, X = 10, X = 30, X = 31
C. X = 10, X = 30
D. X = 9, X = 31
2.5 逻辑覆盖测试用例设计
2.5.1 判定覆盖(分支覆盖)(DC)
设计足够多的测试用例,使得被测试程序中的每条可执行语句至少被执行一次。在本例中,可执行语句是指语句块1到语句块4中的语句。
用例数据 | P1(x > && y > 0) | P2(magic < 0) | 路径 |
---|---|---|---|
{x = 3, y = 3} | T | F | abef |
{x = -3, y = 0} | F | T | acdf |
设计足够多的测试用例,使得被测试程序中的每个判断的“真“,”假“分支至少被执行一次。
2.5.2 条件覆盖(CC)
设计足够多的测试用例,使得被测试程序中的每个逻辑条件的可能值至少被满足一次。
| 用例数据 | C1(x > 0) | C2(y > 0) | C3(magic < 0) | P1(x > 0 && y > 0) |
|:—:|:—:|:—:|:—:|:—:|:—:|
| {x = 3, y = 0} | T | F | T | F | T |
| {x = -3, y = 15} | F | T | F | F | F |
2.5.3 条件判定覆盖(C/DC)
简称C/DC,设计足够多的测试用例,使得被测试程序中的每个判断本身的判定结果(真假)至少满足一次,同时,每个逻辑条件的可能值也至少被满足一次。即同时满足100%判定覆盖和100%条件覆盖的标准。
用例数据 | C1(x > 0) | C2(y > 0) | C3(magic < 0) | P1(x > 0 && y > 0) | P2(magic < 0) | 路径 |
---|---|---|---|---|---|---|
{x = 3, y = 3} | T | T | F | T | F | abef |
{x = -3, y = 0} | F | F | T | F | T | acdf |
2.5.4 条件组合覆盖(MCC)
设计足够多的测试用例,使得被测试程序中的每个判断的所有可能条件取值的组合至少被满足一次。
- 条件组合只针对同一个判断语句内存在多个条件的情况,让这些条件的取值进行笛卡尔乘积组合。
- 不同的判断语句内的条件取值之间无需组合。
- 对于单个条件的判断语句,只需要满足自己的所有值即可。
用例数据 | C1(x > 0) | C2(y > 0) | C3(magic < 0) | P1(x > 0 && y > 0) | P2(magic < 0) | 路径 |
---|---|---|---|---|---|---|
{x = -3, y = 0} | F | F | T | F | T | acdf |
{x = -3, y = 2} | F | T | T | F | T | acdf |
{x = 3, y = 0} | T | F | T | F | T | acdf |
{x = 3, y = 3} | T | T | F | T | F | abef |
2.5.5 路劲覆盖
设计足够多的测试用例,使得被测试程序中的每条路劲至少被覆盖一次。
用例数据 | C1(x > 0) | C2(y > 0) | C3(magic < 0) | P1(x > 0 && y > 0) | P2(magic < 0) | 路径 |
---|---|---|---|---|---|---|
{x = 3, y = 5} | T | T | T | T | T | abef |
{x = 0, y = 2} | F | T | T | F | T | acdf |
这条路径不可能 | abdf | |||||
{x = -10, y = 30} | F | T | F | F | F | acef |
2.5.6 修正的条件判定覆盖(MC/DC)
要求在一个程序中每一种输入输出至少得出现一次,在程序中的每一个条件必须产生所有可能的输出结果至少一次,并且每一个判定中的每一个条件必须必须能够独立影响一个判定的输出,即在其他条件不变的前提下仅改变这个条件的值,而使判定结果改变。
MC/DC首先要求实现条件覆盖、判定覆盖、在此基础上,对于每一个条件C,要求存在符合以下条件的两次计算。
- 条件C所在判定内的所有条件,出条件C外,其他条件的取值完全相同;
- 条件C的取值相反;
- 判定的计算结果相反;
代码示例:以下程序要达到100% MC/DC覆盖所需的最少测试用例数目?
1 | int func(BOOL A, BOOL B, BOOL C) |
解题思路:
- 先进行条件组合。
- 再进行两次计算。
- 条件C所在判定内的所有条件,除了条件C外,其他条件的取值完全相同。
- 条件C的取值相反。
- 判定的计算结果相反。
用例 | A | B | C | Return (A && (B || C)) |
---|---|---|---|---|
用例7 | 1 | 1 | 0 | 1 |
用例3 | 0 | 1 | 0 | 0 |
用例5 | 1 | 0 | 0 | 0 |
用例6 | 1 | 0 | 1 | 1 |
对于条件A,用例7和用例3,B和C相同,A取值相反,判定结果分别为1和0;
对于条件B,用例7和用例5,A和C相同,B取值相反,判定结果分别为1和0;
对于条件C,用例5和用例6,A和B相同,C取值相反,判定结果分别为0和1;
2.5 测试阶段
- 单元测试
- 集成测试
- 一次性组装
- 增量式组装
- 自顶向下
- 自底向上
- 混合式
- 确认测试
- 内部确认测试
- Alpha测试
- Beta测试
- 验收测试
- 系统测试
- 恢复测试
- 强度测试
- 性能测试
- 可靠性测试
一般系统测试用灰盒,确认测试用黑盒。
2.6 例题
- 一下关于嵌入式软件测试的叙述中,错误的是(C)。
A. 软件测试是验证软件是否满足软件开发合同、技术协议或研制任务书要求
B. 通过测试发现软件错误,为了软件产品的质量评价提供依据
C. 软件的测试级别一般分为静态测试和动态测试
D. 动态测试可以采用白盒测试或者黑盒测试
2.7 调试
2.7.1 概念
在开发嵌入式软件时,交叉调试是必不可少的一步。嵌入式软件的特点决定了其调试的特点。
- 调试器和被调试程序运行在不同的机器上
- 调试器通过某种通信方式与目标机建立联系
- 在目标机上一般有调试器的某种代理,这种代理能配合调试器一起完成对目标机上运行的程序的调试
2.7.2 调试方法
调试器通过某种方式能控制目标机上被调试程序的运行方式,并能查看和修改目标机上的内存,寄存器以及被调试程序中的变量。
- 直接测试法
- 调试监控器法
- ROM仿真器法
- 在线仿真器法
- 片上调试法
- 模拟器法
软件调试与测试的区别
- 测试的目的是找出存在的错误,而调试的目的是定位错误并修改程序以修正错误;
- 调试是测试之后的活动,测试和调试在目标、方法和思路上都有所不同;
- 测试从一个已知的条件开始,使用预先定义的过程,有预知的结果;调试从一个未知的条件开始,结束的过程不可预计;
- 测试过程可以事先设计,进度可以事先确定;调试不能描述过程或持续时间;
2.7.3 例题
- 在进行DSP的软件设计时,可以用汇编语言或c语言进行设计,最终是生成可执行文件,通过下载线缆下载到DSP上运行、调试。下列对DSP软件的开发、编译、调试过程中描述不正确的是()。
A. C语言程序和汇编语言程序都会生成目标文件
B. DSP程序的调试一个不断交互、完善的过程
C. DSP一般是通过仿真器将文件下载到板子
D. 目标文件可以直接下载到板子上进行调试
2.8 软件评审
- 不应以测试代替评审
- 评审人员应关注产品而不应评论开发人员
- 评审人员应关注于实质性问题
- 评审会议不应变为问题解决方案讨论会
- 评审应被安排进入项目计划
- 评审参与者应了解整个评审过程
- 评审人员事先应对评审材料充分了解
- 应重视评审的组织工作
2.9 验证与确认
验证与确认的区别
- 验证是指在软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求的过程。
- 确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。
- 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。
2.10 例题
- 以下关于软件验证的叙述中,错误的是(D)
A. 视图证明在软件生命周期各个阶段,软件产品或中间产品能满足客户需求
B. 强调对于过程的检验,而不是对于结果的检验
C. 验证软件是否满足它的需求规格说明
D. 验证软件的手段只有软件测试和评审
3 下午题专题训练
略