学生请假管理系统测试计划

测试计划

版本历史

该测试计划介绍了如何测试学生请假管理系统。它提供了测试范围、测试策略，人员安排等详细信息。

1.1目的

这份文档的目标是详细描述对“学生请假管理系统”进行功能测试的过程。本文档所关注的特征来自于软件设计规格说明书。（关于学生请假管理系统的功能描述,请参阅软件设计规格说明书。）

1.2背景

学生请假管理系统是以实现对请假管理的计算机化和办公室自动化目的，以学生、教师和请假信息为基础，以先进的信息网络技术及数据库技术为手段，把学生的请假信息等日常管理工作实行计算机统一管理，提高工作效率和管理水平。这个系统能满足用户权限设置，不同权限的用户使用自己的用户名登录。主要角色有辅导员、系领导和学生。辅导员用户可以查看自己的基本信息，对自己的学生信息进行增加、查看、删除和修改，文档的上传和查看,查看学生请假信息以及审批学生的请假等。系领导用户查看自己的基本信息，对全部学生信息、全部教师信息进行查看、添加、删除、修改,文档的上传和查看,查看学生请假信息以及审批学生的请假。学生用户可以查看自己的基本信息、自己的请假记录信息以及在线向辅导员请假。操作简单、界面友好；确保信息的准确性，动态性，安全性。适于分布式多客户作业，客户端的配置要求也很低。

1.3范围

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

本计划所提到的测试类型是需求阶段的测试，即对学生请假管理系统进行功能验证的测试过程。

1.3.1准备测试的特征

以下特征将被测试，以确保“学生请假理系统”能满足规定的需求：

1）用户Login、Logout，以及管理员与普通用户的权限区别

     用户Login、Logout:

       >Login

       >Logout

     管理员与普通用户的权限:

       >管理员的权限: 添加、删除、修改、查询

       >普通用户只能查看信息

2）学生信息和教职工信息的添加，删除，修改，查询

     学生信息的添加、删除、修改、查询:

       >添加新学生信息

       >删除已经添加的学生信息（可同时删除多个学生）

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

      >查询学生基本信息

     教职工信息的添加、删除、修改、查询:

       >添加新的教职工信息

       >删除已经添加的教职工信息（可同时删除多个教职工信息）

       >修改已经添加的教职工信息

      >查询教职工的基本信息

3) 请假信息的申请、删除、修改、审核、打印

请假信息的申请、删除、修改、审核、打印:

       >添加新的请假信息

       >删除已经添加的请假信息（可同时删除多个请假信息）

       >修改已经添加的请假信息

>审核已经添加的请假信息

>打印已经通过审核的请假信息

4) 请假审核信息的管理，维护

请假审核信息的管理，维护:

      >管理审核请假信息

       >对已有请假信息进行维护

5) 查看学生的请假信息

6) 文件的上传和查看:

      >上传文件

        >查看已上传的文件

7) 按要求筛选不同类别的学生

8) DB连接可以根据配置文件进行动态设置

       >配置文件修改后，DB连接也会相应改变

     >在后台修改配置文件

       >在前台可以看到DB也会发生了改变

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

以下功能和系统配置时不需要测试的内容：

1）本次测试将不考虑关系数据库（My SQL）的安装和功能。假定数据库已安装并处于可操作的状态。假定数据库表结构是准确的，包含需求规格说明书中定义的规定类型和字段的宽度。这些需求在准备和安装文档中有详细说明。

2)本次测试将不会直接测试Web服务器（Tomcat）

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

2.1测试参考文档

     学生请假管理系统产品需求文挡

     学生请假管理系统软件设计规格说明书

2.2测试提交文档

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

     测试计划

     测试规格说明文档

     测试用例设计文挡

     测试Bug列表

     测试小结

     测试分析报告

3.测试进度

表 1-2 测试进度

4.1人力资源

下表列出了在此项目的人员配备方面所作的各种假定。

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

表 1-3 人力资源安排

下表列出了测试的系统环境

1-4 测试环境综合

此项目将列出测试使用的工具：

表 1-5 测试工具列表

5.系统风险

可能出现的风险如下：

●bug的修复情况

●模块功能的实现情况

●系统整体功能的实现情况

●代码的编写质量

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

●开发人员、测试人员关于项目约定的执行情况

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

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

6.测试策略

测试策略提供了对测试对象进行测试的推荐方法。下面列出了本系统测试的各个阶段可能用到的测试方法。

测试案例流程图：如图1-1

图1-1测试案例流程图

6.1接口测试

表1-6 接口测试

集成测试主要目的是检测系统是否达到设计需求，对业务流程及数据流的处理是否符合标准，检测系统对业务流程处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此阶段测试是基于功能完成的测试。 

表 1-7 集成测试

对测试对象的功能测试应侧重于所有可直接追踪到业务功能和业务规则的测试需求。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要： 

表 1-8 功能测试

用MS Internet Explorer和chrome对图形用户界面进行测试。要求在两种浏览器上对所将使有功能进行测试。

表 1-9 界面测试

性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。

表 1-10 性能测试

容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。本系统需要为生成一份报表而处理一组数据库记录，那么容量测试就需要使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。 

表 1-11 容量测试

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

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

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

应用程序级别的安全性可确保：在预期的安全性情况下，用户只能访问特定的功能模块。

系统级别的安全性可确保：只有具备系统访问权限的用户才能访问应用程序。 

表 1-12 安全测试

和规格说明书上定义不一致的，或者不符合常规的地方都属于bug，应该提交给相关人员进行修订。

8.计划文档审阅

这个计划文档需要被下列人员审阅并给出确认意见。

[PM/EM]:xxx

[DEV owner]:xxx

[QA owner]:xxx