Ch3-质量保证与测试策略

上传人:gfy****yf 文档编号:252018589 上传时间:2024-11-12 格式:PPT 页数:30 大小:176KB
返回 下载 相关 举报
Ch3-质量保证与测试策略_第1页
第1页 / 共30页
Ch3-质量保证与测试策略_第2页
第2页 / 共30页
Ch3-质量保证与测试策略_第3页
第3页 / 共30页
点击查看更多>>
资源描述
,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,软件测试方法和技术,-Ch.3,质量保证与测试策略,Zhu.Kerrygmail,.com,Kerry Zhu,1,第二章回忆,Zhu.,软件质量就是客户的满意度,软件缺陷(Bug)是什么,软件测试的根本方法,-白盒/黑盒,静态/动态,自动化/手工,软件测试的分类和阶段,-单元、集成、系统(性能、适用性、兼容性)、验收测试,软件测试的工作范畴,-策略、方案、设计、执行、报告、评估,2,第三章 质量保证与测试策略,Zhu.,3.1 软件质量保证,3.2 测试策略,3.3 测试方案,3.4 软件质量的可靠性评估,3,3.1,软件质量保证,(,SQA,),SQA,概述,SQA,活动,SQS,与软件测试的关系,Zhu.,4,什么是,SQA?,软件质量保证是通过对软件产品和活动有方案的进行评审和审计来验证软件是否符合标准的系统工程活动.,Zhu.,确保SQA活动要自始至有方案的进行,审查软件产品和活动是否遵守适用的标准、规程和要求并得到客观验证。,SQA的活动和结果要保证全员参与,沟通顺畅。,逐级解决不符合问题,5,SQA,活动,技术方法的应用,正式技术评审的实施,软件测试,标准的执行,修改的控制,度量,质量记录和记录保存,Zhu.,6,SQA,活动的影响因素,知识结构:专业的技术,例如质量管理与控制知识、统计学知识等。,经验,依据:如果没有这些标准,就无法准确地判断开发活动中的问题,容易引发不必要的争论,因此组织应当建立文档化的开发标准和规程。,全员参与:全员参与至关重要,高层管理者必须重视软件质量保证活动。,把握重点:一定要抓住问题的重点与本质,尽可能防止陷入对细节的争论之中。,Zhu.,7,SQA,策略,SQA策略主要分三个阶段:,以检测为重:产品制成之后进行检测,只能判断产品质量,不能提高产品质量。,以过程管理为重:把质量的保证工作重点放在过程管理上,对制造过程中的每一道工序都要进行质量控制。,以新产品开发为重:在新产品的开发设计阶段,采取强有力的措施来消灭由于设计原因而产生的质量隐患。,Zhu.,8,SQA,与软件测试有什么关系和区别?,Zhu.,9,SQA,与软件测试的关系,SQA,是,管理,工作、审查对象是,流程,、强调以,预防,为主,测试,是,技术,工作、测试对象是,产品,、主要是以,事后检查,SQA,指导测试、监控测试,测试为,SQA,提供依据,Zhu.,10,测试策略的概念,测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试(如单元测试、集成测试、系统测试)以及每个阶段内进行的测试种类(如功能测试、性能测试、压力测试等),以确定合理的测试方案使得测试更有效。,Zhu.,11,影响测试策略的因素,1、测试完成的标准,标准的上下对策略确定有着重要的影响。比方该软件的应该用场合为军用,这将对软件的可靠性、平安性要求非常高,但如果是用于小型商场的收费系统由于是内部使用,主要考虑其计算的准确与精度及复杂统计与报表生成等方面准确性与易用性。,2、资源状况,参与测试的人、测试中所需要的软件平台(如操作系统甚至会涉及到第三方的一些应用软件)及测试可能用到的相关硬件设备(如计算机,网络硬件其它外设等),Zhu.,12,制定测试策略,全面细致地了解产品的工程信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构,基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响,公正客观地开展测试方案,根据程序的重要性和一旦发生故障将造成的损失,来确定它的测试等级和测试重点,认真研究测试策略,以便能使用尽可能少的有效测试用例,发现尽可能多的程序错误,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则说明本次测试是失败的,是缺乏的;而测试缺乏意味着让用户承担隐藏错误带来的危险.同时反过来说,如果过度测试,则又会浪费许多珍贵的资源.找到一个最正确平衡点。,Zhu.,13,测试范围确实立,优先级最高的需求功能,新功能和编码改动较大(提高性能表现)的旧功能,运用有效的测试技术去提高测试效果,经常容易出现问题局部的功能,一些经常被用户使用的功能和配置,Zhu.,14,测试持续阶段确实定,当测试任务明确后,测试方案将依赖于测试小组的人力资源而最终确定.,Task 1/1 1/8 1/15 1/20 1/29 2/5 2/12 2/20 2/28,需 求 分 析 -,设 计 审 查 -,测 试方案准备工作 -,设 计测试用例 -,功 能 测 试 -,集 成&系统测试 -,第一轮测试 -,第二轮测试 -,确 认 测 试 -,测 试 结 束 -,Zhu.,15,通过/失败的标准,单个的测试通过/失败,测,试,用例,全部产品测试通过/失败,每,个阶段的通过/,失败,Zhu.,16,测试周期,MRD/PRD/UI Sign-off,Eng.Plan Sign-off,Eng.Spec Sign-off,Test Plan Sign-off,Product Review,Code Freeze,Test Case Sign-off,Code Complete,ER,验收测试,QA 创立,Test Plan,QA,QA创立,Test Cases,功能测试,写,/,审查,Spec,系统测试,单元测试,PRD/UI,审查,QA,Zhu.,17,阶段通过/失败的标准,项目经理和测试组长已经全部按计划到位?,所有相关的信息已经传达到,QA?QA.,开始了测试设计?,需求阶段,设计审查,所有设计中及文档中的问题都已经被解决?,技术设计和测试设计已经结束?,最高优先级的功能要求已经实现?新功能已经实现?,所有的功能是按照设计来实现的?代码完成?,功能验证,确认测试,回归测试完成与否?,是不是完全按测试计划完成了所有的测试?没有严重的缺陷?,达到产品发布的标准?,测试环境的检查?,所有严重问题是不是都已测出?,功能测试,压力测试,安全测试,兼容性测试,易用性测试是否都已完成?有没有阻碍产品发布的缺陷?,系统测试,Zhu.,18,风险评估,测试小组开始工程测试时,硬件资源没有按时配备或仍然缺乏,开始工程测试时,软件产品编码没有按方案完成,开始工程测试时,测试用例没有准备好,缺少按方案参加工程测试的测试人员,在工程测试过程中,需求总是不停地改动,当工程测试进行时,在设计说明书中被定义的功能总是不停地被修改,Zhu.,19,测试评估,里程碑的定义和跟踪可以帮助工程管理者掌握工程的进行状态,里程碑 日期,测试方案完成 -1/15,测试用例完成 -1/29,功能验证完成器 -2/5,代码冻结前完成系统测试 -2/20,版本发布前完成确认测试 -2/28,Zhu.,20,测试方案的创立和评审,MRD/PRD,review,测试策略,知识传递,日 程,测试,范围,反馈,讨论分析,Formal,Review meeting,问题,QA draft of,Test Plan,Updated,Test Plan,Final,Test Plan,测试方法,任务,Updated,Test Plan,资 源,Pear-to-Pear or,Internal Review,Check,list,Zhu.,21,测试方案内容构成,测试方案制定的第一步就是将软件分解较小而且相对独立的功能模块,写成测试需求。,测试需求有很多分类方法,最普通的一种就是按照功能分类:,测试需求是测试设计和开发测试用例的根底,分解功能模块可以更好地进行设计;,详细的测试需求是用来衡量测试覆盖率的重要指标;,测试需求包括各种测试实际和开发以及所需资源。,一个测试方案应包括:产品根本情况、测试需求说明、测试策略和记录、测试资源配置、方案表、问题跟踪报告、测试方案的评审、结果等。,Zhu.,22,测试方案标准格式-1,16 components of Test Plan(IEEE,1983),Test plan identifier(测试方案标识),Instruction(引言),Test Items (定义或主题词),Features to be tested (需要被测试的功能),Features not to be tested(无需被测试的功能),Approach(方法和途径),Items pass/fail criteria(测试通过、失败的标准),Suspension criteria and resumption requirements(延迟的标准和再恢复的要求),Test deliverables(测试交付的内容),Testing Tasks(测试任务,Zhu.,23,测试方案标准格式 2,16 components of Test Plan(IEEE,1983),Environmental needs(必备的环境),Responsibilities(职责),Staffing and training needs(人员和必需的培训),Schedule(时间进度表),Risk and contingencies(风险和相关费用),Approvals(批准),模板:中文 测试方案 和 英文,Zhu.,24,3.4,软件质量的可靠性评估,3.4.1,软件可靠性评估的概述,3.4.2,软件可靠性模型,3.4.2,可靠性评估过程,Zhu.,25,软件可靠性评估的概述,软件可靠性评估(Software Reliability Assessment)指根据软件系统可靠性结构(单元与系统间可靠性关系)、寿命类型和各单元的可靠性试验信息,利用概率统计方法,评估出系统的可靠性特征量。,软件可靠性评估的要素,1)规定的时间,2)规定的环境条件,3)规定的功能,Zhu.,26,软件可靠性模型,软件可靠性模型(Software reliability model)是指为预计或估算软件的可靠性所建立的可靠性结构和数学模型。建立可靠性模型是为了将复杂系统的可靠性逐级分解为简单系统的可靠性,以便于定量预计、分配、估算和评价复杂系统的可靠性。,1)可靠性结构模型,是依据系统结构逻辑关系,对系统的可靠性特征及其开展变化规律做出可靠性评价。,2)可靠性预计模型,是用来描述软件失效与软件缺陷的关系,借助这类模型,可以对软件的可靠性特征做出定量的预计或评估。依据软件缺陷与运行剖面数据,利用统计学原理建立二者之间的数学关系,获取开发过程中可靠性变化、软件在预定工作时间的可靠度、软件在任意时刻发生的失效数的平均值以及软件在规定时间间隔内发生失效次数的平均值。,Zhu.,27,可靠性评估过程,可靠性数据收集,用时间定义的软件可靠性数据可以分为四类:,失效时间数据,记录发生一次失效所累积经历的时间;,失效间隔时间数据,记录本次失效与上一次失效间的间隔时间;,分组数据,记录某个时间区内发生了多少次失效;,分组时间内的累积失效数,记录某个区间内的累积失效数。这四类数据可以互相转化。,测试时间;,含有测试用例的测试方案或测试说明;,所有与测试有关的测试结果,包括所有测试时发生的故障;,参与测试的个人身份。,可靠性评估报告,Zhu.,28,作业,Zhu.,第三章,2,、,3,29,Q&A,Zhu.,30,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 图纸专区 > 课件教案


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!