微软产品测试管理.ppt

微软软件测试,陈宜微软全球技术中心,议程,软件测试概述软件测试组测试计划和级别Bug的发现和管理,I软件测试概述,什么是软件测试测试的目的与任务软件质量的定义测试与软件成本测试部分常用术语,什么是软件测试?,质量保证-系统的监督和评估项目的各个方面以确保满足质量标准测试是分析并确定产品是否满足客户的需求和期望的所有活动,测试的目的与任务,目的-保证软件质量，确保产品满足设计的要求和客户的需求，同时降低软件的开发成本和维护成本，并最终签发(Signoff)产品质量任务根据特性规格说明制定测试计划开发必要的测试工具编写测试用例执行系统、全面、深入的测试，在开发过程中找出所有可能存在的Bug跟踪并管理产品质量,定期报告质量状态负责最终的发布认可(Signoff),测试与软件成本,成本越早发现bug，修正的机会越大,开发和后期维护的代价越小Specreview编码阶段Beta阶段本地化发布后质量越高，软件发布后维护费用越低,部分常用术语,QA-QualityAssurance质量保证Bug-缺陷，问题BlockingBugShowStopperBug/ReleaseKiller-致命问题Milestone-里程碑TestCase-测试用例StressTest-附压测试,BVT-BuildVerificationTestAd-hoc测试-随机测试BuddyTestDogFoodZBB(ZeroBugBounce)ZBR(ZeroBugRelease)RTM/RTW,II软件测试组,微软测试组在整个项目中的位置与程序员的关系与程序经理的关系测试Team的主要职责测试组成员的职责,微软测试组在整个项目中的位置,和设计组,开发组及用户教育等并列的队伍测试组负责产品的质量控制测试人员和开发人员的比例大约是1：1,与程序员的关系,测试组不是开发组的助手，合作又各司其职程序员不能写完代码扔过墙，等待测试工程师找到所有的BugRAID是桥梁对有分歧的Bug程序员不能擅自关闭测试人员对发现的Bug要尽可能提供详细的信息,与程序经理的关系,没有隶属关系，合作又各司其职程序经理提供详细的规格说明程序经理要参与Review测试计划测试人员要报告测试状态及产品状态,测试队伍的主要职责,测试队伍的组成经理，组长，测试工程师主要职责测试计划测试测试过程项目与资源管理交流与业务,测试工程师的主要责任,创作相关的测试计划和测试用例设计或改编相关的测试工具识别可自动测试的区域参与组内的测试计划和测试用例以及测试脚本分析工作手动自动测试Ad-Hoc测试按照需求规格说明查证并验证各项功能发现并报告Bug，更踪Bug状态评估Bug对产品其它区域的主要影响。,测试组长的主要责任,确定测试的策略参与对整个产品的完整测试计划的制定参与并管理测试评估Bug对用户的影响，推荐Work-Around.独立的跟踪关键Bug的状态管理测试工作和对应的资源.参与面试新人交流状态和存在的问题，并驱动问题的解决促进组内的对间接问题的交流.,测试经理的主要责任,定义时间进度表定义质量标准参加BugTriageSignoff产品发起和计划长期的测试过程，使之规范化积极开发测试人员的技术技能.组建测试队伍，雇用测试工程师合理安排各种资源.负责制定产品测试所需的预算,III测试计划和级别,测试计划的主要内容测试级别,测试计划的主要内容2-1,引言背景信息质量目标责任测试的方法论,测试计划的主要内容2-2,Milestone的处理测试文档自动测试策略集成测试策略API测试策略性能测试Performance(Benchmark)Testing测试资源的规划,兼容测试AdHoc测试策略本地化测试策略全球化测试策略Beta策略ReleaseCriteria对第三方的依赖测试周期：与项目的里程碑配合,测试级别,单元测试-针对单独代码部分进行的测试子程序简单函数组件测试-测试多个单元和数据对象间的互操作性被调用的Subroutines,Data,etc.集成测试-测试集成组件的互操作性Exe和Dll系统测试-测试系统的鲁棒性和与外部系统的交互性附压/性能测试系统安装/应用程序的兼容性,CoffeeBreak!,IVBug的发现和管理,什么是Bug及常见类型RAID/BMS有效地报告BugBug的严重程度和优先级Bug的处理BugTriageActiveBug数量的趋势,Bug及常见类型,功能未实现，和规格说明书不一致不能工作：死机，没反应不兼容边界条件界面、消息、提示不够准确，不友好把尚未完成的工作也作为一个Bug文档与帮助信息中的缺陷也是Bug,RAID,RAID是客户端的工具，Bug数据库整个产品组的中央记录和控制丰富的查询功能，有效地跟踪项目的状态，为产品发布提供判断标准准确的定义了描述Bug要用到的属性PostponedBug所有的记录无法删除，对于每个记录只能一直添加内容,报告新Bug,查寻并确认不重复从标题开始可能查找多次最后是查找Bug的描述部分如果找到类似的Bug，检查是否需要加入新的注释。填写标题，简明描述该问题,Bug记录中的有效信息,StatusAssignedToIssueTypeSeverityPriorityChangeDate，ChangeByOpenedDate,By,RevSource,BetaID,Howfound,LanguageResolution:Bydesign,Fixed,Duplicate,NotRepro,WontFixArea，SubAreaPlatform附件附图,报告新Bug-环境,描述系统配置，如：OS内存大小处理器类型浏览器类型和版本其他应用程序,报告新Bug-描述,帮助开发人员再现Bug.组成列出起始参数再现步骤预期和实际的结果已测试的其它有用信息一旦保存所用描述信息将无法修改，只能添加,Bug的严重程度,死机,数据丢失,主要功能组完全丧失,系统悬挂主要功能丧失，导致严重的问题，或致命的错误声明次要功能丧失,不太严重,如提示信息不太准确微小的问题,对功能几乎没有影响，产品及属性仍可使用.如有个错别字,活Bug,新建一个Bug时的状态BugRegression表明Bug等待修正评估开发进度产品质量的重要指标,处理Bug,对Bug的处理结果必须重新分派给报告该Bug的人员对修正的Bug需要确认标准的处理结果：故意的重复已修正无法重现延期修正永不修正外部,解决/关闭Bug,Bug的解决方法=故意的重复无法重现延期修正永不修正外部Bug的解决方法=已修正Bugregression,Bug的Triage,何时TriageTriage成员主持:ProgramManager成员:PM/QA/Dev/LPM,Builderand经理.讨论,要求Fix的理由Fix可能带来的风险Fix要求被拒绝时要采取的行动,ActiveBug数量的趋势,代码完成前：很少代码完成后：增长很快接近Beta:下降接近RC:奔向零产品质量和里程碑的信号每天新建的Bug与修正的Bug相比较.Active状态Bug的总数,Tester,Raid,PM,Others,Builder,Dev,SLMSrv,BldSrv,RlsSrv,ExchangePublicFolder,ABugsLife100%Raiddriven,1.Fileabug,2.Triagethebug,3.Devinvestigatethebug,4.AskCheckin,5.Builderverifypermission,6。OKcheck