微软的缺陷管理方式(2)

发表于:2014-12-24来源:uml.org.cn作者:不详点击数: 标签:缺陷
登记时间 缺陷来源 解决方案 运行环境 缺陷关联 附件 附图 缺陷细节 4.Bug 的严重程度 死机,数据丢失,主要功能组完全丧失,系统悬挂 主要功能丧失,

  登记时间

  缺陷来源

  解决方案

  运行环境

  缺陷关联

  附件

  附图

  缺陷细节

  4.Bug 的严重程度

  死机,数据丢失,主要功能组完全丧失,系统悬挂

  主要功能丧失,导致严重的问题,或致命的错误声明

  次要功能丧失, 不太严重,如提示信息不太准确

  微小的问题,对功能几乎没有影响,产品及属性仍可使用. 如有个错别字

  5.激活的Bug数量的趋势

  代码完成前:很少

  代码完成后:增长很快

  接近Beta: 下降

  接近RC: 奔向零

  产品质量和里程碑的信号

  每天新建的Bug 与 修正的 Bug 相比较

  Active 状态 Bug 的总数

  四.微软的一天

  1. 让我们看看项目中每个角色的一天是如何度过的

  开发

  测试

  项目经理

  注:里程碑的每个阶段每个角色的工作有不同侧重点,我们以“完成功能”阶段为例

  微软的一天从几点开始?

  答案:半夜

  为什么?

  因为Daily Build是所有工作的核心,而且是在半夜自动启动。

  每日构造Daily Build

  你知道自己所用Windows的版本号吗?

  Daily Build的意义:

  模块得以及时整合

  要求程序员及时把最新代码放入代码库

  用脚本语言和编译/链接工具实现

  BVT Build Verification Test

  对Build进行验证

  Blocking Bug

  让Build无法完成的问题

  BVT中发现的问题

  2.程序员每天上班前最担心什么?

  答案:因为自己昨天的代码check-in,造成Blocking Bug.

  为什么?

  因为每天的Build是所有人当天工作的基础:

  程序员需要Build验证与其他模块的接口

  测试需要Build发现新Bug,并验证新Build中已解决的Bug

  有Blocking Bug怎么办?

  解决问题,并对今天的Build打Patch。

  开发人员的正事

  经历对Build的提心吊胆和争分夺秒之后,第一件事做什么

  答案:打开缺陷跟踪工具,查看指定给自己的Bug,解决高优先度的Bug。因为质量重于新功能。

  接下来,开发人员会…

  从版本控制工具中Check out代码

  修改代码(解决Bug或实现新功能)

  取得版本工具中最新变化,在本机Build和单元测试

  请开发组同事作Code Review

  Check in代码

  3.测试人员第一件事做什么?

  答案:打开Raid/BMS,查看指定给自己的Bug,验证已解决的Bug。

  接下来,测试人员会…

  根据测试用例检验今天的Build

  在Raid/BMS中记录新发现的Bug

  4.专家会诊

  参加者:项目经理和开发组长、测试组长

  通过Raid/BMS评估每个未解决的Bug

  决定Bug优先度

  可否等到下个里程碑或版本解决?

  谁来解决

  预测项目实际进度和发布时间

  缺陷走势图

  5.回顾微软的一天

  构造: daily build

  开发: 解决blocking bugs, 实现功能, check-out, code review, check-in

  测试: BVT, 使用测试用例进行测试

  项目经理/组长: 专家会诊

  6.微软的做法解决了那些常见问题?

  质量问题

  以前解决过的问题发布时又出现了,需要返工

  无法预估发布时间 过早发布,带来质量和维护问题

  测试发现的问题被忘却或不了了之

  无法衡量测试员和开发员的工作

  程序中的问题往往在发布后才发现

  文档管理问题

  文档与程序脱节,文档成为程序结果的描述

  项目组把写文档看成负担

  团队协调问题

  开发人员各自为战,进行整合时发现模块衔接中的严重问题 需要作大的改动

原文转自:http://www.uml.org.cn/Test/200410191.htm