软件系统测试方案.docx

软件系统测试方案.docx

《软件系统测试方案.docx》由会员分享，可在线阅读，更多相关《软件系统测试方案.docx（9页珍藏版）》请在冰豆网上搜索。

软件系统测试方案

软件系统测试方案

前言

系统已在成功上线，从而的业务信息管理逐步走上了集中管控的道路。

由于密集整转在全市各点展开，从而将会势必出现业务系统中信息大量增长的态势。

随着业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：

每天大数据量的“冲击”，系统能稳定在什么样的性能水平，面临公司业务增加时，系统能否经受住“考验”，这些问题需要经过一个完整的性能测试来给出答案。

软件测试主要依据是被试系统的研制任务书和技术规格书，是对软件整体功能和性能的综合测试与评估。

测试原理是软件测试活动的理论基础，测试方法是测原理的实际应用和获得测试数据的手段。

基于软件的共性，对于软件的测试要遵循一般软件的测试原理和方法。

同时，针对软件的特性，找到合适的测试方法。

测试用例的合理性对于软件的测试与评估具有关键作用。

另一方面，软件运行环境的复杂程度对软件评估具有重要作用，因此应产生尽量逼真的运行背景以便于研究。

前言………………………………………………………………2

测试方案

第一章普通话等级考试报名及成绩查询系统性能测试概述

…………………………………………………………5

1.1被测系统定义………………………………………………5

1.1.1功能简介………………………………………………………5

1.1.2性能测试指标…………………………………………………5

1.2系统结构及流程……………………………………………6

1.2.1系统总体结构………………………………………………6

1.2.2功能模块…………………………………………………………6

1.3性能测试环境…………………………………………………7

第二章性能测试……………………………………………………7

2.1压力测试………………………………………………………7

2.1.1压力测试概述……………………………………………………………7

2.1.2测试目的…………………………………………………………………7

2.2正确性测试………………………………………………………8

2.3容错性（健壮性）测试…………………………………………8

2.4完整（安全）性测试……………………………………………8

2.5接口间测试………………………………………………………8

2.6数据库测试………………………………………………………8

2.7错误推测…………………………………………………………8

2.8效率………………………………………………………………8

2.9可理解（操作）性…………………………………………………8

2.10可移植性…………………………………………………………8

2.11回归测试…………………………………………………………9

2.12比较测试…………………………………………………………9

第三章预计测试过程及结果描述……………………………………9

3.1测试描述……………………………………………………………9

3.2测试场景……………………………………………………………9

3.3测试结果……………………………………………………………10

测试用例

第四章目的……………………………………………………………12

第五章项目概要…………………………………………………12

第六章项目简介…………………………………………………12

6.1设计目的………………………………………………………………12

6.1.1开发环境……………………………………………………………………………12

6.1.2程序功能……………………………………………………………………………12

测试方案

第一章普通话等级考试报名及成绩查询系统性能测试概述

1.1.被测系统定义

普通话等级考试报名及成绩查询系统作为本次测试的被测系统（注：

以下所有针对被测系统地描述均为针对普通话等级考试报名及成绩查询系统进行的），普通话等级考试报名及成绩查询系统是由C#编写的网页系统，后台应用了SQLsever数据库，该系统包括主要功能有:

普通话等级考试报名及成绩查询等，在本次测试中，将针对这些大数据量的查询、统计功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统的负载能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。

1.1.1.功能简介

支持考生信息的输入，管理。

考生能够登录自己的账户进行考试报名以及报名信息、成绩查询等。

能够统计考试报名信息，进行管理录入。

创立考试数据库，而且能够进行数据管理、修改、添加等。

包括对考生报名信息限制的操作管理功能。

1.1.2性能测试指标

本次测试是针对普通话等级考试报名及成绩查询系统在应对密集整转的大压力下而进行的，主要需要获得如下的测试指标。

1、应用系统的负载能力：

即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。

2、系统的响应能力：

即在各种负载压力情况下，系统的响应时间，也就是从客户端请求发起，到服务器端应答返回所需要的时间，包括网络传输时间和服务器处理时间。

3、应用系统的可靠性：

即在连续工作时间状态下，系统能够正常运行的时间，即在连续工作时间段内没有出错信息。

1.2.系统结构及流程

普通话等级考试报名及成绩查询系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也是一致的。

不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。

1.2.1系统总体结构

描述本系统的总体结构，包括：

硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。

1.2.2功能模块

1．本次性能测试中各类操作都是由若干功能模块组成的，每个功能都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块）。

2．本系统的功能模块包括：

考生注册、信息确认、考生登录、考试报名、成绩查询、学生信息修改、信息管理。

功能模块分布如下图所示：

1.3.性能测试环境

本次性能测试环境与真实运行环境硬件和网络环境有所不同，是真实环境的缩小，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端经过前台安装访问应用系统。

其中具体的环境如下：

中间服务器：

InternetExplorer

Ø操作系统：

Windows7/Windowsxp

Ø网络环境：

LAN（10M）

Ø数据库：

sqlserver

Ø客户端：

PC（Windows）

第二章性能测试

从广泛意义上讲性能测试包括：

压力测试、稳定性测试、负载能力测试和可扩展性测试等。

在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次普通话等级考试报名及成绩查询系统的性能测试主要是采用一般的压力测试模式来执行的，即：

逐步增加压力，查看应用系统在各种压力状况下的性能表现。

在本次性能测试中，将使用美科利（Mercury）公司的性能测试LoadRunner8.1对测试应用的各层进行监控，判断J2EE各层次的各类方法和类的调用使用时间和效率，并帮助开发人员分析J2EE应用的各类操作的性能瓶颈点。

2.1压力测试

在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。

2.1.1压力测试概述

本次测试是针对普通话等级考试报名及成绩查询系统在应对密集整转的压力下业务处理能力的测试，检验系统的吞吐率。

本系统的压力测试主要是针对主要业务功能、报表统计进行，检查在日间应用高峰时期，并发用户数较多的时候的处理能力等等。

2.1.2测试目的

压力测试的目的就是检验系统的最大吞吐量，检验现行的业务系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。

本次针对普通话等级考试报名及成绩查询系统所进行的压力测试的测试目的为：

✧给出普通话等级考试报名及成绩查询系统当前的性能状况

✧定位普通话等级考试报名及成绩查询系统性能瓶颈或潜在性能瓶颈总结一套合理的、可操作的、适合公司现实情况的性能测试方案，为后续的性能测试工作提供基本思路。

2.2正确性测试

输入用户实际相关数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，而且正常。

取某些特例进行检测，看是否能出现预期的效果。

2.3容错性（健壮性）测试

程序能够接收正确数据输入而且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。

把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。

增大系统适用范围。

2.4完整（安全）性测试：

对XX的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整与安全。

2.5接口间测试：

接口间测试：

测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

2.6数据库测试：

依据数据库设计规范对软件系统的数据库结构、数据表及其之间数据调用关系进行测试。

2.7错误推测：

主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

2.8效率：

完成预定的功能，系统的运行时间（主要是针对数据库而言）。

2.9可理解（操作）性：

理解和使用该系统的难易程度（界面友好性）。

2.10可移植性：

在不同操作系统及硬件配置情况下的运行性。

2.11回归测试：

按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员已经解决，进行下一轮的测试。

2.12比较测试：

将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。

第三章预计测试过程及结果描述

3.1测试描述

根据系统特性与共性准备测试数据，在测试数据准备完备以后，由测试人员进行测试。

并由测试人员记录每次测试的结果，分析测试结果对系统进行全面评估以及做出相关改进。

3.2测试场景

先进行一些简单的数据录入、管理、修改及输出测试。

采用一些原本该受限制不可用的数据进行检测，观察是否能得出预想的结果。

参照其它类似系统会出现的问题或在设计过程中认为可能出现的问题对该系统进行检测，观察结果，是否符合要求。

进行一些正常操作，记录系统反应时间，计算系统运行速率。

观察操作界面是否足够人性化，在相关操作进行时能否出现相关提示。

测试中，使用逐步加压的模式，测试运行场景安排如下：

1.每隔2秒增加1个用户连接，最多增加到100个用户，查看并记录运行情况

2.每隔2秒增加2个用户连接，最多增加到200个用户，查看并记录运行情况

3.每隔2秒增加1个用户连接，最多增加到300个用户，查看并记录运行情况

4.每隔3秒增加1个用户连接，最多增加到400个用户，查看并记录运行情况

每个场景都包括：

用户登录-业务操作-业务完成-退出系统，所有用例都按以上场景进行测试，由于pc性能限制，为了更准确模拟现场环境，将运行的所有脚本部署在8台LoadRunner终端上，主要目的就是检查在不同的压力的情况下，业务系统的性能表现。

按照测试用例进行测试完毕进行相关修改后再进行下一轮测试。

3.3测试结果

将测试得出的数据与原来预想的数据进行对比，寻找差距，从中分析出错原因，与上述所需要做的性能测试一一对照，寻找可能出现的相关问题，再想办法解决。

测试结果记录为一下相关数据：

测试中完成各操作的平均响应时间：

（单位：

秒）

测