《产品质量的基石-微软Bug管理.ppt》由会员分享，可在线阅读，更多相关《产品质量的基石-微软Bug管理.ppt（47页珍藏版）》请在三一办公上搜索。
1、产品质量的基石微软Bug管理,日程,微软项目管理团队组织项目流程管理缺陷管理开发管理的切面透视 微软的一天如何提高软件开发管理的质量,团队组织,常见问题没有人愿意做测试觉得养不起那么多测试人员开发人员不遵循规范，随心所欲项目经理事必躬亲，分身乏术,微软团队模型,项目经理,开发,测试,发布经理,用户教育,产品经理,Communication,各角色的职责,角色项目经理开发测试产品经理用户教育发布经理,职责编写功能规范，协调各角色关系按照功能规范编写软件质量控制客户联系的桥梁，进行需求分析让产品容易使用保证产品顺利发布,项目管理,常见问题无法决定项目所需的资源（人力和预算）无法决定项目的进度表无法
2、控制外包项目的进度和质量,微软项目管理-多里程碑式流程,时间,功能,里程碑 1,里程碑 2,里程碑 3,多里程碑式管理,每个里程碑完成部分功能便于团队集中力量完成一个又一个功能提供多个机会以适应需求的更改,透视每个里程碑,如何完成一个里程碑,步骤一：达成共识基本完成需求调研和分析（产品经理负责）确定大方向和长中短期目标所有角色都参与讨论并真正认同结论产生的文档：常见用户情景：覆盖80%以上功能Vision：言简意赅地说明大方向，并有激励团队的作用,如何完成一个里程碑,步骤二：完成项目计划编写详细的功能规范（项目经理负责）在编程前想清楚所有功能流程，并引导用户明确需求所有角色都参与审阅功能规范制
3、订开发计划和进度表（开发团队）制订测试计划和进度表（测试团队）分配资源（人力和预算）形成项目综合计划和综合进度表产生的文档：功能规范，开发计划，测试计划（用例），项目综合计划开发进度表，测试进度表，综合进度表,如何完成一个里程碑,步骤三：完成功能开发人员分别完成自己的功能使用版本控制工具使程序员及时check out和check in，避免积累大量代码及时进行模块间的整合，及时发现问题（daily build）对每一项可测试的功能进行测试，无需等待使用测试用例工具，对功能进行完整和重复的检验使用BMS进行缺陷跟踪记录所有程序问题实现解决Bug的自动流程按照综合进度表不断检查进度使用的工具：版本
4、控制工具 VSS缺陷跟踪工具 Raid/BMS测试用例管理工具,如何完成一个里程碑,步骤四：稳定与发布测试组全面地测试功能，包括性能和稳定性开发组全力配合解决Bug使用BMS进行监测质量情况预测发布日期专家会诊机制：决定Bug的优先度决定哪些Bug可以等到下个里程碑或版本中解决决定由谁解决某个Bug使用的工具：版本控制工具 VSS缺陷跟踪工具 BMS测试用例管理工具,微软的开发管理经验：100%以Bug为核心,测试人员,Raid/BMS,项目经理,其他人员,构造员,开发人员,VSS,构造服务器,发布服务器,Exchange,100%由缺陷跟踪工具驱动,Bug 及常见类型,功能未实现，和规格说明
5、书不一致不能工作：死机，没反应不兼容边界条件界面、消息、提示不够准确，不友好把尚未完成的工作也作为一个Bug文档与帮助信息中的缺陷也是Bug,RAID/BMS的基本功能,完整的Bug数据库整个产品组的中央记录和控制强大的查询功能，有效地跟踪项目的状态所有的记录无法删除，对于每个记录只能一直添加内容丰富的报表功能，为产品发布提供判断标准,Bug 记录中的有效信息,状态负责人问题种类严重级优先级修改时间登记时间缺陷来源,解决方案运行环境缺陷关联附件附图缺陷细节,Bug 的严重程度,死机，数据丢失，主要功能组完全丧失，系统悬挂主要功能丧失，导致严重的问题，或致命的错误声明次要功能丧失，不太严重，如提
6、示信息不太准确微小的问题，对功能几乎没有影响，产品及属性仍可使用.如有个错别字,激活的Bug数量的趋势,代码完成前：很少代码完成后：增长很快接近Beta:下降接近RC:奔向零产品质量和里程碑的信号每天新建的Bug 与 修正的 Bug 相比较.Active 状态 Bug 的总数,微软的一天,让我们看看项目中每个角色的一天是如何度过的开发测试项目经理注：里程碑的每个阶段每个角色的工作有不同侧重点，我们以“完成功能”阶段为例,微软的一天从几点开始？,微软的一天从几点开始？,答案：半夜为什么？,微软的一天从几点开始？,答案：半夜因为Daily Build是所有工作的核心，而且是在半夜自动启动。,每日构
7、造,你知道自己所用Windows的版本号吗？Daily Build的意义：模块得以及时整合要求程序员及时把最新代码放入代码库用脚本语言和编译/链接工具实现BVT Build Verification Test对Build进行验证Blocking Bug让Build无法完成的问题BVT中发现的问题,程序员每天上班前最担心什么？,程序员每天上班前最担心什么？,答案：因为自己昨天的代码check-in，造成Blocking Bug.为什么？,程序员每天上班前最担心什么？,答案：因为自己昨天的代码check-in，造成Blocking Bug.因为每天的Build是所有人当天工作的基础：程序员需要Bu
8、ild验证与其他模块的接口测试需要Build发现新Bug，并验证新Build中已解决的Bug,有Blocking Bug怎么办？,解决问题，并对今天的Build打Patch。,开发人员的正事,经历对Build的提心吊胆和争分夺秒之后，第一件事做什么？,开发人员的正事,经历对Build的提心吊胆和争分夺秒之后，第一件事做什么？答案：打开缺陷跟踪工具，查看指定给自己的Bug，解决高优先度的Bug。因为质量重于新功能。,接下来，开发人员会,从版本控制工具中Check out代码修改代码（解决Bug或实现新功能）取得版本工具中最新变化，在本机Build和单元测试请开发组同事作Code ReviewCh
9、eck in代码,Raid/BMS,测试人员,邮件系统,源代码服务器,发布服务器,专家会诊,开发人员,Builder,1.拿到新的版本,2.记录bug,3.得到新的bug,4.解决Bug,5.Check in 请求,6.批准,7.Check in,8.拿到最新源代码,9.编译,10.验证bug解决 并关闭,Check-in 过程,测试人员第一件事做什么？,测试人员第一件事做什么？,答案：打开Raid/BMS，查看指定给自己的Bug，验证已解决的Bug。,接下来，测试人员会,根据测试用例检验今天的Build在Raid/BMS中记录新发现的Bug,专家会诊,参加者：项目经理和开发组长、测试组长通过
10、Raid/BMS评估每个未解决的Bug决定Bug优先度可否等到下个里程碑或版本解决？谁来解决预测项目实际进度和发布时间,缺陷走势图,回顾微软的一天,构造:daily build开发:解决blocking bugs,实现功能,check-out,code review,check-in测试:BVT,使用测试用例进行测试项目经理/组长:专家会诊,微软的做法解决了那些常见问题？,质量问题,以前解决过的问题发布时又出现了，需要返工无法预估发布时间 过早发布，带来质量和维护问题测试发现的问题被忘却或不了了之无法衡量测试员和开发员的工作程序中的问题往往在发布后才发现,文档管理问题,文档与程序脱节，文档成为程序结果的描述项目组把写文档看成负担,团队协调问题,开发人员各自为战，进行整合时发现模块衔接中的严重问题 需要作大的改动没有保管好公司以往的版本和代码，无法满足用户对旧版本的更改要求开发人员离职对项目带来很大冲击，没有人知道代码在哪，或无法读懂,提高软件管理的步骤,提高软件开发管理的步骤,使用Raid/BMS，将流程管理自动化使用测试用例管理工具使用文档管理工具使用版本控制工具，进行Daily Build建立代码标准建立Code Review机制建立专家会诊机制建立团队沟通机制根据需要调整团队结构,Q&A,
