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

　　登记时间

　　缺陷来源

　　解决方案

　　运行环境

　　缺陷关联

　　附件

　　附图

　　缺陷细节

　　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