预算执行与经费审批网络管理系统
测试计划
V1.0
1引言 ............................................................................................................................................... 3
1.1编写目的 ............................................................................................................................. 3
1.2背景 ..................................................................................................................................... 3
1.3参考资料 ............................................................................................................................. 3
2计划 ............................................................................................................................................... 4
2.1软件说明 ........................................................................................... 错误！未定义书签。
2.2测试内容 ............................................................................................................................. 4
2.3测试 ................................................................................................... 错误！未定义书签。
2.3.1进度安排 ................................................................................ 错误！未定义书签。
2.3.2条件 ........................................................................................ 错误！未定义书签。
2.3.3测试资料 ................................................................................ 错误！未定义书签。 3测试设计说明 .............................................................................................. 错误！未定义书签。
4.测试重点及顺序 .......................................................................................... 错误！未定义书签。
5.暂停标准和再启动要求 .............................................................................................................. 12
1引言
1.1编写目的
本计划定义软件测试活动的范围、方法、资源和进度，被测试的对象、被测试的特性、应完成的测试任务、人员职责等。
为保证《预算执行与经费审批网络管理系统》的测试工作有序进行，保证《预算执行与经费审批网络管理系统》正确实现需求规格说明书中的功能定义，特制定本计划供软件测试相关人员执行。
1.2系统背景
系统名称：预算执行与经费审批网络管理系统V1.0
任务提出者：
开发者（承接单位）：华中科技大学软件学院
用户：
1.3编写依据
本软件测试计划编写依据，包括项目计划，项目质量计划，有关的规定、相关的标准等。
中华人民共和国国家标准——计算机软件文档编制规范
预算执行与经费审批网络管理系统计划任务书
预算执行与经费审批网络管理系统项目开发计划
预算执行与经费审批网络管理系统需求规格说明书
预算执行与经费审批网络管理系统概要设计说明书
预算执行与经费审批网络管理系统详细设计说明书
1.4测试目标
通过确认测试后，该软件将在用户现场投入试运行。并能保证系统在出现故
障的情况下能重新启动运行，或者花费较少的时间与人力等代价进行修复与维护来保证系统正常运行。
2测试范围
本次测试采用系统测试，按所要集成的子系统或完整的业务功能进行系统描述。首先定义测试的内容概述，然后各个子系统进行测试需求的详细说明。
2.2.1测试内容
1) 数据采集测试
(1) 测评对象的测评数据采集结果正确性。
(2) 同一测评人员同一测评类型不可重复进行。
(3) 被评测对象同一测评类型的测评子项必须全部输入数据。
2) 单一测评类型的统计结果测试
3) 测评结果统计测试
4) 多种测评类型统计结果的综合查询测试
2.2.2测试需求
根据业务情况分析，本项目旨在建立一个经费预算与开支管理系统，该系统包括：预算上报管理、预算审核管理、开支管理、 统计查询和数据备份恢复等模块。
1 服务端系统（V1.0）
包括：服务管理、系统日志、用户管理、系统设置、数据库设置。
2 财务审核子系统（V1.0）
包括：财务审核、信息管理、信息查询、借款报销记录查询、数据统计、数据库备份、当前用户管理、帮助。
3 科室上报子系统（V1.0）
包括：预算上报、借款管理、报销管理、信息查询、当前用户管理、帮助。 4 领导审批子系统（V1.0）
包括：审批管理、信息查询、借款报销启示查询、当前用户管理、帮助。 3测试阶段
测试阶段大致分为三个阶段：单元测试、集成测试、系统测试。本测试计划包括单元测试、集成测试与系统测试这三个阶段。 在这三个阶段中将完成以下类型测试：
? 功能测试
? 业务测试
? 压力测试
? 安装测试
? 验收测试
4测试依据
? 功能测试依据《预算执行与货币化操作管理系统》需求规格说明书（V1.0）。 ? 业务测试依据《预算执行与货币化操作管理系统》需求规格说明书（V1.0）。 ? 压力测试依据《预算执行与货币化操作管理系统》需求规格说明书（V1.0）。 ? 安装测试依据《预算执行与货币化操作管理系统安装手册》（V1.0）。
? 验收测试依据《预算执行与货币化操作管理系统》需求规格说明书（V1.0）。
5测试要求
5.1被测试特性
分不同的测试阶段（如单元测试、集成测试、确认测试）分别规定需要测试特性，主要从功能性、性能、可靠性、使用性、可维护性、安全性等方面进行维护。
5.2不被测试特性
分不同的测试阶段（如单元测试、集成测试、确认测试）分别规定不需要测试特性，例如：不考虑可移植性和高效性。
6测试方法
在不同测试阶段就规定采用相适应的测方试法。测试方法主要有程序走查，白盒测试，黑盒测试等。
如是集成测试，还应规定软件的集成方式。如哪些部分采用自顶向下集成，哪些部分测试自底向上集成。
对于白盒测试，应具体规定是采用语句覆盖、判定覆盖、条件覆盖、路径覆盖等测试方法中的一种或者几种的组合。例如：采用语句覆盖。
对于黑盒测试，应具体规定采用GUI测试，等价类划分、边界值分析、错误推测、比较测试等测试方法中的一种或者几种的组合。 例如：
1. 单元测试把每个模块作为一个单独的实体来测试，所发现的往往是编码和详细设计的错误。采用黑盒测试法。
重要模块：要求至少采用等价类划分、边界值分析、错误推测。 一般模块：要求至少采用等价类划分、边界值分析。
2. 集成测试是把经过单元测试的模块放在一起形成一个功能模块或子系统来测试。着重测试模块的接口。
3. 确认测试是证实软件功能与用户要求是否一致。还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。着重从用户角度发现问题。
由于测试阶段的根本目标是尽可能多发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用，因此用户在测试阶段的直接参与、指正和确认起着十分重要的作用。在后两个测试阶段，集成测试和确认测试将需要局方精悍有素的业务人员的大力支持与配合，并且为我方提供大量的测试数据。
6.1功能测试
6.1.1模块功能测试
系统能按照设计要求实现模块的各个功能，数据应完整、界面美观、操作方便。
具体可参照本文档测试重点及顺序部分。
6.1.2数据项测试
? 字母数字数据项是否能够正确回显，并输入到系统中？
? 是否能够识别非法数据？
? 数据输入消息是否可理解？
6.1.3帮助文档测试
? 文档是否精确描述了如何使用各种使用模式？
? 交互顺序的描述是否精确？
? 例子是否精确？
? 术语、菜单描述和系统响应是否与实际程序一致？
? 是否能够很方便地在文档中定位指南？
? 是否能够很方便地使用文档排除错误？
? 文档的内容和索引是否精确完整？
? 文档的设计（布局、缩进和图形）是否便于信息的理解？
? 显示给用户的错误信息是否有更详细的文档解释？
? 如果使用超级链接，超级链接是否精确完整？
6.2业务测试
功能测试完成后进行业务测试，业务测试关注的要点是业务流程，及数据流从软件中的一个模块流到另一个模块的过程中的正确性。
6.3压力测试
6.3.1 压力测试说明
本次压力测试根据实际情况包含性能测试，重点模拟客户进行多用户测试。压力测试有一条8：2原则。及百分之八十的业务量在百分之二十的时间内输入。例如:正常每天有100条新数据，测试时在两小时内输入80条数据。我们无法知道用户的业务量，所以只有利用现有资源进行大量的数据量的测试。
6.3.2 压力测试工具
待定
6.4安装测试
6.4.1安装测试说明
除了嵌入式软件之外，安装是软件产品实现其功能的第一步，没有正确的安装根本就谈不上正确的执行，因此对于安装的测试就显得尤为重要。
6.4.2安装测试方法及标准
? 自动安装还是手工配置安装，测试各种不同的安装组合，并验证各
种不同组 合的正确性，最终目标是所有组合都能安装成功。
? 安装退出之后，确认应用程序可以正确启动、运行。
? 卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之后需检验系统是否把所有的文件全部删除，注册表中有关的注册信息是否也被删除。
? 至少要在一台笔记本上进行安装测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品。(有条件的情况下)
? 安装完成之后，可以在简单地使用之后再执行卸载操作，有的系统在使用之后会发生变化，变得不可卸载。
? 安装时间是否合理；
? 对于客户服务器模式的应用系统，可以先安装客户端，然后安装服务器端，测试是否会出现问题。
? 考察安装该系统是否对其他的应用程序造成影响，特别是Windows操作系统，经常会出现此类的问题。
6.5验收测试
6.5.1验收测试说明
软件产品测试部对经过内部单元测试、集成测试和系统测试后的软件所进行的测试，测试用例采用业务流程测试用例。
6.5.2验收测试方法及标准
参考三普软件验收测试规范.doc和软件测试停止标准.doc
7测试工作流程
测试工作流程所依据的公司的质量体系中的程序文件或质量体系作业指导书，或部门自行编制的规程或作业指导书。
本测试依据《中华人民共和国国家标准——计算机软件文档编制规范》中的
软件测试规程。
7.1预测风险
本次测试过程中，可能出现的风险如下：
? bug的修复情况
? 模块功能的实现情况
? 系统整体功能的实现情况
? 代码的编写质量
? 人员经验以及对软件的熟悉度
? 开发人员、测试人员关于项目约定的执行情况
? 人员调整导致研发周期延迟
? 开发时间的缩短导致某些测试计划无法执行
7.2测试重点
7.2.1功能测试
这里仅为测试重点的描述，具体测试方法以及内容请参见测试用例。
1) 预算上报功能
? 下拉菜单是否正常
? 输入功能是否正确
? 表格是否正常提交
2) 借款管理功能
? 下拉菜单是否正常
? 输入功能是否正确
? 表格是否正常提交
3) 报销管理功能
? 下拉菜单是否正常
? 输入功能是否正确
? 表格是否正常提交
4) 信息查询功能
? 树形菜单是否正常
? 列表显示是否正确
? 下拉菜单是否正常
? 搜索是否正确
5) 用户管理功能
? 输入功能是否正常
? 密码修改是否能执行
6) 财务审核功能
? 列表显示是否正确
? 表格选择是否正常
? 审核通过、否决按钮是否正常
7) 信息管理功能
? 输入功能是否正常
? 树形菜单是否正常
? 添加、删除、修改按钮是否正常
8) 数据统计功能
? 图形窗口显示是否正确 ? 树形菜单是否正常
? 下拉菜单是否正常
9) 数据备份还原功能
? 输入功能是否正常
? 是否正确备份、还原
10) 审批管理
? 表格选择是否正常
? 按钮功能是否正确
? 表格是否正常显示
7.2.2业务测试
1) 预算上报功能
? 提交预算到财务审核系统
? 预算关联到财务审核、领导审批 ? 与数据库关联
2) 借款管理功能
? 提交借款请求到财务审核系统 ? 预算关联到财务审核、领导审批 ? 与数据库关联
3) 报销管理功能
? 提交报销请求到财务审核系统
? 预算关联到财务审核、领导审批
? 与数据库关联
4) 信息查询功能
? 显示正确的查询结果
5) 用户管理功能
? 密码修改正常
? 预算关联到科室上报、财务审核、领导审批
? 与数据库关联
6) 财务审核功能
? 财务审核通过、否决成功
? 预算关联到科室上报、领导审批
? 与数据库关联
7) 信息管理功能
? 编辑部门、科室、管理员信息
? 预算关联到科室上报、财务审核、领导审批
? 与数据库关联
8) 审批管理
? 审批或否决请求
? 预算关联到科室上报、财务审核
? 与数据库关联
8测试通过准则
8.1通过指数
确认测试阶段重要模块100%通过，一般模块99%测试通过则测试通过。
8.2暂停标准和再启动要求
? 软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现一
级错误（大于等于1）、二级错误（大于等于2）暂停测试返回开发。 ? 软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。
? 软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止
时，测试应随之暂停或终止，并备份暂停或终止点数据。
? 如有新的项目需求，则在原测试计划下做相应的调整。
? 若开发暂停，则相应测试也暂停，并备份暂停点数据。。
? 若项目中止，则对已完成的测试工作做测试活动总结。
? 项目再启动时，测试进度重新安排或顺延。
9环境要求
9.1 系统运行硬件与软件环境
硬件条件：普通PC机，1G内存。
运行环境：Windows 2003
数据库：SQL Server 2005企业版。
测试软件：PL/SQL Developer 2.0.0
其他应用软件：字处理器、电子邮件、电子表格等。
9.2 测试数据环境
指作为本次测试的基础数据。描述该数据的来源，是否真实数据，数据覆盖的时间范围。
应对该数据进行标识和备份。以保证测试的具有可重复性。但在用户正式运行的现场进行测试，应避免将备份数据重新装入。
9.3 测试环境的安装、测试和控制
测试环境的安装、测试和控制包括：
1. 获取或开发测试环境中的每一个成分。
2. 在使用前安装和测试测试环境的每一个项。
3. 控制和维护测试环境的每一项。
10职责分工
根据项目的实践需求与工程测试量，规定专业测试员4名，其中包括1名测试组组长与3名测试员。
10.1 测试组组长
测试组组长的职责：负责本项目测试任务的派发、管理和测试进度的控制。定期编写工作进度报告等管理文件。
10.2 测试员
规定测试员的工作职责：编写测试用例，进行实际的测试，并编写测试报告，进行错误登记和统计。
11进度安排
对于单元测试应规定提交一个单元后平均需要1天时间完成测试。集成测试在模块可以集成时即开始测试。为了提高测试效率，可以考虑在开发组向测试组提交文档时，测试组开始设计测试用例。
表11-1 按照测试阶段确定的进度安排表
12需求可追溯性
建议考虑需求的可追溯性。在需求文档已规范时应包括这一部分内容。 需求可追溯性包括：
1.从本计划中标识的测试的到软件配置项的可追溯性。如可能，应指出所引
用的软件需求说明书及版本。
2.从软件配置项到本计划中标识的测试的可追溯性。