需求分解与需求跟踪矩阵

需求分解是将需求分解成一个个的功能点。先写出大的模块,然后子模块,然后细分成各个功能点,模块的个数名称,子模块的层数,名称,功能点均可维护。同时每个功能点后面还有开发人员和维护人员的记录。开发人员和维护人员可以根据不同时期叠加。
模块名称 子模块名称1 子模块名称2 功能点 开发人员 维护人员 备注





需求跟踪矩阵保存需求与最终成果间的对应关系。具体就是要写出需求中功能点相对应的需求分析文档,详细设计文档,代码及相应的版本。
入口:从需求分解中取出详细的功能点。
功能点:功能点编号,功能点说明,所属模块,功能点变更;功能点的变更可以有数次。
需求文档:各功能点对应的需求文档,文档名称,作者,基线时间,版本,修改时间,备注
。每个文档可以有数次的修改。
设计文档:各功能点对应的设计文档,文档名称,作者,基线时间,版本,修改时间,备注。每个文档可以有数次的修改。
代码:对应功能点编号,组件/包/类名称,代码存放位置,文件名称,作者,版本
测试报告:测试报告名称
需求跟踪矩阵
原始需求 需求分析 设计 代码 测试
功能点1 需求文档名称 设计文档 组件/包/类名称 测试报告名称
功能点2
功能点3


功能点
功能点编号 功能点说明 所属模块 功能点变更时间 功能点变更次数 功能点变更内容
需求文档
文档名称 作者 基线时间 版本 修改时间 备注
代码
功能点编号 代码存放位置 文件名称 作者 版本
软件测试需求是开发测试用例的依据,测试需求分解的越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,对测试用例的设计质量的帮助越大。详细的测试需求还是衡量测试覆盖率的重要指标,测试需求是计算测试覆盖的分母,没有详细的测试需求就无法有效的进行测试覆盖计算。 软件测试执行阶段是由一系列不同的测试类型的执行过程组成的,每种测试类型都有其具体的测试目标和支持技术,每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试,准确的测试类型可以给软件测试带事半功倍的效果。 现有的软件测试分析技术不太成熟,对测试需求和测试类型的分析,所采用的方法主要是根据经验进行收集、整理,该方法依赖于测试设计人员的测试经验,由此方法得出的测试需求、测试类型往往导致测试用例设计不充分,测试覆盖度低,测试目的性不强,容易遗漏等缺陷。 可见,如何对测试需求进行细致的整理分析,明确测试执行时的测试类型,是一个亟待解决的问题。 有鉴于此,本方法的主要目的在于提供一种软件测试需求的分析方法,可以方便、详尽的获取测试需求,明确测试执行时需要实施的测试类型。 为实现上述目的,本方法提供了一种软件测试需求分析的方法,包括以下步骤: a)列出软件开发需求中具有可测试性的开发需求; b)对步骤a)列出的每一条开发需求,形成可测试的分层描述的测试需求; c)对步骤b)形成的每一条测试需求,从GB/T 16260.1-2006《软件工程 产品质量 第1部分:质量模型》中定义的软件内部/外部质量模型来确定软件产品的质量需求; d)对步骤c)所确定的质量需求,分析测试执行时需要实施的测试类型; e)建立测试需求跟踪矩阵,对测试需求进行管理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值