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