嵌入式软件白盒测试技术.ppt

领测技术（EzTester）简介 目录 白盒测试基本概念 嵌入式白盒测试遵循的理念 嵌入式软件测试设计技术 嵌入式软件测试评估技术 常用覆盖率统计标准 基于调用的覆盖率统计技术 如何选择覆盖率标准 用例覆盖度 缺陷密度评估 白盒测试问题管理 第4代白盒测试方法 如何组织嵌入式软件白盒测试 常用覆盖率统计标准 语句覆盖（Statement?Coverage?） 判定覆盖（Decision?Coverage?） 条件覆盖（Condition?Coverage?） 多条件覆盖（Multiple?Condition?Coverage?） 判定条件组合覆盖（Condition/Decision?Coverage?） 修正条件/判定覆盖（Modified?Condition/Decision?Coverage，MCDC） 路径覆盖（Path?Coverage?） 基于调用的覆盖率统计技术 位置无关调用覆盖（Location-independent call coverage） LICC = (已覆盖的不重复的函数调用个数 / 全部不重复的函数调用个数) * 100% 位置相关调用覆盖率（Location-dependent call coverage ） LDCC = (已覆盖的函数调用个数 / 全部函数调用个数) * 100% 比如某函数中调用了3个子函数，其中第1个子函数调用在函数定义的两个地方出现，其余2个子函数都只在一处调用（即，只使用了一次）。如果这个3个子函数都被调用过，而且第1个子函数只一个位置调用了，另一个位置尚未覆盖到。这时，我们计算LICC是“3/3 = 100%”，而LDCC是“3/4 = 75%”。 演示：覆盖率定制的一个实例 演示：覆盖率定制的一个实例 如何选择覆盖率标准？ 是不是选择覆盖率标准越高越好？ 持续集成对覆盖率指标有哪些要求？ 选择恰如其分的评估标准 避免源码中“噪声”给质量评估带来波动 语句覆盖 判定覆盖 条件覆盖 判定条件覆盖 MCDC覆盖 LCSAJ覆盖 路径覆盖 用例覆盖度 为什么引入用例覆盖度 (Test Case Coverage)？ 定义 TCC = 用例中调用被测函数的总次数 / 函数定义的分支总数 函数分支总数 = 1 + if语句总数 * 2 + while语句总数 * 2 + for语句总数 * 2 用例覆盖度的价值 弥补代码覆盖率的评估欠缺 评估标准可定制 演示：TCC定制实例 缺陷密度评估 缺陷密度定义：发现问题数 / 千行代码 主要评估指标 缺陷密度 遗留缺陷密度 测试用例密度 回归测试通过率 DI值 = (致命问题*10 + 严重问题*3 + 一般问题*1 + 提示问题*0.1) * 难度系数 是否符合Compertz退出准则 案例：研发Metrics质量体系 白盒测试问题管理流程 测试 开发 管理 三方会议 开启 分派 设计变更 分派 解决 符合设计 不用解决 延迟解决 关闭 ODC缺陷分析 触发因素 问题发现活动 验证 开发 开发 验证 结果影响 严重程度 原因 结果 定位 责任来源 问题位置 缺陷年龄 缺陷类型 内容类型 缺陷界定 问题根源对象 ODC缺陷分析 检视发现的主要是一般问题 压力测试发现一个致命问题 缺陷根源分析 一种系统的解决问题的方法，通过标示问题，分析问题的根本原因，针对根本原因制定可行的纠正预防措施，以达到解决问题和预防问题再次发生的目的 标识问题 根本原因分析 制定纠正 预防措施 为什么尽早测试？ 50 验收测试 200 20 10 5 1 纠正费用 交付后维护 单元测试 编码 设计 需求 阶段 越早测试付出代价就越低 案例：什么是持续测试？ 案例：一次测试 与 持续测试 某通信产品在V1版本编码完成时，进行过规范的单元测试活动，之后V2、V3要不断增加功能、修改功能，就放弃单元测试了。 当V3最后市场交付时统计发现，相对V1版本，代码修改量已达到40%。QA从其中两个模块随机抽取100个问题单做缺陷分析，结果发现：第一个模块有50%的问题是在V1版本单元测试结束后引入的，而另一模块也有30%问题是单元测试后引入的。 为什么持续测试 持续集成的典型特征是：写一点测一点 Object Mentor：我们在做任何事情时（无论 是写测试、写产品代码还是重构），都要保 证系统能够一直运行。运行测试的间隔时间 是秒或者分钟级的。即使是10分钟都太长了。 反映了一种质量优先的策略 微软的“每日构建”与“冒烟测试” IBM的“渐增Build测试” XP的持续集成、测试先行等实践 持续集成对“软件