软件测试编号(系统需求跟踪表)

1.系统需求跟踪表

2.方法名

3.E.G.

4.测试项分类


1.系统需求跟踪表

需求ID    :模块名-SRS-需求名称

需求名称:需求名称描述(机会管理)

系统测试项ID:项目名-ST-需求名称/(-子需求名称)

系统测试项描述:功能项描述(查看更改日志)

系统测试子项ID:模块名-ST-Func/Perf/Abnor/Seure/GUI-功能项-编号(001)

系统测试子项描述:功能项描述(查看更改日志)

系统测试用例ID:模块名-ST-Func/Perf/Abnor/Seure/GUI-需求名称-编号(001)

系统用例描述:功能项分解详细描述(查看商业机会的日志)

系统测试用例执行结果:PASS/Failed


2.方法名

测试类型

类型编码

类型编码

类型编码

功能

func

一致性

conf

性能

perf

性能/极限

rerm

压力

Seress

配置

conf

兼容

Compatible

长时间

ltme

安全

secu

异常

ABNO

安装

setup

容量

Capacity

界面

GUI

互操作

Iot

健壮

Robust

 

 


3.E.G.

需求IDOpportunities-SRS-Management
需求名称机会管理
系统测试项IDSugarCRM-ST-Opportunities-Management-CheckAlterlLog
系统测试项描述查看更改日志
系统测试子项IDOpportunities-ST-Func-Log
 Opportunities-ST-Perf-Log
 Opportunities-ST-Abnor-Log
 Opportunities-ST-Seure-Log
 Opportunities-ST-GUI-Log
 Opportunities-ST-STRE-Log
 Opportunities-ST-CAPA-Log
系统测试子项描述查看更改日志
 导出一条以数据成功在2秒内完成
 导出信息过程中断网
 是否有更改日志的权限
 跳转界面正确  2 输入条件错误时有相应有提示信息 3界面格式正确,无错别字
  在线人数在5万人时,并发用户大于5000人时,系统不死机
 最多更改条数为50000条
系统测试用例ID Opportunities-ST-FUNC-CheckAlterlLog-001
系统测试用例描述查看商业机会的日志
系统测试用例执行结果PASS


4.测试项分类

  1. SRS:根据工作任务书(客户需求)的规格,把任务书中的任务(客户需求)分解为可以实现的符合具体的需求项,需求项最终落实到需求文档中(SRS)
  2. HLD:针对需求规格说明书中的需求项分解,一个需求项可以被分级为一个或多个模块,每个模块之间有明确的接口,模块的功能独立,符合高内聚、低耦合的原则,标识每一个模块的项目即概要设计项(HLD最终落实到概要设计说明书中)
  3. ST:测试人员根据SRS(需求规格书)中的需求项描述,完成系统 统测试项、系统测试子项、系统测试用例
        一个软件需求项可以对应一个/多个/甚至数10个系统测试用例项目
        一个系统测试用例项目也可以是对应一个/多个软件需求项
  4. IT:测试(开发)根据概要设计文档中的概要设计项,完成的集成用例
  5. UT:测试(开发)人员根据详细设计文档中的详细设计项,完成的单元测试用例


每个详细设计项应该对应一个或者一个以上的单元测试用例项目

SRS、ST、IT命名方式
a)产品编号--SRS--需求类型--特性名--XXX
                      eg.CALC--SRS--FUNC--ADD--001(表示计算器十进制加法功能需求)
b)产品编号--HLD--子系统名--模块名--XXX
                      eg.CALC--HLD--ADD--DEC(表示计算器十进制加法功能模块)
c)产品编号--ST--系统测试项名--系统测试子项名--XXX
d)产品编号--IT--集成测试项名--集成测试子项名--XXX
e)产品编号--UT--单元测试项名--单元测试子项名--XXX

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

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值