大学学籍管理系统测试计划

大学学籍管理系统

测试计划

版本历史

版本/状态修订人起止日期审核人\日期简要阐明

VI.0王莉2023-11-4建立

VI.1盛安平2023-11-30修订

1.简介

该测试计划简介了怎样测试大学学籍管理系统。它提供了测试范围、测试方略，人员安

排等详细信息。

1.1目的

这份文档日勺目的是详细描述对大学学籍管理系统进行功能验证的测试过程。本文档所关

注的特性来自于需求文档。（有关大学学籍管理系统项目的功能描述，请参阅大学学籍管理系

统需求规格阐明书。）

1.2背景

为了提高从事学生工作的老师的工作效率，我们开发了这个大学学籍管理系统。这个

系统能满足顾客Login/Logout,管理员账户与一般账户，管理员可以添加，修改删除，一

般账户只能查看。重要功能：能完毕新学生日勺添加、修改、删除，能按学生成绩求和，排名，

列出不及格学生的名单等，操作简朴、界面友好；保证信息的精确性，动态性，安全性。大

学学籍管理系统是基于J2EEU勺技术，采用B/S构造，适于分布式多客户作业，客户端的规

定也很低。

1.3范围

测试阶段包括单元测试，集成测试，系统测试，性能测试，验收测试及对测试进行评估。

本计划所针对地测试类型是需求阶段的测试，即对大学学籍管理系统进行功能验证的

测试过程。

准备测试的特性

如卜•特性将被测试，以保证“大学学籍管理系统”能满足规定的需求：

1）管理员与一般顾客的权限

◊管理员的权限：添加，删除，修改

今一般顾客只能查看信息

02）学生信息和成绩的添加，删除，修改

令添加新的学生信息

◊删除已经添加的学生信息（可同步删除多种学生）

令修改已经添加的学生信息

03）学生成绩的添加，删除，修改

力添加新的学生成绩

令删除已经添加的学生成绩（可同步删除多种成绩）

。修改已经添加的学生成绩

e4）学科信息口勺添加，删除，修改

。添加新的学科

。删除己经添加的学科（可同步删除多种学科）

。修改已经添加的学科

5）按学生成绩求和

◊某一种学生的所有成绩之和

◊某一种学科的所有学生成绩之和

6）学生成绩的排名

◊某•种学生的所有成绩排名

令某一种学科的所有学生成绩排名

令可以正序或者倒序

7）按规定筛选不一样类别的学生

今只筛选总提成绩前10名的学生

8）筛选成绩不及格的学生

令只要有一门学科成绩不及格，就要被筛选出来

◊不及格的学科可以用不一样的颜色进行标识

8）DB连接可以根据配置文献来动态设置

今修改配置文献后，DB也对应的动态变化

今在后台修改配置文献

令在前端可以看到DB也发生了变化

测试范囹如表11-1所示。

表11-1测试列表和测试范围

新功能有关模块回归测试范围测试人员

学籍管理首页N/A(new)N/A

新建学生N/A(new)N/A

学生基本信息管理N/A(new)N/A

学生一览表N/A(new)N/A

学生基本信息查询N/A(new)N/A

学生成绩管理N/A(new)N/A

学生成绩一览表N/A(new)N/A

学生成绩查询N/A(new)N/A

登录系统N/A(new)N/A

1.3.2不准备测试的特性

如下功能和系统配置是不准备测试的：

本次测试将不考虑关系数据库(MySQL)的安装和功能。我们假定数据库已安装并处在可操

作的状态。我们也假定数据库表构造是精确R勺，包括需求规格阐明书中定义的规定类型和宽

度的字段。这些需求在安装文档中有详细阐明。

本次测试将不会宜接测试Web服务器(Tomcat)。

2.测试参照文档和测试提交文档

2.1测试参照文档

大学学籍管理系统产品需求文挡

大学学籍管理系统需求规格阐明书

2.2测试提交文档

本次测试完毕后的提交文档包括：

测试计划

测试规格阐明文档

测试用例设计文挡

测试Bug单

测试小结

测试分析汇报

3,测试进度

测试进度如表11-2所示。

表11-2测试进度

测试活动计划开始FI期实际开始FI期结束日期

制定测试计划

单元测试30天

集成测试15天

系统测试8天

性能测试2天

顾客验收测试5天

对测试进行评估1天

产品公布

4.测试资源

4.1人力资源

下表11-3列出了在应项目的人员配置方面所作口勺多种假定。

注：可合适地删除或添加角色项。

表11-3人力资源安排

角色所推荐的至少资源（所分派的误细职责或注释

专职角色数量）

测试设计人员2-3制定和维护测试计划，设计测试用

例及测试过程，生成测试分析汇报

测试人员3-4执行集成测试和系统测试，记录测

试成果

设计人员1设计测试需要日勺驱动程序和稳定桩

编码人员2-3编写测试驱动程序和稳定桩，执行

单元测试

4.2测试环境

下表11-4列出了测试H勺系统环境。

表11-4测试环境综合

软件环境（有关软件、操作系统等）-

操作系统：Windows2023Professional以上版本；

数据库系统:MYSQL

客户端软件：MSInternetExplorer或NetscapeNavigator等浏览器和office软件。

硬件环境（网络、设备等）

对兼做应用服务器、Weblf务丽］数据丽丽寤口勺机器配亶漫及瓦’256M以上为存,

PHI500MHZ以上CPU,10G以上可用硬盘空间；

客户机只要能使用浏览器和Office软件即可。

网络条件和设备：网路连接卡或调制解调器。

4.3测试工具

此项目将列出测试使用的工具，如表11-5所示。

11-5测试工具列表

用途工具生产厂商洎产版本

单元测试工具Junit4.1

功能测试工具Selinum&AutoIT开源组织5.G&3.1

5.系统风险

也许出现的风险如下:

Bug的修复状况

模块功能日勺实现状况

系统整体功能的实现状况

代码的J编写质量

人员经验以及对软件的熟悉度

开发人员、测试人员有关项目约定的执行状况

人员调整导致研发周期延迟

开发时间的缩短导致某些测试计划无法执行

6.测试方略

测试方略提供了对测试对象进行测试的推荐措施。下面列出了本系统测试的各个阶段也

许用到的测试措施。

6.1接口测试

接口测试范围，如表11-6所示。

表11-6接口测试

测试目的保证接口调用的对的性

测试范围所有软件、硬件接口，记录输入输出数据

技术

开始原则

完毕原则

测试重点和优先级

需考虑的特殊事项接口U勺限制条件

6.2集成测试

集成测试，也叫组装测试或联合测试。在单元测试日勺基础上，将所有模块按照设计规定组装

成为子系统或系统，进行集成测试。集成测试日勺重要目的是检测系统能否到达业务需求，检

测系统对业务处理与否存在逻辑不严谨及错误，检测需求与否存在不合理日勺原则及规定。此

阶段测试基于功能完毕的测试。如表>7所示。

表11-7集成测试

测试目日勺检测需求中业务流程，数据流的对时性

测试范围需求中明确的业务流程，或组合不一样功能模块而形成一种大

的J功能。

技术运用有效的和无效的数据来执行各个用例、用例流或功能，以核

算如下内容：

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

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

各业务规则都得到了对的口勺应用。

开始原则在完毕某个集成测试时必须到达原则

完毕原则所计划的测试已所有执行。

所发现的缺陷已所有处理。

测试重点和优先级测试重点指在测试过程中需着重测试口勺地方，优先级可以根据

需求及严重来定

需考虑11勺特殊事项确定或阐明那叫将对功能测试U勺实行和执行导致影响的事项或

原因（内部的J或外部日勺）

6.3功能测试

对测试对象的功能测试应恻重于所向可直接追踪到业务功能和业务规则的测试需求。此类测

试基于黑盒技术，该技术通过图形顾客界面（GUI）与应用程序进行交互，并对交互的输出

或成果进行分析，以此来核算应用程序及其内部进程。如下表11-8为多种应用程序列出了

推荐使用的测试概要。

表11-8功能测试

测试目的保证测试的功能正常，其中包括导航，数据输入，处理和检索

等功能。

测试范围

运用有效的和无效的数据来执行各个用例、用例流或功能，以核

算如下内容：

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

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

各业务规则都得到了对H勺口勺应用。

开始原则

完毕原则

测试重点和优先级

需考虑口勺特殊事项确定或阐明那些将对功能测'式H勺实行和执行导致影响口勺事项或

原因（内部的或外部mP

6.4顾客界面测试

用MSInternetExplorer和Firefox对图形顾客界面进行测试。在两种浏览器上对所有功

能进行测试。如表11-9所示。

表11-9界面测试

测试目的通过测试进行口勺浏览可对的反应业务的功能和需求，这种浏览

包括窗口与窗口之间、字段与字段之间的浏览，以及多种访问措

施（Tab键、鼠标移动、和快捷键）的使用

窗II的J对象和特性（例如，菜单、大小、位置、状态和中心）都

符合原则。

窗口的J对象和特性（例如，菜单、大小、位置、状态和中心）都

符合原则。

测试范围

技术为每个窗口创立或修改测试，以核算各个应用程序窗口和对象

都可对的1地进行浏览，并处在正常的对象状态。

开始原则

完毕原则成功地核算出各个窗口都与基准版本保持一致，或符合可接受

原则

测试重点和优先级

需考虑的特殊事项

6.5性能评测

性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间有关的需求进行评测

和评估。性能评测的目的是核算性能需求与否都已满足。如表11T0所示。

表11T0性能测试

测试目日勺核算所指定的事务或业务功能在如下状况日勺性能行为:

正常的预期工作量

预期的最繁重工作量

测试范围

技术使用为功能或业务周期测试制定的测试过程。

通过修改数据文献来增长事务数量，或通过修改脚本来增长每

项事务的迭代数量。

脚本应当在i台计算机上运行（最佳是以单个顾客、单个事务为

基准），并在多种客户机（虚拟的或实际日勺客户机，请参见下面

的“需要考虑的特殊事项”）上反复。

脚本应当在一台计算机上运行（最佳是以单个顾客、单个事务为

基准），并在多种客户机（虚拟H勺或实际的客户机，请参见下面

H勺”需要考虑的特殊事项”）上反复。

开始原则

完毕原则单个事务或单个顾客：在每个事务所预期时间范围内成功地完

毕测试脚本，没有发生任何故障。

多种事务或多种顾客：在可接受的J时间范围内成功地完毕测试

脚本，没有发生任何故障。

多种事务或多种顾客：在可接受的时间范围内成功地完毕测试

脚小，没有发生任何故障。

多种事务或多种顾客：在可接受的时间范围内成功地完毕测试

脚本，没有发生任何故障。

测试重点和优先级

需考虑的特殊事项综合的性能测试还包括在服务器上添加后台工作量。

可采用多种措施来执行此操作，其中包括：

性能测试应当在专用的计算机上或在专用的环境内执行，以便

实现完全的控制和精确的评测。

性能测试所用H勺数据库应当是实际大小或相似缩放比例的数据

库。

6.6容量测试

容量测试使测试对象处理大量口勺数据，以确定与否到达了将使软件发生故障H勺极限。容量测

试还将确定测试对象在给定期间内可以持续处理的最大负载或工作量。本系统要为生成一份

报表而处理一组数据库记录，那么容量测试就需要使用一种大型的测试数据库。检查该软件

与否正常运行并生成对的H勺报表。如表1171所示。

表11-11容量测试

测试目的核算测试对象在如下高容量条件下能否正常运行：

连接或模拟了最大（实际或实际容许）数量的客户机，所有客户

机在长时间内执行相似口勺、且状况（性能）最坏的1业务功能。

已到达最大的数据库大小（实际时或按比例缩放欧J）,并且同步

执行多种查询或报表事务。

已到达最大日勺数据库大小（实际日勺或按比例缩放的），并且同步

执行多种查询或报表事务。

测试范围

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

应当使用多台客户机来运行相似的测试或互补的测试，以便在

长时间内产生最繁重H勺事务量或最差的事务组合

创立最大的数据库大小（实际日勺、按比例缩放日勺、或填充了代表

性数据的数据库），并使用多台客户机在长时间内同步运行查询

和报表事务。

创立最大的数据库大小（实际口勺、按比例缩放於J、或填充了代表

性数据的数据库），并使用多台客户机在长时间内同步运行查询

和报表事务。

开始原则

完毕原则所计划"勺测试已所有执行，并且到达或超过指定的系统限制时

没有出现任何软件故障。

测试重点和优先级

需考虑欧1特殊事项对于上述的高容量条件，哪个时间段是可以接受的时间？

6.7安全性测试

侧重于安全性的两个关键方面：

应用程序级别的安全性包括对数据或业务切能的访问。〜丁

系统级别的安全性包括对系统的登录。bb

应用程序级别日勺安全性可保证：在预期的J安全性状况下，顾客只能访问特定的I功能模块。

系统级别的安全性可保证：只有具有系统访问权限的顾客才能