缺陷管理(软件测试与度量).ppt

Bug管理 姚砺yaoli 内容 Bug相关概念判断Bug的规则Bug的生命周期报告 跟踪 关闭BugBug报告的内容Bug的统计 什么是Bug 功能没有实现或与规格说明不一致的问题是bug 不能工作 死机 没反应 的部分是bug 不兼容的部分是bug 边界条件未做处理是bug 界面 消息 提示 帮助不够准确是bug 屏幕显示 打印结果不正确也是bug 有时把尚未完成的工作也作为一个bug 什么是Bug 在IEEE1983ofIEEEStandard729中对软件缺陷下了一个标准的定义 1 从产品内部看 软件缺陷是软件产品开发或维护过程中所存在的错误 毛病等各种问题 2 从外部看 软件缺陷是系统所需要实现的某种功能的失效或违背 Bug举例1 文本文件保存错误 在WindowsXP桌面上新建一个文本文档 输入 联通 两个字 并保存退出 退出后再次打开这个文本文件时 刚才输入的内容变成了乱码 Bug举例2 共享文件夹名超长时提示错误 WindowsXP支持的最大共享文件夹名长度为80个英文字母或40个汉字 但设置共享文件夹名时可输入的范围是80个英文字符或80个汉字 如果共享文件夹名在41 80个汉字之间 系统会提示 该共享名包含无效的字符 其实真正的原因是共享文件夹名超长 Bug举例3 替换字符串长度未作限定 Word2000中 如果替换字符串长度过长 则会引起程序崩溃 软件问题报告 Bug报告 软件问题 Bug 报告是软件测试过程中最重要的文档 它记录了Bug发生的环境 如各种资源的配置情况 Bug的再现步骤以及Bug性质的说明 更重要的是它还记录着Bug的处理过程和状态 Bug的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程 如果没有报告缺陷 后果 第1份缺陷报告 判断Bug的规则 软件未达到产品规格说明书 需求 标明的功能 软件出现了规格说明书指明不会出现的错误 软件功能超出规格说明书指明的范围 软件未达到规格说明书虽未指出但应达到的目标 隐含需求 软件测试员认为软件难以理解 不易使用 运行速度缓慢 或者最终用户认为不好 需要注意的是 测试人员报告Bug时 应当保证Bug是可以重现的 对于有时不可重现的Bug 应当反复测试 直到最终确定Bug的发生场景为止 报告Bug的基本原则 尽快报告Bug修改成本小 修改风险小避免报告同类缺陷有效描述Bug简单 明确 具体每个缺陷一份报告简化和优化操作步骤保证重现缺陷缺陷描述客观公正 不带评价和感情色彩保证每个缺陷被报告和处理 有效描述Bug 单一准确 每个报告只针对一个软件缺陷可以再现 不要忽视或省略任何一项操作步骤 特别是关键性的操作一定要描述清楚 确保开发人员按照所描述的步骤可以再现缺陷完整统一 提供完整的软件缺陷描述信息短小简练 如使用业务关键词特定条件 必须注明缺陷发生的特定条件不做评价 客观描述 一个简单的缺陷报告 缺陷报告的描述 缺陷的严重性和优先级缺陷的类型和来源缺陷附件完整的缺陷信息列表 缺陷的严重性和优先级 严重性 缺陷对软件产品使用的影响程度优先级 缺陷必须被修复的紧急程度缺陷越严重 越要优先得到修正 缺陷严重等级和缺陷优先级相关性很强也有例外 如有些缺陷比较严重 但由于技术的限制或第3方产品的限制 暂时没法修正 其优先级就会低 缺陷的类型和来源 缺陷类型可以分为业务逻辑 数据处理 接口 UI 性能 安全性 兼容性 配置 文档等缺陷来源 如需求说明书 设计规格说明书 代码 用户手册等缺陷关联的模块名 缺陷来自于产品的特定模块的名称缺陷发生的阶段 例如需求 系统架构设计 详细设计 编码等 缺陷附件 一张图片可能胜过千言万语Logfile工具捕捉的其它数据文件等 完整的缺陷信息列表 ID标题前提环境操作步骤期望结果实际结果频率 严重程度优先级类型缺陷提交人缺陷指定解决人来源产生原因构建包跟踪 版本跟踪提交时间修正时间验证时间所属项目 模块产品信息状态 编写Bug摘要 Bug的摘要是要用一句话的形式简明扼要地将Bug描述出来 要清晰指出Bug所在部位以及其错误类型 不能太笼统 如 页面对非法输入有问题 可以修改为 流量信息查询页面对于非法输入没有进行校验 有效描述Bug 操作步骤 使用MappingBuilder对URL为 jdbc mysql 10 0 0 12 test 的数据库进行映射 虚拟数据库名称设置为 VMysql 进入DataView主页面 在DASList中点击 VMysql 右侧的 高级查询 链接 在高级查询页面底端的输入框中 输入SQL语句 select fromempinfo 点击查询按钮 在得到的查询结果页面中 点击 下一页 链接 翻页到下一页后 没有出现 保存当前页面的查询结果 链接 无法保存当前页面结果 有效的缺陷描述所带来的益处 容易再现所报告的问题 加快缺陷的修正提高工作效率提高测试人员的信任度 有利于开发团队和测试团队之间的的沟通和合作客观 准确的产品质量评估预防缺陷 分离和再现缺陷的技巧 记下每一个操作步骤和中间结果逐步尝试并缩小侦察范围查找时间依赖问题查找资源依赖问题考虑软件和硬件配置不同的可能 软件缺陷的处理和跟踪 软件缺陷生命周期缺陷的跟踪处理缺陷状态报告 缺陷状态 软件缺陷生命周期 复杂的软件缺陷生命周期 缺陷的跟踪处理 密切跟踪缺陷状态的变化 及时处理缺陷 使项目按预定的计划进行动态报表 及时更新数据自动邮件机制 缺陷分析 作用调整测试进度和项目进度调整测试策略和项目资源分配测试人员与开发人员考核精心设计谨慎使用度量软件质量 评估测试过程的效率 预期发布时间数据最能反映真实情况数据也最能制造假象 缺陷分析 关注对象正在测试的软件哪个模块的问题最多 测试人员中谁报告的软件缺陷最多 测试人员中谁报告的软件缺陷准确率最高 各类缺陷所占的数量百分比分别是多少 开发人员能及时修正软件缺陷吗 开发人员一次正确修正缺陷的百分比是多少 有多少重复报告的缺陷 正在开发的软件能否在计划的时间内正常发布 缺陷分析工具 实时趋势分析累积趋势分析缺陷分布分析 实时趋势分析 实时数据 由每日或每周发生的数据构成的时间序列对随时间变化的趋势进行分析 累积趋势分析 累积数据是将前面产生的数据不断累加起来所构成的时间序列累积曲线趋势特征更明显 借助趋势分析发现问题 产品的质量是否达到预定的标准缺陷修正的速度是否滞后测试人员验证缺陷是否及时缺陷遗漏程度回归缺陷数量流程 实例 缺陷分布分析 缺陷分布分析 主要借助于圆饼图 直方图等工具进行分析包括功能模块 来源分布 不同类型 开发团队等各种分布 直方图 圆饼图 综合 缺陷分析通常用以下三类形式的度量提供缺陷评测 缺陷发现率缺陷潜伏期缺陷密度 缺陷分析 缺陷发现率缺陷发现率是将发现的缺陷数量作为时间的函数来评测 即创建缺陷趋势图 如下图所示 缺陷潜伏期测试有效性的另外一个有用的度量是缺陷潜伏期 通常也称为阶段潜伏期 缺陷潜伏期是一种特殊类型的缺陷分布度量 在实际测试工作中 发现缺陷的时间越晚 这个缺陷所带来的损害就越大 修复这个缺陷所耗费的成本就越多 表5 1显示了一个项目的缺陷潜伏期的度量 表5 2显示了一个项目的缺陷分布情况 按缺陷造成阶段和缺陷发现阶段 缺陷密度缺陷密度是一种以平均值估算法来计算出软件缺陷分布的密度值 程序代码通常是以千行为单位的 软件缺陷密度是用下面公式计算的 下图显示了一个项目的各个模块中每千行代码的缺陷密度 但是 在实际评测中 缺陷密度这种度量方法是极不完善的 度量本身是不充分的 这里边存在的主要问题是 所有的缺陷并不都是均等构造的 各个软件缺陷的恶劣程度 及其对产品和用户的影响的严重程度 以及修复缺陷的重要程度有很大差别 有必要对缺陷进行 分级 加权 处理 给出软件缺陷在各严重性级别或优先级上的分布作为补充度量 这样将使这种评测更加充分 更有实际应用价值 因为在测试工作中 大多数的缺陷都记录了它的严重程度的等级和优先级 所以这个问题通常都能够很好解决 例如 下图所示的缺陷分布图表示软件缺陷在各优先级上所应体现的分布方式 各优先级上软件缺陷分布图 报告和管理缺陷 缺陷报告管理系统 缺陷跟踪系统 过程强制权限控制质量记录文档管理信息共享度量和统计 不仅可以统一数据格式 完成数据校验 而且确保每一个缺陷不会被忽视 使开发人员的注意力保持在那些必须尽快修复的高优先级的缺陷上 可以