测试需求分析与测试计划精编版课件

单击此处编辑母版标题样式,编辑母版文本样式,第二级,第三级,第四级,第五级,9/22/2019,#,第十章,测试需求分析与测试计划,第十章,目 录,测试,目标和准则,1,测试,需求分析,2,测试,项目的估算与进度安排,3,测试,风险和测试策略,4,测试计划,的内容与编制,5,目 录 测试目标和准则1 测试需求分析 2 测试项目的,1,测试目标和准则,1测试目标和准则,1.,测试的目标,明确测试目标是测试需求分析和计划测试的前提,测试目标,向风险管理活动提供信息,提供软件系统质量有关信息,评估软件产品是否满足相关利益者的期望,评估缺陷修正（清除）而不带来负面效应,评估软件变更实施而不带来负面效应,评估软件是否完全符合合规性要求,1.测试的目标明确测试目标是测试需求分析和计划测试的前提,1.,测试的目标,项目的具体测试目标,提供哪些质量风险信息,新改动的业务是否正确实现，对已有业务是否有负面影响,是否满足功能性要求和非功能性要求,在测试覆盖率、测试效率上的具体要求,1.测试的目标项目的具体测试目标,1.,测试的目标,如何确定测试,目标,哪些业务改动，会影响哪些已有业务？,系统改动会影响哪些系统功能和非功能特性？,测试覆盖率：新业务,/,功能？已有业务,/,功能呢,?,如何最大程度提高测试效率？,1.测试的目标如何确定测试目标,2.,测试进入的准则,清楚,了解项目的整体计划框架；,完成需求规格说明书评审；,技术知识或业务知识的储备；,标准环境,技术设计文档；,足够的资源；,人员组织结构及其责任已确定。,2.测试进入的准则清楚了解项目的整体计划框架；,2,测试需求分析,2测试需求分析,1.,测试需求,什么是测试需求？,简单,来说，测试需求就是确定在项目中需要测试什么，即细化被测对象,。,测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容,。,测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求,。,测试,需求描述测试的目标，特别是描述了产品的质量需求，测试需求分析目的是帮助定义测试对象和测试范围，发现软件需求中不完善和不明确的地方并加以完善以节省测试时间的投入，便于软件需求基线化和跟踪业务需求的变更。,1.测试需求什么是测试需求？,1.,测试需求,为什么要做测试需求分析,测试,需求是测试计划的基础与依据，我们在测试活动中，首先需要明确测试需求（,What,），才能决定怎么测（,How,），测试时间（,When,），需要多少人（,Who,），测试的环境是什么（,Where,）,。,是,衡量测试覆盖率的重要指标。,1.测试需求为什么要做测试需求分析,1.,测试需求,测试需求分析意味着什么,确定测试范围,测试项和测试子项,测试优先级,测试风险,1.测试需求 测试需求分析意味着什么,2.,测试需求分析过程,熟悉需求,需求项整理,提取出测试点,测试点细化,确定测试范围,制定测试策略,2.测试需求分析过程熟悉需求,3.,测试需求分析的基本方法,无论,是功能测试，还是非功能性测试，其测试需求的分析都有以下两个基本的,出发点,（,1,）从客户角度进行分析：,通过业务流程、业务数据、业务操作等分析，明确要验证的功能、数据、场景等内容，从而确定业务方面的测试需求。,（,2,）从技术角度分析：,通过研究系统架构设计、数据库设计、代码实现等，分析其技术特点，了解设计和实现要求，包括系统稳定可靠、分层处理、接口集成、数据结构、性能等方面的测试需求。,3.测试需求分析的基本方法无论是功能测试，还是非功能性测试，,4.,测试需求的分析技术,在,软件测试需求分析过程中，,可以借助,下列途径来达到良好的分析,效果：,（,1,）通过提炼，抓住主要线索，或作为整体来进行分析，使测试需求分析简单化,。,（,2,）通过业务需求或功能层次的整理，使测试需求分析结构化、层次化,。,（,3,）通过绘制业务流程图、数据流程图等，使测试需求分析可视化。,（,4,）通过类比、隐喻，加强用户需求的理解，更好地转化为测试需求。,4. 测试需求的分析技术在软件测试需求分析过程中，可以借助下,4.,测试需求的分析技术,在,测试需求分析时，产品本身往往处于需求分析和设计过程中，静态分析技术是常用的分析技术。静态分析技术包括,如下,通过,系统建模语言（,SysML,）的需求图，可以更好地分析各项需求之间的关系，比较容易确定测试需求的边界。,通过,状态图、活动图更容易列出的测试场景，了解状态转换的路径和条件，哪些是重要测试场景等。,实体,关系图可以明确测试的具体对象（实体）及其之间的关系，进行相关分析,。,4. 测试需求的分析技术在测试需求分析时，产品本身往往处于需,4.,测试需求的分析技术,鱼,骨图法、思维导图等，有一个清晰的分析思维过程，迅速展开测试需求，随时补充测试需求等。,代码,复杂度静态分析工具，代码越复杂，测试的投入也需要越多,。,还,可以用一些普通工具，如检查表。,脑力,激荡法，让大家发散思维，相互启发，让任何测试需求不会被错过。,4. 测试需求的分析技术鱼骨图法、思维导图等，有一个清晰的分,5.,功能测试范围分析,在分析测试范围时，一般先进行功能测试的范围分析，然后再进行非功能性测试的范围分析,。,对于,功能测试，可以借助业务流程图、功能框图等来帮助我们进行测试的需求分析。在面向对象的软件开发中，也可借助,UML,用例图、活动图、协作图和状态图来进行功能测试范围分析。,5.功能测试范围分析在分析测试范围时，一般先进行功能测试的范,5.,功能测试范围分析,Google Talk,5.功能测试范围分析Google Talk,6.,非功能性的系统测试需求,对于非功能性的系统测试，主要目的是验证软件系统的整体性能等是否满足其产品设计规格所指定的要求，涉及非功能性的质量需求有系统性能、安全性、兼容性、扩充性等的,测试,对于每一个应用软件系统，非功能特性的质量需求都是存在的，这类测试需求会因不同的项目类型差异比较大，这些需求的程度、重要性不同，因此要求为非功能性测试需求设置,优先级,系统非功能性测试的需求在不同应用领域也体现较大差异。如网上银行、信用卡服务等系统，其安全性、可用性和可靠性等多方面的测试至关重要，因为这方面的缺陷很可能会给用户造成较大的损失。这些系统需要得到充分的安全性测试、容错性测试和负载测试。,6.非功能性的系统测试需求对于非功能性的系统测试，主要目的是,6.,非功能性的系统测试需求,对于,局域网内的企业级应用来说，有关权限控制、口令设置等安全性测试依然重要，但兼容性测试就相对,简单,对于企业级应用系统来说，存在着不同的应用模式，其系统的架构也不一样，可以分为“以功能为中心、以数据库为中心和以业务逻辑（工作流）为中心”等，在进行系统测试时，所设定的目标也有一定的区别。,6.非功能性的系统测试需求对于局域网内的企业级应用来说，有关,3,测试项目的估算与进度安排,3测试项目的估算与进度安排,1,.,测试工作量估算,测试工作量是,根据测试范围、策划任务和开发阶段来确定的，测试范围和测试任务是测试工作量估算的主要依据,。,测试任务由质量需求、测试目标决定,测试,范围由产品（新）功能特性或测试任务决定。,代码,质量越低，测试越要充分，回归测试次数与频率加大。,处在,不同的开发阶段测试工作量不同。,自动化,程度高，测试工作量就越低。,针对,不同的应用领域、技术、编程语言，其估算方法不同,。,1.测试工作量估算测试工作量是根据测试范围、策划任务和开发阶,1,.,测试工作量估算,工作量估算,过程,1.测试工作量估算工作量估算过程,2.,估算方法,工作分解结构表方法,功能,点方法、 对象点方法,代码,行预估,历史,数据推算（相似规模、同类型）,经验,法 （资深人员或专家小组）,综合,方法,2.估算方法工作分解结构表方法,3.,工作分解结构表方法,WBS,测试工作量的估算依赖于测试任务的细化，对每项测试任务进行分解，然后根据分解的子任务进行估算。通常分解粒度越小，估算精度越,高,列出本项目需要完成的各项任务：测试计划、需求和设计评审、测试设计、脚本开发、测试执行等。,对,每个任务进一步细分，可进行多层次的细分，直到不能细分为止。这建立在对于每一阶段工作的细致把握。,列出,需要完成的所有任务之后，根据任务的层次给进行编号，就形成了完整的工作分解结构表。,3.工作分解结构表方法WBS测试工作量的估算依赖于测试任务的,3.,工作分解结构表方法,WBS,工作分解结构,表,3.工作分解结构表方法WBS工作分解结构表,4.,功能点估算法,功能点,是其中一个比较可靠的工作量估算方法，它先估算每个功能点所需要的工作量，然后进行累加获得总的工作量,借助分解结构表（,WBS,）方法来分解功能,国际功能点用户组,(IFPUG),颁布的标准方法,主要参数有：,外部输入数、外部输出数、内部逻辑文件、外部接口文件和外部查询数,详细参考功能点实用手册,(Function Point Counting Practices Manual Release 4.1, 1999),4.功能点估算法 功能点是其中一个比较可靠的工作量估算方法，,4.,功能点估算法,AFP(,调整后功能点,)= UFP (,未调整功能点数目,)* AF (,影响因子,),外部输入数,(EI,：,external input),外部输出数,(EO,：,external output),外部查询数,(EQ,：,external query),内部逻辑,文件,(ILF,：,internal logical file),外部接口文件,(,EIF,：,external interface file),4.功能点估算法 AFP(调整后功能点)= UFP (未调整,5.,测试用例估算法,依据测试用例数来估算测试工作量，例如用功能模块所有要执行的测试用例总数，除以每个人日所能执行的测试用例平均数，就得出人日数,工作量估算，往往基于其它一些假定,效率假设，即测试队伍的工作效率,测试假设，为了验证一个测试需求所需测试动作的数目，可能包括每个测试用例的估算时间,风险假定。考虑增加,10%,20%,的工作量来处理风险产生的不确定性,5.测试用例估算法 依据测试用例数来估算测试工作量，例如用功,6.,相对比例估算法,如果确实没有任何可行的办法，就可以按照测试人员和开发人员的比例来确定,大致可以分为,3,类，其比例分别是,1:2,、,1:1,、,2:1,6.相对比例估算法 如果确实没有任何可行的办法，就可以按照测,7.,总工作量,W,Wo + Wo,R1 + Wo ,R2 + Wo ,R3,W,为总工作量，,Wo,为一轮测试所需的工作量,R1,，,R2,，,R3,为每轮的递减系数。受代码质量、开发流程和测试周期等影响，,R1,、,R2,、,R3,的值是不同的,7.总工作量W Wo + Wo R1 + Wo ,4,测试风险和测试策略,4测试风险和测试策略,1.,测试风险,软件测试存在较高的风险，测试风险管理就是设法降低或缓解测试过程中的风险，包括确定哪些风险是可以避免的、可以采取哪些措施等。,风险识别的有效方法就是建立风险项目检查表,此前,，历史资料、,Brainstorming,等帮助建立项目检查表,风险,识别并确定其程度，给出预防或处理措施。,1.测试风险软件测试存在较高的风险，测试风险管理就是设法降低,1.,测试风险,风险项目检查,表,1.测试风险风险项目检查表,1.,测试风险,风险项目检查,表,1.测试风险风险项目检查表,2.,控制风险的对策,消除执行风险,降低进度风险,减少人员风险,2.控制风险的对策 消除执行风险,2.,控制风险的对策,风险,管理,2.控制风险的对策 风险管理,2.,控制风险的对策,风险的控制,方法,采取措施避免可以避免的风险。,高,风险转移为低风险。,设法,降低不可避免的风险,做好,风险管理计划。,制定,处理风险一些应急、有效的方案。,计划,时，对于估算资源、时间、预算留有余地,制定,文档标准，建立机制，保证文档及时产生。,2.控制风险的对策 风险的控制方法,3.,测试策略及其内容,测试,策略描述当前测试项目的目标和所采用的测试方法，描述不同测试阶段的测试对象、范围和方法以及每个阶段内所要进行的测试类型,。,针对风险（工作量、时间等压力）采取对策，包括遵照的标准取舍、测试任务的优先级等,如何更好地执行测试用例以及后续的回归测试,选定使用测试技术和工具,考虑影响资源分配的特殊情况,3.测试策略及其内容测试策略描述当前测试项目的目标和所采用的,3.,测试策略及其内容,测试策略,影响因素,测试方式,(,静态,/,动态，探索式,方式，,黑盒,/,白盒,）,测试,层次（单元、集成、系统）,测试人员（责任、能力、独立性）,测试用例选择,/,优化（如用例是否有优先级）,测试环境（设置是否简单、自动部署）,测试工具（能不能用测试工具、使用简单与否）,质量标准（采用国内标准或美国,DO-178C,）,3.测试策略及其内容测试策略影响因素,3.,测试策略及其内容,制定测试,策略,全面细致地了解产品的项目信息,:,应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构,基于,模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响,公正客观地开展测试计划,根据,程序的重要性和一旦发生故障将造成的损失,来确定它的测试等级和测试重点,认真,研究测试策略,以便能使用尽可能少的有效测试用例,发现尽可能多的程序错误,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则表明本次测试是失败的,是不足的,;,而测试不足意味着让用户承担隐藏错误带来的危险,.,同时反过来说,如果过度测试,则又会浪费许多宝贵的资源,.,找到一个最佳平衡点。,3.测试策略及其内容制定测试策略,5,测试计划内容与编制,5测试计划内容与编制,1.,测试计划内容,软件测试计划是指导测试过程的纲领性文件，描述测试活动的范围、方法、策略、资源、任务安排和进度等，并确定测试项、哪些功能特性将被测试、哪些功能特性将无需测试，识别测试过程中的风险。,内容,主要集中在测试目标和需求说明、测试工作量估算、测试策略、测试资源配置、进度表、测试风险等,1.测试计划内容软件测试计划是指导测试过程的纲领性文件，描述,1.,测试计划内容,IEEE829,1998,：测试计划,内容,测试计划标识符（文档编号）,项目总体情况简介；,测试项（,test item,）；,需要测试的功能；,方法（策略）；,不需要测试的功能；,测试项通过,/,失败的标准；,测试中断和恢复的规定；,测试完成所提交的材料；,测试任务；,测试环境要求；,测试人员职责；,人员安排与培训需求；,进度表；,潜在的问题和风险；,审批,1.测试计划内容IEEE8291998：测试计划内容测试计,2.,测试项目的计划过程,计划,初期是收集项目各类信息，理解用户的真正需求,确定测试需求和测试范围,起草计划。,内部审查。,计划讨论和修改。,测试计划的多方审查。,测试计划的定稿和批准。,测试计划的跟踪。,2.测试项目的计划过程计划初期是收集项目各类信息，理解用户的,3.,制定有效的测试计划,测试计划的创建和评审,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,3.制定有效的测试计划测试计划的创建和评审MRD/PRD测试,3.,制定有效的测试计划,制定,有效的测试计划,确定测试项目的任务，清楚测试范围和测试目标,尽量,识别出各种测试风险，制定出相应的对策,让所有合适的相关人员参与测试项目的计划制定,客观、准确、留有余地；,制定测试项目的输入、输出和质量标准,识别出可变因素，建立变化处理和控制的流程规则,不要忽视技术上的问题,要对测试的公正性、遵照的标准做一个说明,测试计划应简洁、易读并有所侧重,3.制定有效的测试计划制定有效的测试计划,3.,制定有效的测试计划,测试输入,/,输出,标准,测试的输入标准,整体项目计划框架；,需求规格说明书；,技术知识或业务知识,标准环境,设计文档；,足够的资源,人员组织结构,测试的输出标准,测试执行标准,Bug,描述和处理标准,文档标准和模板,测试分析、质量评估标准等,3.制定有效的测试计划测试输入/输出标准测试的输出标准,3.,制定有效的测试计划,测试输入,/,输出,标准,测试的输入标准,整体项目计划框架；,需求规格说明书；,技术知识或业务知识,标准环境,设计文档；,足够的资源,人员组织结构,测试的输出标准,测试执行标准,Bug,描述和处理标准,文档标准和模板,测试分析、质量评估标准等,计划不是文档、是一个过程,3.制定有效的测试计划测试输入/输出标准测试的输出标准计划不,3.,制定有效的测试计划,测试计划是一个,过程,确认测试目标、范围和需求,识别测试风险，制订相应的测试策略,对测试任务和工作量进行估算,确定所需的时间和资源,进度安排和资源分派，包括团队角色、责任和培训,测试阶段划分，包括阶段性任务和成果,计划评审与批准,跟踪和控制机制,3.制定有效的测试计划测试计划是一个过程,3.,制定有效的测试计划,示例：系统测试结束,标准,对于非严格系统可以采用“基于测试用例”的准则：,功能性测试用例通过率达到,100%,；,非功能性测试用例通过率达到,95%,。,对于严格系统，应当补充“基于缺陷密度”的规则：,相邻,n,个,CPU,小时内“测试期缺陷密度”全部低于某个值,m,。具体值根据项目的类型来确定。,3.制定有效的测试计划示例：系统测试结束标准,感谢观看,THANKS,感谢观看THANKS,