单元二任务一将软件需求转化为测试需求.ppt

《单元二任务一将软件需求转化为测试需求.ppt》由会员分享，可在线阅读，更多相关《单元二任务一将软件需求转化为测试需求.ppt（42页珍藏版）》请在三一办公上搜索。

1、单元二、计划测试工作,任务一、根据需求分析明确测试需求与任务,能够区分测试需求与软件需求能够收集测试需求了解测试需求的特征,能力目标,测试需求,定义：描述在你的应用程序中哪些需要被测试，简单来讲就是一个测试的范围。根据这个范围再来拟制测试计划依据：软件规格说明书、市场需求，产品本身的属性内容：内容就是需要被测试的“哪些”，这个“哪些”包括功能、性能与效率、易用性、配置、兼容性测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求；,测试需求的特征,制定的测试需求项必须是可核实的。即，它们必须有一个

2、可观察、可评测的结果，无法核实的需求不是测试需求；测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件；测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容。,为什么需要测试需求,软件测试需求是开发测试用例的依据。有助于保证测试的质量与进度。测试需求是衡量测试覆盖率的重要指标。,1.把不直观的需求-直观的需求（用例/活动图）使得测试范围可以度量（功能点的数量、功能项的数量）；使得独立的功能点其对应的所有的处理分支可以度量；使得该系统需要测试的业务场景可以度量2.把不明确的需求-明确的需求明确其功能点对应的输入、处理、输出3.把不能度量的需求-可度量的需求,

3、测试需求分析要达到的目的,软件需求：项目所要实现的功能以及要达到的性能，主要面向开发人员测试需求：描述的是测试点，包括各个功能点，功能间的交互，硬件及软件环境等，主要面向测试人员,软件需求与测试需求的区别,需求分析：初步设想-原始需求-需求分析-需求规格：输入、处理和输出测试需求分析：单功能点输入处理输出-业务流分析-全局-隐式需求挖掘需求分析和测试需求分析两者的过程是相反的,需求分析与测试需求分析的区别,测试需求分析过程,1.熟悉需求2.需求项整理3.提取出测试点4.测试点细化5.确定测试范围6.制定测试策略,测试需求分析的过程,需求采集,需求分析,需求采集,需求采集的过程是将软件开发需求中

4、的那些具有可测试性的需求或特性提取出来，形成原始测试需求。可测试性是指这些提取的需求或特性必须存在一个可以明确预知的结果，可以用某种方法对这个明确的结果进行判断、验证，验证是否符合文档中的要求。,需求采集,需求采集的提取方法：通过列表的形式对软件开发需求进行梳理，形成原始测试需求列表，列表的内容包括需求标识、原始测试需求描述、信息来源。将每一条软件需求对应的开发文档及章节号作为软件需求标识。使用软件需求的简述作为原始测试需求描述。软件需求获取的来源信息 作为信息来源。,需求采集,提取的原始测试需求中，可能存在重复和冗余，在提取原始测试需求过程中，可以通过以下方法整理原始测试需求：删除：删除原始

5、测试需求表中重复的、冗余的含有包含关系的原始测试需求描述；细化：对太简略的原始测试需求描述进行细化；合并：如果有类似的原测试始需求，在整理时需要对其进行合并。,需求采集内容（1）,功能需求输入方面输入来源是什么？输入数据数量是几个？如果有错误输入，响应是什么？什么是非法输入？什么是无效输入？功能需求处理方面输入数据的有效性检测的流程是什么？操作的确切次序，包括各事件的时序是什么？对异常情况的回应是什么？例如：溢出、通信失败、错误处理,需求采集内容（2）,功能需求结果输出方面输出到何处（如浏览器，打印机，文件）？输出的数量是多少？输出的时序是什么样的？对非法值的处理是什么样的？功能需求性能需求方

6、面静态量化可能包含：支持的终端数目，支持的同时使用的用户数，处理的文件和记录的数目，表和文件的大小动态量化可能包含：在正常或峰值工作量情况下一个特定时间段处理事务或任务的数目及数据量。在正常或峰值工作量情况下处理某个事务或任务所占用系统资源的数量,需求采集内容（3）,功能需求用户接口方面系统用户显示时要求的屏幕格式页面规划及报告或菜单的内容输入和输出的相关时序一些组合功能键的用法功能需求硬件接口方面描述软件产品和系统硬件组件之间接口的逻辑特征该功能运行支持哪些设备？怎样支持这些设备和协议呢？,需求采集-举例,测试需求分析的步骤,测试需求分析的步骤,a）对原始测试需求列表中列出的每一条开发需求，

7、形成可测试的分层描述的测试要点；b）对步骤a）形成的每一条测试要点，确定软件产品的质量需求；c）对步骤b）所确定的质量需求，分析测试执行时需要实施的测试类型；d）建立测试需求跟踪矩阵，对测试需求进行管理。,Step1-测试要点分析（1）,测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求。对开发需求的细化和分解具体包括：通过分析每条开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容；通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据（功能交互分析），对存在功能交互的功能项，给出对应的验证内容。,Step1-测试要点分析（2

8、）,进行细化和分解还需考虑：需求的完整性，经过分解获得的需求必须能够充分覆盖软件需求的各种特征（包括隐含的特征），每个需求必须可以独立完成有意义的功能或功能组合，可以进行单独测试；需求的规模，每个最低层次的需求能够使用数量相当的测试用例来实现，也即测试的粒度是均匀的,Step2-质量特性分析,对每一条测试要点，确定所对应的质量子特性。,质量特性定义,功能性适合性：软件产品为指定的任务和用户目标提供一组合适的功能的能力。准确性：软件产品提供具有所需精度的正确或相符的结果或效果的能力。可靠性容错性：在软件出现故障或违反其指定接口的情况下，软件产品维持规定的性能级别的能力。易用性易理解性：软件产品使

9、用户能理解软件是否合适以及如何能将软件用于特定的任务和使用条件的能力。易操作性：软件产品使用户能理解和操作它的能力。,分析质量特性-举例,分析质量特性-举例,Step3-分析测试类型(1),不同的质量子特性可以确定出不同的测试内容，这些测试内容可以通过不同的测试类型来实施。软件测试可以划分为以下测试类型：功能测试、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复性测试、配置测试、兼容性测试、安装测试等。根据质量子特性的定义，以及各测试类型的测试内容，可以分析出质量子特性与测试类型的对应关系。,Step3-分析测试类型(2),质量子特性和

10、测试类型的对应关系基准表,功能测试：侧重于验证测试目标预期功能，确保满足提供所需的服务、方法或用例。针对不同测试目标（包括单元、集成单元、应用程序和系统）实施和执行此测试。完整性测试：侧重于评估测试目标的健壮性（防止故障）和语言、语法和资源用途的技术一致性。针对不同测试目标（包括单元和集成单元）实施并执行此测试。容量测试：侧重于验证测试目标处理大量数据的能力，可以是输入和输出或数据库中驻留的数据。,安全性测试：侧重于确保测试目标数据只供预订好的那些参与者访问。针对各种测试目标实施并执行此测试。接口测试：侧重于验证测试目标的数据接口的正确性和对其设计的遵循性。结构测试：侧重于评估测试目标对其设计

11、和形式的遵循性。通常，对支持web的应用程序执行此测试，以确保连接所有链接，显示合适的内容和未孤立任何内容。,用户界面测试：侧重于验证测试目标预期功能，确保满足提供所需的服务、方法或用例。针对不同测试目标（包括单元、集成单元、应用程序和系统）实施和执行此测试。完整性测试：侧重于评估测试目标的健壮性（防止故障）和语言、语法和资源用途的技术一致性。针对不同测试目标（包括单元和集成单元）实施并执行此测试。容量测试：侧重于验证测试目标处理大量数据的能力，可以是输入和输出或数据库中驻留的数据。安全性测试：侧重于确保测试目标数据只供预订好的那些参与者访问。针对各种测试目标实施并执行此测试。接口测试：侧重于

12、验证测试目标的数据接口的正确性和对其设计的遵循性。结构测试：侧重于评估测试目标对其设计和形式的遵循性。通常，对支持web的应用程序执行此测试，以确保连接所有链接，显示合适的内容和未孤立任何内容。,分析测试类型-举例,分析测试类型-举例,Step4-测试需求跟踪矩阵(1),建立测试需求跟踪矩阵，对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。测试需求跟踪矩阵为原始测试需求与测试要点的对应关系表，格式如下：,Step4-测试需求跟踪矩阵(2),建立测试需求跟踪矩阵，对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵

13、。通过测试需求跟踪矩阵的方式对需求变更实施管理。软件需求一旦发生变化，就要对需求跟踪表进行维护，启动配置管理过程，将与软件需求变更相关的内容进行同步变更。,测试需求跟踪矩阵-举例,增加培训信息,测试需求跟踪矩阵-举例,增加培训信息,测试需求评审,评审的内容：完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作

14、为测试用例设计的依据。,测试需求评审,评审的形式相互评审、交叉评审：甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查。相互评审是最不正式的一种评审形式，但应用方便、有效。轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收集他们的反馈意见。,测试需求评审,评审的形式走查：作者将测试需求在现场向一组同事介绍，以收集大家的意见。希望参与评审的其他同事可以发现其中的错误，并能进行现场讨论。这种形式介于正式和非正式之间。小组评审：通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式。评审定义了评审会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进行了独立研究。,测试需求评审,评审的形式审查：审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、准备和组织会议、跟踪和分析审查结果等。,测试需求评审,评审的人员组成：正式评审小组中，一般存在多种角色，包括协调人、作者、评审员等。评审员需要精心挑选，保证不同类型的人员都要参与进行来，通常包括开发经理、项目经理、测试经理、系统分析人员、相关开发人员和测试人员等。,选择“大学学籍管理系统”的某一功能，按照测试需求分析的4个步骤，完成对该功能的“测试需求跟踪矩阵”,作业,