系统测试设计用例设计方法三篇.docx

上传人:b****6 文档编号:16069358 上传时间:2023-07-10 格式:DOCX 页数:49 大小:753.97KB
下载 相关 举报
系统测试设计用例设计方法三篇.docx_第1页
第1页 / 共49页
系统测试设计用例设计方法三篇.docx_第2页
第2页 / 共49页
系统测试设计用例设计方法三篇.docx_第3页
第3页 / 共49页
系统测试设计用例设计方法三篇.docx_第4页
第4页 / 共49页
系统测试设计用例设计方法三篇.docx_第5页
第5页 / 共49页
系统测试设计用例设计方法三篇.docx_第6页
第6页 / 共49页
系统测试设计用例设计方法三篇.docx_第7页
第7页 / 共49页
系统测试设计用例设计方法三篇.docx_第8页
第8页 / 共49页
系统测试设计用例设计方法三篇.docx_第9页
第9页 / 共49页
系统测试设计用例设计方法三篇.docx_第10页
第10页 / 共49页
系统测试设计用例设计方法三篇.docx_第11页
第11页 / 共49页
系统测试设计用例设计方法三篇.docx_第12页
第12页 / 共49页
系统测试设计用例设计方法三篇.docx_第13页
第13页 / 共49页
系统测试设计用例设计方法三篇.docx_第14页
第14页 / 共49页
系统测试设计用例设计方法三篇.docx_第15页
第15页 / 共49页
系统测试设计用例设计方法三篇.docx_第16页
第16页 / 共49页
系统测试设计用例设计方法三篇.docx_第17页
第17页 / 共49页
系统测试设计用例设计方法三篇.docx_第18页
第18页 / 共49页
系统测试设计用例设计方法三篇.docx_第19页
第19页 / 共49页
系统测试设计用例设计方法三篇.docx_第20页
第20页 / 共49页
亲,该文档总共49页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

系统测试设计用例设计方法三篇.docx

《系统测试设计用例设计方法三篇.docx》由会员分享,可在线阅读,更多相关《系统测试设计用例设计方法三篇.docx(49页珍藏版)》请在冰点文库上搜索。

系统测试设计用例设计方法三篇.docx

系统测试设计用例设计方法三篇

系统测试设计用例设计方法三篇

篇一:

系统测试设计用例设计方法

一、等价类分析法2

二、边界值分析2

三、错误猜测法3

四、判定表法3

五、流程分析方法4

六、正交试验设计法4

七、状态迁移法6

一、等价类分析法

等价类划分方法针对手机状态大致可以归几个大类:

1.按键类(等价法):

有效输入和无效输入(有效输入指UM和菜单指示;无效输入指测试菜单功能此时没有定义的按键和用户动作);

2.外部中断类(等价法):

常用、不常用及无效

2.1.常用:

来电和来消息(短信、彩信、push消息);掀合盖;侧键;耳机&FM;情景模式;电量不足

2.2.不常用:

充电;闹钟&记事本&关机时间&整点报时提示;Icon&动画显示;Icon&动画刷新;编辑界面&pop显示框输入为空或满;编辑界面&pop显示框状态输入法默认&字符编码默认;失效SIM卡;大容量等SIM卡兼容;排序;号码识别;

2.3.无效:

“资料读取中…”;“复制中…”;“请稍后再试”

3.存储器类

3.1.等价法分类:

读或写;不读或不写。

3.2.因果法分类:

先SIM卡后手机;先手机后SIM卡;提示用户选择存储器(对比Nokia)。

3.3.操作分类:

读;写;新增;删除;复制(先删除后新增;先新增后删除)

状态类:

正确;错误;变更;用户设定变更

举例一,短消息发送功能:

英文:

Default7-bitalphabet(over160characters)

合法等价类:

0~160

非法等价类:

>160

Thequickfoxjumpsoverthelazybrowndog

中文:

UCS-2alphabet(over70characters)

合法等价类:

0~70

非法等价类:

>70

诺基亚(英文):

Extendeddefault7-bitalphabet(over140Bytes),智慧短信,可以携带黑白图片。

合法等价类:

0~140

非法等价类:

>140

在写字板里面输入“联通”二字,保存后,再打开,即出现乱码。

举例二,单个通话实例的拨打与挂断

测试用例标识

测试阶段:

系统测试

测试项

单个通话实例的拨打与挂断

测试项属性

A

参照规范

重要级别

测试原因

手机在待机状态下,确保手机能正常拨出电话

预置条件

1.正常信号环境

2.IDLE状态

3.默认原厂参数设定

输入

1.电话号码(手机号码,固定电话,带分机的号码,字符串,特殊号码如:

**21*021xxxxxxxx#,+或00,超短号码,超长号码,拨打一位号码,拨打最大长度号码等)

2.拨号过程中电池低电量提示、来短信、来彩信

3.拨号过程中闹钟时间到、行事历时间到

4.拨号过程中插上充电器

5.拨号过程中突然断电

6.按键加锁

测试执行步骤

IDLE状态拨打号码

按Send键发送

按End键挂断

预期输出结果

1.按Send键可以拨打并显示,按End键可挂断

2.拨打号码过程电池低电量提示、来短信、来彩信拨打界面正常

3.拨打号码过程闹钟时间到、行事历时间到拨打界面正常

4.拨号过程中插上充电器,背光状态及拨打界面正常

5.拨号过程中突然断电,插上充电器重新开机后能正常拨出

6.按键加锁仅可拨打紧急电话号码112

测试用例标识

测试阶段:

系统测试

测试项

单个通话实例的拨打与挂断

测试项属性

A

参照规范

重要级别

测试原因

手机在无信号或无网络情形下,手机无法正常拨打电话

预置条件

1.正在搜索网络或正处于注册界面

2.IDLE状态

3.默认原厂参数设定

输入

同上用例

测试执行步骤

IDLE状态拨打号码

按Send键拨号

预期输出结果

1.重复以上操作,提示无法拨打成功的提示信息

2.重复以上步骤,背光处理正常

测试用例标识

测试阶段:

系统测试

测试项

单个通话实例的拨打与挂断

测试项属性

A

参照规范

重要级别

测试原因

SIM卡失效情况下,手机无法正常拨打电话

预置条件

1.事先准备欠费、过期、被锁、注册失败、无法使用的SIM卡

2.IDLE状态

3.默认原厂参数设定

输入

同上用例

测试执行步骤

IDLE状态拨打号码

按Send键拨号

预期输出结果

1.重复以上操作,提示无法拨打成功的提示信息

2.重复以上步骤,背光处理正常

3.重复以上步骤,提示给用户可接受的错误异常信息

测试用例标识

测试阶段:

系统测试

测试项

单个通话实例的拨打与挂断(开启固定拨号名单时)

测试项属性

A

参照规范

重要级别

测试原因

手机在待机状态下,确保手机能正常拨出固定拨号名单中电话号码

预置条件

正常信号环境

IDLE状态

默认原厂参数设定

SIM卡开启固定拨号名单

输入

1.预选存取电话号码(手机号码,固定电话,带分机的号码,字符串,特殊号码如:

**21*021xxxxxxxx#,+或00,超短号码,超长号码,拨打一位号码,拨打最大长度号码等)

2.拨打固定拨号名单中存在的号码。

如,8621xxxxxxxxw0000000

3.拨打固定拨号名单中没有的号码。

如,xxxxxxxx

4.拨号过程中电池低电量提示、来短信、来彩信

5.拨号过程中闹钟时间到、行事历时间到

6.拨号过程中插上充电器

7.拨号过程中突然断电

8.按键加锁

9.操作通话选项菜单

测试执行步骤

IDLE状态拨打号码

按Send键发送

按End键挂断

预期输出结果

1.按Send键可以拨打并显示,按End键可挂断,拨号画面正常,且显示固定拨号名单中名字

2.拨号画面正常

3.拨号画面提示“限拨FDN名单”

4.拨打号码过程电池低电量提示、来短信、来彩信拨打界面正常

5.拨打号码过程闹钟时间到、行事历时间到拨打界面正常

6.拨号过程中插上充电器,背光状态及拨打界面正常

7.拨号过程中突然断电,插上充电器重新开机后能正常拨出

8.按键加锁仅可拨打紧急电话号码112

9.通话选项菜单功能正常

测试用例标识

测试阶段:

系统测试

测试项

单个通话实例的拨打与挂断(设定通话限制时)

测试项属性

A

参照规范

重要级别

测试原因

手机在待机状态下,确保手机能满足通话限制功能

预置条件

正常信号环境

IDLE状态

默认原厂参数设定

申请开通通话限制服务

输入

测试执行步骤

IDLE状态拨打号码

按Send键发送

按End键挂断

预期输出结果

测试用例标识

测试阶段:

系统测试

测试项

单个通话实例的拨打与挂断(漫游情形时)

测试项属性

A

参照规范

重要级别

测试原因

手机在待机状态下,确保手机能满足通话限制功能

预置条件

正常信号环境

IDLE状态

默认原厂参数设定

申请开通通话限制服务

输入

测试执行步骤

IDLE状态拨打号码

按Send键发送

按End键挂断

预期输出结果

二、边界值分析

例子1:

短消息发送功能的等价类划分方法:

英文:

Default7-bitalphabet(over160characters)

合法等价类:

0~160

非法等价类:

>160

中文:

UCS-2alphabet(over70characters)

合法等价类:

0~70

非法等价类:

>70

诺基亚(英文):

Extendeddefault7-bitalphabet(over140Bytes),智慧短信,可以携带黑白图片。

合法等价类:

0~140

非法等价类:

>140

例子2:

首先用7列的LCD显示屏,软件可以显示7列汉字,如果换成8列汉字的显示屏,那么,如果软件格式化处理比较僵化,可能依然显示7个汉字。

这样,软件的实现,与LCD的规格不符合。

因此,需要考虑LCD屏幕的规格,依据边界值方法设计用例。

LCD屏幕上有效显示区域4行每行8汉字,可考虑编辑超过4行每行超过16字符情形来进行测试。

LCD列边界值需要考虑:

7个汉字,8个汉字,9个汉字

行边界值:

31个汉字,32个汉字,33个汉字

例子3:

SIM卡名片簿姓名超长(20个英文字符),号码超长情形,新增和查看用户姓名

由学员完成该作业:

1、注意等价类和边界值的用例设计方法

2、关注LCD的显示格式问题

三、关注新增、查看两种功能的结合,可能新增姓名是正确的,但是查看的格式错误。

四、错误猜测法

例子1:

利用手机闹钟重响的例子引入错误猜测法基本概念,讲解错误猜测法的意义

未接来电29通,内存中规划的分区一直分配被占用。

即使同一号码也同样占用资源。

假设此时第30通电话正好为来电号码不显示,即“来电号码未知”或境外来电号码隐藏时(国外保护个人隐私,自动开启来电号码隐藏功能),可能会出现BUG,实际情况证明,此时会出现Reset问题。

同样道理,推断第一通电话如果为“来电号码未知”,也可能出现上述问题。

例子2:

通常手机解决方案中sunplus、雅马哈和弦芯片发声。

为了降低成本采用DSP策略纯软件发声(如果采用硬件独立声音控制芯片,不会出现下面问题),此时测试中就猜测当手机设定闹钟时,闹钟时间到后,确定为重响,此时用户进入铃声选择-浏览-播放时,这时候铃声控制软件会出现资源冲突,可能出现BUG。

测试结果是出现RESET或者浏览铃声无响铃的结果。

例子3:

五、比如,设定闹钟铃声,在IDLE下闹钟响铃未处理(响铃一分钟后,铃声停止,系统进入另外一种状态,菜单提示为闹钟是否重响?

),待钤声响完后按两次SKL键(确定键),(第一次确定要重响,第二次应该返回IDLE状态),再次进入"钤声设定"/"钤声类型",此时任选一铃声都没有声音

六、判定表法

举例一,若手机用户欠费或停机,则不允许主被叫。

表示为判定表如下:

1

2

3

4

条件

用户欠费

Y

Y

N

N

用户被停机

Y

N

Y

N

动作

可以主被叫

N

N

N

Y

举例二,区别手机掉网、搜网、飘网、SIM卡座松动问题

1

2

3

4

条件

显示运营商logo正确

Y

Y

N

N

显示有信号

Y

N

Y

N

动作

可以拨打电话

Y

N

Y(除拨112外还可以拨打其它号码)

Y

七、

八、流程分析方法

1-手动/自动选网模式;11-自动注册并显示已有网络服务

2-手动模式(选网模式的一种);3-搜寻到HPLMN(归属网络)及FPLMN(禁止网络);6-频段搜索;7-自动选择频段;8-手动选择频段900或1800;(新手机才有频段手动选择)4-选择FPLMN;5-注册FPLMN

路径

path1:

1-11

path2:

1-2-3-4-5-1-11

path3:

1-2-3-6-8-9-10-1-11

path4:

1-2-3-6-7-9-10-1-11

举例二,彩信发送功能

1.终端发送MMS,如果是终端到终端,那么以WSP(无线会话协议)协议编码送到WAP网关;如果终端到应用服务器(发送Email),则以IP协议发送到IP网关;

2.WAP网关或IP网关都以HTTP协议与MMS中继器通信,文件内容传给中继器

3.中继器将文件送往MMS服务器,并以MIME格式存储。

(MIME的格式可以被手机终端识别并显示,并且可以被Email客户端浏览并显示的文件格式)

4.如果MMS接收方为手机终端,MMS服务器调用号码以及相关路由信息,并进行数据分析,判断终端支持能力和承载能力,如果终端不支持MMS,只通过短消息格式发文字部分;如果终端支持MMS,直接发送MIME格式的文件到手机终端。

5.如果,发送到Email服务器,系统通过路由选择,把MIME格式的文件发送到Email地址所在的服务器。

该MMS支持的媒体格式包括文本、铃声、图片;文本没有上限64K,包括64K;铃声单首最大为64K,包括64K,最多支持5页;单页图片最大64K,最多5页;

测试用例设计

利用流程分析方法,测试分析时需要考虑以下几点:

1.彩信发送测试时需要考虑基于WAP业务实现和基于IP网关的流程差异;

2.MMS服务器数据分析并确定处理方法时需要考虑终端到终端的情形和终端到应用的业务情形;

3.确定终端到终端的情形下,还需要考虑终端是否支持MMS发送

九、正交试验设计法

例子1:

假设一个WEB站点,该站点有大量的服务器和操作系统,并且有许多具有各种插件的浏览器浏览:

WEB浏览器:

Netscape6.2、IE6.0、Opera4.0

插件:

无、RealPlayer、MediaPlayer

应用服务器:

IIS、Apche、NetscapeEnterprise

操作系统:

Windows2000、WindowsNT、Linux

正交表:

 

1

2

3

4

1

1

1

1

1

2

1

2

2

2

3

1

3

3

3

4

2

1

2

3

5

2

2

3

1

6

2

3

1

2

7

3

1

3

2

8

3

2

1

3

9

3

3

2

1

提取系统功能说明中的因子:

WEB浏览器

插件

应用服务器

操作系统

分析各因子的状态

WEB浏览器:

1=Netscape6.2、2=IE6.0、3=Opera4.0

插件:

1=None、2=RealPlayer、3=MediaPlayer

应用服务器:

1=IIS、2=Apche、3=NetscapeEnterprise

操作系统:

1=Windows2000、2=WindowsNT、3=Linux

将因子、状态映射到上面正交表中:

测试用例

浏览器

插件

服务器

操作系统

1

Netscape6.2

None

IIS

Windows2000

2

Netscape6.2

RealPlayer

Apche

WindowsNT

3

Netscape6.2

MediaPlayer

NetscapeEnterprise

Linux

4

IE6.0

None

Apche

Linux

5

IE6.0

RealPlayer

NetscapeEnterprise

Windows2000

6

IE6.0

MediaPlayer

IIS

WindowsNT

7

Opera4.0

None

NetscapeEnterprise

WindowsNT

8

Opera4.0

RealPlayer

IIS

Linux

9

Opera4.0

MediaPlayer

Apche

Windows2000

举例2:

MMS处理模块

编辑模块:

支持SMIL(同步多媒体综合语言)、不支持SMIL…..

效果处理模块:

水波纹、半透明、水印、反透…..

界面显示模块:

POP形式、窗体式显示…..

一十、举例3:

照相机功能测试

一十一、状态迁移法

举例手机mp3键盘播放模式测试用例设计

1.键盘用户模式基本操作功能

2.支持媒体格式与文件格式要求

3.多媒体播放中对外部事件的响应

4.终端处理能力(包括终端异常处理、文件操作)

PC与终端同步能力

键盘用户模式基本操作功能系统测试用例设计步骤:

编写状态—事件表;

编制状态图转换表;

编写合法测试用例;

编写非法测试用例;

编写错误异常处理测试项;

序号

需求内容

播放器要求

1

功能类型和操作方式

采用菜单选项方式

2

文件播放

必须支持

3

播放基本功能Play,Pause,Stop,Seek

必须支持

4

声音调节

必须支持

5

亮度调节

必须支持

6

对比度调节

推荐支持

7

播放进度显示

必须支持

8

模式选择及切换

必须支持,可通过设定功能键切换常规模式

9

后台播放模式

推荐支持

10

播放器设置

必须支持,提供缺省设置

11

播放统计及列表记录

必须支持

12

5键快捷设定及操作

必须支持

5键

功能定义

Up

增大音量

Down

减小音量

Left

上一首或后退

Right

下一首或快进

Select(侧键ok)

播放/暂停功能切换

状态—事件表(黑点着重号表示为非法组合)

函数名字

Idle

播放

录音

EvRewindbutton

(倒)

1-倒

·

8-倒

11-倒

·

Evplaybutton

(播放)

2-播放

5-播放

·

12-播

·

Evfastforwardbutton

(进)

3-进

6-进

9-进

·

·

Evrecord

(录音)

4-录音

·

·

·

·

Evstopbutton

(Idle)

·

7-idle

10-idle

13-idle

14-idle

7软件测试文档

1、软件测试文档就是为将软件测试当作一个项目一样实施计划和管理而引入的,它为测试项目的组织、规划和管理提供了一个规范化的架构。

2、软件测试文档主要包括测试计划、测试用例、测试规程、测试事件报告、测试总结报告等。

测试文档总所规定的内容可以作为对测试过程完备性的对照检查表,有助于提高测试工程每个阶段的能见度,极大地提高了测试工作的可管理性。

为了统一测试文档的书写标准,IEEE/ANSI制定了829-1983标准,还有其他的一些也用于指导软件测试文档的编写,如我国制定的《计算机软件测试文件百年之规范(GB/T9386-1988)》

3、测试文档编写规范(GB/T9386-1988)简介

(1).引用标准

该规范的引用标准为:

GB/T11457软件工程术语

GB8566计算机软件开发规范

GB8567计算机软件产品开发文件编制指南

(2).关键术语定义

设计层:

软件项的设计分解(如系统,子系统,程序,模块)

通过准则:

一个软件项或软件特性的测试是否通过的判别依据

软件特性:

软件项的显著特性(如功能,性能或可移植性)

软件项:

源代码,目标代码,作业控制代码,控制数据或这些项的集合。

测试项:

作为测试对象的软件项

(3).规范的主要内容

该规范确定了各个测试文件的格式和内容,所提出的文件类型包括测试计划,测试说明和测试报告。

测试计划免除测试活动的范围,方法,资源和进度,他规定被测试的项,被测试的特性,应完成的测试任务,担任各项工作的人员职责及与本计划有关的风险等。

4、测试说明包括三类文件

测试设计说明:

详细描述测试方法,规定该设计及其有关测试所包括的特性,还规定完成测试所需的测试用例和测试规程,并规定特性的通过准则。

测试用例说明:

列出用于输入的具体值以及预期的输出结果,并规定在使用具体测试用例时,对测试规程的各种限制。

将测试用例与测试设计封开,可以使它们用于多个设计并能在其它情形下重复使用。

测试规程说明:

规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。

5、测试报告则包括四类文件:

测试项传递包括:

指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而传递的测试项。

测试日志:

测试组用于记录测试执行过程中发生的情况。

测试事件报告:

描述在测试执行期间发生并需进一步调查的一切事件。

测试总结报告:

总结与测试设计说明有关的测试活动。

6.对规范的实施

使用该规范的每个单位,要规定测试阶段所应有的特性文件,并在测试计划中规定测试完成后所能提交的全部文件。

使用该规范的每个单位应该补充规定对内容的要求和约定,及便反映总结在测试,文件控制,配置管理和质量保证方面所用的特定方法,设备工具。

一下是规范中的文件编制实施及使用指南

(1)实施指南

在实施测试文件编制的初始阶段可先编写测试计划于测试报告文件。

测试计划将为整个测试过程提供基础。

测试报告将鼓励测试单位以良好的方式记录整个测试过程的情况。

(2)用法指南

在项目计划及单位标准中,指明在那些测试活动中需要那些测试文件,并可在文件中加入一些内容,使各个文件适应一个特定的测试项及一个特定的测试环境。

7《软件测试文件编制规范》中的内容要求

以下是规范中各个测试文件的书写格式及内容。

a测试计划

(1)测试计划名称(该计划的第1章)

(2)引言(该计划的第2章)

(3)测试项

(4)被测试的特性

(5)不被测试的特性

(6)方法

(7)项通过的准则

(8)暂停标准和再启动要求

(9)应提供的测试文件

(10)测试任务

(11)环境要求

(12)职责

(13)人员和训练要求

(14)进度

(15)风险和应急

(16)批准

b测试设计说明

(1)测试设计说明名称

(2)被测试的特性

(3)方法详述

(4)测试用例名称

(5)特性通过准则

c测试用例说明

(1)测试用例说明名称

(2)测试项

(3)输入说明

(4)输出说明

(5)环境要求

(6)特殊的规程要求

(7)用例间的依赖关系

d测试规程说明

(1)测试规程说明名称

(2)目的

(3)特殊要求

(4)规程步骤

e测试项传递报告

(1)传递报告名称

(2)传递项

(3)位置

(4)状态

(5)批准

f测试日志

(1)测试日志名称

(2)描述

(3)活动和事件条目

g测试事件报告名称

(1)测试事件报告取一个专用名称

(2)摘要

(3)事件描述

(4)影响

h测试总结报告

1.规定该报告必须由哪些人(姓名和职务)审批,并为签名和日期留出位置。

1、V模型2

2、W模型3

3、H模型5

4、 X模型6

5、其他测试模型7

1、瀑布模型8

2、原型模型9

3、螺旋模型11

 

背景知识:

目前主流的软件生命周期模型或软件开发过程模型有:

瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发(RAD)以及Rational统一过程(RUP)等,这些模型对于软件开发过程具有很好的指导作用,但是在这些过程方法中,软件测试的地位和价值并没有体现出来,也没有给软件测试以足够的重视,利用这些模型无法更好地指导测试实践。

软件测试是与软件开发紧密相关的一系列有计划、系统性的活动,显然软件测试也需要测试模型去指导实践。

下面先对主要的模型做一些简单的介绍,再补充软件生命周期做介绍。

1、V模型

   V模型是最具有代表性的测试模型。

V模型最早是由PaulRook在20世纪80年代后期提出的,V模型在英国国家计算中心文献中发布,旨在改进软件开发的效率和效果。

   在传统的开发模型中,比如瀑布模型,通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段,尽管有时测试工作会占用整个项目周期一半的时间,但是有人仍认为测试只是一个收尾工作,而不是主要的工程。

V模型是软件开发瀑布

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 自然科学 > 物理

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2