让测试管理变轻松 上海泽众软件 2008年9月
让测试管理变轻松 软件测试管理 自动化测试工具选用 自动化测试工具演示与实践
软件测试管理 软件测试过程管理 缺陷跟踪与管理
软件测试管理 软件测试过程管理 缺陷跟踪与管理
软件测试过程管理 测试工作目的 测试过程设计 如何规划测试 测试策略
软件测试工作目的 在测试技术兴起的早期，测试的目的主要有两个：证明系统可用，满足了需求；发现系统中的错误。 随着软件技术的成熟，人们发现大量错误的根源在于需求和设计，因此现代测试的目的在于：证明系统可用，满足了需求；发现系统中的错误； 避免错误的发生。
缺陷产生的原因
测试工作的目的
软件测试过程管理 测试工作目的 测试过程设计 如何规划测试 测试策略
软件测试过程设计 立项阶段 项目过程流图 项目启动阶段 项目计划阶段 需求阶段 设计阶段 编码阶段 单元测试 集成测试阶段 系统测试阶段 测试预算 测试团队 测试计划 测试需求 测试用例设计 测试执行,缺陷管理 项目过程流图 项目启动阶段 项目计划阶段 需求阶段 设计阶段 编码阶段 单元测试 集成测试阶段 系统测试阶段 项目结束
测试过程模型
测试计划和实施的原则(一) 穷尽测试是不可能的 测试工作具有创造性和挑战性 测试是有风险的 测试分析、计划和设计是非常重要的
测试计划和实施的原则(二) 测试者的工作态度非常重要 时间和资源非常重要 测试准备和时间表的重要性 必须度量和跟踪测试覆盖度
软件测试过程管理 测试工作目的 测试过程设计 如何规划测试 测试策略
如何规划测试 测试对象 测试工作范围 项目限制 制定测试策略 测试资源和获取
如何规划测试 测试作为一个子项目来规划
测试对象 被测对象的特性基线 被测对象的版本 如何评价被测对象的质量？各个质量指标的优先级是什麽？ 测试需求？
测试工作范围 确定测试工作范围 单元测试？ 集成测试？ 系统测试？
项目限制 项目进度限制 项目的成本限制 资源的限制
制定测试策略 技术方法和工具 测试资源的估计和获取（人力、设备、软件工具） 测试进度安排 测试人员分工 测试启动准则 测试结束准则 与其他组的协同
测试资源和获取 测试资源： 人力 设备 软件工具 资源获取方式： 设备和软件工具
软件测试过程管理 测试工作目的 测试过程设计 如何规划测试 测试策略
测试策略 技术方法和工具 测试进度安排 测试人员的分工 测试的启动准则 测试结束准则 与其他组的协同 测试跟踪
技术方法和工具 测试环境 测试方法 测试程序 测试例设计方法
测试进度安排 测试工作阶段的划分： 计划 设计 检查 执行 报告分析 如何保证测试计划、设计、实现与开发任务的并行？ PDCA模型
测试人员的分工 测试任务分类 测试管理 测试设计 测试实现 测试执行 测试报告
测试的启动准则 何时可以开始测试？ 在测试计划阶段就必须明确，而且是在整个项目组达成一致。 可参考的准则： 完成单元测试，单元测试符合结束准则 建立代码基线 发布了测试版本 通过版本基本验证项
测试结束准则 项目有预先定义的结束时间，因此测试工作也不可能无休止的进行。 可参考的测试结束准则： 所有需求都进行了验证 通过所有功能验证 无致命和严重的问题
与其他组的协同 与开发组的协同 与配置组的协同 与质量经理的协同 与项目各级管理者的协同
组间协同-与开发组 测试组与开发组共同确认测试的范围 开发组为测试方案提供建议 测试组借鉴开发组的程序开发测试程序 测试组与开发组共同确认测试开始和启动准则 测试组向开发组通报测试结果和分析 测试组和开发组之前的版本传递经配置组完成。
组间协同-配置组 所有测试记录提交配置组管理 所有测试版本由配置组负责合成和发布
组间协同-质量经理 与质量经理一起制定测试流程和规范 质量经理审计测试的进行状况
组间协同-各级管理者 测试组与各级管理者共同确认测试的范围 各级管理者为测试方案提供建议 测试组与各级管理者共同确认测试开始和启动准则 测试组向各级管理者通报测试结果和分析 各级管理者监控测试执行进度和结果
测试跟踪 你计划运行多少个测试用例？ 你实际运行了多少个测试用例？ 有多少个测试用例失败了，在这些失败的测试用例中，有多少个在错误得到修改后最终运行成功了？ 这些测试平均占用的运行时间比你预期的长还是短？ 你有没有跳过一些测试？如果有的话，为什么？ 你的测试涵盖了所有影响系统性能的重要事件吗？ 你的测试小组是否要求提交一份关于所有测试结果（成功和失败的）累计报告呢？如果是的话，你是否提交了这样一份精确的报告呢？
测试用例工作表 T：测试用例数量；F：失败数量；P：成功数量 [项目名称] 测试包/用例 状态 系统配置 缺陷ID 执行人 备注 T F P 功能测试 内资企业开业 Pass A,B 017 Jack 1 …… … 包汇总 8 7 T：测试用例数量；F：失败数量；P：成功数量
系统配置子表 系统配置ID 硬件信息 操作系统 软件信息 备注 A CPU=6个 内存=6G 硬盘=100G HP UNIX Weblogic 6.0 B CPU=4个 内存=4G Windows NT Oracle 817
测试包工作表 [项目名称] 测试包 用例总数 Fail Pass 等待 … 总计 1000 100 800 百分比 10% 80% 功能测试 500 10 490 性能测试 7 3 … 总计 1000 100 800 百分比 10% 80%
扩展的测试用例工作表 [项目名称] 负责人 ID 测试包/用例 状态 系统配置 缺陷ID 计划日期 实际日期 计划时长 实际时长 备注 T F P Jack 2.000 功能测试 2.001 内资企业开业 Pass A,B 017 13/7 14/7 2 3 1 …… … 包汇总 8 7
软件测试管理 软件测试过程管理 缺陷跟踪与管理
缺陷跟踪与管理 缺陷生命周期 如何收集缺陷 缺陷的优先级 缺陷的状态 缺陷的严重程度 缺陷的类型 缺陷报告 缺陷趋势 缺陷统计
缺陷生命周期
缺陷生命周期
如何收集缺陷 缺陷既指程序中存在的错误，例如语法错误、拼写错误或者是一个不正确的程序语句，缺陷也指可能出现在设计中，甚至在需求、规格说明或其他的文档中的种种错误。 为了对缺陷进行管理，首先应对缺陷进行分类，通过对缺陷进行分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷。 这正是缺陷管理的关键，一旦这几类缺陷得到控制，再进一步找到新的容易引起问题的几类缺陷上。
缺陷的优先级 代码 解决优先级 描述 1 立即解决 Resolve Immediately 缺陷必须被立即解决 2 正常排队 Normal Queue 缺陷需要正常排队等待修复 或列入软件发布清单 3 不紧急 Not Urgent 缺陷可以在有时间允许时被纠正
缺陷的状态 代码 缺陷状态 描述 1 已提交 Submitted 已提交的缺陷 2 已打开 Opened 已确认的缺陷，等待修复 3 已拒绝 Rejected 拒绝提交的缺陷，不需要修复或 不是缺陷 4 已解决 Resolved 缺陷已被修复 5 已关闭 Closed 被修复的缺陷被确认，将其关闭
缺陷的严重程度 代码 缺陷严重等级 描述 1 致命缺陷 Critical 不能执行正常工作功能或重要功能 危及生命或财产 2 严重缺陷 Major 严重影响系统要求或基本功能的实现 且没有办法更正 3 普通缺陷 Minor 影响系统要求或基本功能的实现 但有办法更正 4 轻微缺陷 Cosmetic 是操作者遇到麻烦或不方便，但不 影响执行功能 5 其他缺陷 Other 其它错误，例如文字错误、 布局不合理等
缺陷的类型 按错误的影响和后果分类 按错误的性质和范围分类
按错误的影响和后果分类 其他错误 轻微错误 普通错误 严重错误 非常严重的错误 致命错误
按错误的性质和范围分类 功能错误 系统错误 加工错误 数据错误 代码错误
功能错误 规格说明错误 功能错误 测试错误 测试标准引起的错误
系统错误 外部接口错误 内部接口错误 硬件结构错误 操作系统错误 软件结构错误 控制与顺序错误 资源管理错误
加工错误 算术与操作错误 初始化错误 控制和次序错误 静态逻辑错误
数据错误 动态数据错误 静态数据错误 数据内容错误 数据结构错误 数据属性错误
代码错误 语法错误 打字错误 对语句或指令不正确理解所产生的错误
按软件生存期阶段分类 问题定义（需求分析）错误 规格说明错误 设计错误 编码错误
问题定义（需求分析）错误 它们是在软件定义阶段，分析员研究用户的要求后所编写的文档中出现的错误。 换句话说，这类错误是由于问题定义不满足用户的要求而导致的错误。
规格说明错误 不一致性错误 冗余性错误 不完整性错误 不可行错误 不可测试错误
设计错误 设计不完全错误 算法错误 模块接口错误 控制逻辑错误 数据结构错误
编码错误 编码过程中的错误是多种多样的，大体可归为以下几种：数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入／输出错，及其它的错误。
缺陷报告 缺陷报告的目的 摘要 语言 可重现的步骤 测试数据 截屏 严重程序/优先级别 日志 其他信息
缺陷趋势 Open&Close图形 缺陷遗漏图形 全部解决图形 缺陷发现趋势图形
Open&Close图形
理想Open&Close图形
无休止的Open&Close图形
缺陷遗漏图形
全部解决图形
缺陷发现趋势图形
缺陷统计 缺陷严重程度分布统计 模块-开发员-测试员-缺陷统计 模块缺陷率统计 项目缺陷率统计
缺陷严重程度分布统计
模块-开发员-测试员-缺陷统计
模块缺陷率统计 5年以下的工程师：缺陷数/KLOC>12 12年以下的工程师：缺陷数/KLOC<6 模块代号 缺陷数 N(KLOC) 缺陷数/KLOC M 1001 16 5 3.2 M 1002 19 12 1.6 M 1003 30 7 4.2 M 1004 62 20 3.1 M 1005 21 1 21 M 1006 14 3 4.7 M 1007 6 2 3 5年以下的工程师：缺陷数/KLOC>12 12年以下的工程师：缺陷数/KLOC<6
项目缺陷率统计
自动化测试工具选用 自动化测试工具优缺点 自动化测试工具选取
自动化测试工具优点 缩短软件开发测试周期 测试效率高，充分利用硬件资源 节省人力资源，降低测试成本 增强测试的稳定性和可靠性 提高软件测试的准确度和精确度 在回归测试阶段，使用自动化工具可大大提高测试的可靠性与客观性
自动化测试工具缺点 不适合开发周期很短、一次性、不稳定的软件测试 不适合易用性、适用性、功能逻辑、物理交互性测试 无法替代手工测试 工具本身没有想象力和灵活性
自动化测试工具选用 自动化测试工具优缺点 自动化测试工具选取
自动化测试工具选取方法 考虑公司实际情况 分析测试需求 考虑测试周期 功能问题 考虑成本
自动化测试工具演示 测试管理工具TestCenter演示 自动化测试工具AutoRunner For Terminal演示 自动化测试工具AutoRunner For Application演示 自动化测试工具实践
我们的优势 泽众公司产品的优势 正版软件免费升级服务 提供技术支持 价格优势 操作简便，功能强大 客户化，更适合企业发展
谢 谢！