大学学籍管理系统
版 本 历 史 版本/状态 V1.0 V1.1
测试计划
修订人 王莉 盛安平 起止日期 2010-11-4 审核人\\日期 简要说明 建立 修订 2010-11-30 1.简介
该测试计划介绍了如何测试大学学籍管理系统。它提供了测试范围、测试策略，人员安排等详细信息。
1.1目的
这份文档的目标是详细描述对大学学籍管理系统进行功能验证的测试过程。本文档所关注的特征来自于需求文档。（关于大学学籍管理系统项目的功能描述,请参阅大学学籍管理系统需求规格说明书。）
1.2背景
为了提高从事学生工作的老师的工作效率，我们开发了这个大学学籍管理系统。 这个系统能满足用户Login/Logout,管理员账户与普通账户，管理员可以添加，修改删除，普通账户只能查看。主要功能：能完成新学生的添加、修改、删除，能按学生成绩求和，排名，列出不及格学生的名单等。操作简单、界面友好；确保信息的准确性，动态性，安全性。大学学籍管理系统是基于J2EE的技术，采用B/S结构，适于分布式多客户作业，客户端的要求也很低。
1.3范围
测试阶段包括单元测试，集成测试，系统测试，性能测试，验收测试及对测试进行评估。 本计划所针对地测试类型是需求阶段的测试，即对大学学籍管理系统进行功能验证的测试过程。
1.3.1准备测试的特征
以下特征将被测试，以确保“大学学籍管理系统”能满足规定的需求：
1) 管理员与普通用户的权限
? 管理员的权限: 添加，删除，修改 ? 普通用户只能查看信息
2）学生信息和成绩的添加，删除，修改 ? 添加新的学生信息
? 删除已经添加的学生信息（可同时删除多个学生） ? 修改已经添加的学生信息 3）学生成绩的添加，删除，修改 ? 添加新的学生成绩
? 删除已经添加的学生成绩（可同时删除多个成绩） ? 修改已经添加的学生成绩 4) 学科信息的添加，删除，修改 ? 添加新的学科
? 删除已经添加的学科（可同时删除多个学科） ? 修改已经添加的学科 5) 按学生成绩求和
? 某一个学生的所有成绩之和 ? 某一个学科的所有学生成绩之和 6）学生成绩的排名
? 某一个学生的所有成绩排名 ? 某一个学科的所有学生成绩排名 ? 可以正序或者倒序
7) 按要求筛选不同类别的学生 ? 只筛选总分成绩前10名的学生 8）筛选成绩不及格的学生
? 只要有一门学科成绩不及格，就要被筛选出来 ? 不及格的学科可以用不同的颜色进行标识 8) DB连接可以根据配置文件来动态设置 ? 修改配置文件后，DB也相应的动态变化 ? 在后台修改配置文件
? 在前端可以看到DB也发生了改变
测试范围如表11-1所示。
表11-1 测试列表和测试范围 新功能 学籍管理首页 新建学生 学生基本信息管理 学生一览表 相关模块 N/A (new) N/A (new) N/A (new) N/A (new) 回归测试范围 测试人员 N/A N/A N/A N/A 学生基本信息查询 N/A (new) N/A 学生成绩管理 学生成绩一览表 学生成绩查询 登录系统
1.3.2不准备测试的特征
N/A (new) N/A (new) N/A (new) N/A (new) N/A N/A N/A N/A 以下功能和系统配置是不准备测试的：
本次测试将不考虑关系数据库（My SQL）的安装和功能。我们假定数据库已安装并处于可操作的状态。我们也假定数据库表结构是准确的，包含需求规格说明书中定义的规定类型和宽度的字段。这些需求在安装文档中有详细说明。
本次测试将不会直接测试Web服务器（Tomcat）。
2.测试参考文档和测试提交文档 2.1测试参考文档
大学学籍管理系统产品需求文挡 大学学籍管理系统需求规格说明书 2.2测试提交文档
本次测试完成后的提交文档包括： 测试计划
测试规格说明文档 测试用例设计文挡 测试Bug单 测试小结
测试分析报告 3.测试进度
测试进度如表11-2所示。
表11-2 测试进度 测试活动 制定测试计划 单元测试30天 集成测试15天 系统测试8天 性能测试2天 用户验收测试5天 产品发布
4.测试资源 4.1人力资源
下表11-3 列出了在此项目的人员配备方面所作的各种假定。 注：可适当地删除或添加角色项。
表11-3 人力资源安排 角色 测试设计人员 测试人员 设计人员 编码人员
4.2测试环境
下表11-4 列出了测试的系统环境。
表11-4 测试环境综合
所推荐的最少资源（所分配的专职角色数量） 2-3 3-4 1 2-3 具体职责或注释 制定和维护测试计划，设计测试用例及测试过程，生成测试分析报告 执行集成测试和系统测试，记录测试结果 设计测试需要的驱动程序和稳定桩 编写测试驱动程序和稳定桩，执行单元测试 计划开始日期 实际开始日期 结束日期 对测试进行评估1天 软件环境（相关软件、操作系统等） 操作系统：Windows 2000 Professional以上版本； 应用服务器和Web服务器：Tomcat 5.5.15 数据库系统：MY SQL 客户端软件：MS Internet Explorer或Netscape Navigator等浏览器和office软件。 硬件环境（网络、设备等） 对兼做应用服务器、Web服务器和数据库服务器的机器配置要求较高：256M以上内存，PIII500MHz以上CPU，10G以上可用硬盘空间； 客户机只要能使用浏览器和Office软件即可。 网络条件和设备：网路连接卡或调制解调器。
4.3测试工具
此项目将列出测试使用的工具，如表11-5所示。
11-5 测试工具列表 用途 单元测试工具 功能测试工具 5.系统风险
可能出现的风险如下： Bug的修复情况
模块功能的实现情况 系统整体功能的实现情况 代码的编写质量
人员经验以及对软件的熟悉度
开发人员、测试人员关于项目约定的执行情况 人员调整导致研发周期延迟
开发时间的缩短导致某些测试计划无法执行 6.测试策略
测试策略提供了对测试对象进行测试的推荐方法。下面列出了本系统测试的各个阶段可能用到的测试方法。
6.1接口测试
接口测试范围，如表11-6 所示。
表11-6 接口测试
测试目标 测试范围 技术 开始标准 完成标准 测试重点和优先级 需考虑的特殊事项
确保接口调用的正确性 接口的限制条件 所有软件、硬件接口，记录输入输出数据 工具 Junit Selinum&Auto IT 生产厂商/自产 开源组织 版本 4.1 5.0&3.1 6.2集成测试
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。集成测试的主要目的是检测系统能否达到业务需求，检测系统对业务处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此阶段测试基于功能完成的测试。 如表11-7所示。
表11-7 集成测试 测试目标 测试范围 技术 检测需求中业务流程，数据流的正确性 需求中明确的业务流程，或组合不同功能模块而形成一个大的功能。 利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容： 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。 在完成某个集成测试时必须达到标准 所计划的测试已全部执行。 所发现的缺陷已全部解决。 测试重点指在测试过程中需着重测试的地方，优先级可以根据需求及严重来定 确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的） 开始标准 完成标准 测试重点和优先级 需考虑的特殊事项 6.3功能测试
对测试对象的功能测试应侧重于所有可直接追踪到业务功能和业务规则的测试需求。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下表11-8 为各种应用程序列出了推荐使用的测试概要。
表11-8 功能测试 测试目标 测试范围 技术 确保测试的功能正常，其中包括导航，数据输入，处理和检索等功能。 利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容： 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。 确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的） 开始标准 完成标准 测试重点和优先级 需考虑的特殊事项 6.4用户界面测试