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

任务一、根据需求分析明确测试需求与任务;能够区分测试需求与软件需求 能够收集测试需求 了解测试需求的特征;定义：描述在你的应用程序中哪些需要被测试，简单来讲就是一个测试的范围。根据这个范围再来拟制测试计划 依据：软件规格说明书、市场需求，产品本身的属性 内容：内容就是需要被测试的“哪些”，这个“哪些”包括——功能、性能与效率、易用性、配置、兼容性 测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。 测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求； ; 制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求； 测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件； 测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容。;软件测试需求是开发测试用例的依据。 有助于保证测试的质量与进度 。 测试需求是衡量测试覆盖率的重要指标。;1.把不直观的需求-直观的需求（用例/活动图） 使得测试范围可以度量（功能点的数量、功能项的数量）； 使得独立的功能点其对应的所有的处理分支可以度量； 使得该系统需要测试的业务场景可以度量 2.把不明确的需求-明确的需求 明确其功能点对应的输入、处理、输出 3.把不能度量的需求-可度量的需求;软件需求：项目所要实现的功能以及要达到的性能，主要面向开发人员 测试需求：描述的是测试点，包括各个功能点，功能间的交互，硬件及软件环境等，主要面向测试人员;需求分析：初步设想----原始需求---需求分析---需求规格：输入、处理和输出 测试需求分析：单功能点输入处理输出-----业务流分析----全局---隐式需求挖掘 需求分析和测试需求分析两者的过程是相反的 ;1.熟悉需求 2.需求项整理 3.提取出测试点 4.测试点细化 5.确定测试范围 6.制定测试策略;需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求。 可测试性是指这些提取的需求或特性必须存在一个可以明确预知的结果，可以用某种方法对这个明确的结果进行判断、验证，验证是否符合文档中的要求。 ;需求采集的提取方法： 通过列表的形式对软件开发需求进行梳理，形成原始测试需求列表，列表的内容包括需求标识、原始测试需求描述、信息来源。 将每一条软件需求对应的开发文档及章节号作为软件需求标识。 使用软件需求的简述作为原始测试需求描述。 软件需求获取的来源信息 作为信息来源。;提取的原始测试需求中，可能存在重复和冗余，在提取原始测试需求过程中，可以通过以下方法整理原始测试需求： 删除：删除原始测试需求表中重复的、冗余的含有包含关系的原始测试需求描述； 细化：对太简略的原始测试需求描述进行细化； 合并：如果有类似的原测试始需求，在整理时需要对其进行合并。 ;功能需求—输入方面 输入来源是什么？ 输入数据数量是几个？ 如果有错误输入，响应是什么？ 什么是非法输入？什么是无效输入？ 功能需求—处理方面 输入数据的有效性检测的流程是什么？ 操作的确切次序，包括各事件的时序是什么？ 对异常情况的回应是什么？例如：溢出、通信失败、错误处理 ;功能需求—结果输出方面 输出到何处（如浏览器，打印机，文件）？ 输出的数量是多少？ 输出的时序是什么样的？ 对非法值的处理是什么样的？ 功能需求—性能需求方面 静态量化可能包含：支持的终端数目，支持的同时使用的用户数，处理的文件和记录的数目，表和文件的大小 动态量化可能包含：在正常或峰值工作量情况下一个特定时间段处理事务或任务的数目及数据量。在正常或峰值工作量情况下处理某个事务或任务所占用系统资源的数量 ;功能需求—用户接口方面 系统用户显示时要求的屏幕格式 页面规划及报告或菜单的内容 输入和输出的相关时序 一些组合功能键的用法 功能需求—硬件接口方面 描述软件产品和系统硬件组件之间接口的逻辑特征 该功能运行支持哪些设备？怎样支持这些设备和协议呢？ ;“人力资源管理系统”原始测试需求表;a）对原始测试需求列表中列出的每一条开发需求，形成可测试的分层描述的测试要点； b）对步骤a）形成的每一条测试要点，确定软件产品的质量需求； c）对步骤b）所确定的质量需求，分析测试执行时需要实施的测试类型； d）建立测试需求跟踪矩阵，对测试需求进行管理。;测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求。 对开发需求的细化和分解具体包括： 通过分析每条开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容； 通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据（功能交互分析） ，对存在功能交互的功能项，给出对应的验证内容