微软Bug管理

　　一.团队组织

　　1.常见问题

　　没有人愿意做测试

　　觉得养不起那么多测试人员

　　开发人员不遵循规范，随心所欲

　　项目经理事必躬亲，分身乏术

　　2.微软团队模型

　　各角色的职责

　　二.项目管理

　　1.常见问题

　　无法决定项目所需的资源(人力和预算)

　　无法决定项目的进度表

　　无法控制外包项目的进度和质量

　　2.微软项目管理-- 多里程碑式流程

　　每个里程碑完成部分功能

　　便于团队集中力量完成一个又一个功能

　　提供多个机会以适应需求的更改

　　如何完成一个里程碑

　　步骤一： 达成共识

　　基本完成需求调研和分析 (产品经理负责)

　　确定大方向和长中短期目标

　　所有角色都参与讨论并真正认同结论

　　产生的文档：

　　常见用户情景：覆盖80%以上功能

　　Vision：言简意赅地说明大方向，并有激励团队的作用

　　步骤二： 完成项目计划

　　编写详细的功能规范(项目经理负责)

　　在编程前想清楚所有功能流程，并引导用户明确需求

　　所有角色都参与审阅功能规范

　　制订开发计划和进度表(开发团队)

　　制订测试计划和进度表(测试团队)

　　分配资源(人力和预算)

　　形成项目综合计划和综合进度表

　　产生的文档：

　　功能规范，开发计划，测试计划(用例)，项目综合计划

　　开发进度表，测试进度表，综合进度表

　　步骤三： 完成功能

　　开发人员分别完成自己的功能

　　使用版本控制工具

　　使程序员及时check out和check in，避免积累大量代码

　　及时进行模块间的整合，及时发现问题(daily build)

　　对每一项可测试的功能进行测试，无需等待

　　使用测试用例工具，对功能进行完整和重复的检验

　　使用BMS进行缺陷跟踪

　　记录所有程序问题

　　实现解决Bug的自动流程

　　按照综合进度表不断检查进度

　　使用的工具：

　　版本控制工具 VSS

　　缺陷跟踪工具 Raid/BMS

　　测试用例管理工具

　　步骤四： 稳定与发布

　　测试组全面地测试功能，包括性能和稳定性

　　开发组全力配合解决Bug

　　使用BMS进行

　　监测质量情况

　　预测发布日期

　　专家会诊机制：

　　决定Bug的优先度

　　决定哪些Bug可以等到下个里程碑或版本中解决

　　决定由谁解决某个Bug

　　使用的工具：

　　版本控制工具 VSS

　　缺陷跟踪工具 BMS

　　测试用例管理工具

　　三. 微软的开发管理经验：100%以Bug为核心

　　1.Bug 及常见类型

　　功能未实现，和规格说明书不一致

　　不能工作：死机，没反应

　　不兼容

　　边界条件

　　界面、消息、提示不够准确，不友好

　　把尚未完成的工作也作为一个Bug

　　文档与帮助信息中的缺陷也是Bug

　　2.RAID/BMS的基本功能

　　完整的Bug数据库

　　整个产品组的中央记录和控制

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