微软测试培训心得体会（转）

本文载自：http://thlsky.spaces.live.com/Blog/cns!DCC21ED5B3B0AB33!239.entry

微软测试培训心得体会

讲师经历介绍:

2004年之前在信产部直属某邮电所工作,开发过linux电信工控机系统,为linux2.2内核写过热插拔驱动. 因单位的产品质量问题而主动请缨创建测试团队.

2004年进入微软亚洲研究院,带领Exchange2007中国团队的Test Team(一只全STE'D队伍)

一.微软的文化

质量第一：宁愿砍项目或拖进度,不能把质量不行的产品放出去,不能砸公司牌子(在内部砍了不少项目,讲师形容是鲜血淋漓)
           发布前,1级与2级bug一定全部改掉(2级是指包括所有需求文档上定义的特性错误,界面错误码也算2级)
内部竟争：每个项目自负盈亏,微软内部竟争激烈(exchange2007这个项目是中国亚洲工程院从MS新加坡和MS印度手中抢下来的)
执行力：定了的规范与流程保证一定执行,不搞空架子
鼓励"尽量多做一点,减少别人的麻烦"
不鼓励"少做一点,导致增加别人的麻烦"
         体现在工作接口上,比如函数,模块,邮件,让接口人用起来很舒服,通畅
设备可以买来,时间买不来
          体现在申请机器里,拿机器和软硬件安装均不需要工程师自已去做(节省一两个小时)全部由保安和信息部门搞定,工程师一打开机器就可以工作了
         工程师可以有多台机器,同时跑不同的测试任务(不同级别的回归测试)
承诺：上班不用考勤,但是到了时间就必须交东西

bug文化:

       1.全民找bug,项目负责人是副总裁级别人物,也经常找bug,天天关注bug情况
       2.各种奖励方式鼓励找bug
            A.找bug最多奖

            B.找bug质量最高奖
            C.解决bug最多奖
            D.开发人员中找到最多bug奖
        3.exchange2007到了项目后期,找到一个bug奖8美元(项目的领导自掏腰包)
           发布之后,找到一个bug奖100美元(公司给50美元,bug责任人罚出50美元)
            每个里程碑,都有一次找bug比赛,奖励规定时间内找到bug最多的团队



二.微软的开发组织结构

产品组是由一个个的特性小组组成(类似于我们的功能小组)
特性小组的组成是由一个PM(Program Manager程序经理),一个DEV(程序),一个TEST(测试)组成
PM 程序经理负责功能定义,写功能定义文档PM-SPEC(类似于我们的策划人员)
DEV开发人员 负责功能实现,写实现文档DEV-SPEC
TEST 测试人员 负责保障质量,写测试文档TEST-SPEC

DEV leader 开发组长

TEST leader 测试组长

DEV Manager 开发经理

TEST Manager 测试经理

Product Unit Manager 产品单元经理 -相当于我们的项目经理,负责人
PM没有人事权,绩效权利,虽然挂了一个Manager的名,其实就是需求人员
Exchange 2007这个产品组 测试与开发人员比例为1:1
其它组大部分是测试:开发为2:1
Exchange 2007这个产品是由三支团队共同开发,各负责一部份(美国,中国,印度,讲师是带中国的测试团队)

三.微软的各种平台

这些平台是积累和复用和保障流程规范执行的基础
BUG库
    所有项目人员都很关心这个库,所有的bug在24小时内必定有人去处理(不一定是解决)
CASE库(案例库)
TEST Result库(测试结果库)
    以上都是以数据库形式存储,方便查询统计,形成报告与趋势图,每天所有leader都非常关注这些情况,因为反应了产品的质量情况

Guideline库(规范库,以sharepoint形式存储)
    包括UI Guideline(界面规范)
       UE Guideline(用户体验规范)
       CODE Guideline(代码规范)等等
     测试人员会把这些Guideline都形成自动化测试的检查内容,对产品天天进行检查
     一旦有新的规范需求,有一个比较权威的组就会对其进行审核,加入到规范库中去
     Guideline是公司级的,还有产品级的约束叫checklist,checklist也会形成自动化测试,天天进行检查
    
四.微软的测试

a.测试目的是建立一个质量保障体系
b.把可能自动化的都自动化了,自动化率达到95%以上,包括环境的搭建(不能自动化的多是一些破坏性测试)
c.Exchange 2007的测试人员绝大部分是测试开发人员,据有与程序人员同样的开发水平(待遇各方面也一样)
d.Exchange 2007的测试人员为了检验开发人员写的命令行命令是否正确,把所有的命令行命令又实现了一遍,这也是自动化功能测试与性能,压力测试的复用基础
e.为了解决GUI测试的世界级难题,Exchange 2007测试团队开发了ATO实现了进程内的GUI测试,获得当年的MS EEI(杰出工程贡献奖)
f.白盒测试也实现了自动化,让程序代替人去读程序,整体提高所有测试人员的能力,让每个测试人员都有能力去做白盒测试
g.环境的搭建自动化,实现包括格式化,安装操作系统,安装软件
h.所以的Guideline与checklist都实现了自动化
i.测试人员的代码工作量是开发人员的几倍
j.自动化的目的:提高效率,回归测试,性能测试,压力测试
k.自动化的前提:明确的需求文档,开发能力,平台积累
l.保障bug的有效性,入bug库之前先花5分钟确认是否重复bug

m.测试的最高境界:预防bug

四.微软的需求

1.需求是开发与测试活动的起源,这个一定要做好做细
2.在微软没有概要设计,都是详细设计
3.详细到每个函数接口,提示信息,UI的控件摆放坐标位置都定义清楚
4.有了这么清晰的需求文档PM-SPEC,测试人员可以提前于开发人员把测试用例(Case)写好,成为开发的检验标准
5.如果因为需求文档PM-SPEC的问题,导致开发进度或质量出大问题,PM(需求人员)会被开掉,六个人中的相关人员负责50%责任
6.需求文档PM-SPEC的评审,需要六个人确认(sign off)
       PM      需求负责人,写文档
       TEST    可测性
       DEV     技术难度
       TEST Lead 测试进度影响预估,可测性,总体
       DEV Lead 开发进度影响预估,技术难度,总体
       产品单元经理(等同于我们的项目负责人) 是否符合产品定位,总体
同样DEV-SPEC开发文档和TEST-SPEC测试文档都需要六人signoff
7.需求文档的进度要求不是说写完就可以,而是要六人sign off通过
8.Exchange 2007共有300多篇需求文档PM-SPEC,在不同的里程碑阶段完成
9.需求文档如果要变更,再走一次这个六人sign off的流程
10.需求流程是在平台上执行,六人进行电子签名