课件02-嵌入式软件测试

1、嵌入式软件测试第二部分测试测试类型类型测试类型提要 代码类测试类型 规格说明类测试类型 质量特性类测试类型代码类测试类型 代码审查(Code inspections) 代码走查(Code walkthroughs) 静态分析 逻辑覆盖测试(Logic-Coverage Testing) 数据流测试 变元测试(mutation test)代码审查内容与方法 主要测试内容v检查代码和设计的一致性检查代码和设计的一致性v检查代码执行标准的情况检查代码执行标准的情况v检查代码逻辑表达的正确性检查代码逻辑表达的正确性v检查代码结构的合理性检查代码结构的合理性v检查代码的可读性检查代码的可读性 方法v审查

2、会审查会v依据代码审查单逐项审查依据代码审查单逐项审查代码审查过程1. 计划2. 介绍3. 准备4. 审查会5. 返工6. 后续跟踪代码审查审查会评审组长产品开发人员记录人员评审人员SQA人员系统维护人员用户代表代码审查准入条件 一组技术上有能力且经过培训的审查人员 一个受过培训的审查组长 正确的计划和材料的分发 良好的专业态度 在审查会召开之前的全面准备 已完成的设计文档和源代码 已确认的检查单或编码标准代码审查需要解决的实际问题 审查工作流于形式，缺乏操作性 参与审查工作的人员缺乏相应的培训，审查过程中得不到适当的指导、监督 对审查工作的重要性和严肃性认识不足，没有合理的计划，审查前准备不

3、充分，审查工作变成一种临时性的即兴活动 审查人员的审查技能或专业知识不足代码审查需要解决的实际问题 审查会偏离主题，演变成解决方案研讨或技术攻关会，审查效率低下 没有对审查中发现的问题进行跟踪，使审查工作功亏一篑，前功尽弃 没有建立测量数据收集机制，不分析审查工作的有效性，管理人员和技术人员体会不到审查带来的效益和效果，不利于全员参与代码审查工作指南1. 审查作为项目计划的一部分考虑，分配资源和时间2. 为每个要审查的工作产品建立一个检查表3. 限制参与人数， 35名成员最佳4. 制定议程，并且遵守议程5. 审查会的时间不要超过两个小时6. 以建设性的方式讨论问题，不要针对被审查产品的设计者代

4、码类代码审查工作指南7.将注意力集中在验证和确认参与者提出的意见，避免探讨解决方案8.限制争论和辩驳，对提出的问题有不同意见时，通过记下问题并另行专题讨论来结束争论9.将讨论的意见及其验证和确认的结果形成文档10.建立跟踪机制，确保返工活动具有满意的性能代码走查内容与方法 主要测试内容v代码执行逻辑的正确性代码执行逻辑的正确性v代码数据操作的正确性代码数据操作的正确性v代码的健壮性代码的健壮性 方法v人工执行测试用例人工执行测试用例v采用会议形式，关键在于用例执行过采用会议形式，关键在于用例执行过程中的讨论程中的讨论静态分析内容与方法 主要测试内容v控制流分析控制流分析v数据流分析数据流分析v

5、接口分析接口分析v表达式分析表达式分析v质量度量质量度量v最差情况分析最差情况分析 方法v自动测试工具辅助自动测试工具辅助静态分析复杂性度量使用使用McCabe复杂度度量作为指标复杂度度量作为指标对循环嵌套进行计算对循环嵌套进行计算对控制流图进行直观检查对控制流图进行直观检查对数据流图进行直观检查对数据流图进行直观检查静态分析关注点未定义但被引用的变量未定义但被引用的变量v必须从代码中消除必须从代码中消除全局变量异常全局变量异常(局部覆盖全局局部覆盖全局)v必须从代码中消除必须从代码中消除消除不使用的内容消除不使用的内容v不可达的代码不可达的代码 (包括过程包括过程)v声明但未使用的变量声明但

6、未使用的变量定义的变量但未在作用域中使用定义的变量但未在作用域中使用v应在代码中文档化说明应在代码中文档化说明静态分析关注点变量定义后未使用又被重新定义变量定义后未使用又被重新定义v应在代码中文档化说明应在代码中文档化说明可疑的抛投可疑的抛投(信息丢失信息丢失, 不匹配不匹配)v如果不可避免如果不可避免, 使用显示抛投使用显示抛投v应在代码中文档化说明应在代码中文档化说明设计架构问题设计架构问题v对控制流图进行直观检查对控制流图进行直观检查v过程参数异常过程参数异常(仅引用仅引用, 仅定义仅定义, 未使用未使用)静态分析关注点被零除范围检查错栈溢出错堆溢出错无效指针操作浮点上溢出浮点下溢出无效

7、浮点运算对象未初始化逻辑覆盖测试覆盖要求 语句覆盖 分支覆盖 条件覆盖 条件分支覆盖 修正条件分支覆盖(MC/DC) 条件组合覆盖 基本路径覆盖逻辑覆盖测试控制流图 一个段是一个或多个无条件连续执行的语句 一个段在控制流图中用一个结点表示，结点可以用任何方便的形式命名 一个控制条件转移是一个分支，一个分支段在控制流图中用一个输出边表示 一个程序的入口点用入口结点表示，它是一个没有输入边的结点，一个程序的出口点用出口结点表示，它是一个没有输出边的结点逻辑覆盖测试程序实例1. void DoWork(int x,int y,int z)2. 3. int k=0,j=0;4. if(x3)&

8、;(z5)10. 11. j=x*y+10; 12. 13. j=j%3; 14. 逻辑覆盖测试控制流图例A: 1,2,3B: 4C: 5, 6, 7, 8D: 9E: 10, 11, 12F: 13, 14ABDFEC逻辑覆盖测试复杂度度量 圈复杂度V(G) 计算1vV(G) = e n + 2ve表示控制流图中边的数量，表示控制流图中边的数量，n表示控表示控制流图中节点的数量制流图中节点的数量 计算2vV(G)=区域数区域数 计算3vV(G)=判定节点数判定节点数+1逻辑覆盖测试语句覆盖 程序中每条语句至少被执行一次 C1覆盖、行覆盖、段覆盖、基本块覆盖 语句覆盖的盲点(循环; 条件) 语

9、句覆盖是最起码的测试要求逻辑覆盖测试语句覆盖 用例 v x=4、y=5、z=5 执行路径vABCDEFABDFEC判定判定1：(x3)&(z5)逻辑覆盖测试分支覆盖 程序中的每一个分支至少通过一次 C2覆盖、决策覆盖、判定覆盖 分支覆盖的盲点v短路估值使分支覆盖不必考虑所有短路估值使分支覆盖不必考虑所有条件条件v分支覆盖不能保证所有入口出口分支覆盖不能保证所有入口出口路径都被执行路径都被执行逻辑覆盖测试分支覆盖 用例v x=4、y=6、z=5v x=2、y=5、z=5 执行路径vABCDEFvABDFABDFEC12判定判定1：(x3)&(z5)逻辑覆盖测试条件覆盖 判定中的每

10、个条件获得各种可能的结果 不要求测试所有可能的分支逻辑覆盖测试条件覆盖 用例v x=4、y=6、z=15v x=2、y=5、z=5 执行路径vABDEFvABDF12ABDFEC判定判定1：(x3)&(z5)逻辑覆盖测试条件分支覆盖 判定中每个条件的所有可能取值至少执行一次 同时每个判定的所有可能判定结果至少执行一次逻辑覆盖测试条件分支覆盖 用例v x=4、y=6、z=5v x=2、y=5、z=15 执行路径vABCDEFvABDF判定判定1：(x3)&(z5)12ABDFEC逻辑覆盖测试MC/DC 修正条件分支覆盖(MC/DC) 程序里的每一个判定都至少取所有可能的输出一次

11、程序中判定的每一个条件都取所有可能的输出至少一次 判定中的每一个条件都被证明可以独立影响判定的输出逻辑覆盖测试MC/DC用例编号用例编号条件条件(与与)判定判定1x3z521TFT22FTT23FFF逻辑覆盖测试MC/DC 用例v x=4、y=5、z=511, 21v x=2、y=5、z=913, 23v x=6、y=6、z=1512, 22 执行路径vABCDEFvABDFvABDEF12ABDFEC3逻辑覆盖测试条件组合覆盖 每个判定中条件的各种组合至少出现一次 达到了条件组合覆盖，所有的语句、分支和条件都将覆盖，但不保证路径覆盖 在实际测试中，由于谓词表达式的短路估值和排它性条件使得达到

12、所有条件组合不可能逻辑覆盖测试条件组合覆盖 用例v x=4、y=6、z=5v x=4、y=5、z=15v x=2、y=6、z=5v x=2、y=5、z=15 执行路径vABCDEFvABDEFvABDEFvABDFABDFEC1423判定判定1：(x3)&(z5)逻辑覆盖测试基本路径覆盖 基本路径数 = 圈复杂度(C) 基本路径覆盖要求测试C条不同的入口出口路径 在某些程序中，分支覆盖可在少于C条路径的情况下获得 基本路径覆盖可能既没有获得语句覆盖也没有获得分支覆盖逻辑覆盖测试基本路径覆盖 圈复杂度vC=7-6+2=3 用例v x=4、y=6、z=5v x=4、y=5、z=15v x=

13、2、y=5、z=15 执行路径vABCDEFvABDEFvABDFABDFEC132逻辑覆盖测试覆盖分析器 覆盖分析器是分析测试覆盖率的工具 覆盖分析器工作原理1)通过对源代码的词法分析，插入可通过对源代码的词法分析，插入可跟踪代码，再编译连接；跟踪代码，再编译连接；2)当装配过可跟踪代码的软件执行时，当装配过可跟踪代码的软件执行时，就会产生一个跟踪文件；就会产生一个跟踪文件；3)测试完成后，利用跟踪文件生成覆测试完成后，利用跟踪文件生成覆盖报告。盖报告。逻辑覆盖测试覆盖率的作用 发现v不可执行的路径或条件不可执行的路径或条件v不可能到达或冗余的代码不可能到达或冗余的代码v不充分的测试用例集不

14、充分的测试用例集逻辑覆盖测试覆盖与缺陷查找 覆盖与发现缺陷之间没有必然联系 达到85% 容易, 达到100% 困难v不可到达的代码不可到达的代码(控制流无法到达控制流无法到达)v复杂序列复杂序列(很难使控制流到达很难使控制流到达)数据流覆盖测试 通过一定的覆盖准则检查程序中每个数据对象的每次定义、使用和消除 数据流模型(DUK) 数据流覆盖策略变元测试 测试覆盖被测实现的指定的变体，如测试探测到变元，则变体“退役”，如测试探测不到变元，则修正测试包 变元是指为程序植入小的变化，一般是常出现的错误，如将=改写成 用于检查系统的容错能力和测试套件的充分性规格说明类测试 功能测试 性能测试 接口测试

15、 人机交互界面测试功能测试 详尽测试每一个软件功能v功能功能产品能够完成的任务，如：产品能够完成的任务，如：特征特征/命令命令/任务标识等任务标识等 组合功能的测试v测试基本流测试基本流(最简单执行路径最简单执行路径)v测试备选流测试备选流(特定条件下的执行路径特定条件下的执行路径)功能测试要求 检验功能的完备性 检验功能的正确性v需要满足精度等要求需要满足精度等要求 测试功能的健壮性功能测试用例设计方法 单项功能v边界值分析边界值分析v等价类划分等价类划分v组合逻辑分析组合逻辑分析 组合功能v场景测试场景测试(Scenario testing)v状态转换状态转换性能测试 性能测试是对软件需求

16、规格说明或设计文档中的性能需求逐项进行的测试，以验证其性能是否满足规定的指标要求 性能测试有时可理解为有定量指标要求的一些功能，其基础是功能满足要求，所以通常在功能测试的基础上再做性能测试性能测试性能 系统或组件对于其及时性和资源利用性目标的符合程度 良好的性能需求定义v有前提条件有前提条件性能测试及时性 在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力 响应时间v系统对事件产生响应所需要的时间系统对事件产生响应所需要的时间 吞吐量v特定时间内能够处理的事件数量特定时间内能够处理的事件数量性能测试时间限制类型 实时嵌入式系统的时间限制类型v最大时间最大时间: 一个事

17、件和另一个事件发一个事件和另一个事件发生的时间间隔最大不超过生的时间间隔最大不超过t个单位时个单位时间间v最小时间最小时间: 两个事件之间发生的时间两个事件之间发生的时间间隔最小不小于间隔最小不小于t个单位时间个单位时间v持续时间持续时间: 一种状态必须存在一种状态必须存在t个单个单位时间位时间性能测试资源利用率 在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力 主要包括v内存使用内存使用vCPU负载负载v数据库连接数数据库连接数v接口饱和度接口饱和度v磁盘利用率磁盘利用率性能测试性能约束 需要弄清影响性能指标要求的全部潜在因素的约束条件 考虑v系统能力系统能力(硬件、支撑软

18、件硬件、支撑软件)v网络负载情况，典型网络负载情况，典型/峰值的并发峰值的并发v需访问的数据库，类型、数量、结需访问的数据库，类型、数量、结构、布局，数据库中的数据量构、布局，数据库中的数据量v网络的结构，带宽网络的结构，带宽性能测试合格判据 实时系统往往考虑最差情况v强实时系统的一次性能不满足要求强实时系统的一次性能不满足要求,往往就是功能失效往往就是功能失效 非实时系统通常考虑平均情况性能测试方法 从软件性能需求中获得性能测试需求v确定需测试的性能指标确定需测试的性能指标 确定关键用例、关键场景v最重要、最耗时、最频繁等最重要、最耗时、最频繁等 确定影响被测性能指标的负载规模 准备测试环境

19、 执行测试用例，记录测试结果 分析、计算 结果判定性能测试性能数据采集方法 系统监视器 程序监视器 系统事件记录器 外部程序事件记录器 内部事件记录器性能测试环境 时间测量v外部观察，适用于精度要求不高时，外部观察，适用于精度要求不高时，如使用秒表计时如使用秒表计时v插桩探测，使用数字示波器，或机插桩探测，使用数字示波器，或机器时钟，关键在于测量分辨率器时钟，关键在于测量分辨率 测量资源利用率v系统自带测量工具系统自带测量工具v专门设计的方法专门设计的方法性能测试执行 考虑尽可能多的情况，反复测试，如实记录每次测试结果 在测试记录中要记清相应的测试环境，尤其是关键影响因素，以便做出正确判断 在

20、得到一系列数据后再作判断v实时系统通常根据最差情况判断实时系统通常根据最差情况判断v非实时系统通常根据数据分布判断非实时系统通常根据数据分布判断性能测试最差运行时间(WCET) 获取最差运行时间(WCET)的常用手段 动态测量技术v软件动态运行获取软件动态运行获取v测试所有情况比较困难测试所有情况比较困难v需要专门的测量仪器和设备需要专门的测量仪器和设备 静态分析技术v分析目标代码分析目标代码v结果精确结果精确接口测试 从系统和子系统设计规格说明、软件接口需求规格说明中获得接口测试需求 测试所有外部接口，检查接口信息的格式及内容，考核异常情况的管理 测试所有内部接口的功能和性能接口测试主要接口

21、类型 参数接口数据通过参数从一个过程传递到另一个过数据通过参数从一个过程传递到另一个过程程 共享存储器接口在过程或函数之间共享存储器在过程或函数之间共享存储器 API接口一系列的过程被封装成子系统一系列的过程被封装成子系统,供另一个子供另一个子系统调用系统调用 消息接口一个子系统向其它子系统请求服务一个子系统向其它子系统请求服务接口测试主要接口错误类型 接口误用一个组件调用另一个组件时，在使用一个组件调用另一个组件时，在使用其接口时产生了错误其接口时产生了错误 接口误解在调用组件中嵌入了对被调用组件行在调用组件中嵌入了对被调用组件行为的不正确假设为的不正确假设 同步误差调用和被调用的组件以不同

22、的速度运调用和被调用的组件以不同的速度运行行，访问到过时的信息访问到过时的信息接口测试通信协议测试 嵌入式系统的通信协议种类很多标准协议标准协议私有协议私有协议 接口驱动程序采用非货架产品时，需要测试非应用层协议的实现正确性测试正确性测试健壮性测试健壮性测试 需要接口测试设备接口测试指南 设计超出被调用组件参数范围的测试 对于指针参数，一定要测试空指针 设计可导致组件失效的测试 在消息传递系统中，使用强度测试 在共享存储器系统中, 改变组件活动的次序人机交互界面测试 操作和显示界面及界面风格与需求规格说明中要求的一致性和符合性(正确性、有效性) 以非常规操作、误操作、快速操作来检验人机界面的可

23、靠性 对错误命令或非法数据输入的检测能力与提示情况(健壮性) 对错误操作流程的检测与提示 对照用户或操作手册逐条进行操作和观察质量特性类测试类型 容量测试 余量测试 强度测试 安全性测试 信息安全测试 可靠性测试容量测试 容量测试的目的是检验软件的能力最高能达到什么程度，确定系统的可伸缩性，从容量规划的角度确定软件的使用等级限制 可伸缩性是系统在对其功能要求增加的情况下，继续实现响应时间或吞吐量目标的能力 有时系统容量作为系统指标，有时系统的实际容量需要测试才能得到容量测试用例设计 确定进行容量测试的性能指标或指标的成分 确定影响指标行为的因素，给出这些影响因素在“正常”情况下的典型要求 确定

24、性能负载增加的增量值 确定到达不正常后，寻找临界值(容量点)的方法，如二分法容量测试执行 测试前做好分析，确定容量测试不会造成系统损伤 测试执行时，通过向系统逐步施加不断增大的性能负载，确定系统能否可靠地适应性能负载的增加 记录每次性能负载增加的测试结果 仔细观察系统的响应结果，与“正常情况”进行对比 根据测试结果，综合分析，确定系统能可靠处理的最大性能负载，评估系统的可伸缩性余量测试 余量测试是对软件是否达到需求规格说明中要求的余量的测试 余量测试时，需要获得测试量的最大值，剩下的是余量。用什么办法能说明获得的测试量是最大值是关键 例如v时间片规定是时间片规定是50ms，规定要求余量是，规定

25、要求余量是30，需要说明测试中考虑了消耗时，需要说明测试中考虑了消耗时间最长情况，其结果也在间最长情况，其结果也在35ms以内以内余量测试动因 嵌入式软件常常通过裕度设计提高系统的可靠性 在实际应用中，由于某些预料不到的情况的发生，系统会在某些时刻以某种方式膨胀，如：处理时间变长，数据从正常区域波动到非正常区域等，设计留有余量将可以容纳这些意外波动，维持系统正常运行 规格说明中无明确要求时，一般至少留有20%的余量余量测试目标 存储器使用 输入/输出通道使用 处理时间 吞吐量 注意：不是所有的性能要求都需要余量测试强度测试 强制软件运行在不正常到发生故障的情况下(设计的极限状态到超出极限)，检

26、验软件可以运行到何种程度v需要弄清被测对象什么叫不正常，需要弄清被测对象什么叫不正常，什么叫发生故障，它们表现形式是什么叫发生故障，它们表现形式是什么什么 通常基于单因素假设，选取不同因素反复测试和试验 发现软件的性能瓶颈，提供优化方案强度测试相关思考 找出临界点是关键v测试过程中负载逐步增加，反复测测试过程中负载逐步增加，反复测试找到一个最低的导致故障的点试找到一个最低的导致故障的点v也存在达不到故障点的情况也存在达不到故障点的情况 关于连续运行时间强度v需要连续不中断的运行，应该构造需要连续不中断的运行，应该构造一个较大的测试用例库作为支撑，一个较大的测试用例库作为支撑，测试用例库的测试用

27、例重复周期要测试用例库的测试用例重复周期要超过指定的时间长度超过指定的时间长度v最好能实现自动测试最好能实现自动测试强度测试与其它测试的关系正常运行正常运行不正常但可运行不正常但可运行性能测试性能测试故障故障容量测试容量测试强度测试强度测试正常运行正常运行设计规范设计规范余量测试余量测试工作极限工作极限破坏极限破坏极限正常工作区正常工作区设计裕度设计裕度过应力过应力安全性测试 对防止危险状态措施的有效性和每个危险状态下的反应的测试 对设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案的测试 对异常条件下系统/软件的处理和保护能力的测试，以表明不会导致不安全状态 对双工切换、多机替换的

28、正确性和连续性的测试安全性测试要点 应明确系统的安全状态以及对软件处理的要求 安全性测试重点关注安全相关的功能，因此需求的分类管理很重要 进行安全性测试时，应对测试的后果预先进行评估，防止测试导致损失，在真实环境下测试前应在仿真环境下预先验证 安全性测试应关注系统各级别上安全机制的协调性和合理性信息安全测试 对具有防止非法进入软件并保护软件的数据完整性能力的测试 对重要数据的抗非法访问能力的测试 防止数据完整性被破坏能力的测试 防止系统可用性遭受破坏能力的测试 逻辑炸弹等恶意逻辑和功能检测信息安全测试焦点 嵌入式系统关注的信息安全特征A(可用性可用性)-I(完整性完整性)-C(机密性机密性)，控制，控制的可用性和完整性最重要，数据平均信的可用性和完整性最重要，数据平均信息量较低，机密性要求不高息量较低，机密性要求不高许多控制系统提供许多控制系统提供0.999999的可用性，的可用性，安全不能降低可用性安全不能降低可用性!信息安全测试安全功能验证 身份识别与验证系统对用户身份进行鉴别系统对用户身份进行鉴别 权限管理通过鉴别的用户的特权和访问许可通过鉴别的用户的特权和访问许可 完整性避免数据讹误避免数据讹误 保密性维持数据保密性维持数据保密性 安全审计对系统的审计和检查对系统的审计和检查信息安全测试未知漏洞挖掘 Vulnerable Code The Buffer Overflow