测试需求
测试需求的意义
无论对于开发还是测试,一个全面精准有预见性的设计是保证项目顺利进行的前提。实际项目操作中,常常感受到测试过程有着各种问题:
1、产品质量维度关注的不全面,测试类型不完整;
2、测试规格设计较为随意,测试分解分配比较随意;
导致测试过程中,经常会出现需求遗漏、测试设计遗漏的问题;
因此一份详细精准的测试需求分析有利于这些问题的解决。
测试需求的定义
软件需求定义的是要产品要实现的功能是什么,而测试需求这个名词业界并没有权威的定义,多数的意见认为测试需求定义测试的范围(即主要解决测什么、及测到什么程度的问题),这样说还是太过泛泛,换个说法,测试人员依据初期功能需求,评估需要测试的功能点都有什么,每个功能点需要什么类型的测试,每个功能点测试到什么程度算是通过,这样初步评估出了测试的规模、复杂程度和风险,同时可以初步预估出哪个环节需要研发同事提供测试接口。
测试需求设计的愈加详细精准,代表对待测试的软件了解的愈深,对各种测试手段了解的愈深,但是这往往要求测试需求的设计者拥有一定的测试经验。
测试需求的流程:
测试需求的采集
测试需求最直接的来源是:
- 软件需求规格;
- 业界协议规范;
- 测试经验库;
- 对于已有旧版本的软件测试,还需要考虑继承性的测试需求。
对以上内容进行梳理,形成原始测试需求表,列表的内容包括需求标识、原始测试需求描述、信息来源,如下:
来源编号 |
测试原始需求编号 |
测试原始需求描述 |
开发特性 |
需求标识 |
需求描述 |
需求优先级 |
测试规格分析的工程方法 |
DR001 |
EMAIL-001 |
能够支持电子邮件的收发 |
|
OR_MKT.00010 |
能够支持电子邮件的收发 |
|
|
测试人员需要对开发需求进行整理,首先需要确认软件需求的正确性、其次保证软件需求的可测试性。所谓的可测试指的是“存在一个可明确预知的结果,可用某种方法对这个明确的结果进行判断、验证。”原则上,所有的软件需求都应该是可测试的,因为如果作为测试人员对需求无法产生准确的理解(即无法得出明确的结果),那么开发人员也同样无法对同一条需求产生准确的理解。每一个测试需求需要保证一条需求只包含一项测试内容,因此一条软件需求通常可能对应多条测试需求。
这个阶段的测试需求整理,最重要的一点就是要注意广泛性和全面性,要尽可能的收集更多的原始需求,不存在遗漏,并且可以对需求进行适当的扩充,这些需求应该不仅仅局限于上述的五种来源类型,也不仅仅局限于各种文档、资料。
测试需求的分析:
测试需求采集之后得到的是一张没有优化的需求表,需要对这份原始需求表进行初步的规划:
- 删除冗余重复的需求,各个需求间没有过多的交集;
- 需求需覆盖业务流程、功能、非功能方面的需求;
业务流程:任何一套软件都会有一定的业务流,也就是用户用该软件来实现自己实际业务的一个流程。简单的来说,在做测试需求分析时需要列出以下类别:
1) 常用的或规定的业务流程
2) 各业务流程分支的遍历
3) 明确规定不可使用的业务流程
4) 没有明确规定但是应该不可以执行的业务流程
5) 其他异常或不符合规定的操作
- 需求需考虑了各功能模块之间交互关系分析;
- 确定测试特性(即测试功能点);
- 确定需求的测试类型;
测试类型 |
编码 |
备注 |
功能测试 |
FUNC |
|
一致性测试 |
CONF |
|
互操作测试 |
IOT |
|
安全性测试 |
SECU |
|
流控测试 |
LC |
|
性能测试 |
PER |
|
压力测试 |
STR |
|
大容量测试 |
CAPA |
|
长时间测试 |
LTME |
|
配置测试 |
CFG |
|
兼容测试 |
COMP |
|
安装测试 |
INST |
|
备份测试 |
BACK |
|
恢复测试 |
RECOV |
|
易用性测试 |
USE |
|
Qos测试 |
QOS |
|
国际化测试 |
NAT |
|
接口测试 |
|
|
完整性测试 |
|
|
结构测试 |
|
|
界面测试 |
|
|
负载测试 |
|
|
- 确定需求的质量属性;
- 确定本版本测试所属的阶段;
测试阶段:产品的不同阶段,对于测试阶段的要求也不一样。对于初期版本的产品,更侧重于关注:功能是否实现(这个功能正常场景下是否顺利)、较为成熟阶段之后,会关注:功能是否实现的够完善(异常场景下,是否正常处理),更加成熟之后会关注,是否通得过各种压力测试场景。
测试需求跟踪矩阵
建立测试需求跟踪矩阵,对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。
软件需求 |
测试需求 |
|||
标识 |
描述 |
标识 |
描述 |
测试类型 |
|
|
|
|
|
建立测试需求跟踪矩阵,对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。
通过测试需求跟踪矩阵的方式对需求变更实施管理。软件需求一旦发生变化,就要对需求跟踪表进行维护,启动配置管理过程,将与软件需求变更相关的内容进行同步变更。
测试需求评审
评审的内容:
完整性审查:应保证测试需求能充分覆盖软件需求的各种特征,重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面,同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求;
准确性审查:应保证所描述的内容能够得到相关各方的一致理解,各项测试需求之间没有矛盾和冲突,各项测试需求在详尽程度上保持一致,每一项测试需求都可以作为测试用例设计的依据。