02-嵌入式软件测试探究.pptx

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