图书管信息管理系统测试分析报告1.软件项目介绍1.1软件测试项目背景根据各大学校希望能够充分利用现代科技来提高图书管理的效率，在原有的办公系统基础上进行扩展，将一些可以用计算机来管理的都进行计算机化，使得图书管理人员工作更加方便，工作效率也更加的高。

图书馆信息系统的系统结构如图1.1所示，系统的主要构成部分是图书管各业务处理的子系统。

用于处理图书馆日常运营中的主要业务，包括编目子系统、图书采购子系统、图书流通子系统等，另外业务处理子系统能够正常运行还需要基础信息的维护和权限控制；业务处理子程序产生的数据还需要呈献给图书管理员和读者等，所以按性质图书管理系统可以分为业务处理、基础信息管理和信息查询三部分。

图1.1 图书馆信息管理系统的系统结构图1.2图书流通子系统的介绍图书流通子系统实现了对图书信息的有效管理，对图书的日常流通管理具有一定的辅助作用。

图书馆流通子系统使图书管理工作规范化、系统化、程序化、避免图书管理的随意性，提高信息处理的速度和准确性，能够及时准确有效的查询和修改图书情况。

图书馆流通子系统是图书馆管理系统的一部分，主要管理图书的流动。

图书馆流通子系统是提供给图书管理人员用来管理和维护数据记录。

管理员能够对图书信息进行添加、查询、更改、删除以及对数据的维护；管理员需要通过密码进行登录，也可以修改密码。

普通用户无需登录，可以使用查询功能等部分功能。

图书管理员对读者的借阅及还书要求进行操作，同时形成借书或还书报表给借阅者查看确认，还要对图书进行管理和维护。

由于此系统大部分功能只是对管理员开放，所以管理员可以操作所有功能，图书管理员可以添加、查询、更改、删除、统计图书的基本信息，查询、统计图书馆的借阅信息。

图书馆流通子系统具体功能模块和界面如下：A.管理员登陆功能模块首先利用管理员登录功能块，实现管理员登陆，管理员必须输入正确的密码才能进入主界面，如果管理员密码错误，应用程序会提示错误信息。

B．图书馆流通子系统界面管理员进入系统界面完成以下功能，图书管理、图书借阅、用户管理和信息查询。

图 1.2 图书馆流通子系统管理模块操作界面1.3子系统的功能需求分析为了能更好的解读后面的测试用例，先给出图书管理流通子系统的功能需求分析图。

1.4子系统的性能及可用性要求除了功能需求以外，每个系统都会有一些性能上、安全上及其它方面的具体要求。

另外还有一些一般性的规定，它可能不是针对某个具体模块，而是整个系统，要求软件的每个模块都能达到某种程度的要求，这些需求没有固定的模式，但一个具体的软件测试过程中必须要考虑所测试的软件项目的具体需求，并经过实际测试确定该软件在这些方面能够达到用户的要求。

2.测试计划测试计划一般由测试经理来制定。

测试计划光有预算、人员安排和时间进度还远远不够，测试计划涉及许多测试工作的具体规划。

很难想象，一个没有经过很好策划的测试项目能够进行顺利。

测试计划工作的成果是提交一份完整的测试计划报告。

关于测试计划报告的模板，不必千篇一律，它会随着软件的运用行业、软件功能及性能要求、管理规范性要求等的不同而不同。

但一个完整的测试计划一般均包括被测试项目的背景、测试目标、测试的范围、方式、资源、进度安排、测试人员组织以及与测试有关的风险等方面。

下面给出图书信息管理系统1.0版集成测试的测试计划报告。

2.1测试概述本测试项目拟对图书信息管理系统1.0进行测试。

2.2定义●质量风险：被测试系统不能实现描述的产品需求或系统不能达到用户的期望的行为，即系统可能存在的错误。

●测试用例：为了查找被测试软件中的错误而设计的一系列的操作数据和执行步骤，即一系列测试条件的组合。

●测试工具：应用于测试用例的硬件/软件系统，用于安装或撤销测试环境、创造测试条件，执行测试，或者度量测试结果等工作。

测试工具独立于测试用例本身。

●进入标准：一套决策的指导方针，用于决定项目是否准备好进入特定的测试阶段，在集成测试和系统测试阶段，进入标准会很苛刻。

●退出标准:一套标准，用于决定项目是否可以退出当前的测试阶段，或者进入下一个测试阶段或结束项目。

同进入标准，测试过程的后几个阶段退出标准一般很苛刻。

●功能测试：集中于功能正确性方面的测试，功能测试必须和其它测试方法一起处理潜在的重要的质量风险，比如性能、负荷、容积和容量等。

2.3质量风险摘要2.4测试进度计划2.5进入标准●“测试小组”配置好软硬件环境，并且可以正确访问这些环境。

●“开发小组”已完成所有特性和错误修复并完成修复后的单元测试。

●“测试小组”完成“冒烟测试”——程序包能打开，随机的测试操作正确完成。

2.6退出标准●“开发小组”完成了所有必需修复的错误。

●“测试小组”完成了所有计划的测试。

没有优先级为3以上的错误。

优先级为2以下的错误少于5个。

●“项目管理小组”认为产品实现稳定性和可靠性。

2.7测试配置和环境●服务器一台：惠普PIII550,2GB内存，8.4GB硬盘；软件环境是Windows7。

●打印机1台：Panasonic KX-P1131。

●地点：NB-617。

2.8测试开发●设计测试用例已进行手工测试。

●准备使用MI Loadrunner，以检测系统对比并发性的控制和系统的强壮性。

●设计开发问题记录及交互工具，包括问题存储控制系统及所对应的数据库，以对测试结果做很好的记录并提供相关测试和开发人员的交互平台。

2.9预算表2.9 测试预算表2.10关键参与者●测试经理：XXXX（制定测试计划及部署、监督相关工作）。

●测试人员：XXXX（负责相关子系统测试）。

●开发人员：XXXX（及时解决影响测试进行的系统问题）。

●项目管理人员：XXXX（跟踪项目进展）。

2.11参考文档●《图书信息管理系统1.0系统需求说明书》●《图书信息管理系统1.0用户手册》●《图书信息管理系统1.0设计报告》●《图书信息管理系统1.0基本功能规范》●《软件测试》●《软件测试过程管理》3.图书信息管理系统测试过程概述广义的说，测试工作贯穿一个软件项目开发过程的始终，从项目的策划和相关文档的生成开始直到软件通过用户的验收。

通常所说的测试是指运行软件系统（或单个的模块）以检验其是否满足用户要求的过程。

图书信息管理系统的测试按照一般测试过程，将其分为单元测试、集成测试、系统测试和验收测试4个阶段。

对于测试开发人员来讲，关注的是前三个阶段的测试过程。

3.1单元测试单元测试首先要理解单元原本是要做什么的，而不是它现在实际做了什么，我们更关心的是：模块或函数是否做了它该做的事情而没有做不该做的事情。

主要依据详细设计的描述和源程序清单针对五部分内容进行测试：模块接口、局部数据结构、边界条件、出错处理、独立路径。

首先模块与周围环境的接口有无差错应首先得到检验，否则其内部的各种测试工作将是徒劳;局部数据结构也是常见的错误来源，对基本控制流进行测试同样也会发现大量的错误;异常处理要给予适当的出错处理对策，以便在程序出错时，能对出错程序重新做出安排，保证其逻辑上的正确性;边界测试，对数据流的测试将是单元测试的最后一步。

3.2集成测试集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，当一个系统还没有完成，设计相应的桩和驱动模块进行集成测试，便于早期发现接口问题以及集成后的功能问题，同时编码不是一个可以一次性通过的过程，对最初的单元测试中一些被忽略和遗漏的BUG，也将会在集成测试阶段被发现。

概要设计的对象主要为系统，系统子系统，模块，子模块，函数等，通过体系结构进行模块的划分，并进行数据设计、接口设计，遵循高内聚、低耦合的原则，对其进行分解描述，依赖关系描述，接口描述等，并保持模块与需求的对应关系，因此，对集成测试的重点，将主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能。

确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，验证接口是与设计相符合?发现设计与需求中存在的错误是集成测试的工作内容。

通过接口的覆盖率进行集成测试的评估。

3.3系统测试系统测试是我们传统观念的一种测试方式，也就是一般放在项目功能基本实现后的功能和性能等方面的测试，目前软件测试已由开发的后期介入扩展到了整个生命周期，由基于代码运行扩展到静态走读，由传统的发现错误为目的扩展到了对缺陷的预防。

系统测试主要验证功能是否符合需求规格定义，是一种在实际环境下的测试，同时也是全面的系统级测试，其内容包括产品功能、性能指标、兼容性、可靠性、容错能力、可维护性、安全性等方面;功能方面主要检查是否有不正确或遗漏了的功能，性能测试目标是度量系统相对于预定义目标的差距，必须要有工具的支持;GUI测试界面实现与界面设计的吻合，以及界面处理的正确性，是直接面对用户的首要条件，因此相对在易用性方面显的较为重要;兼容性，可靠性的、容错性，可维护性，安全性等根据项目要求的不同，具体情况具体分析。

系统测试评估的标准是对需求规格说明书的覆盖率。

3.4验收测试软件验收测试完成标准：无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。

软件验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。

项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

4.测试用例设计测试用例应由测试人员在充分了解系统的基础上在测试之前设计好，测试用例的设计是测试系统开发中一项非常重要的内容。

集成测试阶段测试用例的设计依据为系统需求分析、系统用户手册和系统设计报告等相关资料的内容，而且测试人员要与开发人员充分交互。

在写出测试用例之前还要编写测试大纲，大纲基本上是测试思路的整理，以保证测试用例的设计能够清晰、完整而不是顾此失彼。

测试大纲可以按照模块、功能点、菜单和业务流程这样的思路来策划。

4.1子系统测试大纲4.2其它可用性测试检查标准软件产品的可用性是指软件产品能否让用户更快更容易的完成工作。

即软件是否易学、易用，并使用户感到满意。

软件产品的可用性主要反映在软件产品的用户界面及操作过程上减少错误出现，提高用户工作效率，增加用户满意度；对于开发商而言可以缩减服务和后期培训费用，提高用户满意度。

软件的可用性已经越来越用户和开发商的关注。

可用性测试对所有功能模块来说，检测标准是相同的，而这些检测在功能测试同时就可检验，所以不再设计单独的测试用例。

表4.2 列出图书信息管理系统中流通子系统的可用性检测标准。

表4.2 图书流通子系统的可用性检测标准4.3功能测试用例4.3.1登录模块测试用例4.3.2维护图书信息模块测试用例4.3.3图书录入模块测试用例4.3.4维护管理员信息模块测试用例4.3.5图书查询模块测试用例4.3.6图书的借阅模块测试用例4.4性能测试用例表4.4 性能测试用例5.缺陷报告在测试阶段，利用缺陷报告来记录、描述、跟踪被测试系统中已被捕获的不能满足用户对质量的合理期望的问题——缺陷或叫错误。