测试需求

测试需求的意义

无论对于开发还是测试,一个全面精准有预见性的设计是保证项目顺利进行的前提。实际项目操作中,常常感受到测试过程有着各种问题:

1、产品质量维度关注的不全面,测试类型不完整;

2、测试规格设计较为随意,测试分解分配比较随意;

导致测试过程中,经常会出现需求遗漏、测试设计遗漏的问题;

因此一份详细精准的测试需求分析有利于这些问题的解决。

 

测试需求的定义

    软件需求定义的是要产品要实现的功能是什么,而测试需求这个名词业界并没有权威的定义,多数的意见认为测试需求定义测试的范围(即主要解决测什么、及测到什么程度的问题),这样说还是太过泛泛,换个说法,测试人员依据初期功能需求,评估需要测试的功能点都有什么,每个功能点需要什么类型的测试,每个功能点测试到什么程度算是通过,这样初步评估出了测试的规模、复杂程度和风险,同时可以初步预估出哪个环节需要研发同事提供测试接口。

测试需求设计的愈加详细精准,代表对待测试的软件了解的愈深,对各种测试手段了解的愈深,但是这往往要求测试需求的设计者拥有一定的测试经验。

测试需求的流程:

 

测试需求的采集

测试需求最直接的来源是:

  1. 软件需求规格;
  2. 业界协议规范;
  3. 测试经验库;
  4. 对于已有旧版本的软件测试,还需要考虑继承性的测试需求。

对以上内容进行梳理,形成原始测试需求表,列表的内容包括需求标识、原始测试需求描述、信息来源,如下:

来源编号

测试原始需求编号

测试原始需求描述

开发特性

需求标识

需求描述

需求优先级

测试规格分析的工程方法

DR001

EMAIL-001

能够支持电子邮件的收发

Email

OR_MKT.00010

能够支持电子邮件的收发

 

 

 

测试人员需要对开发需求进行整理,首先需要确认软件需求的正确性、其次保证软件需求的可测试性。所谓的可测试指的是“存在一个可明确预知的结果,可用某种方法对这个明确的结果进行判断、验证。”原则上,所有的软件需求都应该是可测试的,因为如果作为测试人员对需求无法产生准确的理解(即无法得出明确的结果),那么开发人员也同样无法对同一条需求产生准确的理解。每一个测试需求需要保证一条需求只包含一项测试内容,因此一条软件需求通常可能对应多条测试需求。

这个阶段的测试需求整理,最重要的一点就是要注意广泛性和全面性,要尽可能的收集更多的原始需求,不存在遗漏,并且可以对需求进行适当的扩充,这些需求应该不仅仅局限于上述的五种来源类型,也不仅仅局限于各种文档、资料。

测试需求的分析:

测试需求采集之后得到的是一张没有优化的需求表,需要对这份原始需求表进行初步的规划:

  1. 删除冗余重复的需求,各个需求间没有过多的交集;
  2. 需求需覆盖业务流程、功能、非功能方面的需求;

业务流程:任何一套软件都会有一定的业务流,也就是用户用该软件来实现自己实际业务的一个流程。简单的来说,在做测试需求分析时需要列出以下类别:

1) 常用的或规定的业务流程

2) 各业务流程分支的遍历

3) 明确规定不可使用的业务流程

4) 没有明确规定但是应该不可以执行的业务流程

5) 其他异常或不符合规定的操作

  1. 需求需考虑了各功能模块之间交互关系分析;
  2. 确定测试特性(即测试功能点);
  3. 确定需求的测试类型;

测试类型

编码

备注

功能测试

FUNC

 

一致性测试

CONF

 

互操作测试

IOT

 

安全性测试

SECU

 

流控测试

LC

 

性能测试

PER

 

压力测试

STR

 

大容量测试

CAPA

 

长时间测试

LTME

 

配置测试

CFG

 

兼容测试

COMP

 

安装测试

INST

 

备份测试

BACK

 

恢复测试

RECOV

 

易用性测试

USE

 

Qos测试

QOS

 

国际化测试

NAT

 

接口测试

 

 

完整性测试

 

 

结构测试

 

 

界面测试

 

 

负载测试

 

 

 

  1. 确定需求的质量属性;

 

  1. 确定本版本测试所属的阶段;

测试阶段:产品的不同阶段,对于测试阶段的要求也不一样。对于初期版本的产品,更侧重于关注:功能是否实现(这个功能正常场景下是否顺利)、较为成熟阶段之后,会关注:功能是否实现的够完善(异常场景下,是否正常处理),更加成熟之后会关注,是否通得过各种压力测试场景。

测试需求跟踪矩阵

建立测试需求跟踪矩阵,对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。

软件需求

测试需求

标识

描述

标识

描述

测试类型

 

 

 

 

 

建立测试需求跟踪矩阵,对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。 

通过测试需求跟踪矩阵的方式对需求变更实施管理。软件需求一旦发生变化,就要对需求跟踪表进行维护,启动配置管理过程,将与软件需求变更相关的内容进行同步变更。

测试需求评审

评审的内容:

完整性审查:应保证测试需求能充分覆盖软件需求的各种特征,重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面,同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求;

准确性审查:应保证所描述的内容能够得到相关各方的一致理解,各项测试需求之间没有矛盾和冲突,各项测试需求在详尽程度上保持一致,每一项测试需求都可以作为测试用例设计的依据。

 

 

 

posted @ 2013-05-18 09:28  MaggieYeung  阅读(860)  评论(0编辑  收藏  举报