微软产品测试方法.pptVIP

* * 微软软件测试 议程 软件测试概述 软件测试组 测试计划和级别 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及常见类型 RAI