飞机订票系统的测试.docx

资源描述

飞机订票系统的测试.docx

《飞机订票系统的测试.docx》由会员分享，可在线阅读，更多相关《飞机订票系统的测试.docx（22页珍藏版）》请在冰豆网上搜索。

飞机订票系统的测试.docx

飞机订票系统的测试

飞机订票系统性能测试计划

性能测试

Team4

发布时间：

2010年5月4日

1测试计划总论（朱云峰）

1.1项目背景

在开发大型软件的漫长过程中，面对极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺。

因此，在软件生命周期的每个阶段都不可避免地会产生差错。

尤其对于机票预订系统这类会影响人们生活．财产的工程软件，必须尽量减少差错，以免造成严重的损失。

测试是“为了发现程序中的错误而执行程序的过程”。

测试的目的就是在软件投入生产性运行之前，尽可能多的发现软件中的错误。

此次的性能测试，也是必不可少的关键步骤。

软件系统名称:

FlightReservationSystem

软件系统功能：

让旅客能够方便、正确、无误的在网上订购自己所需的机票

本项目测试类型分类:

1.常用测试类型:

并发测试：

并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。

负载测试：

负载测试（LoadTesting）在给定的测试环境下，通过逐步增加系统负载，直到性能指标超过预定指标或某种资源使用已经达到饱和状态，从而确定系统在各种工作负载下性能容量和处理能力，以及持续正常运行的能力，确定系统所能够承受的最大负载量。

稳定测试：

通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

2.非常用测试类型:

峰谷测试：

确定系统从高负载到低负载、甚至空闲，然后再攀升到高负载、再降低的能力。

这里的峰值，不是系统所能承载的最大吞吐量。

而是，系统正式运行时会出现的峰值（或这个峰值的加权值），峰谷测试一定是在压力测试已经完成并且测试通过后进行的。

1.2项目目标

测试是“为了发现程序中的错误而执行程序的过程”,测试的目的就是在软件投入生产性运行之前，尽可能多的发现软件中的错误。

1.保证此软件系统能够正常运行。

2.保证此软件系统不会出现严重的错误。

3.减少一般的不威胁系统运行的错误发生率。

4.能够让用户方便，快捷的使用本系统，为日常的办公提供方便。

1.3系统视图

系统登陆界面：

系统订票界面：

1.4文档目的

此系统软件为方便旅客把预定机票的个人信息，包括姓名、旅行时间、旅行目的地、座位需求所、订航班号输入机票预定系统的客户端程序，系统经过查询航空公司内的航班数据服务器后，为旅客安排航班，印出取票通知。

要求系统能有效、快速、安全、可靠和无误的完成上述操作。

本文档为此测试项目能够顺利执行而写。

运行环境

由于系统将由两部分程序组成，安装在各旅行社客户机上的客户程序及航空公司内的数据服务器程序。

一、服务器端子系统的运行要求：

系统软件：

WindowNTServer

数据库管理系统：

SQLServer

二、客户端子系统的运行要求：

系统软件：

WindowNTWorkstation

数据库管理系统：

SQLServer

1.6参考文档

测试计划（GB8567——88）

银行储蓄系统测试计划

SOVO网站（第二版）SovoWebSystem（Ver2nd）软件系统测试计划书

山东电子职业技术学院无限餐饮系统软件测试计划（STP）

机票预定系统测试计划

软件测试计划

三普销售助手标准版测试计划

中金玛泰测试计划

性能测试基础流程—阿里巴巴性能测试实践

性能测试分析报告评审流程—某大银行

性能测试详细介绍和相关模型—淘宝性能测试白皮书V1[1].0_内部

性能测试最基本的应用—OA系统的性能测试方案

性能测试基本案例—一个邮件系统比较详细的测试案例

附录—石化人力资源性能测试方案0903

2测试策略的制定（林琰，赵宸）

2.1整体策略：

此次项目特点,不是单纯的网页,而是和服务器连接的主机上的软件,所以网页上的一些问题不需要测试,测试重点在和服务器的联系上。

主要方法定位负载测试,压力测试,稳定测试,性能测试.需要的自动化工具主要是多用户模拟器测试之前要做试运行以及对类似服务器的数据调查,用于制定每日最大浏览量和峰值出现时间段,以便模拟每个测试用例要有相应的表格进行记录,并和测试标准进行比较。

（标点全都有问题）

2.2测试范围:

登陆,操作（包括提交,删除,查询）时服务器端的状态

策略

登陆界面负载测试策略

方法：

单场景

内容：

模拟7000~11000个用户同时登陆flights的登陆界面

先有7000个用户同时登陆flights的登陆界面，进行登陆操作，记录响应时间。

再以10人/秒的速度增加用户数，进行登录操作，记录每次的响应时间。

风险分析：

测试可能会导致系统崩溃

解决方案：

1重要数据事前备份、事后恢复2测试时间选择系统空闲时间

风险分析：

测试可能会造成数据损坏

解决方案：

1重要数据事前备份、事后恢复2实时关注系统状态

风险分析：

测试会产生大量垃圾数据

解决方案：

1重要数据事前备份、事后恢复2给测试数据加标记

风险分析：

若利用手工测试需要大量人员及设备

解决方案：

1增加费用2使用模拟器

订票界面负载测试

方法：

单场景，组合场景

内容：

模拟7000~11000个用户进行单项执行操作

先有7000个用户同时进行单项执行操作，记录响应时间。

再以10人/秒的速度增加用户数，进行单项执行操作操作，记录每次的响应时间。

模拟1个用户在订票界面同时进行多项执行操作，记录响应时间。

模拟1000个用户在订票界面同时进行多项执行操作，记录响应时间。

风险分析：

测试可能会导致系统崩溃

解决方案：

1重要数据事前备份、事后恢复2测试时间选择系统空闲时间

风险分析：

测试可能会造成数据损坏

解决方案：

1重要数据事前备份、事后恢复2实时关注系统状态

风险分析：

测试会产生大量垃圾数据

解决方案：

1重要数据事前备份、事后恢复2给测试数据加标记

风险分析：

若利用手工测试需要大量人员及设备

解决方案：

1增加费用2使用模拟器

并发测试策略

登陆界面测试策略

方法：

单场景

内容：

模拟7000~11000个用户同时登陆flights的登陆界面

先有7000个用户同时登陆flights的登陆界面，进行登陆操作，记录客户端的响应时间和服务器端的性能监测情况。

再以10人/秒的速度增加用户数，进行登录操作，记录客户端的响应时间和服务器端的性能监测情况。

风险分析：

测试可能会导致系统崩溃

解决方案：

1重要数据事前备份、事后恢复2测试时间选择系统空闲时间

风险分析：

测试可能会造成数据损坏

解决方案：

1重要数据事前备份、事后恢复2实时关注系统状态

风险分析：

测试会产生大量垃圾数据

解决方案：

1重要数据事前备份、事后恢复2给测试数据加标记

风险分析：

若利用手工测试需要大量人员及设备

解决方案：

1增加费用2使用模拟器

订票界面并发测试

方法：

单场景，组合场景

内容：

模拟7000~11000个用户进行单项执行操作

先有7000个用户同时进行单项执行操作，记录客户端的响应时间和服务器端的性能监测情况。

再以10人/秒的速度增加用户数，进行单项执行操作操作，记录客户端的响应时间和服务器端的性能监测情况。

模拟1个用户在订票界面同时进行多项执行操作，记录客户端的响应时间和服务器端的性能监测情况。

模拟1000个用户在订票界面同时进行多项执行操作，记录客户端的响应时间和服务器端的性能监测情况。

风险分析：

测试可能会导致系统崩溃

解决方案：

1重要数据事前备份、事后恢复2测试时间选择系统空闲时间

风险分析：

测试可能会造成数据损坏

解决方案：

1重要数据事前备份、事后恢复2实时关注系统状态

风险分析：

测试会产生大量垃圾数据

解决方案：

1重要数据事前备份、事后恢复2给测试数据加标记

风险分析：

若利用手工测试需要大量人员及设备

解决方案：

1增加费用2使用模拟器

稳定性测试策略

登陆界面测试策略

方法：

单场景

内容：

7000个用户持续在页面上登陆7*24/30*24小时，记录响应时间

风险分析：

测试可能会导致系统崩溃

解决方案：

1重要数据事前备份、事后恢复2测试时间选择系统空闲时间

风险分析：

测试可能会造成数据损坏

解决方案：

1重要数据事前备份、事后恢复2实时关注系统状态

风险分析：

测试会产生大量垃圾数据

解决方案：

1重要数据事前备份、事后恢复2给测试数据加标记

风险分析：

若利用手工测试需要大量人员及设备

解决方案：

1增加费用2使用模拟器

2.5.2订票界面测试策略

方法：

单场景，组合场景

内容：

7000个用户持续在页面上操作7*24/30*24小时，记录响应时间

风险分析：

测试可能会导致系统崩溃

解决方案：

1重要数据事前备份、事后恢复2测试时间选择系统空闲时间

风险分析：

测试可能会造成数据损坏

解决方案：

1重要数据事前备份、事后恢复2实时关注系统状态

风险分析：

测试会产生大量垃圾数据

解决方案：

1重要数据事前备份、事后恢复2给测试数据加标记

风险分析：

若利用手工测试需要大量人员及设备

解决方案：

1增加费用2使用模拟器

峰值测试策略

登陆界面测试策略

方法：

单场景

内容：

10~7000用户登陆,每秒增加10人,每秒记录一次,升降3次，记录响应时间

风险分析：

测试可能会导致系统崩溃

解决方案：

1重要数据事前备份、事后恢复2测试时间选择系统空闲时间

风险分析：

测试可能会造成数据损坏

解决方案：

1重要数据事前备份、事后恢复2实时关注系统状态

风险分析：

测试会产生大量垃圾数据

解决方案：

1重要数据事前备份、事后恢复2给测试数据加标记

风险分析：

若利用手工测试需要大量人员及设备

解决方案：

1增加费用2使用模拟器3投入试运行得到数据

订票界面测试策略

方法：

单场景，组合场景

内容：

10~7000用户操作,每秒增加10人,每秒记录一次,升降3次，记录响应时间

风险分析：

测试可能会导致系统崩溃

解决方案：

1重要数据事前备份、事后恢复2测试时间选择系统空闲时间

风险分析：

测试可能会造成数据损坏

解决方案：

1重要数据事前备份、事后恢复2实时关注系统状态

风险分析：

测试会产生大量垃圾数据

解决方案：

1重要数据事前备份、事后恢复2给测试数据加标记

风险分析：

若利用手工测试需要大量人员及设备

解决方案：

1增加费用2使用模拟器3投入试运行得到数据

3测试方法的制定（屈超杰）

3.1里程碑技术

里程碑标志着上一个阶段的结束，下一个阶段的开始，也就是说上一个阶段结束的标准，和下一个阶段开始的启动条件。

包括制定测试计划。

设计测试。

？

实施测试。

执行测试。

评估测试。

3.2测试用例设计

一．采用专业测试工具LoadRunner、Yslow，采用录制/回放的方法，即首先录制客户端信息的发送、服务器端接收的数据包，然后采用单线程/多线程的方式模拟大量客户端向服务器方发送业务请求，达到压力测试的目的．

二．在各时段，例如，订票高峰期，午夜时分，节假日的服务器储存客户订票信息的准确性，是否会出现丢包的现象。

三．测试，当客户更改订票信息的时候，服务器是否会准确的记录，是否出现数据记录错误的情况。

四．测试，同时在线的最大人数。

3.3测试实施过程

测试环境：

服务器是一台dellpcserver，安装的软件包括IIS，ASP.NET，SQLSERVER

使用20个笔记本模拟客户端发出请求。

一、2M、4M、10M带宽的站点支持的同时在线的用户数

二、a）模拟1000.、3000、5000、10000的用户数对服务器操作，进行压力测试。

b）用客户端对服务器进行长达30天的持续数据交换，以进行稳定性测试。

c）多用户，对服务器进行同一数据操作，以及用户对服务器进行多数据操作，以进行并发性测试。

d）在特定的某一时间段，进行大量客户登陆服务器，以进行峰谷测试。

三、服务器的吞吐量，即每秒内可以处理的交易个数。

指标包括cpu=80%的吞吐量和cpu=100%的吞吐量

注：

1、一般情况下，比较好的用户体验是在5秒以内完成交易，所以以上提到的同时在线用户数是指在5秒的收到响应的用户。

2、本次测试的交易响应时间只包括服务器经处理并返回信息到客户端的时间

单场景测试

测试的业务

带宽

最大并发虚拟用户数

服务器响应时间

1000

3000

登陆

10M

5000

订票

1000

订票

3000

订票

10M

5000

.3组合场景测试

测试的业务

带宽

最大并发虚拟用户数

服务器数据记录状况

10M

1000

10M

3000

登陆、订票、取消订票

10M

5000

10M

1000

10M

3000

10M

5000

10M

1000

10M

3000

10M

5000

4测试标准的制定（谷常敏）

4.1测试通过/失败标准

测试通过/失败标准如下：

◆测试用例执行通过率＝通过的测试用例个数/测例总数。

该值>=95％。

◆性能测试通过标准还包括服务端性能、前端性能和用户体验性能，通过标准如下表所示。

类别

判断维度

通过

不通过

备注

服

务

端

性

能

超时概率

小于万分之一

大于万分之一

性能测试团队根据通过标准，判定被测性能点不通过，而PM、PDM认为可以通过时，需要进行沟通。

沟通以会议形式，由专家组来评判。

错误概率

小于万分之一

大于万分之一

每秒事务处理量

大于10000

小于10000

CPU利用率

小于75%

大于75%

响应时间

小于2s

大于2s

物理磁盘读写时间

小于2s

大于2s

内存使用率

小于80%

前端性能

YSlow评定

YSlow评定为C级以上

YSlow评定为C级以下

用户体验性能

界面响应时间

10M带宽，小于5秒

10M带宽，大于5秒

4.2测试挂起标准及恢复条件

挂起标准及要求：

1.软件系统在进行性能测试时，当发现一级错误、二级错误暂停测试返回开发。

2．软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。

3.软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。

4.如有新的项目需求，则在原测试计划下做相应的调整。

5.出现优先级更高的任务。

6.人员，设备不足。

恢复条件：

1.发现的一级错误、二级错误已被修复。

2.软件项目调整完成。

3.人员，设备到位。

5资源需求（何铁流）

5.1培训需求

▪培训需求：

对新进项目人员进行测试工具培训以及了解项目背景。

培训内容：

当前项目软件测试工具培训（如：

LoadRunner）;当前项目内容及相关知识培训。

培训时间：

2个工作日（每日八小时计）。

培训组织：

由项目经理安排。

5.2硬件需求

▪硬件需求：

本系统的硬件环境如下：

客户机：

普通PC（需要7台）

内存：

256MB以上

分辨率：

推荐使用1024*768像素

WEB服务器

内存：

256MB以上

数据库服务器

内存：

256MB以上

5.3软件需求

软件需求：

软件名称：

FlightRrservation

版本号：

5.0.89.0

权限分类：

管理员组（Administrators）、高权限用户组（PowerUsers）、普通用户组（Users）、备份操作组（BackupOperators）、文件复制组（Replicator）

5.4网络需求

FTTX+LAN（10MB/S或更高）。

为了满足测试时实际网络安全需求，建设安全防护系统，完成测试安全政策和安全管理措施的制定，安全管理中心和网络监视系统的建设（包括将防火墙、防垃圾邮件、防病毒、安全控管平台等相关单元安全产品配置到的各个具体位置上，发挥安全防护作用；网络设备和服务的7X24小时监视以及手机短信报警系统）。

办公空间需求？

1.确保能容纳至少7人同时工作，隔音效果良好，采光度良好，空气质量正常。

2.办公场所必须保持干净整洁，禁止摆放与工作无关的个人用品（如餐具、玩具、装饰品等），每天至少做一次保洁，做到窗明几净，地面无污物，桌面无灰尘。

　3.办公用品摆放整齐，桌面不得堆放与手头无关的办公用品，个人办公桌及文件柜至少一个月清理一次，无价值或价值不大的东西一律丢弃。

　4.计算机硬件部分要保持整洁，键盘、屏幕擦拭干净，确保正常运转。

　5.不准在系统计算机安装与工作无关的软件、桌面（屏幕）须保留原系统设置，工作时间一律不得用计算机玩游戏（包括正常游戏：

纸牌、扫雷等）。

　6.办公场所的电话应保持通畅，个人私事用线路一次不得超过两分钟。

5.6相关信息保存的需求

1.软件测试过程中所有开发和测试执行人员都能够访问软件相关信息；

经常性的备份，备份文件应该定期的恢复；

3.所有测试计划测试用例和测试结果都需要备份；

件测试过程中应具有版本控制功能，确保能回复到较早前的版本。

5.7人力资源需求

1.测试经理，测试项目经理

工作概要：

进行管理监督。

工作职责：

提供技术指导，获取适当的资源，提供管理报告。

2.测试设计员

工作概要：

确定测试用例、确定测试用例的优先级并实施测试用例。

工作职责：

生成测试计划，生成测试模型，评估测试工作的有效性。

3.测试员

工作概要：

执行测试。

工作职责：

执行测试，记录结果，从错误中恢复，记录变更请求

4.测试系统管理员

工作概要：

确保测试环境和资产得到管理和维护。

工作职责：

管理测试系统，授予和管理角色对测试系统的访问权

6时间进度安排（姚钰）

6．1时间进度计划表

测试阶段

测试任务

工作量估计

人员分配

起止时间

性能测试

测试计划总论制定

制定项目背景，项目目标，系统视图，文档目的，文档摘要

一名测试人员

2010-4-29至2010-5-3

测试策略制定

并发测试，负载测试，稳定性测试，峰谷测试

两名测试人员

2010-4-29至2010-5-3

测试方法制定

包括里程碑技术，测试用例设计，测试实施过程的制定

一名测试人员

2010-4-29至2010-5-3

测试标准制定

包括制定测试通过/失败标准，测试挂起标准及恢复条件

一名测试人员

2010-4-29至2010-5-3

资源需求分析

包括制定培训需求，硬件需求，软件需求，办公空间需求，相关信息保存的位置，人力资源需求

一名测试人员

2010-4-29至2010-5-3

测试用例草案制定

包括并发测试，负载测试，稳定性测试，峰谷测试的测试用例草案制定

一名测试人员

2010-4-29至2010-5-3

里程碑任务

预计工作量

预计开始时间

预计结束时间

确定基线

三人每人8小时

2010年5月10日

2010年5月11日

通过压力测试找到一个瓶颈点

七人每天8小时

2010年5月12日

2010年5月14日

通过峰谷测试找到极限点

七人一天8小时

2010年5月15日

注：

确定基线期间，其余4人做测试前期准备工作。

风险分析

序号

风险描述

解决方法

系统可侧性差

测试环境不符合测试要求

加强测试环境的管理和改进

测试人手不够，时间不足

在项目前期加强对人员的管理和培训，测试人员要尽早熟悉产品，做好人员分配工作。

测试所需硬件、软件需求不满足

测试前做好测试所需硬件配置，软件安装更新等工作。

7测试过程管理（姚钰）

7.1报告机制

▪为帮助更加有效的管理和控制整个项目的进展，整个测试项目中，测试人员每周进行工作报告，项目管理人员每月进行测试项目阶段报告。

报告要求是以Word、excel或者ppt形式介绍工作进程和工作内容的具体情况。

7.2沟通机制

▪由于测试项目的参与不同，需要对各方之间的沟通机制进行定义并实施，才能保证各方能够及时、有效的沟通，沟通主要来于两方面：

内部沟通：

测试团队内部会议、交流等方式，包括发起责任人，参与者，发起周期、主要范围和输出等。

外部沟通：

测试团队与开发、用户之间的会议、交流等方式

8测试用例草案（赵宸）

案例名称

并发用户数

网络环境（带宽）

方法

负载测试登陆页面

7000，7010，7020…10990，11000

FTTX+LAN（10MB/s）

单场景（并发用户全部执行登陆）

负载测试订票页面

7000，7010，7020…10990，11000

单场景（并发用户全部执行提交，删除，查询中的一种），组合场景（并发用户全部执行提交，删除，查询中的多种）

并发测试登陆页面

7000，7010，7020…10990，11000

FTTX+LAN（10MB/s）

单场景（并发用户全部执行登陆）

并发测试订票页面

7000，7010，7020…10990，11000

单场景（并发用户全部执行提交，删除，查询中的一种），组合场景（并发用户全部执行提交，删除，查询中的多种）

稳定性测试登陆页面

7000

FTTX+LAN（10MB/s）

单场景（并发用户全部执行登陆），持续一段时间（7*24/30*24小时）

稳定性测试订票页面

7000

单场景（并发用户全部执行提交，删除，查询中的一种），组合场景（并发用户全部执行提交，删除，查询中的多种），持续一段时间（7*24/30*24小时）

峰值测试登陆页面

10，20，30，40…6990，7000，6990…20，10，20，30…6990，7000

FTTX+LAN（10MB/s）

单场景（并发用户全部执行登陆），升降3次（模拟峰值峰谷变化）

峰值测试订票页面

10，20，30，40…6990，7000，6990…20，10，20，30…6990，7000

单场景（并发用户全部执行提交，删除，查询中的一种），组合场景（并发用户全部执行提交，删除，查询中的多种），升降3次（模拟峰值峰谷变化）

9.数据字典（谷常敏）

通过测试用例的相应设定，从而确定所需测试数据的数量。

测试数据以实际订票需要的相应数据为基准。

数据流编号：

DF001

数据流名称：

定票单

简述：

定票时填写的定票单

数据流来源：

外部实体“旅客”

数据流去处：

处理逻辑“预定机票”

数据流组成：

FlightSchedule、OrderInformation、PassengerName、

Class、TicketInformatin

流通量：

每天20万份

高峰期流通量：

上午9：

00—11：

00、约7000份

9.（对于定票单）

1.FlightSchedule：

DataOf

展开阅读全文