软件测试管理之测试需求分析精.docx
《软件测试管理之测试需求分析精.docx》由会员分享，可在线阅读，更多相关《软件测试管理之测试需求分析精.docx（18页珍藏版）》请在冰豆网上搜索。
软件测试管理之测试需求分析精
S1测试需求及需求分析
•1测试需求概述
-1.1什么是测试需求
-1.2测试需求的特征
-1.3为什么需要测试需求
•2测试需求分析过程
-2.1需求采集
-2.2测试需求分析
-2.3测试需求评审
逼”1什么是测试需求
•测试需求主要解决“测什么”的问题，即指明被测对象中什么需要测试。
・测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。
•测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求；
1.2测试需求的特征
制定的测试需求项必须是可核实的
可评测的结果,
同
•璽離齡髓歸翱离I据,
测试数据设计
.3为什么需要测试需求
•软件测试需求是开发测试用例的依据。
•有助于保证测试的质量与进度。
•测试需求是衡量测试覆盖率的重要指标。
2测试需求分析过程
乔求飒格说明书
占亠嘗土
要交特类
Sim
测版荼求
2.1
需求采集
•需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出來，形成原始测试碍求。
•可测试性是指这些提取的需求或特性必须存在一个可以明确预知的结果，可以用某种方法对这个明确的结果进行判断、验证，验证是否符合文档中的要求。
2.1需求采集
•需求采集的提取方法；
-通过列表的形式对软件开发需求进行梳理，形成原始测试需求列表，列表的内容包括需求标识、原始测试需求描述、信息*源。
-将每一条软件需求对应的开发文档及章节号作为软件需求标识。
-使用软件需求的简述作为原始测试需求描述。
-软件需求获取的来源信息作为信息来源。
•提取的原始测试需求中，可能存在重复和冗余，在提取原始测试需求过程中，可以通过以下方法整理原始测试需求：
-删除：
删除原始测试需求表中重复的、冗余的含有包含关系的原始测试需求描述；
-细化：
对太简略的原始测试需求描述进行细化；
-合并：
如果有类似的原测试始需求，在整理时需要对其进行合并。
需求采集举例
“人力资源管理系统”原始测试需求表
序号
软件需求标识
原始测试需求描述
信息来源
1
3丄1基木信息管理
增加员工信息
人事部门招聘专员对于新招聘的职员信息可以录入到HRMIS系统中,主要职员信息如下：
姓名.性别、出生II期、政治面貌.文化水¥、婚姻時况、家庭住址.身份证号.办公电话、移动电话、紧急怡况卜的联系人和耽系方式、毕业院校、入职时间.崗位及职责，其中，性别包含男、女两个类别：
婚姻悄况包括未婚.己婚、离异三种時况。
人力资源管理系统业务需求说明书
删除员匸信息
删除需用八确认，町以逐条删除或多条一次删除
GB/T17544-
1998
2
322时间特性耍求
并发15个用户，平均登录时间小于10秒
人力资源管理系统业务需求说明书
3
隐含而求：
在使用中操作错误的易恢复性
程序应对关键数据的操作给出警告或在执行前确认
GB/T17544-
1998
下一活动
•a）对原始测试需求列表中列小的每一条开发需求，形成可测试的分层描述的测试要点;
•b）对步骤a）形成的每一条测试要点，从GB/T16260.1-2006《软件工程产品质量第1部分：
质量模型》中定义的软件内部/外部质量模型來确定软件产品的质量需求；
•c）对步骤b）所确定的质量需求，分析测试执行时需要实施的测试类型；
•d）建立测试需求跟踪矩阵，对测试需求进行管理。
•测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求。
•对开发需求的细化和分解具体包扌舌：
-通过分析每条开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容；
-通过分析各个功能模块之间的业务顺序，和各个功能模块Z间传递的信息和数据（功能交互分析），对存在功能交互的功能项，给出对应的验证内容。
•功能交互分析
回2.2.1测试要点分析
•进行细化和分解还需考虑:
-需求的完整性，经过分解获得的需求必须能够充分覆盖软件需求的各种特征（•包括隐含的特征），每个需求必须可以独立完成有意义的功能或功能组合，可以进行单独测试；
-需求的规模，每个最低层次的需求能够使用数量相当的测试用例来实现，也即测试的粒度是均匀的
區2.2.1测试要点分析-举例
原始需求描述
标识
测试要点
一条完整的培训信息包括培训的主题.证书、内容.起止时间、费用、地点、机构，其中培训的主题、内容、起止时间、费用.机构为必填项•培训的起始时间不能晚于截止时间，培训费用精确到元角分。
每一个输入项的数据规格在数据字典中可以得到•
1
输入符合字典要求的各信息后执行保存，检査保存是否成功；
2
检査每个输入项的数摇长度是否遵循数据字典的要求：
3
检査每个输入项的数据类型是否遵循数据字典的要求：
4
检査“培训费用”是否满足規定的精度要求；
5
检査在培训的起止时间早晚于截止时间时.所増加的记录是否保存成功；
6
检査“培训主题”、“培训内容”、“起止时间”、“培训费用”、“培训机构”是否为必填项：
7
验证系统对数据重复的检査•
8
针对页面中文字.表单.图片.表格等元素.检査每个页面各元素的位置是否协调，各元素的颜色是否协调.各元素的大小比例是否
9
页面信息内容显示是否完整；
10
检査是否有功能标识.功能标识是否准确、清晰；
11
最大化.最小化、还原.切换.移动窗口时是否能正常的显示页面。
•对每一条测试要点，从GB/T16260.1定义的软件质量子特性角度出发，确定所对应的质量子特性。
]2.2.2分析质量特性-举例
质量转性对应表
原始需求描述
标识
测试要点
质量特性
一条完整的培训借息包括培训的主题、证书.内容.起止时间.费用、地点.机构.其中培训的主题.内容.起止时间、费用.机构为必填项。
培训的起始时间不能晚于裁止时间.培训费用精确到元角分.每个输入项的数摇规格在数据字典中可以得到.
1
输入符合字典要求的各信息后执行保存.检査保存是否成功）
功能性/适合性
2
检査每个输入项的数据长度是否遵循数据字典的要求；
功能性/适合性、可靠性/容错性
3
检査每个输入项的数据类型是否遵循数据字典的要求$
功能性/适合性、可施性/容错性
4
检査“培训费用”是否滞足规定的精度要求；
功能性/准确性
5
检査在培训的起止时间早晚于截止时间时.所増加的记录是否保存成功；
功能性/适合性
6
检査“培训主题”.“培训内容“起止时间”.“培训费用”、“培训机构”是否为必填项：
功能性/适合性
质量特性对应表
原始需求描述
标识
测试要点
质量特性
一条完整的培训倍息包括培训的主题、证书、内容、起止时间、费用.地点、机构.其中培训的主题.内客、起止时间.费用、机构为必填项。
培训的起始时间不能晚于截止时间.培训费用精确到元角分•每一个输入项的数据規格右数据字典中可以得
7
验证系统对数据重复的检査•
功能性/适合性
8
针对页面中文字、表单、图片、表格等元素.检査每个页面各元素的位置是否协调.各元素的颜色是否协调，各元素的大小比例是协调'
易用性/易操作性
9
页面信息内容显示是否完整；
易用性/易操作性、易理解性
10
检査是否有功能标识，功能标识是否准确.清晰：
易用性/易理解性
11
最大化.最小化.还原.切换.移动窗口时是否能正常的显示页面•
易用性/易操作性
Si2.2.2分析质量特性-举例
•试内介'这些测试
•软件测试可以划分为以下测试类型：
功能测试、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复性测试、配置测试、兼容性测试、安装测试等。
-醪擁蠶孵鷲初緞輪斃礬测试内容'可
质量特性对应表
原始滞求描述
标识
测试耍点
质量待性
测试类型
一条完整的培训倍息包括培训的主題.证书.内容.起止时间.费用.地点.机构.其中培训的主题.内容、起止时间.费用、机构为必填项•培训的起始时间不能晚于截止时间，培训费用精确到元角分•每一个输入项的数据规格在数据字典中可以得到・
1
输入符合字典要求的各信息后执行保存■检查保存是否成功：
功能性/适合性
功能测试
2
检査每个输入项的数据长度是否遵循数据字典的要求'
功能性/适合性.可靠性/容错性
功能测试.完整性测试
3
检査每个输入项的数据类型是否遵循数摇字典的要求1
功能性/适合性.可靠性/容错性
功能测试、宪整性测试
4
检査“培训费用”是否満足规定的精度要求：
功能性/准确性
功能测试
5
检査在培训的起止时间早晚于截止时间时，所增加的记录是否保存成功；
功能性/适合性
功能测试
6
检査“培训主题”.“培训内容”、“起止时间”、“培训费用”■編培训机构”是否为必填项；
功能性/适合性
功能测试
2.2.3分析测试类型
质最特性对应表
原始需求描述
标识
测试耍点
质童特性
测试类型
一条完整的培训信息包括培训的主题、证书.内容.起止时间、费用.地点、机构，其中培训的主题、内客、起止时间.费用.机构为必填项•培训的起始时间不能晚于截止时间.培训费用精确到元角分•每一个输入项的数据规格右数据•字典中可以得
7
验证系统对数据匣复的检査•
功能性/适合性
功能测试
8
针对页面中文字.表单.图片、表格等元素，检査每个页面各元素的位負是否协调，各元素的颜色是否协调，各元素的大小比例是协调：
易用性/易操作性
用户界面测试
9
页面侑息内容显示是否完整；
易用性/易操作性
用户界面测试
10
检査是否有功能标识.功能标识是否准确、清晰:
易用性/易理解性
用户界面测试.功能测试
11
最大化.最小化、还原.切换.移动窗口时是否能正常的显示页面・
易用性/易操作性
用户界面测试
•为了避免遗漏，在确定测试类型时，还需考虑：
-文档屮是否包含测试类型相对应的情况的说明；
-列出的常见测试类型是否已完全覆盖了被测软件；
-被测软件的某些特殊情况是否已包含在所列出的测试类型中。
2.2.4测试需求跟踪矩阵
•建立测试需求跟踪矩阵，对测试需求进行管理。
将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。
•测试需求跟踪矩阵为原始测试需求与测试要点的对血头紊表，格衣如-卜':
软件需求
测试需求
软件需求标识
软件需求描述
测试需求标识
测试要点
测试类型
•建立测试需求跟踪矩阵，对测试需求进行管理。
将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。
•通过测试需求跟踪矩阵的方式对需求变更实施管理。
软件需求一旦发生变化，就要对需求跟踪表进行维护，启动配置管理过程，将与软件需求变更相关的内容进行同步变更。
HRMIS2.0测试需求跟踪矩阵
软件需求
测试需求
软件需求标识
软件需求描述
测试需
求标识
测试要点
测试类型
3.1.1基本信息管理
一条完整的培训信息包抵培训的主题、证书.内容、起止时间・费用.地点、机构，其中培训的主IBL内容、起止时间.费用、机构为必填项•培训的起始时间不能晚于截止时间.培训费用稱确到元角分・每一个输入项的数据规格应遵循数据字典的要求.
1
输入符合字典要求的各伯息后执行保存.检査保存是否成功：
功能测试
2
检査每个输入项的数期长度是否遵循数括字典的要求；
功能测试、完整性测试
慚S1
3
检杳每个输入项的数据类型是否遵循数括字典的要求：
功能测试、完整性测试
4
检査“培训费用”是否满足规定的梢度要求y
功能测试
5
检査在培训的起止时间早晚于截止时间时，所增加的记录是否保存成功；
功能测试
6
检査“培训主题J“培训内容”、“起止时间”、“培训费用”.“培训机构”是否为必填项：
功能测试
2.2.4测试需求跟踪矩阵-举例
HRMIS2.0测试縄求跟踪矩阵
软件需求
测试需求
软件需求标识
软件需求描述
测试需
求标识
测试要点
测试类型
3.1.1基本伯息管理
一条完戟的培训信息包括培训的主题、证书、内容、起止时间.费用.
地点、机构，其中培训的主题、内容、起止时间、费用.
机构为必填项•培讥的起始时间不能晚于截止时间.培训费用精确到元角分。
每一个输入项的数据规格应遵循数据字典的要求.
7
验证系统时數据卓复的检査。
功能测试
加训息增培信
8
许对页面中文字、表单、图片、表格等元素.检査每个页面各元索的位置是否协调，各元素的锁色是否协调.各元素的大小比例是协调：
用户界面测试
9
页面信•息内容显示是否完
用户界面测试
10
检査是否有•功能标识.功能标识是否准确、清晰；
用户界面测试、功能测试
11
量大化.鍛小化、还原.切换、移动窗口时是否廃正常的显示页面.
用户界面测试
；・4测试需求跟踪矩阵
•测试需求跟踪矩阵需要不断的维护。
-一方面，软件需求一旦发生变化，应启动配置管理过程，将与软件需求变更相关的内容进行同步变更；
-另一方面，随着测试工作的进行，会不断添加新的跟踪内容，对跟踪表进行扩展。
例如，测试设计阶段的测试用例、测试执行阶段的测试记录和测试缺陷都可以添加到跟踪矩阵中。
软件需求
测试需求
测试用例
软件需求标识
软件需求描述
测试需求标识
测试要点
测试类型
用例标识
用例描述
•评审的内容：
-完整性审查：
应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方而，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
-准确性审查：
应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。
•评审的形式
-相互评审、交叉评审：
甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查,乙的工作成果交给甲审查。
相互评审是最不正式的一种评审形式，但应用方便、有效。
-轮查：
又称分配审查方法，是一种异步评审方式。
作者将需耍评审的内容发送给各位评审员，并收集他们的反馈意见。
•评审的形式
-走查：
作者将测试需求在现场向一组同事介绍，以收集人家的意见。
希望参与评审的其他同事可以发现其中的错误，并能进行现场讨论。
这种形式介于正式和非正式之间。
-小组评审：
通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式。
评审定义了评审会议中的各种角色和相应的责任，所有参与者在评审会议的前儿天就拿到了评审材料，并对该材料进行了独立研究。
•评审的形式
-审查：
审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、准备和组织会议、跟踪和分析审查结果等。
•评审的人员组成：
-正式评审小组中，一般存在多种角色，包扌舌协调人、作者、评审员等。
-评审员需要精心挑选，保证不同类型的人员都要参与进行来，通常包插开发经理、项目经理、测试经理、系统分析人员、相关开发人员和测试人员等。
升级会员 