课件02-嵌入式软件测试

嵌入式软件测试

第二部分测试类型测试类型—提要代码类测试类型规格说明类测试类型质量特性类测试类型代码类测试类型代码审查(Codeinspections)代码走查(Codewalkthroughs)静态分析逻辑覆盖测试(Logic-CoverageTesting)数据流测试变元测试(mutationtest)代码审查—内容与方法主要测试内容检查代码和设计的一致性检查代码执行标准的情况检查代码逻辑表达的正确性检查代码结构的合理性检查代码的可读性方法审查会依据代码审查单逐项审查代码审查—过程计划介绍准备审查会返工后续跟踪代码审查—审查会评审组长产品开发人员记录人员评审人员SQA人员系统维护人员用户代表代码审查—准入条件一组技术上有能力且经过培训的审查人员一个受过培训的审查组长正确的计划和材料的分发良好的专业态度在审查会召开之前的全面准备已完成的设计文档和源代码已确认的检查单或编码标准代码审查—需要解决的实际问题审查工作流于形式，缺乏操作性参与审查工作的人员缺乏相应的培训，审查过程中得不到适当的指导、监督对审查工作的重要性和严肃性认识不足，没有合理的计划，审查前准备不充分，审查工作变成一种临时性的即兴活动审查人员的审查技能或专业知识不足代码审查—需要解决的实际问题审查会偏离主题，演变成解决方案研讨或技术攻关会，审查效率低下没有对审查中发现的问题进行跟踪，使审查工作功亏一篑，前功尽弃没有建立测量数据收集机制，不分析审查工作的有效性，管理人员和技术人员体会不到审查带来的效益和效果，不利于全员参与代码审查—工作指南审查作为项目计划的一部分考虑，分配资源和时间为每个要审查的工作产品建立一个检查表限制参与人数，3–5名成员最佳制定议程，并且遵守议程审查会的时间不要超过两个小时以建设性的方式讨论问题，不要针对被审查产品的设计者代码类—代码审查工作指南将注意力集中在验证和确认参与者提出的意见，避免探讨解决方案限制争论和辩驳，对提出的问题有不同意见时，通过记下问题并另行专题讨论来结束争论将讨论的意见及其验证和确认的结果形成文档建立跟踪机制，确保返工活动具有满意的性能代码走查—内容与方法主要测试内容代码执行逻辑的正确性代码数据操作的正确性代码的健壮性方法人工执行测试用例采用会议形式，关键在于用例执行过程中的讨论静态分析—内容与方法主要测试内容控制流分析数据流分析接口分析表达式分析质量度量最差情况分析方法自动测试工具辅助静态分析—复杂性度量使用McCabe复杂度度量作为指标对循环嵌套进行计算对控制流图进行直观检查对数据流图进行直观检查静态分析—关注点未定义但被引用的变量必须从代码中消除全局变量异常(局部覆盖全局)必须从代码中消除消除不使用的内容不可达的代码(包括过程)声明但未使用的变量定义的变量但未在作用域中使用应在代码中文档化说明静态分析—关注点变量定义后未使用又被重新定义应在代码中文档化说明可疑的抛投(信息丢失,不匹配)如果不可避免,使用显示抛投应在代码中文档化说明设计架构问题对控制流图进行直观检查过程参数异常(仅引用,仅定义,未使用)静态分析—关注点被零除范围检查错栈溢出错堆溢出错无效指针操作浮点上溢出浮点下溢出无效浮点运算对象未初始化逻辑覆盖测试—覆盖要求语句覆盖分支覆盖条件覆盖条件分支覆盖修正条件分支覆盖(MC/DC)条件组合覆盖基本路径覆盖逻辑覆盖测试—控制流图一个段是一个或多个无条件连续执行的语句一个段在控制流图中用一个结点表示，结点可以用任何方便的形式命名一个控制条件转移是一个分支，一个分支段在控制流图中用一个输出边表示一个程序的入口点用入口结点表示，它是一个没有输入边的结点，一个程序的出口点用出口结点表示，它是一个没有输出边的结点逻辑覆盖测试—程序实例voidDoWork(intx,inty,intz){intk=0,j=0;if((x>3)&&(z<10)){k=x*y-1;j=sqrt(k);}if((x==4)||(y>5)){j=x*y+10;}j=j%3;}逻辑覆盖测试—控制流图例A:1,2,3B:4C:5,6,7,8D:9E:10,11,12F:13,14ABDFEC逻辑覆盖测试—复杂度度量圈复杂度V(G)计算1V(G)=e–n+2e表示控制流图中边的数量，n表示控制流图中节点的数量计算2V(G)=区域数计算3V(G)=判定节点数+1逻辑覆盖测试—语句覆盖程序中每条语句至少被执行一次C1覆盖、行覆盖、段覆盖、基本块覆盖语句覆盖的盲点(循环;条件)语句覆盖是最起码的测试要求逻辑覆盖测试—语句覆盖用例{x=4、y=5、z=5}执行路径ABCDEFABDFEC判定1：(x>3)&&(z<10)判定2：(x==4)||(y>5)逻辑覆盖测试—分支覆盖程序中的每一个分支至少通过一次C2覆盖、决策覆盖、判定覆盖分支覆盖的盲点短路估值使分支覆盖不必考虑所有条件分支覆盖不能保证所有入口－出口路径都被执行逻辑覆盖测试—分支覆盖用例{x=4、y=6、z=5}{x=2、y=5、z=5}执行路径ABCDEFABDFABDFEC12判定1：(x>3)&&(z<10)判定2：(x==4)||(y>5)逻辑覆盖测试—条件覆盖判定中的每个条件获得各种可能的结果不要求测试所有可能的分支逻辑覆盖测试—条件覆盖用例{x=4、y=6、z=15}{x=2、y=5、z=5}执行路径ABDEFABDF12ABDFEC判定1：(x>3)&&(z<10)判定2：(x==4)||(y>5)逻辑覆盖测试—条件分支覆盖判定中每个条件的所有可能取值至少执行一次同时每个判定的所有可能判定结果至少执行一次逻辑覆盖测试—条件分支覆盖用例{x=4、y=6、z=5}{x=2、y=5、z=15}执行路径ABCDEFABDF判定1：(x>3)&&(z<10)判定2：(x==4)||(y>5)12ABDFEC逻辑覆盖测试—MC/DC修正条件分支覆盖(MC/DC)程序里的每一个判定都至少取所有可能的输出一次程序中判定的每一个条件都取所有可能的输出至少一次判定中的每一个条件都被证明可以独立影响判定的输出逻辑覆盖测试—MC/DC用例编号条件(与)判定1x>3z<1011TTT12TFF13FTF用例编号条件(或)判定2x==4y>521TFT22FTT23FFF逻辑覆盖测试—MC/DC用例{x=4、y=5、z=5}11,

21{x=2、y=5、z=9}13,

23{x=6、y=6、z=15}12,

22执行路径ABCDEFABDFABDEF12ABDFEC3逻辑覆盖测试—条件组合覆盖每个判定中条件的各种组合至少出现一次达到了条件组合覆盖，所有的语句、分支和条件都将覆盖，但不保证路径覆盖在实际测试中，由于谓词表达式的短路估值和排它性条件使得达到所有条件组合不可能逻辑覆盖测试—条件组合覆盖用例{x=4、y=6、z=5}{x=4、y=5、z=15}{x=2、y=6、z=5}{x=2、y=5、z=15}执行路径ABCDEFABDEFABDEFABDFABDFEC1423判定1：(x>3)&&(z<10)判定2：(x==4)||(y>5)逻辑覆盖测试—基本路径覆盖基本路径数=圈复杂度(C)基本路径覆盖要求测试C条不同的入口－出口路径在某些程序中，分支覆盖可在少于C条路径的情况下获得基本路径覆盖可能既没有获得语句覆盖也没有获得分支覆盖逻辑覆盖测试—基本路径覆盖圈复杂度C=7-6+2=3用例{x=4、y=6、z=5}{x=4、y=5、z=15}{x=2、y=5、z=15}执行路径ABCDEFABDEFABDFABDFEC132逻辑覆盖测试—覆盖分析器覆盖分析器是分析测试覆盖率的工具覆盖分析器工作原理通过对源代码的词法分析，插入可跟踪代码，再编译连接；当装配过可跟踪代码的软件执行时，就会产生一个跟踪文件；测试完成后，利用跟踪文件生成覆盖报告。逻辑覆盖测试—覆盖率的作用发现不可执行的路径或条件不可能到达或冗余的代码不充分的测试用例集逻辑覆盖测试—覆盖与缺陷查找覆盖与发现缺陷之间没有必然联系达到85%容易,达到100%困难不可到达的代码(控制流无法到达)复杂序列(很难使控制流到达)数据流覆盖测试通过一定的覆盖准则检查程序中每个数据对象的每次定义、使用和消除数据流模型(DUK)数据流覆盖策略变元测试测试覆盖被测实现的指定的变体，如测试探测到变元，则变体“退役”，如测试探测不到变元，则修正测试包变元是指为程序植入小的变化，一般是常出现的错误，如将>=改写成>用于检查系统的容错能力和测试套件的充分性规格说明类测试功能测试性能测试接口测试人机交互界面测试功能测试详尽测试每一个软件功能功能——产品能够完成的任务，如：特征/命令/任务标识等组合功能的测试测试基本流(最简单执行路径)测试备选流(特定条件下的执行路径)功能测试—要求检验功能的完备性检验功能的正确性需要满足精度等要求测试功能的健壮性功能测试—用例设计方法单项功能边界值分析等价类划分组合逻辑分析组合功能场景测试(Scenariotesting)状态转换性能测试性能测试是对软件需求规格说明或设计文档中的性能需求逐项进行的测试，以验证其性能是否满足规定的指标要求性能测试有时可理解为有定量指标要求的一些功能，其基础是功能满足要求，所以通常在功能测试的基础上再做性能测试性能测试—性能系统或组件对于其及时性和资源利用性目标的符合程度良好的性能需求定义有前提条件性能测试—及时性在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力响应时间系统对事件产生响应所需要的时间吞吐量特定时间内能够处理的事件数量性能测试—时间限制类型实时嵌入式系统的时间限制类型最大时间:一个事件和另一个事件发生的时间间隔最大不超过t个单位时间最小时间:两个事件之间发生的时间间隔最小不小于t个单位时间持续时间:一种状态必须存在t个单位时间性能测试—资源利用率在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力主要包括内存使用CPU负载数据库连接数接口饱和度磁盘利用率性能测试—性能约束需要弄清影响性能指标要求的全部潜在因素的约束条件考虑系统能力(硬件、支撑软件)网络负载情况，典型/峰值的并发需访问的数据库，类型、数量、结构、布局，数据库中的数据量网络的结构，带宽性能测试—合格判据实时系统往往考虑最差情况强实时系统的一次性能不满足要求,往往就是功能失效非实时系统通常考虑平均情况性能测试—方法从软件性能需求中获得性能测试需求确定需测试的性能指标确定关键用例、关键场景最重要、最耗时、最频繁等确定影响被测性能指标的负载规模准备测试环境执行测试用例，记录测试结果分析、计算结果判定性能测试—性能数据采集方法系统监视器程序监视器系统事件记录器外部程序事件记录器内部事件记录器性能测试—环境时间测量外部观察，适用于精度要求不高时，如使用秒表计时插桩探测，使用数字示波器，或机器时钟，关键在于测量分辨率测量资源利用率系统自带测量工具专门设计的方法性能测试—执行考虑尽可能多的情况，反复测试，如实记录每次测试结果在测试记录中要记清相应的测试环境，尤其是关键影响因素，以便做出正确判断在得到一系列数据后再作判断实时系统通常根据最差情况判断非实时系统通常根据数据分布判断性能测试—最差运行时间(WCET)获取最差运行时间(WCET)的常用手段动态测量技术软件动态运行获取测试所有情况比较困难需要专门的测量仪器和设备静态分析技术分析目标代码结果精确接口测试从系统和子系统设计规格说明、软件接口需求规格说明中获得接口测试需求测试所有外部接口，检查接口信息的格式及内容，考核异常情况的管理测试所有内部接口的功能和性能接口测试—主要接口类型参数接口数据通过参数从一个过程传递到另一个过程共享存储器接口在过程或函数之间共享存储器API接口一系列的过程被封装成子系统,供另一个子系统调用消息接口一个子系统向其它子系统请求服务接口测试—主要接口错误类型接口误用一个组件调用另一个组件时，在使用其接口时产生了错误接口误解在调用组件中嵌入了对被调用组件行为的不正确假设同步误差调用和被调用的组件以不同的速度运行，访问到过时的信息接口测试—通信协议测试嵌入式系统的通信协议种类很多标准协议私有协议接口驱动程序采用非货架产品时，需要测试非应用层协议的实现正确性测试健壮性测试需要接口测试设备接口测试—指南设计超出被调用组件参数范围的测试对于指针参数，一定要测试空指针设计可导致组件失效的测试在消息传递系统中，使用强度测试在共享存储器系统中,改变组件活动的次序人机交互界面测试操作和显示界面及界面风格与需求规格说明中要求的一致性和符合性(正确性、有效性)以非常规操作、误操作、快速操作来检验人机界面的可靠性对错误命令或非法数据输入的检测能力与提示情况(健壮性)对错误操作流程的检测与提示对照用户或操作手册逐条进行操作和观察质量特性类测试类型容量测试余量测试强度测试安全性测试信息安全测试可靠性测试容量测试容量测试的目的是检验软件的能力最高能达到什么程度，确定系统的可伸缩性，从容量规划的角度确定软件的使用等级限制可伸缩性是系统在对其功能要求增加的情况下，继续实现响应时间或吞吐量目标的能力有时系统容量作为系统指标，有时系统的实际容量需要测试才能得到容量测试—用例设计确定进行容量测试的性能指标或指标的成分确定影响指标行为的因素，给出这些影响因素在“正常”情况下的典型要求确定性能负载增加的增量值确定到达不正常后，寻找临界值(容量点)的方法，如二分法容量测试—执行测试前做好分析，确定容量测试不会造成系统损伤测试执行时，通过向系统逐步施加不断增大的性能负载，确定系统能否可靠地适应性能负载的增加记录每次性能负载增加的测试结果仔细观察系统的响应结果，与“正常情况”进行对比根据测试结果，综合分析，确定系统能可靠处理的最大性能负载，评估系统的可伸缩性余量测试余量测试是对软件是否达到需求规格说明中要求的余量的测试余量测试时，需要获得测试量的最大值，剩下的是余量。用什么办法能说明获得的测试量是最大值是关键例如时间片规定是50ms，规定要求余量是30％，需要说明测试中考虑了消耗时间最长情况，其结果也在35ms以内余量测试—动因嵌入式软件常常通过裕度设计提高系统的可靠性在实际应用中，由于某些预料不到的情况的发生，系统会在某些时刻以某种方式膨胀，如：处理时间变长，数据从正常区域波动到非正常区域等，设计留有余量将可以容纳这些意外波动，维持系统正常运行规格说明中无明确要求时，一般至少留有20%的余量余量测试—目标存储器使用输入/输出通道使用处理时间吞吐量注意：不是所有的性能要求都需要余量测试强度测试强制软件运行在不正常到发生故障的情况下(设计的极限状态到超出极限)，检验软件可以运行到何种程度需要弄清被测对象什么叫不正常，什么叫发生故障，它们表现形式是什么通常基于单因素假设，选取不同因素反复测试和试验发现软件的性能瓶颈，提供优化方案强度测试—相关思考找出临界点是关键测试过程中负载逐步增加，反复测试找到一个最低的导致故障的点也存在达不到故障点的情况关于连续运行时间强度需要连续不中断的运行，应该构造一个较大的测试用例库作为支撑，测试用例库的测试用例重复周期要超过指定的时间长度最好能实现自动测试强度测试—与其它测试的关系正常运行不正常但可运行性能测试故障容量测试强度测试正常运行设计规范余量测试工作极限破坏极限正常工作区设计裕度过应力安全性测试对防止危险状态措施的有效性和每个危险状态下的反应的测试对设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案的测试对异常条件下系统/软件的处理和保护能力的测试，以表明不会导致不安全状态对双工切换、多机替换的正确性和连续性的测试安全性测试—要点应明确系统的安全状态以及对软件处理的要求安全性测试重点关注安全相关的功能，因此需求的分类管理很重要进行安全性测试时，应对测试的后果预先进行评估，防止测试导致损失，在真实环境下测试前应在仿真环境下预先验证安全性测试应关注系统各级别上安全机制的协调性和合理性信息安全测试对具有防止非法进入软件并保护软件的数据完整性能力的测试对重要数据的抗非法访问能力的测试防止数据完整性被破坏能力的测试防止系统可用性遭受破坏能力的测试逻辑炸弹等恶意逻辑和功能检测信息安全测试—焦点嵌入式系统关注的信息安全特征A(可用性)-I(完整性)-C(机密性)，控制的可用性和完整性最重要，数据平均信息量较低，机密性要求不高许多控制系统提供0.999999的可用性，安全不能降低可用性!信息安全测试—安全功能验证身份识别与验证系统对用户身份进行鉴别权限管理通过鉴别的用户的特权和访问许可完整性避免数据讹误保密性维持数据