开始学习微软的缺陷管理方法(3)

发表于:2011-11-02来源:未知作者:领测软件测试网采编点击数: 标签:缺陷管理
缺陷来源; 解决方案; 运行环境; 缺陷关联; 附件; 附图; 缺陷细节 6. Bug 的严重程度 1)死机,数据丢失,主要功能组完全丧失,系统悬挂; 2) 主要功能丧失,

  缺陷来源; 解决方案; 运行环境; 缺陷关联; 附件; 附图; 缺陷细节

  6. Bug 的严重程度

  1)死机,数据丢失,主要功能组完全丧失,系统悬挂;

  2) 主要功能丧失,或致命的错误声明

  3) 次要功能丧失,不太严重,如提示信息不太准确 ;

  4) 微小的问题,对功能几乎没有影响,仍可使用.

  7. 激活的Bug数量的趋势

  代码完成前:很少; 代码完成后:增长很快; 接近Beta: 下降; 接近RC: 奔向零 ;

  产品质量和里程碑的信号

  每天新建的Bug 与 修正的 Bug 相比较 ; Active 状态 Bug 的总数

  四.微软的一天

  1.每日构造Daily Build

  Daily Build是所有工作的核心,而且是在半夜自动启动。

  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。

  答案:打开缺陷跟踪工具,查看指定给自己的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. 根据需要调整团队结构

  产品设计考虑问题

  1 Who : 为谁设计,用户是谁?不能为所有人服务;

  2 What:要解决哪些用户问题?

  3 Why: 为什麽要解决这些用户问题?例:曲别针,餐馆中尖头筷子,一正一反可供参考。

  设计之源:在于用户;设计之本:要满足用户需求,方便用户使用,并且使生产制造工艺尽可能简单;不能把软件设计单纯当作自我技术水准,个人才智表达的方式。(用户场景: 用户使用软件的特定环境或场合。)

  The Program Management Role Today

  Development team organization chart:

  Marketing, Deve Lead, PM, Test Lead, Documentation

  Developer: Mostly C.S. majors; Input: Spec, Bugs;Output: Source Code;Resolve build breaks;Conduct unit testing; Buddy Testing; Reality check: what's possible

  Testers: Many different majors;Input:Spec, Compiled Code;Output:Bugs, Sign-off;Types of Testing:

  Manual vs Automated(regression), Basic vs Functional vs Stress;Performance & Reliability;Buddy Testing

  Marketing: Mostly Business majors;Input: Market Research ;Outputs: Long-term Planning , Advertising, Packaging, Distribution Channels, Interaction with Sales groups

  Documentation: Input: Specs, Product;Outputs: Books, Online Help, Training classes, online tutorials

  PM : not have authority;Plans & Specs reviewed by marketing, dev lead, test lead and vp;everyone has thr right to ask question, and could disagree with it.

  What do Program Managers do?

  1) Design the product;2) Write product plans and specifications;3)Drive day-to-day development process; 4) Triage; 5)Coordinate with other departments - location, Lrgal, other product groups, etc. 6) Communicate project status & schhedule; 7) Hold Post-Mortem

  Design PM focus on 1)-4)aspects;Release PM address on 3)-7) aspects.

  7 key PM Roles

  1 Design the product

原文转自:http://www.ltesting.net