软件测试是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。 
 
     系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。
系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。

系统测试过程主要包括：

1.1.2 性能测试指标

本次测试是针对普通话等级考试报名及成绩查询系统在应对密集整转的大压力下而进行的，主要需要获得如下的测试指标。
1、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。
2、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端请求发起，到服务器端应答返回所需要的时间，包括网络传输时间和服务器处理时间。
3、应用系统的可靠性：即在连续工作时间状态下，系统能够正常运行的时间，即在连续工作时间段内没有出错信息。

1.  系统结构及流程

      系统结构跟本次性能测试所采用的体系结构是一样的，交易流程也是一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。

1. 系统总体结构

描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。

1.2.2  功能模块

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

2. 本系统的功能模块包括：考生注册、信息确认、考生登录、考试报名、成绩查询、学生信息修改、信息管理。

1. 性能测试环境

本次性能测试环境与真实运行环境硬件和网络环境有所不同，是真实环境的缩小，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端通过前台安装访问应用系统。
   其中具体的环境如下：
中间服务器：Internet Explorer

• 性能测试

从广泛意义上讲性能测试包括：压力测试、稳定性测试、负载能力测试和可扩展性测试等。在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次普通话等级考试报名及成绩查询系统的性能测试主要是采用通常的压力测试模式来执行的，即：逐步增加压力，查看应用系统在各种压力状况下的性能表现。
在本次性能测试中，将使用美科利（Mercury）公司的性能测试LoadRunner8.1对测试应用的各层进行监控，判断J2EE各层次的各类方法和类的调用使用时间和效率，并帮助开发人员分析J2EE应用的各类操作的性能瓶颈点。
2.1  压力测试
在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。
2.1.1压力测试概述
本次测试是针对普通话等级考试报名及成绩查询系统在应对密集整转的压力下业务处理能力的测试，检验系统的吞吐率。本系统的压力测试主要是针对主要业务功能、报表统计进行，检查在日间应用高峰时期，并发用户数较多的时候的处理能力等等。
2.1.2测试目的
压力测试的目的就是检验系统的最大吞吐量，检验现行的业务系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。
本次针对普通话等级考试报名及成绩查询系统所进行的压力测试的测试目的为：

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

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

2.2 正确性测试
   输入用户实际相关数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。取某些特例进行检测，看是否能出现预期的效果。
2.3 容错性（健壮性）测试
程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。增大系统适用范围。
2.4 完整（安全）性测试：
对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整与安全。
2.5 接口间测试：
接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
2.6 数据库测试：
依据数据库设计规范对软件系统的数据库结构、数据表及其之间数据调用关系进行测试。
2.7 错误推测：
主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
2.8 效率：
完成预定的功能，系统的运行时间（主要是针对数据库而言）。
2.9 可理解（操作）性：
理解和使用该系统的难易程度（界面友好性）。
2.10 可移植性：
在不同操作系统及硬件配置情况下的运行性。
2.11 回归测试：
按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员已经解决，进行下一轮的测试。

1. 比较测试：

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

预计测试过程及结果描述

测试描述

根据系统特性与共性准备测试数据，在测试数据准备完备以后，由测试人员进行测试。并由测试人员记录每次测试的结果，分析测试结果对系统进行全面评估以及做出相关改进。

1. 测试场景

   先进行一些简单的数据录入、管理、修改及输出测试。采用一些原本该受限制不可用的数据进行检测，观察是否能得出预想的结果。参照其他类似系统会出现的问题或在设计过程中认为可能出现的问题对该系统进行检测，观察结果，是否符合要求。
进行一些正常操作，记录系统反应时间，计算系统运行速率。
观察操作界面是否足够人性化，在相关操作进行时能否出现相关提示。
测试中，使用逐步加压的模式，测试运行场景安排如下：

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

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

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

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

每个场景都包括：用户登录-业务操作-业务完成-退出系统，所有用例都按以上场景进行测试，由于pc性能限制，为了更准确模拟现场环境，将运行的所有脚本部署在8台LoadRunner终端上，主要目的就是检查在不同的压力的情况下，业务系统的性能表现。
按照测试用例进行测试完毕进行相关修改后再进行下一轮测试。
3.3  测试结果
将测试得出的数据与原来预想的数据进行对比，寻找差距，从中分析出错原因，与上述所需要做的性能测试一一对照，寻找可能出现的相关问题，再想办法解决。
测试结果记录为一下相关数据：
测试中完成各操作的平均响应时间：（单位：秒）