测试需求及需求分析

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

2.1 需求采集
• 需求采集的提取方法:
– 通过列表的形式对软件开发需求进行梳理,形成原始 测试需求列表,列表的内容包括需求标识、原始测试 需求描述、信息来源。 – 将每一条软件需求对应的开发文档及章节号作为软件 需求标识。
– 使用软件需求的简述作为原始测试需求描述。
– 软件需求获取的来源信息 作为信息来源。
1.3 为什么需要测试需求
• 软件测试需求是开发测试用例的依据。 • 有助于保证测试的质量与进度 。
• 测试需求是衡量测试覆盖率的重要指标。
2 测试需求分析过程Байду номын сангаас
2.1 需求采集
• 需求采集的过程是将软件开发需求中的那些具有 可测试性的需求或特性提取出来,形成原始测试 需求。
• 可测试性是指这些提取的需求或特性必须存在一 个可以明确预知的结果,可以用某种方法对这个 明确的结果进行判断、验证,验证是否符合文档 中的要求。
2.2.2 质量特性分析
• 对每一条测试要点,从GB /T16260.1定义 的软件质量子特性角度出发,确定所对应 的质量子特性。
2.2.2 分析质量特性-举例
测试需求及需求分析
测试需求及需求分析
• 1 测试需求概述
– 1.1 什么是测试需求
– 1.2 测试需求的特征 – 1.3 为什么需要测试需求 • 2 测试需求分析过程 – 2.1 需求采集 – 2.2 测试需求分析 – 2.3 测试需求评审
1.1 什么是测试需求
• 测试需求主要解决“测什么”的问题 ,即指明 被测对象中什么需要测试。 • 测试需求通常是以软件开发需求为基础进行分 析,通过对开发需求的细化和分解,形成可测 试的内容。
• 测试需求应全部覆盖已定义的业务流程,以及 功能和非功能方面的需求;
1.2 测试需求的特征
• 制定的测试需求项必须是可核实的。即,它们必 须有一个可观察、可评测的结果,无法核实的需 求不是测试需求;
• 测试需求应指明满足需求的正常的前置条件,同 时也要指明不满足需求时的出错条件; • 测试需求不涉及具体的测试数据,测试数据设计 是测试设计环节应解决的内容。
2.1 需求采集
• 提取的原始测试需求中,可能存在重复和冗余, 在提取原始测试需求过程中,可以通过以下方法 整理原始测试需求:
– 删除:删除原始测试需求表中重复的、冗余的含有包 含关系的原始测试需求描述; – 细化:对太简略的原始测试需求描述进行细化; – 合并:如果有类似的原测试始需求,在整理时需要对 其进行合并。
2.2.1 测试要点分析
• 测试要点是对原始测试需求表每一条开发需求的 细化和分解,形成的可测试的分层描述的软件需 求。 • 对开发需求的细化和分解具体包括:
– 通过分析每条开发需求描述中的输入、输出、处理、 限制、约束等,给出对应的验证内容;
– 通过分析各个功能模块之间的业务顺序,和各个功能 模块之间传递的信息和数据(功能交互分析) ,对存 在功能交互的功能项,给出对应的验证内容。
2.1 需求采集-举例
“人力资源管理系统”原始测试需求表 序号
1
软件需求标识
3.1.1基 增加员工 本信息 信息 管理
原始测试需求描述
信息来源
人事部门招聘专员对于新招聘的职员信 人力资源管理 息可以录入到HRMIS系统中,主要职员 系统业务需求 信息如下:姓名、性别、出生日期、政 说明书 治面貌、文化水平、婚姻情况、家庭住 址、身份证号、办公电话、移动电话、 紧急情况下的联系人和联系方式、毕业 院校、入职时间、岗位及职责,其中, 性别包含男、女两个类别;婚姻情况包 括未婚、已婚、离异三种情况 。 删除需用户确认,可以逐条删除或多条 GB/T 17544一次删除 1998 并发15个用户,平均登录时间小于10 秒 人力资源管理 系统业务需求 说明书
删除员工 信息 2 3.2.2时间特性要求
3
隐含需求:在使用 中操作错误的易恢 复性
程序应对关键数据的操作给出警告或在 GB/T 17544执行前确认 1998
2.2 测试需求分析
2.2 测试需求分析
• a)对原始测试需求列表中列出的每一条开发需求,形成 可测试的分层描述的测试要点; • b)对步骤a)形成的每一条测试要点,从GB/T 16260.12006《软件工程 产品质量 第1部分:质量模型》中定义的 软件内部/外部质量模型来确定软件产品的质量需求; • c)对步骤b)所确定的质量需求,分析测试执行时需要实 施的测试类型; • d)建立测试需求跟踪矩阵,对测试需求进行管理。
2.2.1 测试要点分析
• 功能交互分析
2.2.1 测试要点分析
• 进行细化和分解还需考虑:
– 需求的完整性,经过分解获得的需求必须能够充分覆 盖软件需求的各种特征(包括隐含的特征),每个需 求必须可以独立完成有意义的功能或功能组合,可以 进行单独测试; – 需求的规模,每个最低层次的需求能够使用数量相当 的测试用例来实现,也即测试的粒度是均匀的
2.2.1 测试要点分析-举例
原始需求描述 标识 1 2 3 一条完整的培训信息包括培训 的主题、证书、内容、起止时 间、费用、地点、机构,其中 培训的主题、内容、起止时间、 费用、机构为必填项。培训的 起始时间不能晚于截止时间, 培训费用精确到元角分。每一 个输入项的数据规格在数据字 典中可以得到。 9 10 11 8 6 7 4 5 测试要点 输入符合字典要求的各信息后执行保存,检查保存是否成功; 检查每个输入项的数据长度是否遵循数据字典的要求; 检查每个输入项的数据类型是否遵循数据字典的要求; 检查“培训费用”是否满足规定的精度要求; 检查在培训的起止时间早晚于截止时间时,所增加的记录是否保存 成功; 检查“培训主题”、“培训内容”、“起止时间”、“培训费用”、 “培训机构”是否为必填项; 验证系统对数据重复的检查。 针对页面中文字、表单、图片、表格等元素,检查每个页面各元素 的位置是否协调,各元素的颜色是否协调,各元素的大小比例是否 协调; 页面信息内容显示是否完整; 检查是否有功能标识,功能标识是否准确、清晰; 最大化、最小化、还原、切换、移动窗口时是否能正常的显示页面。
相关文档
最新文档