产品质量的基石讲义

产品质量的基石

——微软Bug管理日程微软工程管理团队组织工程流程管理缺陷管理开发管理的切面透视–微软的一天如何提高软件开发管理的质量团队组织常见问题没有人愿意做测试觉得养不起那么多测试人员开发人员不遵循标准，随心所欲工程经理事必躬亲，分身乏术微软团队模型工程经理开发测试发布经理用户教育产品经理Communication各角色的职责角色工程经理开发测试产品经理用户教育发布经理职责编写功能标准，协调各角色关系按照功能标准编写软件质量控制客户联系的桥梁，进行需求分析让产品容易使用保证产品顺利发布工程管理常见问题无法决定工程所需的资源〔人力和预算〕无法决定工程的进度表无法控制外包工程的进度和质量微软工程管理

--多里程碑式流程时间功能里程碑1里程碑2里程碑3多里程碑式管理每个里程碑完成局部功能便于团队集中力量完成一个又一个功能提供多个时机以适应需求的更改透视每个里程碑IENVSOGINNIPLANIGNNDEVLOPIGENSTABILZNGII1.达成共识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的严重程度死机，数据丧失，主要功能组完全丧失，系统悬挂主要功能丧失，导致严重的问题，或致命的错误声明次要功能丧失，不太严重，如提示信息不太准确微小的问题，对功能几乎没有影响，产品及属性仍可使用.如有个错别字激活的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和单元测试请开发组同事作CodeReviewCheckin代码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,使用测试用例进行测试工程经理/组长:专家会诊微软的做法解决了那些常见问题？质量问题以前解决过的问题发布时又出现了，需要返工无法预估发布时间–

过早发布，带来质量和维护问题测试发现的问题被忘却或不了了之无法衡量测试员和开发员的工作程序中的问题往往在发布后才发现文档管理问题文档与程序脱节，文档成为程序结果的描述工程组把写文档看成负担团队协调问题开发人员各自为战，进行整合时发现模块衔接中的严重问题–需要作大的改动没有保管好公司以往的版本和代码，无法满足用户对旧版本的更