图书管理系统《软件测试技术》课程设计报告测试计划Word文档下载推荐.docx

图书管理系统《软件测试技术》课程设计报告测试计划Word文档下载推荐.docx

《图书管理系统《软件测试技术》课程设计报告测试计划Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《图书管理系统《软件测试技术》课程设计报告测试计划Word文档下载推荐.docx（13页珍藏版）》请在冰豆网上搜索。

图书管理系统

项目背景为：

科学技术的飞速发展把人类社会推向了一个崭新的时代——信息时代。

人们对这些信息进行收集、加工、传递等过程的时间性和准确性提出了更高的要求。

这一切使得传统的手工作业为基础的信息系统陷入了机构日益庞大，效率日益降低的困境。

电子计算机的出现为摆脱这种困境找到了出路。

计算机用于管理信息处理的突出优点是迅速、准确、可靠、具有很大的存储能力，适应于管理信息量大、面宽的特点，适合于管理信息处理及时、准确的要求信息对社会经济发展的巨大推动作用，使其与物质能源一起并列为现代社会的三大支柱。

图书管理系统是一个图书单位不可缺的部分，图书管理系统应该能够为用户提供充足的信息和快捷的查询手段。

但一直以来人们使用传统人工的方式管理文件档案，这种管理方式存在着许多缺点，如：

效率低、保密性差，这对于查找、更新和维护都带来了不少的困难。

对于借阅者来说，想要借书必须去到图书馆，一本本的查找，效率低，占用时间长，不利于查找，而且没有人性化管理。

图书馆的规模越大，管理员对图书的管理越来越复杂，如果用传统的方法来管理，将是不可能实现的问题，对于借阅者，想要找到需要的图书也是一个复杂的问题。

为了使图书管理简单化，使非专业人员也能轻松管理图书，使读者便于查找借阅归还图书，就必须设计一套实用简单，功能强大的图书管理系统。

项目范围：

本图书管理系统主要面向中小型图书管理机构或中小型机构的资料或文件等的管理，由于系统本身的和管理方面的限制及数据方面的要求和局限性，本系统并不适合于大型机构和其他性质的机构使用，此外本系统也可作为学习和参考方面的资料。

1.2.2系统基本功能

图：

1.1系统功能模块图

1.2.3系统总体用例

1.2系统功能模块图

图1.3读者子系统用例图

1.2.4系统技术架构

系统采用C/S架构

C/S（Client/Server）结构，即大家熟知的客户机和服务器结构。

它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。

目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；

因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。

这也就是目前应用系统的发展方向。

传统的C/S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。

由于没能提供用户真正期望的开放环境，C/S架构的软件需要针对不同的操作系统系统开发不同版本的软件

C/S的优点是能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器。

对应的优点就是客户端响应速度快。

缺点主要有以下几个：

　　1）只适用于局域网。

而随着互联网的飞速发展，移动办公和分布式办公越来越普及，这需要我们的系统具有扩展性。

这种方式远程访问需要专门的技术，同时要对系统进行专门的设计来处理分布式的数据。

　　2）客户端需要安装专用的客户端软件。

首先涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进行安装或维护。

特别是有很多分部或专卖店的情况，不是工作量的问题，而是路程的问题。

还有，系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。

3）对客户端的操作系统一般也会有限制。

在编程技术方面采用VB.NET技术，开发环境应用VisualStudio2005数据库采用Access2003

VisualStudio:

VisualStudio是微软公司推出的开发环境，VisualStudio可以用来创建Windows平台下的Windows应用程序和网络应用程序，也可以用来创建网络服务、智能设备应用程序和Office插件。

1.3所需参考资料

表1-1：

所需资料列表

参考资料

提交日期

责任人

备注

项目开发计划

2012-4-10

需求规格说明书

系统设计说明书

系统原型

系统源码

用户使用手册

1.4测试提交文档

表1-2：

测试提交文档列表

提交文档

测试计划

2012-3-25

测试分析报告（包括测试用例、缺陷报告）

2012-4-29

测试日志

2012-5-8

2.测试进度安排

表2-1：

测试进度安排表

测试活动

计划开始时间

计划结束时间

实际开始时间

实际结束时间

制定测试计划

2012-3-11

2012-3-20

2012-3-22

测试方案设计

2012-3-29

不定

测试执行

单元测试

2012-4-11

2012-4-15

集成测试

2012-4-16

2012-4-20

系统测试

2012-4-21

2012-4-24

性能测试

2012-4-27

安装测试

2012-4-28

2012-5-2

用户验收测试

2012-5-3

2012-3-10

产品发布

2012-5-10

2012-5-15

3.测试资源

3.1人力资源

表3-1：

测试人力资源安排表

角色

承担人

具体职责

测试经理

资源管理和监督

提供技术指导

分配适当资源

编写测试计划、测试方案

管理测试分析报告

参加测试

制定一些测试方案

测试员

执行测试计划

编写测试用例

记录测试结果

编写缺陷报告

编写测试分析报告

进行具体的测试工作

3.2测试环境

3.2.1硬件环境

个人PC机一台

Pentium（R）Dual-CoreCPU

T4400@2.20GHz

2.19GHz,2.0GB的内存

3.2.2操作系统

WindowsXPprosp332位

3.2.3软件环境

VisualStudio2005Access2003word2003

3.3测试工具

表3-2：

测试工具列表

用途

工具

生产厂商

版本

Word

Microsoft

2003

测试分析报告

功能测试

QTP

Mercury

9.0

与手工测试配合使用

NTtime

AdamSlosarski

测试代码响应能力

AQTime

Automated

语句级或行级代码性能和结果分析

LoadRunner

MercuryInteractive

9.5

系统性能测试

测试管理

DevTestStudio

TechExcel

4.测试方案

4.1测试方法的选择

测试的方法：

在这里我们采用黑盒、白盒、静态、动态、回归、单元和集成测试。

黑盒测试：

黑盒测试又称功能测试或者数据驱动测试。

黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。

软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。

白盒测试：

白盒测试又称结构测试或者逻辑驱动测试。

白盒测试是把测试对象看作一个打开的盒子。

利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。

白盒测试是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证

静态测试：

静态测试指测试不运行的部分，例如测试产品说明书，对此进行检查和审阅.。

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

静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。

静态测试结果可用于进一步的查错，并为测试用例选取提供指导

动态测试：

动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。

回归测试：

回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。

理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。

根据修复好了的缺陷再重新进行测试。

回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。

一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

通常确定所需的再测试的范围时是比较困难的，特别当临近产品发布日期时。

因为为了修正某缺陷时必需更改源代码，因而就有可能影响这部分源代码所控制的功能。

所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。

单元测试：

单元测试是最微小规模的测试;

以测试某个功能或代码块。

典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。

这个工作不容易做好，除非应用系统有一个设计很好的体系结构;

还可能需要开发测试驱动器模块或测试套具。

集成测试：

集成测试是指一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作并没有冲突。

部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。

这种类型的测试尤其与客户服务器和分布式系统有关。

一般集成测试以前，单元测试需要完成。

　　集成测试是单元测试的逻辑扩展。

它的最简单的形式是：

两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。

从这一层意义上讲，组件是指多个单元的集成聚合。

在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。

方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。

最后，将构成进程的所有模块一起测试。

此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

集成测试识别组合单元时出现的问题。

通过使用要求在组合单元前测试每个单元，并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。

这种方法将可能发生的情况数量减少到更简单的分析级别

测试用例的选取原则：

一：

测试用例必须具有代表性、典型性。

二：

测试用例要有“浓缩性”，即精要、综合。

三：

尽量避免含糊的测试用例。

四：

尽量将具有类似效果的测试用例抽象并归类。

五：

尽量避免冗长和复杂的测试用例。

4.2测试覆盖率要求

4.2.1对源代码的测试覆盖率要求

在这里我们争取对软件关键模块的语句覆盖率要达到100%，分支覆盖要达到85%以上。

从而使系统的整体代码覆盖率能够达到87%以上。

4.2.2对需求的测试覆盖率要求

在这里争取测试用例的执行率要在100%，即所有用例都要执行一遍，测试用例的通过率要达到95%以上。

5.测试项目说明

表5-1：

测试项目列表

测试项

达到的指标

完成日期

功能测试列表

G.1读者子系统

G.1.1个人信息查询

按查询条件正确输出学生信息

G.1.2个人信息修改

学生可以将部分个人信息的添加或修改到学生信息表中

G.2.1当前借阅的查看

输出当前读者当前所借阅的书籍

G.2.2当前借阅的更新

当读者进行新的借阅或进行还书操作时可以在借阅表中增加或删除记录

G.3.1借阅历史的查看

成功输出当前读者的借阅历史

G.3.2借阅历史的更新

当读者只要进行书籍借阅时，将相关的借阅信息可以添加到到借阅表中

G.4.1读者违规查询

当读者登陆失败或进行图书检索时失败时给出错误提示

性能测试项列表

X.1可靠性

X.1.1无故障运行时间

用户在当前网络可用的情况下可以在任何时间段内可以访问

X.1.2并发操作的可用性

在系统正常运行时间内，系统将能适应100个用户，平均每个会话估计持续8分钟。

X.2效率

用户提交了查询之后，对查询的响应时间不能超过5秒。

参考文献

[1][德]Spillner，Linz，[挪]Schaefer著，刘琴等译,《软件测试基础（第2版）》,人民邮电出版社，2009年4月

[2]朱少民，《软件测试方法和技术》，清华大学出版社,2005年7月

[3]教育部考试中心/教育部考试中心，《全国计算机等级考试四级教程--软件测试工程师（2008年版）》，高等教育出版社，2007年9月

[4]赵斌，《软件测试技术经典教程（第二版）》，科学出版社，2011年3月

[5][美]PaulC.Jorgensen,《软件测试（原书第2版）》，机械工业出版社，2007年4月