产品质量的基石——微软Bug管理.ppt

微软项目管理 团队组织 项目流程管理 缺陷管理 开发管理的切面透视 微软的一天 如何提高软件开发管理的质量 常见问题 没有人愿意做测试 觉得养不起那么多测试人员 开发人员不遵循规范，随心所欲 项目经理事必躬亲，分身乏术 项目经理 开发 测试 发布经理 用户教育 产品经理 Communication 角色 项目经理 开发 测试 产品经理 用户教育 发布经理 职责 编写功能规范，协调各角色关系 按照功能规范编写软件 质量控制 客户联系的桥梁，进行需求分析 让产品容易使用 保证产品顺利发布 常见问题 无法决定项目所需的资源（人力和预算） 无法决定项目的进度表 无法控制外包项目的进度和质量 时间 功能 里程碑 1 里程碑 2 里程碑 3 每个里程碑完成部分功能 便于团队集中力量完成一个又一个功能 提供多个机会以适应需求的更改 I E N V S O G I N N I P L A N I G N N D E V L O PI G E N S T A B I L Z N G I I 1. 达成共识 2. 完成项目计 划 3. 完成功能 4. 发布 步骤一： 达成共识 基本完成需求调研和分析 （产品经理负责） 确定大方向和长中短期目标 所有角色都参与讨论并真正认同结论 产生的文档： 常见用户情景：覆盖80%以上功能 Vision：言简意赅地说明大方向，并有激励团队的 作用 步骤二： 完成项目计划 编写详细的功能规范（项目经理负责） 在编程前想清楚所有功能流程，并引导用户明确需求 所有角色都参与审阅功能规范 制订开发计划和进度表（开发团队） 制订测试计划和进度表（测试团队） 分配资源（人力和预算） 形成项目综合计划和综合进度表 产生的文档： 功能规范，开发计划，测试计划（用例），项目综合计划 开发进度表，测试进度表，综合进度表 步骤三： 完成功能 开发人员分别完成自己的功能 使用版本控制工具 使程序员及时check out和check in，避免积累大量代码 及时进行模块间的整合，及时发现问题（daily build） 对每一项可测试的功能进行测试，无需等待 使用测试用例工具，对功能进行完整和重复的检验 使用BMS进行缺陷跟踪 记录所有程序问题 实现解决Bug的自动流程 按照综合进度表不断检查进度 使用的工具： 版本控制工具 VSS 缺陷跟踪工具 Raid/BMS 测试用例管理工具 步骤四： 稳定与发布 测试组全面地测试功能，包括性能和稳定性 开发组全力配合解决Bug 使用BMS进行 监测质量情况 预测发布日期 专家会诊机制： 决定Bug的优先度 决定哪些Bug可以等到下个里程碑或版本中解决 决定由谁解决某个Bug 使用的工具： 版本控制工具 VSS 缺陷跟踪工具 BMS 测试用例管理工具 微软的开发管理经验： 100%以Bug为核心 测试人员 Raid/BMS 项目经理 其他人员 构造员 开发人员 VSS 构造服务器 发布服务器 Exchang e 100%由缺陷跟踪工具驱动 功能未实现，和规格说明书不一致 不能工作：死机，没反应 不兼容 边界条件 界面、消息、提示不够准确，不友好 把尚未完成的工作也作为一个Bug 文档与帮助信息中的缺陷也是Bug 完整的Bug数据库 整个产品组的中央记录和控制 强大的查询功能，有效地跟踪项目的 状态 所有的记录无法删除，对于每个记录 只能一直添加内容 丰富的报表功能，为产品发布提供判 断标准 状态 负责人 问题种类 严重级 优先级 修改时间 登记时间 缺陷来源 解决方案 运行环境 缺陷关联 附件 附图 缺陷细节 1.死机，数据丢失，主要功能组完全丧失，系 统悬挂 2.主要功能丧失，导致严重的问题，或致命的 错误声明 3.次要功能丧失， 不太严重，如提示信息不太 准确 4.微小的问题，对功能几乎没有影响，产品及 属性仍可使用. 如有个错别字 代码完成前：很少 代码完成后：增长很快 接近Beta: 下降 接近RC: 奔向零 产品质量和里程碑的信号 每天新建的Bug 与 修正的 Bug 相比较. Active 状态 Bug 的总数 让我们看看项目中每个角色的一天是如何度过的 开发 测试 项目经理 注：里程碑的每个阶段每个角色的工作有不同侧重 点，我们以“完成功能”阶段为例 答案：半夜 为什么？ 答案：半夜 因为Daily Build是所有工作的核 心，而且是在半夜自动启动。 你知道自己所用Windows的版本号吗？ Daily Build的意义： 模块得以及时整合 要求程序员及时把最新代码放入代码库 用脚本语言和编译/链接工具实现 BVT Build Verification Test 对Build进行验证 Blocking Bug 让Build无法完成的问题 BVT中发现的问题 答案： 因为自己昨天的代码check-in， 造成Blocking Bug. 为什么？ 答案： 因为自己昨天的代码check-in， 造成Blocking Bug. 因为每天的Build是所有人当天工作的基础： 程序员需要Build验证与其他模块的接口 测试需要Build发现新Bug，并验证新Build中已解决 的Bug 解决问题，并对今天的Build打Patch。 经历对Build的提心吊胆和争分夺秒之后，第 一件事做什么？ 经历对Build的提心吊胆和争分夺秒之后，第一 件事做什么？ 答案：打开缺陷跟踪工具，查看指定给自己的 Bug，解决高优先度的Bug。因为质量重于 新功能。 从版本控制工具中Check out代码 修改代码（解决Bug或实现新功能） 取得版本工具中最新变化，在本机Build和单元测试 请开发组同事作Code Review Check in代码 Raid/BMS 测试人员 邮件系统 源代码 服务器 发布服务器 专家会诊开发人员 Builder 1. 拿到新的版本 2. 记录bug 3. 得到新的bug 4. 解决Bug 5. Check in 请求 6. 批准 7. Check in 8. 拿到最新源代码 9. 编译 10. 验证bug解决 并关闭 测试人员第一件事做什么？ 答案：打开Raid/BMS，查看指定给自己的 Bug，验证已解决的Bug。 根据测试用例检验今天的Build 在Raid/BMS中记录新发现的Bug 参加者：项目经理和开发组长、测试组长 通过Raid/BMS评估每个未解决的Bug 决定Bug优先度 可否等到下个里程碑或版本解决？ 谁来解决 预测项目实际进度和发布时间 缺陷走势图 构造: daily build 开发: 解决blocking bugs, 实现功能, check- out, code review, check-in 测试: BVT, 使用测试用例进行测试 项目经理/组长: 专家会诊 以前解决过的问题发布时又出现了，需要 返工 无法预估发布时间 过早发布，带来质量 和维护问题 测试发现的问题被忘却或不了了之 无法衡量测试员和开发员的工作 程序中的问题往往在发布后才发现 文档与程序脱节，文档成为程序结果的 描述 项目组把写文档看成负担 开发人员各自为战，进行整合时发现模块衔 接中的严重问题 需要作大的改动 没有保管好公司以往的版本和代码，无法满 足用户对旧版本的更改要求 开发人员离职对项目带来很