图书管理系统测试计划说明书.docx

图书管理系统测试计划说明书.docx

《图书管理系统测试计划说明书.docx》由会员分享，可在线阅读，更多相关《图书管理系统测试计划说明书.docx（12页珍藏版）》请在冰豆网上搜索。

图书管理系统测试计划说明书

图书管理系统

测试计划说明书

第五组

2014年5月28日

1引言

1.1编写目的

本测试计划文档作为指导此测试项目循序渐进的基础，帮助我们安排合适的资源和进度，避免可能的风险。

本文档主要阐述图书信息管理系统测试过程中的一些细节，为图书信息管理系统的测试工作提供一个框架和规范：

1）确定项目测试的策略、范围和方法； 

2）使项目测试工作的所有参与人员（开发人员、测试管理者、测试人员对项目测试的目标、范围、策略、方法、组织、资源等有一个清晰的认识； 

3）使项目测试工作的所有参与人员理解测试控制过程； 

4）从策略角度说明本项目测试的组织和管理，指导测试进展，并作为项目

5）测试工作实施的依据； 

本文档是本项目测试整个过程进行的依据、规范和标准；在测试过程中严格按照本文档的制定的规范去执行。

1.2背景

随着人们知识层次的提高，图书馆成为日常生活中不可缺少的一部分。

而图书馆的库存数量和业务量庞大，仅仅靠传统的记账式管理是不可行的。

图书馆管理系统应运而生，逐渐成为信息化建设的重要组成部分。

图书馆管理系统为学校或社会型图书馆的管理员提供所有借阅者的详细信息，以及馆内库存的详细情况，对借书和还书两大功能进行合理操纵并登记。

说明：

开发软件名称：

图书管理系统。

项目开发者：

软件工程学院第五小组。

用户单位：

待定。

1.3名词解释

1.3.1黑盒测试

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。

在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

1.3.2白盒测试：

白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

1.3.3静态测试

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。

1.3.4动态测试

动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：

构造测试实例、执行程序、分析程序的输出结果。

1.3.5功能测试

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

1.3.6集成测试

集成测试，也叫组装测试或联合测试。

在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。

程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。

1.3.7单元测试

单元测试（unittesting），是指对软件中的最小可测试单元进行检查和验证。

对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。

总的来说，单元就是人为规定的最小的被测功能模块。

单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

1.3.8性能测试：

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

负载测试和压力测试都属于性能测试，两者可以结合进行。

1.4参考资料

张海藩：

《软件工程导论》第五版清华大学出版社

肖刚等：

《实用软件文档写作》清华大学出版社

李涛等：

VisualC#SQLServer数据库开发与实例清华大学出版社

第五组：

《图书管理系统需求分析说明书》

2总体计划

为了更好地实现对图书管理系统的测试，特别设计各个阶段的测试时间表，来管理测试计划的项目进度：

测试阶段

开始时间

完成时间

测试人员

交付物

制定测试计划

2014/5/28

2014/5/28

第五小组成员

测试计划说明书

需求review

2014/5/29

2014/5/29

第五小组成员

需求review报告

设计review

2014/5/29

2014/5/29

第五小组成员

设计review报告

测试环境准备

2014/5/30

2014/5/30

第五小组成员

测试环境

功能测试

2014/5/31

2014/5/31

第五小组成员

测试报告

集成测试

2014/5/31

2014/5/31

第五小组成员

测试报告

性能测试

2014/5/31

2014/5/31

第五小组成员

测试报告

验收测试

2014/6/1

2014/6/1

第五小组成员

测试报告

文档编写

2014/6/1

2014/6/1

第五小组成员

测试报告

3需求review

需求review（RequirementReview）对工作产品的评审有两类方式，一类是正式技术评审，也称同行评审，另一类是非正式技术评审。

对于我们学生来说，还没有同行评审，所以我们采用的第二种。

需求review的评审团队主要由开发方和客户方的代表共同组成，因为需要知道开发的系统的功能是否满足客户的需求。

需求review过程：

我们采用的静态测试，仔细阅读图书管理系统需求说明书，检查需求文档中的每一个需求，每一行文字，每一张图表，每一个数据类型设计。

评判需求优劣的主要指标有：

正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。

如果有可能，最好可以制定评审的检查表，最后完成需求review报告。

4设计review

设计评审是对一项设计进行正式的、按文件规定的、系统的评估活动，由不直接涉及开发工作的人执行。

设计评审可采用向设计组提建议或帮助的形式，或就设计是否满足客户所有要求进行评估。

在产品开发阶段通常进行不只一次的设计评审。

最终的设计评审（即设计终止之前），其性质是建议性的。

这些评审的结果采用推荐和建设性建议的形式。

对设计评审中发现问题进行更改和对结论进行选择的权力在设计组。

其目的是尽可能早的在开发阶段确认这些因素和工艺会不会造成最终产品质量偏差。

设计review过程：

我们采用的静态测试，仔细阅读图书管理系统概要设计说明书，应当考虑到的问题包括但不限于：

（1）该设计满足产品全部规定或服务要求吗？

?

（2）考虑了安全吗？

?

（3）该设计满足功能和运行的要求，即性能、可靠性、可维修性目标吗？

?

（4）该设计能满足全部预期的环境和负载条件吗？

将所有问题考虑完成之后，完成设计review报告。

5测试环境准备

5.1设备

服务器

（1）处理器（CPU）：

Pentium900M（推荐Pentium41.2G）

（2）内存容量（RAM）：

至少256M（推荐512M）

客户端

（1）处理器（CPU）：

Pentium133M或更高

（2）内存容量（RAM）：

64M或更高

5.2支持软件

数据库服务器端

（1）操作系统：

MicrosoftWindows2003

（2）数据库管理系统：

SQLServer2005，配置TCP/IP协议

Web服务器端

（1）操作系统：

MicrosoftWindows2003

（2）Internet信息服务（IIS）6.0管理器

（3）VisualStudio.NET2005，配置TCP/IP协议

客户端

（1）操作系统：

Windows98/2000/2003/XP

（2）Web浏览器：

InternetExplorer6.0以上或Netscape4.0以上，配置TCP/IP协议

5.3人员

第五小组全体人员

6功能测试

由于该系统未编写代码，所以白盒测试在测试计划中很少使用，测试计划采用黑盒测试方法，整个过程采用自底向上，逐个集成的的办法，依次进行功能测试，集成测试，系统测试，而每一个功能将相当于一个单元，所以相当于进行单元测试。

测试用例的设计应包括合理的和不合理的输入条件。

6.1功能回顾

根据需求分析中的各项说明，整理一下几点功能：

6.1.1系统操作登录

目的：

测试系统操作界面。

内容：

帐号口令输入、合理性检查、合法性检查，系统操作界面显示控制 

6.1.2借书  

目的：

测试出借功能。

内容：

括读者证号输入、合理性检查、合法性检查，借书对话显示控制，图书书号提交、合理性检查、合法性检查，借书登记。

6.1. 3还书

目的：

测试还书功能。

内容：

还书对话框显示控制，图书书号提交、合理性检查、合法性检查，还书登记。

6.1. 4图书库管理 

目的：

测试图书库操作功能。

内容：

图书库管理界面显示控制，图书库浏览，增加图书记录，删除图书记录，编辑图书记录。

6.1. 5图书查询

目的：

测试图书查询功能。

内容：

图书查询对话框显示控制，输入数据合理性检验、提交，图书查询结果显示。

6.1.6缴纳罚金

目的：

测试缴纳罚金功能

内容：

借阅证号和输入输入、合理性检查、合法性检查，系统操作界面显示控制。

6.2测试用例

在设计测试用例的过程中，使用了等价类划分的方法来设计测试用例。

就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:

有效等价类和无效等价类.

6.2.1系统操作登录测试 

输入

输出

用户名

密码

‘     ‘

‘ 12degf’ 

错误—用户名空

‘  2345’

‘12456‘

错误—用户名非法 

‘134她5’

‘58687‘ 

错误—用户名非法 

‘12334’

‘     ’

错误—密码为空

1367’

35我469’

错误—密码非法

‘55301’

880527’

正确---登陆成功

6.2.2借书测试

输入数据

选择策略

命令

输出数据

借阅证号为空，正确书号

测试借阅证号为空的情况

借书按钮

“借阅证号不能为空”的提示框

正确借阅证号，书号为空

测试书号为空的情况

借书按钮

“书号不能为空”的提示框

错误的借阅证号，正确书号

测试当不存在改借阅证时的情况

借书按钮

“该读者不存在”的提示框

正确的借阅证号，错误的书号

测试当书号错误的情况

借书按钮

“该书不存在”的提示框

修改数据库，使得欠费表中有某读者的欠费记录，输入这个读者的借阅证号，输入正确的书号

测试读者有欠费记录时的情况

借书按钮

“该读者已欠费…”的提示框

修改数据库，使某读者的已借书中有逾期的，输入该读者借阅证号和该逾期书籍号

测试读者已借书中有逾期的书籍的情况

借书按钮

“该读者已欠费…”的提示框

以上情况都没有且借阅证号和书号都正确

测试当读者符合借书条件的情况

借书按钮

“借书成功”的提示框

6.2.3还书测试

输入数据

选择策略

命令

输出数据

借阅证号为空，正确书号

测试借阅证号为空的情况

还书按钮

“借阅证号不能为空”的提示框

正确借阅证号，书号为空

测试书号为空的情况

还书按钮

“书号不能为空”的提示框

错误的借阅证号，正确书号

测试当不存在改借阅证时的情况

还书按钮

“该读者不存在”的提示框

正确的借阅证号，错误的书号

测试当书号错误的情况

还书按钮

“该书不存在”的提示框

修改数据库，使某读者已借的该书已逾期，输入该读者借阅证号和该书籍号

测试读者该书已逾期的情况

还书按钮

“该书已欠费…”和“还书成功”的提示框

以上情况都没有且借阅证号和书号都正确

测试当读者符合还书条件的情况

还书按钮

“还书成功”的提示框

6.2.4图书库管理测试

输入数据

选择策略

命令

输出数据

书号、书名、作者、出版社、单价、总量有空项

测试书籍信息填写不完整的情况

入库按钮

“请将信息填写完整”的提示框

书号在图书库中已存在

测试书号为空的情况

入库按钮

数据库中该书的总量和现存量各增加

书号在图书库中不存在

测试当不存在改借阅证时的情况

入库按钮

Book_Info表中增加一条记录

6.2.5图书信息查询测试 

输入

输出

选择作者，KK （存在）

显示列表，仅一项（图书书目编号1）

选择作者，si （不存在）

显示警告“没有符合条件的书目”

选择作者，ee （存在）

显示列表，共1项

选择书名，hardware 

显示查询内容（1项）

步骤及操作：

驱动模块调用之后，看库是否已经关闭，并打开图书信息库直接察看结果  

允许偏差：

不允许任何偏差 

条件：

图书表

6.2.6缴纳罚金测试

输入数据

选择策略

命令

输出数据

没有欠费记录的读者的借阅证号

测试该读者没有欠费记录的情况

缴费按钮

“该读者没有欠费记录”的提示框

有欠费记录的读者的借阅证号

测试该读者有欠费记录的情况

缴费按钮

“缴费成功”的提示框

Punish_Info表中删除一条记录

7集成测试

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

此阶段测试是基于功能完成的测试。

测试目标

检测需求中业务流程，数据流的正确性

测试范围

需求中明确的业务流程，或组合不同功能模块而形成一个大的功能。

技术

利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：

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

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

各业务规则都得到了正确的应用。

开始标准

在完成某个集成测试时必须达到标准

完成标准

所计划的测试已全部执行。

所发现的缺陷已全部解决。

测试重点和优先级

测试重点指在测试过程中需着重测试的地方，优先级可以根据需求及严重来定

需考虑的特殊事项

确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）

8性能测试

性能测试对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。

性能评测的目标是核实性能需求是否都已满足。

测试目标

核实所指定的事务或业务功能在以下情况下的性能行为：

正常的预期工作量

预期的最繁重工作量

测试范围

技术

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

通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。

脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。

开始标准

完成标准

单个事务或单个用户：

在每个事务所预期时间范围内成功地完成测试脚本，没有发生任何故障。

多个事务或多个用户：

在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。

测试重点和优先级

需考虑的特殊事项

综合的性能测试还包括在服务器上添加后台工作量。

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

性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。

性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。

9验收测试

由于该设计无软件产品，所以没有可以提交的产品来供执行验收测试。

10文档编写

完成测试计划中规定的内容，由第五小组同学编写测试报告。