51Testing软件测试论坛

标题: Microsoft的测试过程 [打印本页]

作者: 晓诺    时间: 2008-1-16 23:29
标题: Microsoft的测试过程
一.团队组织

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数据库
· 整个产品组的中央记录和控制
·强大的查询功能,有效地跟踪项目的状态
·所有的记录无法删除,对于每个记录只能一直添加内容
·丰富的报表功能,为产品发布提供判断标准

3.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.微软的做法解决了那些常见问题?

质量问题

以前解决过的问题发布时又出现了,需要返工
无法预估发布时间 过早发布,带来质量和维护问题
测试发现的问题被忘却或不了了之
无法衡量测试员和开发员的工作
程序中的问题往往在发布后才发现

文档管理问题

文档与程序脱节,文档成为程序结果的描述
项目组把写文档看成负担

团队协调问题

开发人员各自为战,进行整合时发现模块衔接中的严重问题 需要作大的改动
没有保管好公司以往的版本和代码,无法满足用户对旧版本的更改要求
开发人员离职对项目带来很大冲击,没有人知道代码在哪,或无法读懂

五.提高软件管理的步骤

1. 使用Raid/BMS,将流程管理自动化
2. 使用测试用例管理工具
3. 使用文档管理工具
4. 使用版本控制工具,进行Daily Build
5. 建立代码标准
6. 建立Code Review机制
7. 建立专家会诊机制
8. 建立团队沟通机制
9. 根据需要调整团队结构
作者: 阿妮妲    时间: 2008-1-23 15:03
测试部分,有一些跟我要做的工作一样哦~~~~
作者: scarlett    时间: 2008-1-24 17:31
我觉得像微软那样的测试很难建立。虽然看过这篇文章之后,对微软的测试过程总是向往,要是俺们公司都能是这样的话,软件质量不怕上不去,管理也轻松多了。
但是一看公司的现状,想要开始都挺难。
大家都是一副自扫门前雪,哪管他人事。
所以这也和公司的上层领导的决策以及氛围和团队精神有一定关系。
万事开头难啊。
一根筷子起不了什么作用啊,得大家齐心协力。
作者: baizhudan    时间: 2008-1-24 17:47
XBOX360是如何通过测试的?真滑天下之大稽
作者: syang0517    时间: 2008-1-25 16:53
收藏了 不要把这样的好帖子 沉了 顶一个
作者: 西门一笑    时间: 2008-1-25 22:09
相当之规范,大公司就是不一样
作者: liweiwei0104    时间: 2008-2-3 04:09
需求中!谢谢您的慷慨提供!




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2