产品质量的基石——微软Bug管理

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