软件测试需求分析PPT学习课件.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,#,测试需求及需求分析,伊薇亦,2013,年,12,月,28,号,1,2025/4/11 周五,工作中的场景？,问题漏测；测试设计不充分,60%,！,测试出很多，还有这么多问题？,这些问题怎么没有考虑到？,不知道如何站在客户立场测试？,客户到底关心什么？,需要做测试需求分析！,2,2025/4/11 周五,很多公司现状,测试输入,测试对象分析,测试用例设计（方案内的）,测试用例,没有测试需求分析过程,测试经理口头分配测试方案任务不明确,测试过程与结果缺乏质量评估与控制,测试对象分析侧重测试方案内部实现,过多关注功能实现、产品质量维度关注不全面,没有统一成熟的分析设计工程方法支撑,3,2025/4/11 周五,测试过程中遇到的问题汇总,测试需求不充分，没有明确的测试需求分析过程,产品质量维度关注不全面，测试类型不完整,没有测试规格，测试分解分配比较随意,责任主体不明确,没有系统的工程方法或指导,没有相应的质量评估原则,4,2025/4/11 周五,需求的定义,需求是用户为解决一个或达到一个目标所需要的一种能力条件。,或需求是一个系统或系统组成部分为满足一个合同、标准、规则说明或其它正式规定的文件必须达到或具备的能力条件。,5,2025/4/11 周五,什么是测试需求,测试需求主要解决“测什么”的问题，即指明被测对象中什么需要测试,测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容,测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求,Test Requirement=Test Condition=Test Specification,测试需求,=,测试条件,=,测试规格,6,2025/4/11 周五,业务需求与测试需求的关系,业务需求,通常是指系统需要做什么,测试需求,除了需要覆盖系统应该做什么外，还要覆盖系统不应该做什么。,测试需求,是用来发现需求中存在的问题,7,2025/4/11 周五,为什么做测试需求分析？,测试需求分析目的是：明确应该测试什么。即明确测试需求，其核心是产品质量。,产品质量,就是符合用户的明确的或隐含的需求的程度。,需求文档中的产品需求、系统设计需求是明确的需求,未在需求文档中明确的隐含的用户需求也是我们需要分析的，如用户使用产品方式、感受等。,清晰把握测试需求！,时刻关注产品质量！,8,2025/4/11 周五,测试需求分析的作用和重要性,测试需求提供一个测试应用程序所必须的详细的描述。,软件测试需求是开发测试用例的依据,确定测试完整性的一个基础,确定测试工作的范围,识别可做自动化测试的策略,作为测试的方向标,有助于保证测试的质量与进度,有助于进行需求跟踪,有利于测试管理,9,2025/4/11 周五,测试需求的特征,一条有用的测试需求总是：,唯一的,精确的,有边界的,可测试的,其它可能：,必要的前置条件,不涉及测试数据,10,2025/4/11 周五,测试需求分析内容,测试需求的内容：测试范围、测试目标,测试范围：就是测试项目中，我们需要进行开发生命周期的各个阶段的测试，还是部分测试,测试目标：系统的那些特性需要测试,测试需求的要点：,解决系统要测什么而不是描述如何测,测试需求包含：功能性需求和非功能性需求,功能性需求,:,系统功能、业务流程、界面、系统安装等,非功能性需求：性能要求、安全性要求、兼容性要求、移植要求,11,2025/4/11 周五,需求分析通常步骤,1,、通过列表的形式对软件开发需求进行梳理，形成原始测试需求列表，列表的内容包括需求标识、原始测试需求描述、信息来源。,2,、将每一条软件需求对应的开发文档及章节号作为软件需求标识。,3,、使用软件需求的简述作为原始测试需求描述。,4,、软件需求获取的来源信息作为信息来源。,12,2025/4/11 周五,5,、提取的原始测试需求中，可能存在重复和冗余，在提取原始测试需求过程中，可以通过以下方法整理原始测试需求：,删除：删除原始测试需求表中重复的、冗余的含有包含关系的原始测试需求描述；,细化：对太简略的原始测试需求描述进行细化；,合并：如果有类似的原测试始需求，在整理时需要对其进行合并。,13,2025/4/11 周五,方法参考,1,、强调测试需求分析,分析过程和结果分开，产生测试需求需要问自己，“这些功能假设要做什么？如果做了这些，我如何才能知道”，和开发进行交流的思路来源于以下事实：有些规格并没有写在,SRS,中，而是停留在开发人员的脑中，特别是用户使用的方式等等。,2,、电子表格是支撑测试分析设计的主要工具,测试设计的工具选择并非一定要有专门的工具支撑，只要能将测试设计活动通过工具串起来，相互之间的继承和依赖关系能够表达出来即可。,3,、测试划分,提出测试划分概念，明确了每个测试方案的输入和测试方案之间的接口。类似于开发的系统规格分解过程。,4,、测试类型,测试类型是扩展测试覆盖的重要方法，业界公司都强调建立自己的测试类型库。长时间以来，有经验的测试设计人员都认可，并且维持着不同的测试类型列表。,14,2025/4/11 周五,软件需求分析,可行性和紧迫程度，近期需求和远期需求，分析的主要工作包括：,通过启发、诱导、深层次的沟通与交流，获取用户潜在需求,分析行业的规则、规范，分析用户需求的合理性,编写分析报告并获得用户认可,将用户需求做阶段性的截止，否则系统设计将无所适从，并增加系统设计的风险和隐患。,如果需求变更，则需要进行变更控制,15,2025/4/11 周五,如何分析测试需求,16,2025/4/11 周五,测试需求分析考虑的因素,测试阶段,待测软件的特性,测试焦点,测试需求优先级,测试需求的覆盖率与覆盖程度,17,2025/4/11 周五,一、测试阶段,系统测试阶段,侧重于技术层面，软件是否实现了功能。同一流程或角色执行功能正确，具有相同特征的业务或角色都能执行正确。,验收测试阶段,侧重于业务层面，更注重于不同角色在同一功能上执行是否正确,18,2025/4/11 周五,二、待测软件的特性,不同业务背景和应用,安全性软件,安全（人身、重大财产）,电子商务网站,压力,ERP,流程,驱动程序,兼容性,政府门户,法律、法规,19,2025/4/11 周五,三、测试焦点,根据所测的功能点划分的层次,例如：界面、业务流、模块化、数据、输入域等,基于业务流的测试需求分析方法,测试需求分析时需要列出以下类别：,常用的或规定的业务流程,各业务流程分支的遍历,明确规定不可使用的业务流程,没有明确规定但是应该不可以执行的业务流程,其它异常或不符合规定的操作,20,2025/4/11 周五,四、测试需求的优先级,把握重点、有的放矢,缓和测试风险,用户需求,软件需求,有优先级：则决定测试需求优先级,无优先级：则通过沟通，确定测试需求优先级,21,2025/4/11 周五,五、测试需求的覆盖率与覆盖程度,测试需求与软件需求的对应关系,覆盖率,=,测试需求覆盖点数,/,软件需求功能点数*,100%,22,2025/4/11 周五,测试需求分析的步骤,1,、熟悉需求背景及商业目标：,了解清楚项目发起的原因，是为了解决用户的什么问题。,当前的解决方案是不是最优的，为什么会这样做？,2,、业务模型法：,考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书。,确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。,23,2025/4/11 周五,3,、业务场景法：,考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注）,考虑系统内部各个用例之间的交互，形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。,24,2025/4/11 周五,4,、业务功能：与用户实际业务直接相关的功能或细节。,辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。,数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。,易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。,25,2025/4/11 周五,编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。,参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。,权限需求：功能的细节，这里的权限是指在功能的执行过程，根据根据不同的权限进行不同处理的，不包括直接限制某个功能的权限,26,2025/4/11 周五,举例：说明如何进行测试需求分析,先看一段关于日志文件的需求描述如下：,“软件要将所有的访问者都要记录下来，对每次访问要记录访问开始时间、访问结束时间、访问者的,IP,地址这三个信息作为一条日志记录。要求以天为单位每天生成一个访问记录日志文件。”,27,2025/4/11 周五,举例说明如何进行测试需求分析（续,1,）,在这段需求描述中，我们首先要想象自己是日志模块的开发者，根据这段需求描述，是否能够开发出日志模块来呢？日志文件要记录的信息内容上面都提到，包括：访问开始时间、结束时间、,IP,地址。,好像可以根据这个需求描述进行开发，但仔细来分析一下这段需求的话，就会发现并不是想象的那样乐观。先找出需求中涉及的三个显性元素：,1,、访问者,2,、访问记录,3,、日志文件,28,2025/4/11 周五,举例说明如何进行测试需求分析（续,2,）,首先对访问者和访问记录这两个元素进行分析，先看访问者有那些属性，除了描述中提及的访问时间和,IP,地址外，访问者还有那些属性呢？,显然访问者的访问内容是最重要的属性，仅记录访问时间和访问者的,IP,地址是否足够呢，从日志能分析出什么有用的信息呢？从时间信息上最多只能看出那段时间访问的人数较多，得到用户的时间分布规律，但很难对用户的行为有深入的分析，只有知道访问者在访问那些内容才能得到更有价值的信息。,Web,服务器软件要记录下访问的,URL,信息以便知道访问者访问的内容，所以访问记录中遗漏了关于访问内容的信息。,29,2025/4/11 周五,举例说明如何进行测试需求分析（续,3,）,从访问记录这个元素来分析，访问记录主要属性是记录格式，每条记录是以什么格式来记录呢？没有描述出来。,有经验的开发者就知道日志记录格式是一个很重要的问题，因为日志记录的分析一般是需要使用专门的分析软件或者写专门的分析程序来分析的。如何设计合理的记录格式来利用已有的日志分析软件来进行分析是首要考虑的问题。,一般要对日志文件属性进行分析，应该具有文件名，还有存放位置，文件格式，文件内容、文件创建时间、文件大小、文件权限等属性。,30,2025/4/11 周五,举例说明如何进行测试需求分析（续,4,）,时间点：需求描述中提到了每天要生成一个日志文件，从文件创建时间属性来看，每天有,24,小时，到底从什么时候开始创建文件，从,0,点开始还是从几点开始，没有描述出来。,文件命名：从文件名属性来看，如何命名日志文件，需求中也没有提及。,文件位置：从存放位置属性来看，日志文件存放在什么地方也没有说明。是不是所有的日志文件都存放在应用程序同一子目录下？,文件格式：日志文件是以文本方式存储还是以二进制格式存储？,内容格式：文件的内容是以何种格式记录，每条访问记录间如何分隔，是以回车换行作为分隔还是以其他字符作为分隔？都没有描述。,其它内容：从文件内容属性来分析，除了存放上述描述的内容外，是否还可以保存其他内容，如果不能保存其他内容的话，需求描述中应该加上一句“日志文件中只能存储访问记录信息，不得储存其他记录信息”。,文件大小：从文件大小属性来分析，日志文件的大小有没有限制？如果某天处于访问高峰期，访问特别多，是否需要将日志文件分拆成多个是一个需要考虑的问题。,访问属性：从文件权限属性来分析，日志文件是否机器上的所有用户都可以访问还是只有特定的用户可以访问？文件是否需要设置权限是一个需要考虑的问题。,31,2025/4/11 周五,举例说明如何进行测试需求分析（续,5,）,需求描述中有很多的问题没有描述清楚。也许有人会有疑问，如果将所有上面说到的问题都描述出来的话会不会工作量太大了？,仅从需求分析的角度来讲，需求规格描述得较细的话确实会增大很多工作量，但从整个开发过程来看，需求描述完整的话，后续阶段的开发产生歧义和遗漏的可能性就很小，实际上后续阶段节约的时间会大大超过需求所多花的时间。,32,2025/4/11 周五,举例,WEB,应用测试需求分析,界面要素分析,页面链接：是否遗漏加链接，链接是否正确；,页面表单：例如用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性；,页面控件：如下拉值，下拉选中后，再次点击，选中焦点是否还在原来的下拉选项；如多选，单选是否正确；,33,2025/4/11 周五,举例,WEB,应用测试需求分析方法（续）,页面功能点分析,单个功能点的处理：正常操作、异常操作；,关联功能处理：,A,删除,QQ,中的好友,B,，在好友列表中就会去掉,B,的显示；在,B,的好友列表中，也会去掉,A,的显示；这点也通常称为关联测试点；,基于数据流的处理：商品库存数量，不同客户端订购并支付成功减少，退货成功后增加，在相关子系统的数据一致性,34,2025/4/11 周五,举例,WEB,应用测试需求分析方法（续）,功能交互分析,交互的入口要鲜明；,交互的步骤要简洁；,交互的结果要正确；,如答疑系统，当某问题再次被学员追问，追问的问题必须有列表显示，助教可清晰区分追问的问题和非追问的问题，助教回答问题后，用户可收到消息提醒；,35,2025/4/11 周五,测试需求分析方法（,1,）,业务流程分析：业务流逐渐细化为子业务流,常用的或规定的业务流程：,各业务流程分支的遍历,明确规定不可使用的业务流程,没有明确规定但是应该不可以执行的业务流程,提交答案,异常判断,确认是否提交,提交成功,是,否,36,2025/4/11 周五,测试需求分析方法（,2,）,用户场景分析,通常指事件触发的场景。,如微信的测试，当前账号已经登录微信了，再用该账号在其他地方登录微信；,如答疑系统中，助教,A,正要领取某问题的时候，助教,B,抢先领取了该问题；,37,2025/4/11 周五,测试需求分析方法（,3,）,不同角色的权限分析,技术实现原理上分析,系统边界分析,非功能性的特征分析,兼容性,系统响应,性能特性,38,2025/4/11 周五,测试需求分析步骤,对测试依据进行分析，列出的每一条开发需求对应的测试需求；,对上面步骤形成的每一条测试需求点，软件内部,/,外部质量模型来确定软件产品的质量需求；,对上面步骤所确定的质量需求，分析测试执行时需要实施的测试类型；,建立测试需求跟踪矩阵，对测试需求进行管理。,39,2025/4/11 周五,测试需求分析（,1,）,测试需求分析是对软件需求中每一条开发需求的细化和分解，形成的可测试的分层描述的软件测试需求。,对开发需求的细化和分解具体包括：,通过分析每条开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容；,通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据（功能交互分析），对存在功能交互的功能项，给出对应的验证内容。,40,2025/4/11 周五,进行细化和分解还需考虑：,需求的完整性，经过分解获得的需求必须能够充分覆盖软件需求的各种特征（包括隐含的特征），每个需求必须可以独立完成有意义的功能或功能组合，可以进行单独测试；,需求的规模，每个最低层次的需求能够使用数量相当的测试用例来实现，也即测试的粒度是均匀的,41,2025/4/11 周五,测试需求分析,-,举例,原始需求描述,标识,测试需求,一条完整的培训信息包括培训的主题、证书、内容、起止时间、费用、地点、机构，其中培训的主题、内容、起止时间、费用、机构为必填项。培训的起始时间不能晚于截止时间，培训费用精确到元角分。每一个输入项的数据规格在数据字典中可以得到。,1,输入符合字典要求的各信息后执行保存，检查保存是否成功；,2,检查每个输入项的数据长度是否遵循数据字典的要求；,3,检查每个输入项的数据类型是否遵循数据字典的要求；,4,检查“培训费用”是否满足规定的精度要求；,5,检查在培训的起止时间早晚于截止时间时，所增加的记录是否保存成功；,6,检查“培训主题”、“培训内容”、“起止时间”、“培训费用”、“培训机构”是否为必填项；,7,验证系统对数据重复的检查。,8,针对页面中文字、表单、图片、表格等元素，检查每个页面各元素的位置是否协调，各元素的颜色是否协调，各元素的大小比例是否协调；,9,页面信息内容显示是否完整；,10,检查是否有功能标识，功能标识是否准确、清晰；,11,最大化、最小化、还原、切换、移动窗口时是否能正常的显示页面。,42,2025/4/11 周五,分析质量特性,-,举例,质量特性对应表,原始需求描述,标识,测试需求,质量特性,一条完整的培训信息包括培训的主题、证书、内容、起止时间、费用、地点、机构，其中培训的主题、内容、起止时间、费用、机构为必填项。培训的起始时间不能晚于截止时间，培训费用精确到元角分。每一个输入项的数据规格在数据字典中可以得到。,1,输入符合字典要求的各信息后执行保存，检查保存是否成功；,功能性,/,适合性,2,检查每个输入项的数据长度是否遵循数据字典的要求；,功能性,/,适合性、可靠性,/,容错性,3,检查每个输入项的数据类型是否遵循数据字典的要求；,功能性,/,适合性、可靠性,/,容错性,4,检查“培训费用”是否满足规定的精度要求；,功能性,/,准确性,5,检查在培训的起止时间早晚于截止时间时，所增加的记录是否保存成功；,功能性,/,适合性,6,检查“培训主题”、“培训内容”、“起止时间”、“培训费用”、“培训机构”是否为必填项；,功能性,/,适合性,43,2025/4/11 周五,分析质量特性,-,举例,质量特性对应表,原始需求描述,标识,测试需求,质量特性,一条完整的培训信息包括培训的主题、证书、内容、起止时间、费用、地点、机构，其中培训的主题、内容、起止时间、费用、机构为必填项。培训的起始时间不能晚于截止时间，培训费用精确到元角分。每一个输入项的数据规格在数据字典中可以得到。,7,验证系统对数据重复的检查。,功能性,/,适合性,8,针对页面中文字、表单、图片、表格等元素，检查每个页面各元素的位置是否协调，各元素的颜色是否协调，各元素的大小比例是协调；,易用性,/,易操作性,9,页面信息内容显示是否完整；,易用性,/,易操作性、易理解性,10,检查是否有功能标识，功能标识是否准确、清晰；,易用性,/,易理解性,11,最大化、最小化、还原、切换、移动窗口时是否能正常的显示页面。,易用性,/,易操作性,44,2025/4/11 周五,45,2025/4/11 周五,46,2025/4/11 周五,Thank you!,47,2025/4/11 周五,