|
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.微软的做法解决了那些常见问题?
质量问题
以前解决过的问题发布时又出现了,需要返工 ;无法预估发布时间 过早发布,带来质量和维护问题
测试发现的问题被忘却或不了了之;无法衡量测试员和开发员的工作;程序中的问题往往在发布后才发现
文档管理问题
文档与程序脱节,文档成为程序结果的描述; 项目组把写文档看成负担
团队协调问题
开发人员各自为战,进行整合时发现模块衔接中的严重问题 需要作大的改动
没有保管好公司以往的版本和代码,无法满足用户对旧版本的更改要求; 开发人员离职对项目带来很大冲击,没有人知道代码在哪,或无法读懂 |
|