嵌入式软件测试-课件1
合集下载
课件05-嵌入式软件测试
实例1—实现方式3
Use maths co-processor to calculate the answer Examine co-processor status registers IF status=error THEN CALL Print_Line "Square root error - negative input“ RETURN 0 ELSE RETURN the answer END_IF
实例1—边界值分析设计
用例3 输入0, 返回0 执行了等价类 I 的上边界外点 , 等价类 II的下边界,等价类a的下边界 用例4 输入仅比0大的数, 返回输入值的正数 平方根 执行了等价类II下边界内点
实例1—边界值分析设计
用例5 输入最大的正数 , 返回输入值的正数 平方根 执行了等价类 II 上边界内点 , 等价类 a 的上边界
实例1—条件覆盖设计
分析 假定用实现方式4的解决方案 假定最多迭代10次 调整实现方案 : EXIT_LOOP WHEN(error<desired accuracy) or (iterations=10) :
实例1—条件覆盖设计
设计结果(1/2) 用例1 10 次迭代, 所有迭代: error>desired accuracy 用例2 2 次 迭 代 , 第 1 次 迭 代 : error>=desired accuracy, 第 2 次迭 代: error<desired accuracy
实例1—实现方式4
IF input<0 THEN CALL Print_Line "Square root error - negative input“ RETURN 0 ELSE_IF input=0 THEN RETURN 0 ELSE Calculate first approximation LOOP Calculate error EXIT_LOOP WHEN error<desired accuracy Adjust approximation END_LOOP RETURN the answer END_IF
嵌入式软件测试(精)
捕获和回放工具： 在运行时将键盘、鼠标、触摸屏上的输入记录下来， 并且能重放。所有初始输入都需要手工形成；
24
3.4 交互式软件测试(续)
• 有人提出最好从软件设计方面解决。将软件设计称接口部分（键盘和触摸屏 操作）是独立可移去的模块。接口模块可以在测试软件主要部分时移去，然 后单独测试接口部分。主要是由于接口模块功能相对而言比较简单。
16
3.2 监测真实硬件运行情况(续)
• 方法2：使用指令集仿真器 指令集仿真器是一个仿真另一种计算机指令集的 程序。这种仿真一般包括处理器和内存，但很少 涉及时间或目标机外围设备仿真，在没有实际外 部设备时，这种仿真在应用程序功能需求测试方 面的作用受到局限；
17
3.2 监测真实硬件运行情况(续)
软件测试工程师 (Ⅱ 级 ) 培训
嵌入式系统软件测试
1
PART 3 嵌入式系统软件测试
1 嵌入式软件的特点 2 嵌入式软件测试的特点 3 困难及解决办法 4 嵌入式软件开发及测试工具 5 例子
2
前言
• 嵌入式软件指嵌入式计算机系统中的软件
• 嵌入式计算机系统：其主要目的不是进行计算， 而是较大系统中成为其完整不可分割部分的计算 机系统； 如武器，航天，航空，指挥控制或运输系统中的 计算机系统。 • 嵌入式软件可能是最难测试的一类软件。
15
3.2 监测真实硬件运行情况
监测嵌入式系统中的真实硬件运行情况的困难 方法1：使用某种对目标机和宿主机都适用的编译器的高 级语言，即采用生成宿主机代码在宿主机上进行目标程序 的运行和测试； (如常用vc编译调试算法，而后移植到单片机中 )
（需要认真估计目标机和宿主机之间的差异，仔细注意可能 存在的问题，如算法字长等） 宿主机上测试的正确运行只能说明测试也将在目标机上正确 运行的有力证据；
24
3.4 交互式软件测试(续)
• 有人提出最好从软件设计方面解决。将软件设计称接口部分（键盘和触摸屏 操作）是独立可移去的模块。接口模块可以在测试软件主要部分时移去，然 后单独测试接口部分。主要是由于接口模块功能相对而言比较简单。
16
3.2 监测真实硬件运行情况(续)
• 方法2：使用指令集仿真器 指令集仿真器是一个仿真另一种计算机指令集的 程序。这种仿真一般包括处理器和内存，但很少 涉及时间或目标机外围设备仿真，在没有实际外 部设备时，这种仿真在应用程序功能需求测试方 面的作用受到局限；
17
3.2 监测真实硬件运行情况(续)
软件测试工程师 (Ⅱ 级 ) 培训
嵌入式系统软件测试
1
PART 3 嵌入式系统软件测试
1 嵌入式软件的特点 2 嵌入式软件测试的特点 3 困难及解决办法 4 嵌入式软件开发及测试工具 5 例子
2
前言
• 嵌入式软件指嵌入式计算机系统中的软件
• 嵌入式计算机系统：其主要目的不是进行计算， 而是较大系统中成为其完整不可分割部分的计算 机系统； 如武器，航天，航空，指挥控制或运输系统中的 计算机系统。 • 嵌入式软件可能是最难测试的一类软件。
15
3.2 监测真实硬件运行情况
监测嵌入式系统中的真实硬件运行情况的困难 方法1：使用某种对目标机和宿主机都适用的编译器的高 级语言，即采用生成宿主机代码在宿主机上进行目标程序 的运行和测试； (如常用vc编译调试算法，而后移植到单片机中 )
（需要认真估计目标机和宿主机之间的差异，仔细注意可能 存在的问题，如算法字长等） 宿主机上测试的正确运行只能说明测试也将在目标机上正确 运行的有力证据；
《嵌入式软件开发》课件
VxWorks
VxWorks是一种实时操作系统，广泛应用于航空航天、军事等领域。 它具有高度的可靠性和实时性，能够满足严苛的实时任务需求。
03
Android
Android是一种基于Linux的开源操作系统，主要用于移动设备。由于
其开放性和丰富的应用生态，Android也被广泛应用于嵌入式领域，如
智能家居、物联网设备等。
数据加密、数据备份与恢复
数据安全与隐私保护问题是嵌入式软 件开发中不可忽视的问题之一。由于 嵌入式系统通常涉及到敏感数据和隐 私信息，如果程序中存在数据泄露或 数据损坏问题，会导致严重的信息安 全和隐私侵犯问题。
解决方案： 对敏感数据进行加密处理 ，使用数据备份与恢复机制，确保数 据的完整性和安全性。同时加强用户 隐私保护意识，避免敏感信息的泄露 和滥用。
时钟管理问题
时钟不准确、时钟同步
时钟管理问题也是嵌入式软件开发中常见的问题之一。由于嵌入式系统 的时钟资源有限，如果程序中存在时钟不准确或时钟同步问题，会导致
系统时间错误或数据采集错误。
解决方案： 使用高精度时钟源，优化时钟配置，实现时钟同步和校准， 确保系统时间的准确性。
多任务并发问题
01
任务优先级、任务同步
外设接口
用于连接外部设备，扩展嵌入 式系统的功能。
嵌入式系统的软件架构
操作系统
负责资源管理和任务调度，提供系统服务。
驱动程序
用于管理硬件设备，实现与操作系统的通信 。
应用程序
实现特定功能的软件，直接与硬件交互。
嵌入式中间件
提供跨平台的通信和数据交换服务。
嵌入式软件开发工具与环境
IDE（集成开发环境）
《嵌入式软件开发》PPT课 件
VxWorks是一种实时操作系统，广泛应用于航空航天、军事等领域。 它具有高度的可靠性和实时性，能够满足严苛的实时任务需求。
03
Android
Android是一种基于Linux的开源操作系统，主要用于移动设备。由于
其开放性和丰富的应用生态，Android也被广泛应用于嵌入式领域，如
智能家居、物联网设备等。
数据加密、数据备份与恢复
数据安全与隐私保护问题是嵌入式软 件开发中不可忽视的问题之一。由于 嵌入式系统通常涉及到敏感数据和隐 私信息，如果程序中存在数据泄露或 数据损坏问题，会导致严重的信息安 全和隐私侵犯问题。
解决方案： 对敏感数据进行加密处理 ，使用数据备份与恢复机制，确保数 据的完整性和安全性。同时加强用户 隐私保护意识，避免敏感信息的泄露 和滥用。
时钟管理问题
时钟不准确、时钟同步
时钟管理问题也是嵌入式软件开发中常见的问题之一。由于嵌入式系统 的时钟资源有限，如果程序中存在时钟不准确或时钟同步问题，会导致
系统时间错误或数据采集错误。
解决方案： 使用高精度时钟源，优化时钟配置，实现时钟同步和校准， 确保系统时间的准确性。
多任务并发问题
01
任务优先级、任务同步
外设接口
用于连接外部设备，扩展嵌入 式系统的功能。
嵌入式系统的软件架构
操作系统
负责资源管理和任务调度，提供系统服务。
驱动程序
用于管理硬件设备，实现与操作系统的通信 。
应用程序
实现特定功能的软件，直接与硬件交互。
嵌入式中间件
提供跨平台的通信和数据交换服务。
嵌入式软件开发工具与环境
IDE（集成开发环境）
《嵌入式软件开发》PPT课 件
课件01-嵌入式软件测试
避错(Defect avoidance)
第一次就做正确
排错(defect removal)
早发现,早实施
容错(Defect tolerance) 有缺陷,也能正确的完成任务 恢复 选用最佳恢复策略,失效后继续工作
成果—缺陷管理的目的
强制按照统一的流程预防/处理缺陷
成果—异常
观察到异常 (征兆)
可能是
软件故障/失效
可能表现为
测试失效 测试缺陷 (原因)
可能造成
软件缺陷 (原因) 开发人员错误
测试人员错误
成果—使用方式的影响
软件缺陷只有被遇到时才会产生故障 , 才有可能导致失效 缺陷在软件中的位置未知 软件执行条件一般不可预知 发现和修正软件缺陷可以降低系统故 障和失效的风险
成果—缺陷分类举例1
1. 2. 3. 4. 5. 功能 系统 过程 数据 杂类
成果—缺陷分类举例2
轻微 普通 反感 烦扰 严重 输出拼写错误，遗漏一些空格 输出可能被误解或者多余 用户需要一些窍门使用户工作 拒绝处理合法事务 事务及其处理无固定轨迹 缺陷频繁且随意的导致一些用户或一些事务 受限 系统失败 使其他系统变坏，导致文件丢失
认识—发展动态
国外的情况
测试是开发过程的常规活动
测试技术的利用趋于科学
国内的情况
专业机构的情况 开发机构的情况 评价技术的使用还较局限
测试成果及其管理
软件缺陷
软件缺陷的征兆
故障
失效
注：相关定义来自IEEE Std 1633™-2008 IEEE Recommended Practice on Software Reliability
成果—错误
第一次就做正确
排错(defect removal)
早发现,早实施
容错(Defect tolerance) 有缺陷,也能正确的完成任务 恢复 选用最佳恢复策略,失效后继续工作
成果—缺陷管理的目的
强制按照统一的流程预防/处理缺陷
成果—异常
观察到异常 (征兆)
可能是
软件故障/失效
可能表现为
测试失效 测试缺陷 (原因)
可能造成
软件缺陷 (原因) 开发人员错误
测试人员错误
成果—使用方式的影响
软件缺陷只有被遇到时才会产生故障 , 才有可能导致失效 缺陷在软件中的位置未知 软件执行条件一般不可预知 发现和修正软件缺陷可以降低系统故 障和失效的风险
成果—缺陷分类举例1
1. 2. 3. 4. 5. 功能 系统 过程 数据 杂类
成果—缺陷分类举例2
轻微 普通 反感 烦扰 严重 输出拼写错误，遗漏一些空格 输出可能被误解或者多余 用户需要一些窍门使用户工作 拒绝处理合法事务 事务及其处理无固定轨迹 缺陷频繁且随意的导致一些用户或一些事务 受限 系统失败 使其他系统变坏，导致文件丢失
认识—发展动态
国外的情况
测试是开发过程的常规活动
测试技术的利用趋于科学
国内的情况
专业机构的情况 开发机构的情况 评价技术的使用还较局限
测试成果及其管理
软件缺陷
软件缺陷的征兆
故障
失效
注：相关定义来自IEEE Std 1633™-2008 IEEE Recommended Practice on Software Reliability
成果—错误
《嵌入式软件测试》课件
嵌入式软件测试的重要性
确保功能正确性
通过测试验证嵌入式软件是否满足设计要求 和用户需求。
提高软件质量
及时发现并修复缺陷，降低软件故障风险。
保障安全性和可靠性
防止因软件故障导致的硬件损坏或安全事故 。
嵌入式软件测试的挑战与解决方案
轻量级测试工具
适用于资源受限环境，如静态 代码分析工具。
灰盒测试
介于白盒和黑盒之间，关注输 入/输出和内部结构。
测试工具
回归测试可以使用各种自动化测试工 具和框架，如TestNG、JUnit等。
03
嵌入式软件测试工具
静态代码分析工具
总结词
通过分析源代码或编译后的目标代码，找出潜在的编码错误、风格问题和安全 漏洞。
详细描述
静态代码分析工具在代码编写阶段就能发现潜在问题，有助于提高代码质量和 减少运行时错误。常见的静态代码分析工具包括Cppcheck、SonarQube等。
测试方法
白盒测试、黑盒测试、灰盒测试等。
测试工具
针对不同开发环境和编程语言，有各种单 元测试框架和工具，如JUnit、TestNG、 CxxTest等。
集成测试
总结词
对嵌入式软件中多个模块或功 能进行集成后的测试
详细描述
集成测试是在单元测试的基础 上，将多个模块或功能进行集 成，检查它们之间的协调性和 整体性能。
测试方法
集成测试可以采用自底向上或 自顶向下的方式进行，确保模 块之间的接口正确、数据传输 无误。
测试工具
集成测试可以使用各种自动化 测试工具和框架，如TestLink、
Jira等。
系统测试
总结词
对整个嵌入式软件系统进行全面的测试
详细描述
嵌入式系统软件测试-OS_test
2020/4/9
12
测试设计－与通用软件测试的区 别
没有可移植性、兼容性等的测试要求； 多数嵌入式系统也没有人机接口的测 试要求； 由于嵌入式系统的软件与硬件系统密 切相关，确认测试完成并不表明软件测试 的结束； 软件最终的确认测试是完成系统集成 测试以后的系统验收测试。
2020/4/9
13
测试设计－系统集成测试
10
测试设计－软件集成测试流程
软件单元测试 软件集成测试 软件系统测试
软件模块测试
模块集成 软件与硬件集成 软件配置项确认测试
软件配置项集成 软件系统确认测试
系统测试
真实系统测试 软件系统与硬件集成 系统验收测试
2020/4/9
11
测试设计－确认测试
检验所开发的软件能否满足功能和性能需求。
与通用软件的确认测试不完全一致 软件配置项级确认测试 系统级确认测试－验收测试 广度上有所要求（重视强度测试、安全性测试、可恢复 性测试… ）
2020/4/9
6
测试设计－单元测试
旨在发现程序模块的编码和逻辑错误。
要重视静态分析和代码审查 确定软件单元粒度 用例设计的方法取决于被测单元的特点 性能测试（中断处理、实时性）
2020/4/9
7
测试设计－关于代码审查
人工测试技术在检查某些编码错 误时，有着特殊的功效，它常常能 够找出利用计算机不容易发现的错 误。人工测试至今仍是一种行之有 效的测试方法。一个对照实验发现， 人工走查和审查会平均能查出被测 程序的38%错误，IBM代码审查会 的查错效率高达80%。
模块的时间特性是一个统计数值而不是只靠 一次测试得到的结果。
2020/4/9
9
测试设计－集成测试
嵌入式系统软件测试-OS test
2013-7-14
24
测试环境－硬件模拟测试环境
使用与产品的嵌入式系统硬件指令兼容 的CPU,设计研制与之严格时序及逻辑等价的测 试平台，以硬件或软件手段实现测试信息的设 定和记录等功能。
优点：接近真实的运行环境，可记录部 分中间结果. 缺点：难于统计覆盖率，响应时间测试 不够准确，记录数据受硬件条件的限制。
测试案例－测试计划
软件配置项划分 测试定义 测试/管理工具的确定 测试环境定义 3
测试案例－测试设计
单元测试 集成测试 确认测试 系统测试
测试说明文档 测试基准 部分或整体 关键模块的选择 分步骤集成 结构测试和功能测试
系统集成和验收测试虽然不属于软件 工程过程的研究范围，也不是由软件开 发人员来进行的，但却是嵌入式系统测 试不可回避的。在软件设计和测试阶段 采用的步骤能够大大增加软件成功地在 复杂系统中进行集成的可能性，但却不 能解决系统集成的所有问题。
2013-7-14
17
嵌入式软件测试工具
静态测试工具 动态测试工具
模块集成 软件与硬件集成 软件配置项确认测试 软件集成测试
软件配置项集成 软件系统确认测试 软件系统测试
系统测试
真实系统测试 软件系统与硬件集成 系统验收测试
2013-7-14
11
测试设计－确认测试
检验所开发的软件能否满足功能和性能需求。
与通用软件的确认测试不完全一致 软件配置项级确认测试 系统级确认测试－验收测试 广度上有所要求（重视强度测试、安全性测试、可恢复 性测试… ）
6
测试设计－单元测试
旨在发现程序模块的编码和逻辑错误。
《嵌入式软件测试》课件
测试重点包括对与硬件的兼容性、与第三方设3 医用呼吸机
测试重点包括对可靠性、安全性、响应速度等多个方面进行测试。
最佳实践
建立清晰的测试计划
在测试开始之前，需要制定测 试计划，明确测试目标、测试 范围和测试方法。
使用多种测试方法
通过使用多种测试方法，包括 自动化测试、手动测试和测试 工具，可以全面评估软件的质 量。
挑战
复杂性
嵌入式软件具有高度复杂性，需要在其生命周期 的多个阶段进行测试。
测试需求
嵌入式软件测试涉及到底层硬件和操作系统，测 试人员需要具备专业的技能和知识。
可靠性
嵌入式系统对稳定性有高要求，任何故障都会导 致损失。
测试环境
嵌入式系统需要在真实的硬件和软件环境中测试， 测试环境的构建成本很高。
方法和技术
嵌入式软件测试
嵌入式软件测试是指在嵌入式软件开发周期中对软件进行的各种测试，旨在 确保软件质量与可靠性。
定义
嵌入式软件是指内置在嵌入式系统中的应用软件，通常与硬件设备紧密耦合。 嵌入式软件测试是指评估嵌入式系统软件的正确性、完整性、安全性和可靠性的一系列活动。
重要性
嵌入式软件通常用于控制机器的行为，如决定加速或减速，控制温度等。 嵌入式系统一旦部署，通常难以更改或修复，因此嵌入式软件测试至关重要。
自动化测试
自动化测试可以提高测试速度和 准确性，降低测试成本。
代码评审
通过代码审查，可以找出潜在的 问题和缺陷，并及时修补。
测试驱动开发
测试驱动开发强调测试的优先级， 先编写测试，再进行代码开发。
实例分析：嵌入式软件测试案例研究
1 电子血压仪
测试目的包括对准确性、稳定性、易用性和耐用性进行测试。
测试重点包括对可靠性、安全性、响应速度等多个方面进行测试。
最佳实践
建立清晰的测试计划
在测试开始之前，需要制定测 试计划，明确测试目标、测试 范围和测试方法。
使用多种测试方法
通过使用多种测试方法，包括 自动化测试、手动测试和测试 工具，可以全面评估软件的质 量。
挑战
复杂性
嵌入式软件具有高度复杂性，需要在其生命周期 的多个阶段进行测试。
测试需求
嵌入式软件测试涉及到底层硬件和操作系统，测 试人员需要具备专业的技能和知识。
可靠性
嵌入式系统对稳定性有高要求，任何故障都会导 致损失。
测试环境
嵌入式系统需要在真实的硬件和软件环境中测试， 测试环境的构建成本很高。
方法和技术
嵌入式软件测试
嵌入式软件测试是指在嵌入式软件开发周期中对软件进行的各种测试，旨在 确保软件质量与可靠性。
定义
嵌入式软件是指内置在嵌入式系统中的应用软件，通常与硬件设备紧密耦合。 嵌入式软件测试是指评估嵌入式系统软件的正确性、完整性、安全性和可靠性的一系列活动。
重要性
嵌入式软件通常用于控制机器的行为，如决定加速或减速，控制温度等。 嵌入式系统一旦部署，通常难以更改或修复，因此嵌入式软件测试至关重要。
自动化测试
自动化测试可以提高测试速度和 准确性，降低测试成本。
代码评审
通过代码审查，可以找出潜在的 问题和缺陷，并及时修补。
测试驱动开发
测试驱动开发强调测试的优先级， 先编写测试，再进行代码开发。
实例分析：嵌入式软件测试案例研究
1 电子血压仪
测试目的包括对准确性、稳定性、易用性和耐用性进行测试。
嵌入式系统实验ppt课件
初始化信号量 int sem_init(sem_t *sem, int pshared, unsigned int value);
销毁信号量 int sem_destroy(sem_t *sem);
11
使用(申请)信号量 int sem_wait(sem_t *sem); 发送(释放)信号量 int sem_post(sem_t *sem);
struct prodcons buffer;
16
实验源代码main()
int main(void) {
pthread_t th_a, th_b; void * retval; init(&buffer); pthread_create(&th_a, NULL, producer, 0); pthread_create(&th_b, NULL, consumer, 0);
④线程中止
void pthread_exit(void *retval);
6
(2)线程间的同步机制
线程在运行过程中需要和其他线程进行交互，在资源不能满足 时，需要暂时挂起以等待其他线程正在使用的资源。这种机制称 为线程之间同步。线程同步的方法主要有互斥锁、条件变量和信 号量。
①互斥锁
线程在运行过程中需要使用共享资源时，要保证该线程独占该资 源，之中机制称为互斥。
实验4 多线程应用程序设计
1
4.1 实验目的
• 熟悉Linux系统下多线程程序设计的基本原理和应 用程序接口API
• 分析求解生产者—消费者问题的实例程序 pthread.c的源代码
• 理解多线程间的资源竞争、共享和同步 • 学习pthread库函数的使用
2
4.2 实验设备
销毁信号量 int sem_destroy(sem_t *sem);
11
使用(申请)信号量 int sem_wait(sem_t *sem); 发送(释放)信号量 int sem_post(sem_t *sem);
struct prodcons buffer;
16
实验源代码main()
int main(void) {
pthread_t th_a, th_b; void * retval; init(&buffer); pthread_create(&th_a, NULL, producer, 0); pthread_create(&th_b, NULL, consumer, 0);
④线程中止
void pthread_exit(void *retval);
6
(2)线程间的同步机制
线程在运行过程中需要和其他线程进行交互，在资源不能满足 时，需要暂时挂起以等待其他线程正在使用的资源。这种机制称 为线程之间同步。线程同步的方法主要有互斥锁、条件变量和信 号量。
①互斥锁
线程在运行过程中需要使用共享资源时，要保证该线程独占该资 源，之中机制称为互斥。
实验4 多线程应用程序设计
1
4.1 实验目的
• 熟悉Linux系统下多线程程序设计的基本原理和应 用程序接口API
• 分析求解生产者—消费者问题的实例程序 pthread.c的源代码
• 理解多线程间的资源竞争、共享和同步 • 学习pthread库函数的使用
2
4.2 实验设备
最新2019-嵌入式软件测试-PPT课件
嵌入式软件工程
火龙果 整理
软件是可以用来设计、制造、运行并且能有效维护的高质 量、高可靠性的技术解决方案的一系列的计算机程序和相 关的组件
工程是指一系列应用特定的技术、遵循适当的方法定义良 好、精确，经过实验检验的过程序列，是科学计数原理在 相关时间中的应用和指导
软件工程是将系统化的、规范的、可量化的方法应用于软 件的开发、运行和维护，即将工程化方法应用于软件工程 及其方法的实践。
出版社
参考网站
火龙果 整理
51testing；软件测试网 softtest/；软件测试在线 iceshi/html/index.html；中国软件测试联盟 /；中国软件评测中心
考核方法
考勤 随堂测试 整体课程设计
火龙果 整理
火龙果 整理
嵌入式系统开发设计的几个阶段
可行性分析和需求分析阶段 设计阶段 实现阶段 测试阶段 维护阶段
火龙果 整理
可行性分析和需求分析阶段
可行性分析：
技术可行性：给定的时间能否实现、软件的质量如何、 生产率如何
经济可行性：研发和生产的成本 操作可行性：社会环境和人的因素等
例如做一个程序, 想在一种机型上运行, 是否和那个系统 兼容, 需要测试.
例如有个程序有网络版本程序和单机版本程序两套, 需 要测试, 你要注意哪些?
例如有个程序, 已经有了老版本, 刚开发的新版本要测试, 你需要注意哪些?
火龙果 整理
如何成为一个优秀测试人员？
优秀的素质是干任何事情的成功保障,作为软件测试人员,
详细设计 编写程序
已通过评 审
进行调试
需编码的 软件单元 已建立了
进行静态分 析和单元测 试
相应模块 编写软件使 的文档 用说明
嵌入式软件测试(一)
这是嵌入式软件的基本要求，而且软件
要求固态存储，以提高速度。软件代码 要求高质量和高可靠性、实时性。
（5）嵌入式软件开发走向标准化
嵌入式系统的应用程序可以没有操作系统直接在芯
片上运行。
为了合理地调度多任务、利用系统资源、系统函数
以及和专家库函数接口，用户必须自行选配RTOS （Real－Time Operating System）开发平台，这样 才能保证程序执行的实时性、可靠性，并减少开发 时间，保障软件质量。
嵌入式软件测试
王海鹏
第一部分 嵌入式系统基本概念
嵌入式系统IEEE定义
根据IEEE（国际电气和电子工程师协会）的定义：
嵌入式系统是“用于控制、监视或者辅助操作 机器和设备的装置”（原文为devices used to control, monitor, or assist the operation of equipment, machinery or plants）。
多任务运行的实现实际上是靠CPU（中央处理单元）在 许多任务之间转换、调度。 CPU只有一个，轮番服务于一系列任务中的某一个。 多任务运行使CPU的利用率得到最大的发挥，并使应 用程序模块化。 在实际应用中，多任务的最大特点是，开发人员可以 将很复杂的应用程序层次化。
3.4系统内核（Kernel)与调度（Scheduler)
非占先式(Non-Preemptive)
低优先级任务
（1）
（2）
ISR
（4） （5）
（3）
TIME 中断服务程序使 高优先级任务就绪
（6）
高优先级任务 （7）
低优先级任务释放 CPU使用权
占先式（preemptive）
当系统响应时间很重要时，要使用占先式 （preemptive）内核。最高优先级的任务一旦就绪， 总能得到CPU的控制权。 当一个运行着的任务使一个比它优先级高的任务进入 了就绪态，当前任务的CPU使用权就被剥夺了，或者 说被挂起了，那个高优先级的任务立刻得到了CPU的 控制权。 使用占先式内核时，应用程序不应直接使用不可重入 型函数。如果调入可重入型函数时，低优先级的任 务CPU的使用权被高优先级任务剥夺，不可重入型函 数中的数据有可能被破坏。
要求固态存储，以提高速度。软件代码 要求高质量和高可靠性、实时性。
（5）嵌入式软件开发走向标准化
嵌入式系统的应用程序可以没有操作系统直接在芯
片上运行。
为了合理地调度多任务、利用系统资源、系统函数
以及和专家库函数接口，用户必须自行选配RTOS （Real－Time Operating System）开发平台，这样 才能保证程序执行的实时性、可靠性，并减少开发 时间，保障软件质量。
嵌入式软件测试
王海鹏
第一部分 嵌入式系统基本概念
嵌入式系统IEEE定义
根据IEEE（国际电气和电子工程师协会）的定义：
嵌入式系统是“用于控制、监视或者辅助操作 机器和设备的装置”（原文为devices used to control, monitor, or assist the operation of equipment, machinery or plants）。
多任务运行的实现实际上是靠CPU（中央处理单元）在 许多任务之间转换、调度。 CPU只有一个，轮番服务于一系列任务中的某一个。 多任务运行使CPU的利用率得到最大的发挥，并使应 用程序模块化。 在实际应用中，多任务的最大特点是，开发人员可以 将很复杂的应用程序层次化。
3.4系统内核（Kernel)与调度（Scheduler)
非占先式(Non-Preemptive)
低优先级任务
（1）
（2）
ISR
（4） （5）
（3）
TIME 中断服务程序使 高优先级任务就绪
（6）
高优先级任务 （7）
低优先级任务释放 CPU使用权
占先式（preemptive）
当系统响应时间很重要时，要使用占先式 （preemptive）内核。最高优先级的任务一旦就绪， 总能得到CPU的控制权。 当一个运行着的任务使一个比它优先级高的任务进入 了就绪态，当前任务的CPU使用权就被剥夺了，或者 说被挂起了，那个高优先级的任务立刻得到了CPU的 控制权。 使用占先式内核时，应用程序不应直接使用不可重入 型函数。如果调入可重入型函数时，低优先级的任 务CPU的使用权被高优先级任务剥夺，不可重入型函 数中的数据有可能被破坏。
课件04-嵌入式软件测试
基本过程—图示
测试管理过程
测试计划 控制指令 测试测量
基本测试过程
静态测试过程 动态测试过程
基本过程—静态测试过程
测试管理过程
测试计划 控制指令 测试测量
基本测试过程
静态测试过程 准备 评审 跟踪
基本过程—静态测试准备
组长会前职责 完成SQE培训 确定本次评审是否已满足进入准则 确定评审组成员 预览材料以确保其符合标准 确保小组规模与组成的正确性 确保至少有5个工作日的准备时间 确保正确的材料已经分发
基本过程—评审
组长会中职责 确保足够的出席人数 确保准备充分 主持审查会议 记录所有缺陷及问题 对重大缺陷及超过 5%缺陷率的代码 二次评审
基本过程—评审
被评者会中职责 解释被评审的材料 以一种清晰并可理解的方式来展示 材料 标注所有难以理解的内容 对规格说明进行回溯 履行正常的评审责任
管理过程—度量及采集
根据测试总结和管理的需要确定
举例
测试需求度量
用例度量
风险度量 缺陷度量 时间度量
管理过程—计划文档
Test Plan
管理过程—测试跟踪与控制
管理过程—跟踪与控制活动
跟踪与控制形式
定期例会、测量等
跟踪与控制依据
项目计划
跟踪与控制对象 工作量和成本、进度、资源要求等
基本过程—设计与实现文档
Test Design Specification
Test Case Specification
Test Procedure Specification
Test Data Requirements
Test Environment Requirements
课件03-嵌入式软件测试
测试用例—测试用例集
测试用例—质量
具有合理的捕获缺陷的概率 执行了重要的区域 做了应引起注意的事情
不做多余的事情
既不太简单也不太复杂
不与其它测试用例冗余
使得缺陷显而易见 考虑缺陷的隔离和识别
测试用例—属性
1 用例编号 2 用例名称 3 被测对象名称 4 测试目标 5 用例类别 10 输入 11 预期结果 12 用例状态 13 用例设计方法 14 用例设计人
敏感度分析—实施举例
将输入范围平均划分为一系列大小相等 的子范围，如100等份 为每个子范围创建一个测试用例 பைடு நூலகம்执行测试用例，观察实际输出和参考函 数值之间的差异，如差值的大小、波动 的速率等 如果在某个子范围内差异急剧变化，则 细分该子范围，继续测试，直到找出缺 陷，或结束测试
边界值分析
因果图法—实例
1 E 2
∨
∽
21
20
11
∧
3
∽
22
因果图法—实例
1 2 3 11 21 20 22 1 1 1 1 2 1 1 0 3 1 0 1 1 0 1 0 4 1 0 0 1 0 0 1 5 0 1 1 1 0 1 0 6 0 1 0 1 0 0 1 7 0 0 1 0 1 0 0 8 0 0 0 0 1 0 1
基本思想 只考虑有效等价类 假设
单一因素产生缺陷
等价类划分—图示
x2 g f e a b c
d
x1
等价类划分—设计准则2
基本思想 只考虑有效等价类 假设
多因素交互可能产生缺陷
等价类划分—图示
x2 g f e
a
b
c
d
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
工具
Seeyou
级别—集成测试内容
单元间的接口测试 全局数据结构测试 软件功能模块的功能测试 性能测试 边界和人为条件下的性能
1. 2. 3. 4. 5.
Seeyou
级别—集成测试焦点
重点寻找与下述内容相关的缺陷 软件系统结构的设计和构造 在子系统层次上被集成的功能或操作
组件/模块之间的接口和相互作用
Seeyou
问题及对策—测试管理
典型问题
被测对象来自非受控渠道 测试没有文档化的计划、方案支持 独立测试组与开发组之间关系不协调
主要对策 建立测试过程，进行测试项目策划、跟 踪与控制，开展测试的质量保证和配置 管理 将需求工程延伸到测试
Seeyou
问题及对策—测试风险
级别—集成测试
集成测试的对象是软件部件 软件部件由软件单元组成 集成测试前，部件中的所有单元必须已经
完成了单元测试
Seeyou
级别—集成测试准备
要求的文档可提交 软件概要设计说明 软件接口设计说明 被集成的软件单元已通过单元测试 被测试构件已纳入配置管理中 具备了满足要求的集成测试环境和测试
R
D C U I V ST 单元测试 集成测试 配置项测试 系统测试
Seeyou
级别—为什么要分级别？
与软件开发过程相适应 为了说明软件系统内单元 / 部件的互操作性
需要进行三种基本的测试
单独单元/部件的测试
测试单元/部件间互操作 测试单元/部件结合成的软件系统
Seeyou
级别—单元测试的特点
嵌入式软件测试
第一部分
SEEYoU
软件测试技术
Seeyou
软件测试技术—提要
软件测试基础 软件测试的典型问题及对策 嵌入式软件测试级别及内容 软件测试过程及管理
Seeyou
概述—测试的定义
由人工或自动方法来执行或评价系统或系
统部件的过程，以验证它是否满足规定的 需求；或识别出期望的结果和实际结果之 间有无差别。
概述—测试与调试
测试不是调试，调试也不是测试，实际工 作中人们常将测试与调试混为一谈 主要区别： 测试是一种检验，调试是推理过程 测试从已知条件开始，使用预先定义的 规程并且有可预知的结果；调试的开始 条件可能是不可知的，结果不可预见 测试经常由非程序设计人员完成，调试 必须由程序设计者完成
Seeyou
概述—测试的目的
验证软件是否满足软件开发合同或任务书、
系统/子系统设计文档、软件需求规格说明 和软件设计说明所规定的软件质量特性要 求； 通过测试，发现软件错误； 为软件产品质量的评价提供依据。
Seeyou
概述—测试的地位
有效的测试对于开发可靠、安全和成功的 软件是必须的 测试不是“银弹(silver bullet)”，它具有有 效范围，它不是其他软件工程方法的替代 品
对象－模块 依据－软件设计规格说明 实现－串行或并行测试
方法－白盒为主
被测模块
结果
测试用例
测试工程师
Seeyou
级别—单元测试内容
静态测试 代码走查 代码检查
静态分析
动态测试 黑盒测试 白盒测试 基于数据结构的测试
Seeyou
级别—单元动态测试焦点
被测单元 单元接口 局部数据结构 边界条件 独立执行路径 错误处理的路径
Seeyou
问题及对策—测试终止准则
典型问题 测试组应对保证质量负责 用发现缺陷数量评价测试业绩 测试到资源耗尽就结束 主要对策 明确定义测试结束的标准 正确理解测试的作用和局限性 提高和改善软件设计质量
Seeyou
级别—测试策略
系统工程 S
软件需求分析
设计 编码
主要对策
培训，指派有经验、富有创造性的人员承担
测试 采用适当的技术、有效的方法进行测试设计 完善动态仿真环境，掌握测试工具
Seeyou
问题及对策—测试追溯性
典型问题 软件需求规格说明太简单、过时 即兴测试 不创建和维护测试文档 主要对策 测试应源于用户需求 维持完整的证据链 进行可重复和可再现的测试
无法确信测试系统(或环境)的正确性
无法确信测试人员完全理解了软件产品
没有足够的资源彻底完成软件测试
Seeyou
概述—测试的发展历程
状况
时间区间
-1956
1957 - 1978
面向调试的阶段
面向证实的阶段
1979 - 1982 1983 - 1987 1988 -
面向缺陷的阶段 面向评价的阶段 面向预防的阶段
质量属性(关注质量设计的实现)
设计约束(关注资源的利用率和余量)
Seeyou
级别—配置项测试主要内容
文档审查 用户操作 特定条件下的行为 与 硬 件 配 置 项 的 集 成 与 系 统 中 其 它 软 件 配置项的集成与协作
功能测试 性能测试 接口测试 容错测试 安全性测试 边界测试 安装性测试
容错(Defect tolerance)
有缺陷，也能正确的完成任务
恢复 选用最佳恢复策略，失效后继续工作
Seeyou
概述—如何获得高质量软件
正式 技术评审
软件工程 方法
度量与控制
软件质量
标准与过程 SCM 与 SQA 测试
Seeyou
概述—验证与确认
验证与确认是广泛认可的质量保证方法和手段 软件测试是软件验证与确认的重要组成部分 验证是指对某项规定活动进行检查的过程，以确
典型问题 不使用风险分析技术，测试不关注风 险 开发时希望成关键，测试时希望成一 般 主要对策 通过风险分析确定测试范围、目标和 策略 将测试作为一种高风险活动进行管理
Seeyou
问题及对策—测试复杂性
典型问题
认为测试工作很简单，测试成为新程序员的
过渡性工作/不合格程序员的归宿 认为软件测试太复杂，投入很大，做了但是 没有效果 进行无知的测试
测试用例
Seeyou
级别—单元动态测试环境
驱动模块
模块接口 局部数据结构 边界条件 独立执行路径 错误处理的路径
被测模块
桩1
桩2
桩n
结果
测试用例
Seeyou
级别—单元测试工作产品
单元测试计划
单元测试说明
单元测试报告 测试记录 问题报告与问题处理报告 质量记录
Seeyou
Seeyou
级别—配置项测试依据
测试要求
任务书、合同、测试规范等对软件测试
有约束力的文件，规定了软件测试的类 型、程度、管理，等等 被测对象的规格说明
软件需求规格说明书，等
Seeyou
级别—配置项测试焦点
功能(针对业务/任务需求，逐项) 接口(关注通信需求与手段)
配置项级的性能(关注容量、余量、瓶颈)
质量记录
Seeyou
级别—配置项测试概念
配置项测试的对象是计算机软件配置项
（CSCI）
计算机软件配置项，是能够被独立地进行
配置管理的，并能够满足最终用户功能的一 组软件
Seeyou
级别—配置项测试的目的
1. 发现软件配置项内存在的缺陷和问题 2. 验证软件配置项实现了所需的能力 验证软件是否按软件需求规格说明书中 确定的软件功能、性能、质量属性、约 束及限制等技术要求进行工作 检验软件配置项与相关的软件 / 硬件配 置项接口的正确性和互操作性
Seeyou
概述—嵌入式软件
执行数据采集、控制等任务，逻辑复杂 运行在资源受限系统上 系统构成多样化 部署后不受人的控制 修补困难 多为实时系统 多为关键系统 既可能运行在芯片上，也可能运行与大型工 业控制系统
Seeyou
概述—嵌入式软件测试
对测试环境的要求高 对专业测试的依赖程度高 测试输入和结果获得需要专门的手段 测试约束大
保该活动实现了规定功能 确认是指审查已建立的软件产品是否符合客户需 要的过程
验证(Verification): Are we building the product right? 确认(Validation): Are we building the right product?
Seeyou
在软件开 发过程中
失误 (mistake)
软件开发 人员产生
隐错／缺陷 (bug/defect)
软件中存在
故障 (fault)
缺陷被激活
失效 (failure)
用户的经历
设计者的错误行为(失误)→导致软件中留有错误的设计 (缺陷) → 导致软件错误地执行(故障) → 导致软件的 错误行为(失效)。
Seeyou
Seeyou
级别—配置项测试环境要求
更关注环境的可控性，通常会在仿真
配置项测试对测试环境的关注
或模拟环境下进行，要求高度的可控 性和尽量的真实性 对侵入式测试方法的支持
Seeyou
级别—配置项测试工作产品
配置项测试计划 配置项测试说明 配置项测试报告
测试记录
概述—缺陷过滤器
排错(defect removal)
(Defect tolerance)
容错
失误Biblioteka 使用缺(Defect avoidance)
陷
编译
逃
测试
逸
避错
审查
Seeyou
概述—缺陷解决策略
避错(Defect avoidance) 第一次就做正确 排错(Defect removal)
早发现,早实施
的固有属性和特征