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. 根据需要调整团队结构

http://www.51testing.com/html/58/471.html