《测试需求分析》PPT课件.pptx

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,#,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,测试需求分析,目录,测试需求概要,什么是,测试需求,测试需求的特征,为什么需要测试需求,测试需求分析过程,测试需求采集,测试需求分析,测试需求评审,2,需求,?,背景：冯大勇吃鱼时嗓子被鱼刺卡住了现在正坐在椅子上候诊大夫：（在桌上拿起一份挂号单，大声的喊）冯大勇！,冯大勇：（病怏怏的样子，边走边咳嗽）我是大夫：怎么了？（低头整理手中的资料，自言自语，并打手势，示意冯大勇坐下）,冯大勇：我,.,咳嗽,.,我今天,.,咳嗽,.,大夫：不用说了，我知道了从桌子下面拿出一个大盒子，放在桌,子上）,我看你适合吃这种药这是本院独家开创的哮喘新药“咽喉糖浆”，疗程短，见效快，一个疗程吃,3,盒，平均每天只需花费,3,块钱给你先开,6,盒吧！（边说边开药方）,冯大勇非常惊讶地瞪大眼睛并止不住地弯腰大声咳嗽，以至于把鱼刺都咳出来了冯大勇从口里掏出一条巨型鱼刺，递给医生医生见到鱼刺先是吃惊，而后又非常尴尬测试需求主要解决“测什么”的问题，,即细化被测对象。

测试需求通常是以软件开发需求为基础进行分,析,，通过对开发需求的细化和分解，形成可测试的内容测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求,4,什么是测试需求？,什,么是需求,需求是产品必须完成的事以及必须具备的,品质分,类：,显式需求,：明确定义的一系列约束软件实现的要求隐式需求,：并不是需求设计人员特意隐藏，更多的,是由理解人员对某方面专业知识，或对产品的业务,了解程度有限导致的5,需求分析没有做好的后果一般会有下列现象：,浪费时间和资源来满足用户并不,需要的需求（过度实现一些功能）,总是需要比较长的时间,来达成对产品设计的共识,员工会厌倦因需求不断被,重新解释而导致的返工,不稳定的产品，用户的不满意,对我们未来的市场造成损失,开发出来的产品技术上先进，,但并不满足用户需求,在产品设计，开发和测试,对于用户需求的解释不一致,未说明的或不正确的需求会导致员工与用户间的不满,浪费时间，增加成本，使得在,一些投标的项目中不能低价,需求分析的重要性,如果你在编码的时候发现某几行有误，那么改掉这几行就行了而如果在编码阶段发现需求有误，那么你很可能需要改变所有代码来适应新的需求,在需求阶段消除问题的代价最小，而如果需求问题等到产品发布出去后才发现的话，那修复的成本就会,N,倍的增加。

稳定的需求是软件开发的关键有了稳定的需求，软件开发工作可能从结构设计到详细设计到代码到测试都会平稳顺利的进行开头错,-,全盘错,-,全盘输,如何进行需求分析,一般可以从三个方面去考虑：,1.,功能需求,2.,非功能性需求,3.,限制条件了,功,能性需求,功能性需求是产品必须完成的那些事，要求一定的功能和品质例：,培训机构的班主任可以给所在班级学员打考勤,9,非功能性需求,非功能性需求是产品必须具备的属性或品质诸如观感、可用性、安全性和法律限,制等例：,平台用户数为,5,万人,每天登录用户数为,1000,左右，网络的带宽为,100M,带宽在工作时间根据资料名称条件进行搜索，可以在,3,秒内得到搜索结果这类需求通常在产品的功能确定之后，一旦知道了产品要做的事情，就可以确定它的行为方式，它需要具备什么品质以及它的响应速度、可用性、可读性和安全性10,限定条件,限制条件是全局性的需求它们可以是对项目本身的限制,或是对产品最终设计的限制例：,南京平台必须在,2010,年开学的第一学期上线,客户是在说，如果顾客不能在给定的时间前使用该产品，那么它就没有什么用了其效果是需求分析师必须对需求进行限制，只包括那些在最后期限前能够提供最大价值的需求。

需求分析的步骤,熟悉需求背景及商业目标,：,1),了解清楚项目发起的原因，是为了解决用户的什么问题2),当前的解决方案是不是最优的，为什么会这样做？,业务模型法：,1),考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书2),确定测试范围和关注点系统的边界是测试的重点，特别需要关注边界交互时的数据交互,13,需求审查点,易读性,二义性,一致性,统一性,是否存在需求过度或不合理,测试人员在需求阶段应做哪些工作,用户的需求是否恰当的描述,如果不恰当，那么是否要确认,这里存在一个隐患，用户可能会在开发的后期突然,要求让,你的需求变动，所以要事先明确,好,一,.,是,用户是否真的能正确地描述自己的需求；,二,.,是,需求人员是否真的能正确地理解需求三,.,是,需求文档被正确的撰写,制定的测试需求项必须是可核实的即它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求；,即,-,期望输出测试需求应指明满足需求的正常的,前提条件,，同时也要指明不满足需求时的出错条件,测试需求不涉及具体的测试数据，测试数据设计是测试设计,(,用例设计,),环节应解决的内容。

16,测试需求的特征,软件测试需求是开发测试用例的依据有助于保证测试的质量与进度测试需求是衡量测试覆盖率的重要指标,17,为什么需要测试需求,测试需求分析过程,a,）对原始测试需求列表中列出的每一条开发需求，形成可测试的分层描述的测试要点；,b,）对步骤,a,）所确定的测试要点，分析测试执行时需要实施的测试类型；,d,）建立测试需求跟踪矩阵，对测试需求进行管理测试需求分析,需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求一句话定义：,可测试性是指这些提取的需求或特性必须存在一个可以明确预知的结果,(,期望输出,),，可以用某种方法对这个明确的结果进行判断,(,实际输出,),、验证，验证是否符合文档中的要求需求采集,需求采集的提取方法：,a),通过列表的形式对软件开发需求进行梳理，形成原始测试需求列表，列表的内容包括需求标识、原始测试需求描述、信息来源b),需求标识：产品版本号,/,功能模块版本号,/LOGO,c),将每一条软件需求对应的开发文档及章节号作为软件需求标识d),使用软件需求的简述作为原始测试需求描述e),软件需求获取的来源信息作为信息来源。

需求采集,提取的原始测试需求中，可能存在重复和冗余，在提取原始测试需求过程中，可以通过以下方法整理原始测试需求：,a,）删除：删除原始测试需求表中重复的、冗余的含有包含关系的原始测试需求描述；,b,）细化：对太简略的原始测试需求描述进行细化；,c,）合并：如果有类似的原测试始需求，在整理时需要对其进行合并需求采集,“人力资源管理系统”原始测试需求表,序号,软件需求标识,原始测试需求描述,信息来源,1,3.1.1,基本信息管理,增加员工信息,人事部门招聘专员对于新招聘的职员信息可以录入到,HRMIS,系统中，主要职员信息如下：姓名、性别、出生日期、政治面貌、文化水平、婚姻情况、家庭住址、身份证号、办公、移动、紧急情况下的联系人和联系方式、毕业院校、入职时间、岗位及职责，其中，性别包含男、女两个类别；婚姻情况包括未婚、已婚、离异三种情况人力资源管理系统业务需求说明书,删除员工信息,删除需用户确认，可以逐条删除或多条一次删除,GB/T 17544-1998,2,3.2.2,时间特性要求,并发,15,个用户，平均登录时间小于,10,秒,人力资源管理系统业务需求说明书,3,隐含需求：在使用中操作错误的易恢复性,程序应对关键数据的操作给出警告或在执行前确认,GB/T 17544-1998,需求采集,-,举例,测试需求分析,测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求。

对开发需求的细化和分解具体包括：,a,）通过分析每条开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容；,b,）通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据（功能交互分析），对存在功能交互的功能项，给出对应的验证内容测试要点分析,功能交互分析,测试要点分析,进行细化和分解还需考虑：,a,）需求的完整性，经过分解获得的需求必须能够充分覆盖软件需求的各种特征（包括隐含的特征），每个需求必须可以独立完成有意义的功能或功能组合，可以进行单独测试；,b,）需求的规模，每个最低层次的需求能够使用数量相当的测试用例来实现,测试要点分析,测试要点分析,-,举例,不同的质量子特性可以确定出不同的测试内容，这些测试内容可以通过不同的测试类型来实施软件测试可以划分为以下测试类型：功能测试、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复性测试、配置测试、兼容性测试、安装测试等根据质量子特性的定义，以及各测试类型的测试内容，可以分析出质量子特性与测试类型的对应关系分析测试类型,质量子特性和测试类型的对应关系基准表,分析测试类型,分析测试类型,-,举例,分析测试类型,-,举例,为了避免遗漏，在确定测试类型时，还需考虑：,a,）文档中是否包含测试类型相对应的情况的说明；,b,）列出的常见测试类型是否已完全覆盖了被测软件；,c,）被测软件的某些特殊情况是否已包含在所列出的测试类型中。

分析测试类型,建立测试需求跟踪矩阵，对测试需求进行管理将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵测试需求跟踪矩阵为原始测试需求与测试要点的对应关系表，格式如下：,测试需求跟踪矩阵,建立测试需求跟踪矩阵，对测试需求进行管理将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵通过测试需求跟踪矩阵的方式对需求变更实施软件需求一旦发生变化，就要对需求跟踪表进行维护，启动配置管理过程，将与软件需求变更相关的内容进行同步变更测试需求跟踪矩阵,增加,培训,信息,测试需求跟踪矩阵,-,举例,增加,培训,信息,测试需求跟踪矩阵,-,举例,测试需求跟踪矩阵需要不断的维护a,）,一方面，软件需求一旦发生变化，应启动配置管理过程，将与软件需求变更相关的内容进行同步变更；,b）,另一方面，随着测试工作的进行，会不断添,加新的跟踪内容，对跟踪表进行扩展例如，测,试设计阶段的测试用例、测试执行阶段的测试记,录和测试缺陷都可以添加到跟踪矩阵中测试需求跟踪距阵,评审的内容：,a,）完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；,b,）准确性审查：应保证所描述的内容能够得到,关各方的一致理解，各项测试需求之间没有矛盾,和冲突，各项测试需求在详尽程度上保持一致，,每一项测试需求都可以作为测试用例设计的依据。

测试需求评审,评审的形式,a,）相互评审、交叉评审：,甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查相互评审是最不正式的一种评审形式，但应用方便、有效测试需求评审,b,）小组评审：,通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式评审定义了评审会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进行了独立研究测试需求评审,需求内审,需求文档,内审,问题反馈,需求内审团队,整理问题反馈,需求宣讲及问题回复,整改需求,需求外审基线,需求文档,整理问题反馈,内审,需求文档,整理问题反馈,需,求,负责人,评审的形式,a,）审查：审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、准备和组织会议、跟踪和分析审查。