民航客运订票系统测试计划说明书.docx

上传人:b****8 文档编号:10520886 上传时间:2023-02-17 格式:DOCX 页数:20 大小:23.73KB
下载 相关 举报
民航客运订票系统测试计划说明书.docx_第1页
第1页 / 共20页
民航客运订票系统测试计划说明书.docx_第2页
第2页 / 共20页
民航客运订票系统测试计划说明书.docx_第3页
第3页 / 共20页
民航客运订票系统测试计划说明书.docx_第4页
第4页 / 共20页
民航客运订票系统测试计划说明书.docx_第5页
第5页 / 共20页
点击查看更多>>
下载资源
资源描述

民航客运订票系统测试计划说明书.docx

《民航客运订票系统测试计划说明书.docx》由会员分享,可在线阅读,更多相关《民航客运订票系统测试计划说明书.docx(20页珍藏版)》请在冰豆网上搜索。

民航客运订票系统测试计划说明书.docx

民航客运订票系统测试计划说明书

文档编号:

HHIT-SECD-081-07T-06

版本号:

V1.0

民航客运订票系统测试计划说明书

项目名称

民航客运订票系统

项目负责人

项目开发单位

计算机科学系软件081班第7项目组

小组成员

起止日期

2011.6.13~2011.7.1

项目名称

民航客运订票系统

 

2011年6月27日(文档完成日期)

 

软件工程课程设计项目组任务分派单(组长用)

班级:

软件081组别:

7组长姓名:

强余彬时间:

2011年06月25日

项目名称:

民航订票系统阶段名称:

测试计划说明书

序号

学号

姓名

任务名称

具体任务内容

完成标准

起止日期

验收成绩

1

测试设计说明

对订票模块描述其的测试设计说明,包含输入、输出、过程等

良好

6.25~6.27

69

2

测试设计说明

对查询模块描述其的测试设计说明,包含输入、输出、过程等

良好

6.25~6.27

72

3

计划

详细安排查询模块的测试计划,包括册数内容进度安排,测试资料等

良好

6.25~6.27

72

4

计划

详细安排订票模块的测试计划,包括册数内容进度安排,测试资料等

良好

6.25~6.27

75

5

评价准则

制定测试的范围、数据整理、尺度等信息

良好

6.25~6.27

65

1、本表由组长为其组员每次上机实践分派任务使用,应认真填写相关任务名称、内容、完成标准等信息;

2、本表在每次任务完成后,由组长按照完成标准验收,并给出每个组员成绩评定(每人平均70分制),除组长保留一份外,应及时上报任课老师(电子和纸质文档同时上报)。

 

1引言

1.1编写目的

本测试计划文档作为指导此测试项目秩序渐进的基础,帮助我们安排合适的资源和进度,避免可能的风险。

<基于航空客运订票系统>的这一测试计划文档有助于实现以下目标:

•确定<航空客运订票系统>的信息和应测试的软件构件

•列出推荐的测试需求。

•推荐可采用的测试策略,并对这些策略加以说明。

•确定所需的资源,并对测试的工作量进行估计。

•列出测试项目的可交付元素。

•明确测试管理过程及测试任务。

•预期客户为软件开发人员。

1.2背景

软件系统的名称:

民航客运订票系统

项目提出者:

***

开发者:

***、***、***、***、***

背景:

通过本航空订票系统使得查询航班变得越来越方便,轻松地对系统进行维护。

民航订票管理系统分为前台操作和后台处理,以数据库为核心。

整个系统围绕订票交易流程而设计。

总体上,其功能贯穿2条线:

一条线贯穿着客户注册、查询、订票、更改客户信息等操作流程;另一条线管理着航空公司的注册,飞机、航线的添加、修改及删除,公司信息的修改及注销等。

该系统正确、完整、及时地收集、加工、整理在整个订票业务流程中所发生的各类订票请求以及相关的机票信息。

通过该系统的多种多样的查询方式会让顾客越来越依赖此系统的便利性的,而且该系统极大地提高了工作效率。

1.3定义

民航客运订票系统是一个关于管理民航客运订票的应用软件。

1.4参考资料

列出用得着的参考资料,如:

a)本项目前期做好的可行性研究报告;

b)《软件工程导论》张海藩编著清华大学出版社第5版

c)《计算机软件产品开发文件编制指南GB8567-88》

d)本系统的《航空客运订票系统需求规格说明书》

2计划

2.1软件说明

提供一份图表,并逐项说明被测软件的功能、输入和输出等质量指标,作为叙述测试计划的提纲。

测试项

测试要求

测试项

测试要求

航班号

两位大写字母和四位数字

座位等级

一位大写字母(A,B,C)

购订票人

字段小于50的整形

到达时间

合法的年月日

身份证号

十位数字

座位总数

小于300

发出城市

字段小于50的整形

所属公司

到达城市

字段小于50的整形

票价

大于0

日期

合法的年月日

剩余座位

小于座位数

起飞时间

合法的年月日

2.2测试内容

列出组装测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的,例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行时间的测试、设计约束和极限的测试等。

(1)数据和数据库完整性测试

测试目标:

确保数据库访问方法和进程正常运行,数据不会遭到损坏。

技术:

调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据(或对数据的请求)。

检查数据库,确保数据已按预期的方式填充,并且所有的数据库事件都已正常发生;或者检查所返回的数据,确保为正当的理由检索到了正确的数据

完成标准:

所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。

需考虑的特殊事项:

使用手工的方式来查看

(2)功能测试

测试目标:

确保测试的功能正常,其中包括导航,数据输入,处理和检索等。

技术:

边界值、等价类划分法

利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:

在使用有效数据时得到预期的结果

在使用无效数据时显示相应的错误消息或警告消息

各业务规则都得到了正确的应用

完成标准:

所计划的测试已全部执行

需考虑的特殊事项:

(3)用户界面测试

测试目标:

核实以下内容:

通过测试对象进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab健、鼠标移动、和快捷键)的使用

窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准。

技术:

为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。

完成标准:

成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准

需考虑的特殊事项:

(4)性能测试

测试目标:

核实所指定的事务或业务功能在以下情况下的性能行为:

正常的预期工作量

预期的最繁重工作量

技术:

通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代数量。

脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多个客户机(虚拟的或实际的客户机,请参见下面的“需要考虑的特殊事项”)上重复。

完成标准:

单个事务或单个用户:

在每个事务所预期或要求的时间范围内成功地完成测试脚本,没有发生任何故障。

多个事务或多个用户:

在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。

需考虑的特殊事项:

(5)负载测试

测试目标:

核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。

技术:

通过修改数据文件来增加事务数量,或通过修改测试来增加每项事务发生的次数。

完成标准:

多个事务或多个用户:

在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。

需考虑的特殊事项:

(6)强度测试

测试目标:

核实测试对象能够在以下强度条件下正常运行,不会出现任何错误:

服务器上几乎没有或根本没有可用的内存(RAM和DASD)

连接或模拟了最大实际(实际允许)数量的客户机

多个用户对相同的数据或账户执行相同的事务

最繁重的事务量或最差的事务组合(请参见上面的“性能测试”)。

技术:

使用为性能评测或负载测试制定的测试。

要对有限的资源进行测试,就应该在一台计算机上运行测试,而且应该减少或限制服务器上的RAM和DASD。

对于其他强度测试,应该使用多台客户机来运行相同的测试或互补的测试,以产生最繁重的事务量或最差的事务组合。

完成标准:

所计划的测试已全部执行,并且在达到或超出指定的系统限制时没有出现任何软件故障,或者导致系统出现故障的条件并不在指定的条件范围之内。

需考虑的特殊事项:

(7)容量测试

测试目标:

核实测试对象在以下高容量条件下能否正常运行:

连接或模拟了最大(实际或实际允许)数量的客户机,所有客户机在长时间内执行相同的、且情况(性能)最坏的业务功能。

已达到最大的数据库大小(实际的或按比例缩放的),而且同时执行了多个查询或报表事务。

技术:

使用为性能评测或负载测试制定的测试。

应该使用多台客户机来运行相同的测试或互补的测试,以便在长时间内产生最繁重的事务量或最差的事务组合(请参见上面的“强度测试”)。

创建最大的数据库大小(实际的、按比例缩放的、或填充了代表性数据的数据库),并使用多台客户机在长时间内同时运行查询和报表事务。

完成标准:

所计划的测试已全部执行,而且在达到或超出指定的系统限制时没有出现任何软件故障。

需考虑的特殊事项:

(8)配置测试

测试目标:

核实测试对象可在所需的硬件和软件配置中正常运行。

技术:

使用功能测试脚本。

在测试过程中或在测试开始之前,打开各种与非测试对象相关的软件(例如Microsoft应用程序:

Excel和Word),然后将其关闭。

执行所选的事务,以模拟Actor与测试对象软件和非测试对象软件之间的交互。

重复上述步骤,尽量减少客户机工作站上的常规可用内存。

完成标准:

对于测试对象软件和非测试对象软件的各种组合,所有事务都成功完成,没有出现任何故障。

需考虑的特殊事项:

2.2.1登录模块测试

参与单位及被测试的部位见下表:

测试部位

登录确定操作

内容

利用有效的和无效的数据来功能,以核实以下内容:

在使用有效数据时可以进入相应主界面。

在使用无效数据时显示相应的错误消息或警告消息。

参与单位

软件工程课程设计第七开发小组

进度安排:

  测试日期安排:

2011年6月25日开始进行工作人员/管理员/航空客运订票管理模块测试。

2011年6月26日结束该模块测试。

熟悉环境:

熟悉《航空客运订票系统》的运行环境。

了解系统的操作方式以及使用方法。

输入数据:

登录界面输入用户名,密码,并选择身份,对登录进行测试。

2.2.2机票查询模块测试

参与单位及被测试的部位见下表:

测试部位

查询确定操作

内容

利用有效的和无效的数据来功能,以核实以下内容:

在使用有效数据时查询所需的机票。

在使用无效数据时显示相应的错误消息或警告消息。

参与单位

软件工程课程设计第七开发小组

进度安排:

  测试日期安排:

2011年6月26日开始进行工作人员/管理员/航空客运订票管理模块测试。

2011年6月26日结束该模块测试。

熟悉环境:

熟悉《航空客运订票系统》的运行环境。

了解系统的操作方式以及使用方法。

输入数据:

在查询模块测试中输入查询数据,对查询功能进行测试。

2.2.3订票模块测试

参与单位及被测试的部位见下表:

测试部位

机票的查询、确认操作

内容

利用有效的和无效的数据来测试功能,以核实以下内容:

在使用有效数据时将所需机票信息搜索出来进行确认订票操作。

在使用无效数据时显示相应的错误消息或警告消息。

参与单位

软件工程课程设计第七开发小组

进度安排:

  测试日期安排:

2011年6月27日开始进行订票模块测试。

2011年6月27日结束该模块测试。

熟悉环境:

熟悉《航空客运订票系统》的运行环境。

了解系统的操作方式以及使用方法。

输入数据:

在订票模块测试中输入查询数据,对查询功能进行测试。

选中已经查询出来的机票信息,测试订票功能。

2.3测试

2.3.1进度安排

测试活动

计划开始日期

结束日期

制定测试计划

2011-06-25

2011-06-25

设计测试

2011-06-25

2011-06-25

复审和评估测试覆盖

2011-06-26

2011-06-26

编写测试用例

2011-06-26

2011-06-26

实施测试

2011-06-26

2011-06-26

执行测试

2011-06-26

2011-06-26

评估测试的执行情况

2011-06-26

2011-06-26

核实结果

2011-06-27

2011-06-27

确定是否达到了测试

完成标准与成功标准

2011-06-27

2011-06-27

2.3.2条件

本次测试需要用到虚拟机软件以及IBM软件工具。

测试人员为5人,要求对IBM软件能熟悉各项功能以及操作。

处理器型号及内存容量:

奔腾III933Hz以上PC机,内存容量256M以上

外存容量:

硬盘空间80G以上

操作系统:

Win2000/XP

DBMS:

SQLServer2000或以上版本

2.3.3测试资料

《航空客运订票系统》的《需求规格说明书》,《概要设计说明书》,《详细设计说明书》。

测试的输入:

机票基本信息,工作人员基本信息,管理员基本信息等。

测试输出数据:

添加成功,删除成功,修改成功,预订成功,查询结果等。

编码涉及:

SQLSERVER数据库系统。

2.3.4测试培训

培训计划:

参照软件系统综合课程设计任务书。

培训内容:

学习IBM-Rational公司的测试工具。

受训人员:

《航空客运订票系统》小组开发人员。

培训的工作人员:

樊老师,董老师。

3测试设计说明

3.1登录模块测试

用与本测试计划3.l条相类似的方式说明第2项及其后各项测试工作的设计考虑。

3.1.1控制

此软件的测试控制方式主要是以人工输入为主,乘客的订票信息记录在乘客数据库中,各种查询信息则记录在航班信息数据库中。

3.1.2输入

用户登陆测试

角色:

工作人员

测试用例1(正确输入)

【输入】:

用户:

user密码:

123456

测试用例2(无该用户)

【输入】:

用户:

aa密码:

123456

测试用例3(密码错误)

【输入】:

用户:

user密码:

aa

测试用例4(无输入)

【输入】:

用户:

密码:

角色:

管理员

测试用例5(正确输入)

【输入】:

用户:

admin密码:

123456

测试用例6(无该用户)

【输入】:

用户:

aa密码:

123456

测试用例7(密码错误)

【输入】:

用户:

admin密码:

aa

测试用例8(无输入)

【输入】:

用户:

密码:

3.1.3输出

用户登陆测试

测试用例1(正确输入)

【期望输出】:

登入成功,进入工作人员用户界面

【实际输出】:

登入成功,进入工作人员用户界面

测试用例2(无该用户)

【期望输出】:

提示用户名或密码错误

【实际输出】:

提示用户名或密码错误

测试用例3(密码错误)

【期望输出】:

提示用户名或密码错误

【实际输出】:

提示用户名或密码错误

测试用例4(无输入)

【期望输出】:

提示用户名或密码错误

【实际输出】:

提示用户名或密码错误。

测试用例6(正确输入)

【期望输出】:

登入成功,进入工作人员用户界面

【实际输出】:

登入成功,进入工作人员用户界面

测试用例7(无该用户)

【期望输出】:

提示用户名或密码错误

【实际输出】:

提示用户名或密码错误

测试用例8(密码错误)

【期望输出】:

提示用户名或密码错误

【实际输出】:

提示用户名或密码错误

测试用例9(无输入)

【期望输出】:

提示用户名或密码错误

【实际输出】:

提示用户名或密码错误

3.2查询模块测试

3.2.1控制

此软件的测试控制方式主要是以人工输入为主,乘客的订票信息记录在乘客数据库中,各种查询信息则记录在航班信息数据库中。

3.2.2输入

查询测试:

测试用例1(正确输入)

【输入】:

按目的地输入:

北京

测试用例2(无该目的地)

【输入】:

按目的地输入:

乌鲁木齐

测试用例3(正确输入)

【输入】:

按航班号输入:

MU8056

测试用例4(无该航班号)

【输入】:

按航班号输入:

MU8054

测试用例5(正确输入)

【输入】:

按出行日期输入:

2011-6-23

测试用例6(无该出行日期)

【输入】:

按出行日期输入:

2011-6-24

3.2.3输出

查询测试

测试用例1(正确输入)

【期望输出】:

查询成功,显示前台机票信息窗体

【实际输出】:

查询成功,显示前台机票信息窗体

测试用例2(无该目的地)

【期望输出】:

提示无此航班信息

【实际输出】:

提示无此航班信息

测试用例3(正确输入)

【期望输出】:

查询成功,显示前台机票信息窗体

【实际输出】:

查询成功,显示前台机票信息窗体

测试用例4(无该航班号)

【期望输出】:

提示无此航班信息

【实际输出】:

提示无此航班信息

测试用例5(正确输入)

【期望输出】:

查询成功,显示前台机票信息窗体

【实际输出】:

查询成功,显示前台机票信息窗体

测试用例6(无该出行日期)

【期望输出】:

提示无此航班信息

【实际输出】:

提示无此航班信息

3.3订票系统测试

在测试过程中,首先需要对各子单元过程进行测试。

在各子单元过程测试完毕后,再对各模块(包括各子单元过程之间的接口)进行测试,处理好各模块之间的接口,最后对系统进行测试和维护。

各子模块测试名称如下:

登陆模块测试

订票模块测试

查询模块测试

3.3.1控制

此软件的测试控制方式主要是以人工输入为主,乘客的订票信息记录在乘客数据库中,各种查询信息则记录在航班信息数据库中。

3.3.2输入

订票模块测试:

测试订票1(正确输入)

【输入】:

目的地:

上海舱类型:

商务舱出发日期:

2011-06-28身份证号:

18位数量:

1

测试订票2(不存在此航班)

【输入】:

目的地:

西藏舱类型:

商务舱出发日期:

2011-06-31身份证号:

18位数量:

2

测试订票3(无余票)

【输入】:

目的地:

上海舱类型:

商务舱为空出发日期:

2011-06-28身份证号:

18位数量:

1

测试订票4(身份证不合法)

【输入】:

目的地:

上海舱类型:

商务舱出发日期:

2011-06-28身份证号:

不是18位数量:

1

测试订票5(订票数量已超出规定票数)

【输入】:

目的地:

上海舱类型:

商务舱出发日期:

2011-06-28身份证号:

18位数量:

11(超出规定的最大10张票的规定)

3.3.3输出

订票模块测试:

测试订票1(正确输入)

【期望输出】:

订票成功,显示订票号;

【实际输出】:

订票成功,显示订票号。

测试订票2(不存在此航班)

【期望输出】:

目的地不存在或该日期没有安排航班;

【实际输出】:

目的地不存在或该日期没有安排航班。

测试订票3(无余票)

【期望输出】:

到达该目的地已没有余额或者没有商务舱或经济舱已全部售出;

【实际输出】:

到达该目的地已没有余额或者没有商务舱或经济舱已全部售出。

测试订票4(身份证不合法)

【期望输出】:

该身份证不是大陆居民或位数不是18位;

【实际输出】:

该身份证不是大陆居民或位数不是18位。

测试订票5(订票数量已超出规定票数)

【期望输出】:

提示一次订票数量过多,预定不成功;

【实际输出】:

提示一次订票数量过多,预定不成功。

 

3.3.4过程

首先测试用户的权限,即选择管理员登陆和用户登陆的使用权限是不同的,用户登陆后只能进行信息查询而不能进行其他的查询,管理员登陆后可以进行各种操作;

然后测试订票子系统,查看输入的信息,是否适合数据库的限制策略。

随后测试航班时刻查询子系统、航班综合信息查询子系统。

4评价准则

4.1范围

在测试航班号时,输入123456和MU8056是不正确的,输入两个相同的航班号时候也不正确,因为航班号是主键,是唯一的;

在测试日期时,(2005年9月8日测试)要求订票期限是当日和以后15天之内的机票,如输入2005-9-25和2005-9-7都是错误的输入。

在测试用户名时,输入users和admins是不正确的,用户名必须根据数据库里的用户名而且还要对应相应的角色。

在测试密码时,输入123456以外的都不正确,因为密码都固定为123456。

在测试目的地时,输入了数据库中地点以外都是不正确的,如输入常德等。

4.2数据整理

陈述为了把测试数据加工成便于评价的适当形式,使得测试结果可以同已知结果进行比较而要用到的转换处理技术,如手工方式或自动方式;如果是用自动方式整理数据,还要说明为进行处理而要用到的硬件、软件资源。

在进行测试结果评价中,我是用手工方式整理数据的,然后同设计时要求的结果相比较。

4.3尺度

说明用来判断测试工作是否能通过的评价尺度,如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。

在测试录入选项时,有的选项是可以为空的,但有的不可以;而测试输出结果与预期输出之间的容许偏离范围是要还能达到预期结果而逻辑顺序可以有偏离。

在登陆时,错误的次数不能超过三次。

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

当前位置:首页 > 小学教育 > 英语

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1