cmmi培训之微软的过程模型.ppt

实现一个0缺陷版本 详细描述测试策略 假设源码是有错误的，证明他是对的 在继续工作前修改错误 采用竞争的设计和实现 将修改错误的工作安排给其他开发员 根据错误重新评估源码 执行代码评审 文档化特性设计和接口 设置0缺陷里程碑 源码评审的作用 传播关于源码的关键部分的信息 对臭虫成堆的源码区域进行分析 评估难于测试的源码的质量 评估不能进行全面测试的源码的改变 作为对新成员的训练手段 增加源码的可维护性 源码评审中的关键角色 内部发布 管理测试过程 Bug跟踪过程 测试类型 覆盖测试 单元测试 功能特性测试 登记测试 BVT测试 可用性测试 配置测试 兼容性测试 压力测试 性能测试 文档与HELP文件测试 Alpha\beta测试 小结 如何知道达到了该里程碑？ 在该阶段每个角色干什么工作？ 在策划阶段有哪些任务？ 内部里程碑有哪些？ 交付物有哪些？ 测试有哪些类型？ 内部版本的目的？ 五 发布里程碑 内容 里程碑达到的条件 角色分工 内部里程碑 交付物 任务提前期 beta测试 bug收敛 0 Bug发布 发布侯选 里程碑达到的条件 6个角色都同意： 产品稳定能力与问题的解决方案 客户接受该产品 移交长期的管理和支持所有权 改变小组重点为下一个版本 角色分工 内部里程碑 内容完成 Bug收敛 源码冻结 0-Bug版本发布 发布侯选版本 金盘版发布 交付物 金盘版本 发布注意事项 性能支持元素 测试结果与测试工具 源码和可执行文件 项目文档 里程碑评审 任务提前期 Beta测试 测试并修复Bugs 测试并修复Bugs是稳定阶段的主要工作，测试组持续运行测试用例。Beta测试将产生新的Bug报告，项目组的每个人在时间允许的情况下都参与测试。 覆盖测试发现越来越来少的错误 新的Bug主要来自于用户场景、最终用户的参与、压力测试和创造性想法 Bug分类 严重级别 优先级 系统崩溃 最高优先级 重要问题 高优先级 一般问题 中优先级 小错误 低优先级 Bug曲线 Bug收敛 当解决Bug的速率超过了发现Bug的速率时称为Bug收敛。此时版本发布日期是可以预测的，项目组看到了光明。 决定是否到了Bug收敛的时间也是意见棘手的事情，Bug发现的速率与测试方法、测试人是有关的。发现速率是不稳定的。 0-Bug版本 除了在提交日期前绝对需要修改的错误外，不再做任何改动。小的错误在下一个版本中修复。 Bug修复是一个非常易于出错的过程。 发布侯选版 严重级别为1、2、3与优先级为1、2、3的已知Bug已经被修复。 所有的文件已经提交，包括Readme文件 在预定义的时间内每有再发现严重级别为1的Bug。 软件不可能再进行全面测试，所有的Bug修订，必须通过源码评审。 金盘版 最后一个侯选版，母盘。 测试组确信发布前以下的测试已完成： 检查遗漏的文件 检查外部文件 正确的时间印记 安装程序 基本功能检查 病毒检测 折中决策 可靠性 交付日期 特性 发布决策 Bug报告数据 新的高严重性的Bug报告频率是否接近于0 最终的验收测试 产品持续运行了一段时间（3天到1周）没有发现严重性为1，优先级为1的Bug 最终用户的参与 参与Beta测试的最终用户和其他有关用户确信产品在每天的使用中是可靠的 维护和支持 产品是可支持的，维护成本是低的，支持系统已建立 里程碑评审 事后总结 在项目完成后总结一下在开发过程中，哪些做对了，哪些做错了，以便于将来优化过程。 评审结果要文档化。在下一个版本的计划中要有描述。 小结 如何知道达到了该里程碑？ 在该阶段每个角色干什么工作？ 在策划阶段有哪些任务？ 内部里程碑有哪些？ 交付物有哪些？ 何时进入Beta测试？ 什么是Bug收敛？ 如何决定是否发布？ 内容 设置好目标 里程碑达到的条件 角色分工 内部里程碑 交付物 任务提前期 设计过程概览 功能规格定义 项目计划 项目进度表 设置好目标 要清楚你的目标在哪里 射箭的幽默 问路的童话 PPA里程碑达到的条件 6个角色都认可： 项目交付物 特性与优先级 风险 提交日期 业务需求 功能规格定义 项目计划 项目进度表 角色分工 Planning阶段的内部里程碑 功能规格定义草稿 开发进度表草稿 交付日期确定 Planning阶段交付物 功能规格定义 风险管理计划 主项目计划 主项目进度表 Planning阶段任务提前期 设计过程概览 概要设计 用户场景 界面 主要流程：基本功能，处理流程 逻辑设计 对象 服务程序 用户界面 逻辑数据库 物理设计 部件 用户界面 物理设计 功能规格定义 Vision与Sc