微软产品测试方法.ppt

微软软件测试 议程 软件测试概述 软件测试组 测试计划和级别 Bug的发现和管理 I 软件测试概述 什么是软件测试 测试的目的与任务 软件质量的定义 测试与软件成本 测试部门常用术语 什么是软件测试？ 质量保证系统的监 督和评估项目的各个 方面以确保满足质量 标准 测试是分析并确定产 品是否满足客户的需 求和期望的所有活动 测试的目的与任务 目的保证软件质量，确保产品满足设计的要求和客 户的需求，同时降低软件的开发成本和维护成本，并 最终签发（Signoff）产品质量 任务 根据特性规格说明制定测试计划 开发必要的测试工具 编写测试用例 执行系统、全面、深入的测试，在开发过程中找出 所有可能存在的Bug 跟踪并管理产品质量，定期报告质量状态 负责最终的发布认可（Signoff） 测试与软件成本 成本-越早发现bug，修正的机 会越大，开发和后期维护的代 价越小 Spec review 编码阶段 Beta阶段 本地化 发布后 质量越高，软件发布后维护费 用越低 开发 费用 需求分析 编码 发布 部分常用术语 QA-Quality Assurance 质量保证 Bug- 缺陷，问题 Blocking Bug Show Stopper Bug/ Release killer-致命问 题 Milestone-里程碑 Test Case-测试用例 Stress Test-破坏性测试 BVT-Build Verification Test Ad-hoc测试- 随机测试 Buddy Test Hot Fixing Dog Food ZBB(Zero Bug Bounce) ZBR(Zero Bug Release) RTM/RTW II 软件测试组 微软测试组在整个项目中的位置 与程序员的关系 与程序经理的关系 测试Team的主要职责 测试组成员的职责 微软测试组在整个项目中的位置 和设计组，开发 组及用户教育等 并列的队伍 测试组负责产品 的质量控制 测试人员和开发 人员的比例大约 是1：1 沟通和联络 测试 后勤 用户教育 产品经理 产品规划 开发 与程序员的关系 测试组不是开发组的助手，合作又各司其职 程序员不能写完代码扔过墙，等待测试工程时找到所有 的Bug RAID是桥梁 对有分歧的Bug程序员不能擅自关闭 测试人员对发现的Bug要尽可能提供详细的信息 与程序经理的关系 没有隶属关系，合作又各司其职 程序经理提供详细的规格说明 程序经理要参与Review测试计划 测试人员要报告测试状态及产品状态 测试队伍的主要职责 测试队伍的组成 经理，组长，测试工程师 主要职责 测试计划 测试 测试过程 项目与资源管理 交流与业务 测试工程师的主要责任 创作相关的测试计划和测试用例 设计或改编相关的测试工具 识别可自动测试的区域 参与组内的测试计划和测试用例以及测试脚本分析工作 手动/自动测试 Ad-Hoc测试 按照需求规格说明查证并验证各项功能 发现并报告Bug，跟踪Bug状态 评估Bug对产品其它区域的主要影响 测试组长的主要责任 确定测试的策略 参与对整个产品的完整测试计划的制定 参与并管理测试 评估Bug对用户的影响，推荐Work-Around. 独立的跟踪关键Bug的状态 管理测试工作和对应的资源 参与面试新人 交流状态和存在的问题，并驱动问题的解决 促进组内的对间接问题的交流 测试经理的主要责任 定义时间进度表 定义质量标准 参加Bug Triage Sing off 产品 发起和计划长期的测试过程，使之规范化 积极开发测试人员的技术技能 组建测试队伍，雇用测试工程师 合理安排各种资源 负责制定产品测试所需的预算 II 测试计划和级别 测试计划的主要内容 测试级别 测试计划的主要内容 2-1 引言 背景信息 质量目标 责任 测试的方法论 测试计划的主要内容 2-2 Milestone 的处理 测试文档 自动测试策略 集成测试策略 API测试策略 性能测试 Performance(Benchmark) Testing 测试资源的规划 兼容测试 Ad Hoc 测试策略 本地化测试策略 全球化测试策略 Beta策略 Release Criteria 对第三方的依赖 测试周期：与项目的里程 碑配合 测试级别 单元测试针对单独代码部分进行的测试 子程序 简单函数 组件测试测试多个单元和数据对象间的互操作性 被调用的Subroutines,Data,etc. 集成测试测试集成组件的互操作性 Exe和Dll 系统测试测试系统的鲁棒性和与外部系统的交互性 附压/性能测试 系统安装/应用程序的兼容性 测试实践活动 IV Bug的发现和管理 什么是Bug及常见类型 RAID 有效地报告Bug Bug的严重程度和优先级 Bug的处理 Bug Triage Active Bug 数量的趋势 Bug及常见类型 功能未完成，和规格说明书不一致 不能工作：死机，没反应 不兼容 边界条件 界面、消息、提示不够准确，不友好 把尚未完成的工作也作为一个Bug 文档与帮助信息中的缺陷也是Bug RAID RAID是客户端的工具，Bug数据库 整个产品组的中央记录和控制 丰富的查询功能，有效的跟踪项目的状态，为产品发布 提供判断标准 准确的定义了描述Bug要用到的属性 Postponed Bug 所有的记录无法删除，对于每个记录只能一直添加内容 报告新Bug 查寻并确认不重复 从标题开始 可能查找多次 最后是查找Bug的描述部分 如果找到类似的Bug，检查是否需要加入新的注释 填写标题，简明描述该问题 Bug 记录中的有效信息 Status Assigned To Issue Type Severity Priority Change Date,Change By Opened Date,By,Rev Source,Beta ID,How found Language Resolution:By design, Fixed,Duplicate,Not Repro.Wont Fix Area,Sub Area Platform 附件 附图 报告新Bug - 环境 描述系统配置，如： OS 内存大小 处理器类型 浏览器类型和版本 其他应用程序 报告新Bug - 描述 帮助开发人员再现Bug 组成 列出起始参数 再现步骤 预期和实际的结果 已测试的其他有用信息 一旦保存所用描述信息将无法修改，只能添加 Bug 的严重程度 死机，数据丢失，主要功能组完全丧失，系统悬挂 主要功能丧失，导致严重的问题，或知名的错误声明 次要功能丧失，不太严重，如提示信息不太准确 微笑的问题，对功能几乎没有影响，产品及属性仍可使 用，如有个错别字 活 Bug 新建一个Bug时的状态 Bug Regression 表明Bug等待修改 评估开发进度产品质量的重要指标 处理 Bug 对Bug的处理结果 必须重新分派给报告该Bug的人员 对修正的Bug需要确认 标准的处理结果 故意的 重复 已修正 无法重现 延期修正 永不修正 外部 解决/关闭 Bug Bug的解决方法= 故意的 重复 无法重现 延期修正 永不修正 外部 Bug的解决方法=已修正 Bug Regression Bug的Triage 何时Triage Triage 成员 主持：Program Manager 成员：PM/QA/Dev/PLM,Builder and 经理 讨论： 要求Fix的理由 Fix可能带来的风险 Fix要求被拒绝时要采取的行动 Active Bug 数量的趋势 代码完成前：很少 代码完成后：增长很快 接近Beta：下降 接近RC：奔向零 产品质量和里程碑的信号 每天新建的Bug与修正的Bug相比较