微软bug管理.docx
- 文档编号:18599377
- 上传时间:2023-08-20
- 格式:DOCX
- 页数:10
- 大小:137.07KB
微软bug管理.docx
《微软bug管理.docx》由会员分享,可在线阅读,更多相关《微软bug管理.docx(10页珍藏版)》请在冰点文库上搜索。
微软bug管理
[微软]产品质量的基石-微软Bug管理
微软中国高级架构师微创软件研发部经理蔡锫
一.团队组织
1.常见问题
∙没有人愿意做测试
∙觉得养不起那么多测试人员
∙开发人员不遵循规范,随心所欲
∙项目经理事必躬亲,分身乏术
2.微软团队模型
各角色的职责
角色
职责
项目经理
编写功能规范,协调各角色关系
产品经理
客户联系的桥梁,进行需求分析
用户教育
让产品容易使用
发布经理
保证产品顺利发布
二.项目管理
1.常见问题
∙无法决定项目所需的资源(人力和预算)
∙无法决定项目的进度表
∙无法控制外包项目的进度和质量
2.微软项目管理--多里程碑式流程
∙每个里程碑完成部分功能
∙便于团队集中力量完成一个又一个功能
∙提供多个机会以适应需求的更改
如何完成一个里程碑
∙步骤一:
达成共识
∙基本完成需求调研和分析(产品经理负责)
∙确定大方向和长中短期目标
∙所有角色都参与讨论并真正认同结论
∙产生的文档:
o常见用户情景:
覆盖80%以上功能
oVision:
言简意赅地说明大方向,并有激励团队的作用
∙步骤二:
完成项目计划
o编写详细的功能规范(项目经理负责)
o在编程前想清楚所有功能流程,并引导用户明确需求
o所有角色都参与审阅功能规范
o制订开发计划和进度表(开发团队)
o制订测试计划和进度表(测试团队)
o分配资源(人力和预算)
o形成项目综合计划和综合进度表
o产生的文档:
功能规范,开发计划,测试计划(用例),项目综合计划
开发进度表,测试进度表,综合进度表
∙步骤三:
完成功能
∙开发人员分别完成自己的功能
∙使用版本控制工具
∙使程序员及时checkout和checkin,避免积累大量代码
∙及时进行模块间的整合,及时发现问题(dailybuild)
∙对每一项可测试的功能进行测试,无需等待
∙使用测试用例工具,对功能进行完整和重复的检验
∙使用BMS进行缺陷跟踪
∙记录所有程序问题
∙实现解决Bug的自动流程
∙按照综合进度表不断检查进度
∙使用的工具:
o版本控制工具VSS
o缺陷跟踪工具Raid/BMS
o测试用例管理工具
∙步骤四:
稳定与发布
∙测试组全面地测试功能,包括性能和稳定性
∙开发组全力配合解决Bug
∙使用BMS进行
o监测质量情况
o预测发布日期
∙专家会诊机制:
o决定Bug的优先度
o决定哪些Bug可以等到下个里程碑或版本中解决
o决定由谁解决某个Bug
∙使用的工具:
o版本控制工具VSS
o缺陷跟踪工具BMS
o测试用例管理工具
三.微软的开发管理经验:
100%以Bug为核心
1.Bug及常见类型
∙功能未实现,和规格说明书不一致
∙不能工作:
死机,没反应
∙不兼容
∙边界条件
∙界面、消息、提示不够准确,不友好
∙把尚未完成的工作也作为一个Bug
∙文档与帮助信息中的缺陷也是Bug
2.RAID/BMS的基本功能
∙完整的Bug数据库
∙整个产品组的中央记录和控制
∙强大的查询功能,有效地跟踪项目的状态
∙所有的记录无法删除,对于每个记录只能一直添加内容
∙丰富的报表功能,为产品发布提供判断标准
3.Bug记录中的有效信息
∙状态
∙负责人
∙问题种类
∙严重级
∙优先级
∙修改时间
∙登记时间
∙缺陷来源
∙解决方案
∙运行环境
∙缺陷关联
∙附件
∙附图
∙缺陷细节
4.Bug的严重程度
∙死机,数据丢失,主要功能组完全丧失,系统悬挂
∙主要功能丧失,导致严重的问题,或致命的错误声明
∙次要功能丧失,不太严重,如提示信息不太准确
∙微小的问题,对功能几乎没有影响,产品及属性仍可使用.如有个错别字
5.激活的Bug数量的趋势
∙代码完成前:
很少
∙代码完成后:
增长很快
∙接近Beta:
下降
∙接近RC:
奔向零
∙产品质量和里程碑的信号
∙每天新建的Bug与修正的Bug相比较
∙Active状态Bug的总数
四.微软的一天
1.让我们看看项目中每个角色的一天是如何度过的
∙开发
∙测试
∙项目经理
注:
里程碑的每个阶段每个角色的工作有不同侧重点,我们以“完成功能”阶段为例
微软的一天从几点开始?
答案:
半夜
为什么?
因为DailyBuild是所有工作的核心,而且是在半夜自动启动。
每日构造DailyBuild
∙你知道自己所用Windows的版本号吗?
∙DailyBuild的意义:
o模块得以及时整合
o要求程序员及时把最新代码放入代码库
∙用脚本语言和编译/链接工具实现
∙BVTBuildVerificationTest
o对Build进行验证
∙BlockingBug
o让Build无法完成的问题
oBVT中发现的问题
2.程序员每天上班前最担心什么?
答案:
因为自己昨天的代码check-in,造成BlockingBug.
为什么?
因为每天的Build是所有人当天工作的基础:
程序员需要Build验证与其他模块的接口
测试需要Build发现新Bug,并验证新Build中已解决的Bug
有BlockingBug怎么办?
解决问题,并对今天的Build打Patch。
开发人员的正事
经历对Build的提心吊胆和争分夺秒之后,第一件事做什么
答案:
打开缺陷跟踪工具,查看指定给自己的Bug,解决高优先度的Bug。
因为质量重于新功能。
接下来,开发人员会…
从版本控制工具中Checkout代码
修改代码(解决Bug或实现新功能)
取得版本工具中最新变化,在本机Build和单元测试
请开发组同事作CodeReview
Checkin代码
3.测试人员第一件事做什么?
答案:
打开Raid/BMS,查看指定给自己的Bug,验证已解决的Bug。
接下来,测试人员会…
∙根据测试用例检验今天的Build
∙在Raid/BMS中记录新发现的Bug
4.专家会诊
∙参加者:
项目经理和开发组长、测试组长
∙通过Raid/BMS评估每个未解决的Bug
o决定Bug优先度
o可否等到下个里程碑或版本解决?
o谁来解决
∙预测项目实际进度和发布时间
缺陷走势图
5.回顾微软的一天
∙构造:
dailybuild
∙开发:
解决blockingbugs,实现功能,check-out,codereview,check-in
∙测试:
BVT,使用测试用例进行测试
∙项目经理/组长:
专家会诊
6.微软的做法解决了那些常见问题?
质量问题
∙以前解决过的问题发布时又出现了,需要返工
∙无法预估发布时间过早发布,带来质量和维护问题
∙测试发现的问题被忘却或不了了之
∙无法衡量测试员和开发员的工作
∙程序中的问题往往在发布后才发现
文档管理问题
∙文档与程序脱节,文档成为程序结果的描述
∙项目组把写文档看成负担
团队协调问题
∙开发人员各自为战,进行整合时发现模块衔接中的严重问题需要作大的改动
∙没有保管好公司以往的版本和代码,无法满足用户对旧版本的更改要求
∙开发人员离职对项目带来很大冲击,没有人知道代码在哪,或无法读懂
五.提高软件管理的步骤
1.使用Raid/BMS,将流程管理自动化
2.使用测试用例管理工具
3.使用文档管理工具
4.使用版本控制工具,进行DailyBuild
5.建立代码标准
6.建立CodeReview机制
7.建立专家会诊机制
8.建立团队沟通机制
9.根据需要调整团队结构
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 微软 bug 管理
![提示](https://static.bingdoc.com/images/bang_tan.gif)