嵌入式软件设计设计功能测试需求
2.1.2 设计功能测试需求
软件功能是否实现对于用户而言是至关重要的,所以功能测试是软件测试的重要组成部分。设计功能测试需求的目的是为了确定功能测试范围和测试目标。
一个完整的软件系统通常是由很多功能点逐层组成的,对一个系统功能测试需求的描述就是以模块为单位对若干功能点逐层描述的集合,通常采用功能矩阵的方法进行组织。功能矩阵的方法是将软件文档例如概要设计说明书、详细设计说明书等进行逐层细分进行测试项的抽取,最终转变成一条条可测试的要点。
功能矩阵方法有以下优点:
● 设计的测试项条理清晰,有利于理解概要设计;
● 易于识别概要设计及字里行间中没有明确描述出来的内容; ● 易于识别存在二义性的概要设计。
功能测试需求任务
1、 任务类型定义
功能测试需求任务类型见表2_11。
表2_11 功能测试需求任务
2、任务计划安排
测试范围在测试计划中已经给出。每个项目组完成“学创购书网”所有模块的功能测试需求设计。测试经理担当本项目组工作任务分配,分配形式可参照表2_12。文档保存请参照表中的“文档名称”列的相关说明。
表2_12 功能测试需求任务计划
3、任务工作量汇总
以项目组为单位进行工作量汇总,测试经理担当,汇总形式如表2_13。
表2_13 功能测试需求任务工作量汇总
功能测试需求规范
通常系统主体业务功能是需要后台数据库做支撑的,所以在进行功能测试需求的设计时需要结合数据库统一进行考虑。 1、功能矩阵规范
有关数据库操作类的主体业务主要参照系统的功能划分和数据库处理的先后顺序进行,所以功能矩阵也是按照层次进行分类的。功能矩阵详见表2_14,在该表中:
功能分类第一层:模块的功能名称,与概要设计书一致,如果功能矩阵文档以一个功能为单位作成,此层可以取消。
功能分类第二层:可按照对数据库操作为拆分的方法,如检索,新建,编辑,删除,复制等。
功能分类第三层:按照数据库处理前、处理、处理后的方法进行分类。 功能分类第四层:对于处理,按成功、失败、取消进行再分类。
功能点测试项:不可拆分的最小单位,例如对于处理成功,测试项通常是数据库的字段。
表2_14 功能矩阵
2、常见功能测试项案例说明
测试项抽取的核心思想就是按照数据库处理的顺序进行分类和抽取,所以对于其他功能只要掌握核心思想和方法,都可以抽取出规范的测试项。下面介绍常见的检索和新建功能的功能矩阵和测试项的抽取方法。 (1)检索功能的功能矩阵测试项
案例中介绍了检索功能测试项的抽取方法,该方法适应于通用的检索功能操作,请参见表2_15。
(2)新建功能的功能矩阵测试项
案例中介绍了对于新建功能的测试项抽取的方法,该方法适应于通用的新建功能操作,详见表2_16。
功能测试需求示例
示例1: “会员登录”功能测试需求
界面如图2_3,功能测试需求请参见表2_17 。
图2_3 “会员”登录界面
表2_17 “会员登录”功能测试需求
示例2: “添加图书”功能测试需求
界面如图2_4,功能测试需求请参见表2_18 。
图2_4 “添加图书”界面
表2_18 “添加图书”功能测试需求
参考知识
功能测试需求规范中用功能矩阵的方法抽取测试项,在实际工作中需要根据项目及模块的特点进行测试项的组织,以下编写准则仅供参考。 1、测试需求分析过程
在描述测试需求时将系统进行分解,然后采用描绘轮廓、分解单元、细化等步骤。其中,
第一步描述轮廓,描绘被测程序的测试范围包括测试目标、对象等; 第二步分解单元,对测试范围进行分解,根据结构分解成不同级别的单元形成树形测试需求,例如子系统、模块等;
第三步单元细化,对已分解的单元进行细化,细述每项测试需求。 2、测试需求编写准则
在编写测试需求时需要注意以下几点:
一,完整性。一份完整的测试需求就是一份测试方案;
二,无歧异性。测试需求、测试用例设计和测试执行人员通常不是一个人完成,所以在描述测试需求,特别描述测试项时无歧异性至关重要;
三,一致性。保持两个一致,一是测试需求与软件需求保持一致,二是测试需求与测试用例设计保持一致;
四,可测试性。因为后继的测试用例设计和缺陷报告均以测试需求为基础,所以测试需求必须具有可测试性。 3、测试需求的评审
为了确保测试的可追踪性和与用户、开发团队目标的一致性,需要对测试需求进行评审。根据具体情况可以采取正式、非正式的需求评审,也可以同事间审查。