图书馆管理系统软件测试计划

1. 引言

1.1. 目的

测试图书管理系统中的各个功能模块是否满足用户要求,并测试是否存bug。预期达到能够使系统进行快速的改进和系统的提高。为了在软件投入生产性运行之前,尽可能多地发现软件的错误。

1.2. 背景

a. 本项目测试的背景;图书管理系统是一个教育单位不可缺少的部分,它的内容对于决策者和管理者来

说都至关重要,所以图书管理系统应该能够为用户提供充足的信息和快捷的查询手段。但一直以来人们使用传统人工的方式管理文件档案,这种管理方式存在着许多缺点,如:效率低、保密性差,另外时间一长,将产生大量的文件和数据,这对于查找、更新和维护都带来了不少的困难。而计算机的应用便解决了以上问题,它带来更加科学,有效,正规的管理方式,给人们带来了很大的便利。图书管理系统界面简洁,操作简单,满足了学校对图书信息管理的需要。

b. 该开发项目的历史,列出用户和执行此项目测试的机构或人群;该项目前后经历了三个阶段,前期设

计阶段,然后是开发阶段,最后是软件的测试阶段。项目的用户针对的是学校的广大学生和管理员,系统的功能测试主要由专业的软件测试人员进行测试。

1.3. 范围

图书管理系统试采用的是黑盒测试的方式来对系统进行测试。主要测试软件的功能是否满足客户的需要,性能是否优越以及系统所存在的问题。对系统的各个模块进行详细的测试,并记录测试的结果,对测试的结果进行细致的分析处理。测试时对系统的各个功能模块进行拆分测试,并以每一个模块都要测试到。对所有可能的结果进行测试,以及测试过程中存在的问题进行分析,然后提交测试的记录。最后,对软件存在的问题以及性能的测试进行全面分析,并给予记录。

在测试的过程中需要提出各个问题的假设,以及根据需求报告文档中存在的项目功能模块和用户的需求来改善系统。列出可能会影响测试设计、开发、或实施的所有风险或意外事件。列出可能会影响测试设计、开发或实施的所有约束。

1.4. 定义

信息(Information):有关图书的详细数据,如书名、作者、出版日期等

管理(Manage):对图书信息进行操作,如增删改查等基本功能

统计(Account):对图书信息的统计,如册数等

1.5. 参考资料

列出编写本计划及测试整个过程中所要参考的文件、资料。

图书馆管理系统软件测试计划

列出编写本计划时需查阅的Intenet上杂志、专业著作、技术标准。

图书馆管理系统软件测试计划

2. 测试内容

下表列出了学生信息管理系统的测试需求,并对其进行了优先级定义:

图书馆管理系统软件测试计划

3. 测试规则

3.1. 进入准则

首先在系统中配置ODBC:控制版板-->ODBC--->选系统 dns--->选 access mdb--->其中 数据源名"信息" ,点击"选择" 按钮,选你的程序目录中的 "信息.mdb"的文件--->确定.

另外安装vb6.0企业版开发系统。使用账户登录系统来完成各个功能的测试。

3.2. 暂停/退出准则

软件系统在进行单元、集成、确认、系统、安装、验收测试时,发现一级错误(大于等于1)、二级错误(大于等于2)暂停测试返回开发。软件系统经过单元、集成、确认、系统、安装、验收测试,分别达到单元、集成、确认、系统、安装、验收测试停止标准。软件系统通过验收测试,并已得出验收测试结论。软件项目需暂停以进行调整时,测试应随之暂停,并备份暂停点数据。软件项目在其开发生命周期内出现重大估算,进度偏差,需暂停或终止时,测试应随之暂停或终止,并备份暂停或终止点数据

3.3. 测试方法

本次测试运用黑盒测试方法,对图书管理系统进行测试。首先,进行对功能模块进行划分,明确功能测试的人员负责情况。其次对各个模块进行测试。黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。黑盒测试着力于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行

1

测试。“黑盒法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

3.4. 当完成模块测试后进行整个系统的功能测试测试手段

路径测试(path testing) 。一条路径包含测试员所执行的所有步骤,或程序为了得到正确状态所通过的所有语句。路径测试包括测试通过程序的很多路径。通过非平凡程序的所有路径是不可能的。因此,有些测试员进行子路径测试(subpath testing),测试很多部分路径。、

语句与分支覆盖率(statement and branch coverage)。如果测试执行了程序中的所有语句(或代码行),则达到100%的语句覆盖率。如果执行了所有语句和一个语句到另一个语句之间的所有分支,则达到100%的语句和分支覆盖率。设计自己的测试,达到高的语句与分支覆盖率,有时叫做“基于覆盖率的测试(coverage-based

testing)” 。(达到覆盖率目标后,可以停止测试,或停止设计更多的测试) 。把它叫做语句与分支覆盖率,是为了与关注其他类型覆盖率的测试相区别。配置覆盖率就是一个很好例子,这种手段执行同一条语句很多次,但是潜在产生非常不同的结果。

配置覆盖率(configuration coverage) 。如果必须测试100台打印饥的兼容性,并且已经测试了10台,就达到10%的打印机覆盖率。更一般地,配置覆盖率度量测试员已经运行(并且程序已经通过)的配置测试占计划运行的配置测试总数的百分比。

基于规格说明的测试(specification-based testing) 。这种测试关注验证在规格说明中所做的有关产品的每个事实声明。(事实声明是可以用真或假表示的任何语句。)常常包括手册、市场开发文档或广告、技术支持人员寄给客户的印刷品中的所有声明。

基于需求的测试(requirements-based testing) 。测试关注证明程序满足需求文档中的所有需求(或关注逐个需求地证明某个需求没有被满足。)

组合测试(combination testing) 。相互组合测试两个或更多变量。本章最后的“测试手段附录”还要讨论这个问题。组合测试很重要,但是很多测试员对这种测试研究得还很不够。

3.5. 测试要点

主要测试系统的功能是否符合客户要求,各个模块之间的衔接程度是否顺畅,并测试软件是否存在缺陷和漏洞。

3.6. 测试工具

1. 负载压力测试工具

这类测试工具的主要目的是度量应用系统的可扩展性和性能,是一种预测系统行为和性能 的自动化测试工具。在实施并发负载过程中,通过实时性能监测来确认和查找问题,并针对所 发现问题对系统性能进行优化,确保应用的成功部署。负载压力测试工具能够对整个企业架构 进行测试,通过这些测试,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布 周期。

2. 功能测试工具

通过自动录制、检测和回放用户的应用操作,将被测系统的输出记录同预先给定的标准结 果比较,功能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版本的功能进 行测试,提高测试人员的工作效率和质量。其主要目的是检测应用程序是否能够达到预期的功 能并正常运行。

3. 测试管理工具

一般而言,测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理,并且测 试管理工具还 2

包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT人员 通过一个中央数据仓库,在不同地方就能交互信息。

4. 测试环境

4.1. 硬件环境

1> 处理器:Intel Pentium 166 MX 或更高

2> 内存:32MB 以上

3> 硬盘空间:1GB 以上

4> 显卡:SVGA显示适配器

4.2. 软件环境

vb6.0企业版开发系统

4.3. 安全性环境要求

操作系统的安全性,测试工具的安全性,测试软件的安全性。

5. 项目任务

以下是测试图书信息管理系统时与测试有关的任务:

5.1. 测试规划

1. 响应时间

我把“响应时间”的概念确定为“对请求作出响应所需要的时间”,把响应时间作`为用户视角的软件性能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。

2. 并发用户数

我把“并发用户数”与“同时在线数”进行区别对待,我的“并发用户数”的标准是:并发用户数取决于测试对象的目标业务场景,因此,在确定这个“并发用户数”前,必须(必要)先对用户的业务进行分解、分析出典型的业务场景(也就是用户最常使用、最关注的业务操作),然后基于场景采用某些方法(有多种计算并发用户数的数学模型与公式)获得“并发用户数”。

这样做的原因是:假设一个应用系统、最高峰有500人同时在线、但这500人却不是并发用户数、因为假设在一个时间点上、有50%的人在填写复杂的表格(填写表格动作对服务器没有任何负担、只有在“提交”动作的时候才会对服务器系统构成压力)、有40%的人在不停的从一个页面跳转到另外一个页面(不停发出请求与回应、产生服务器压力)、还有10%的人挂在线上,没有任何操作在发呆:)(没有对服务器构成压力的动作)。因此只有那40%的人真正对服务器产生了压力,从这里例子可以看出、并发用户数关心的是不但是业务并发用户数、还取决于业务逻辑、业务场景。因此我们需要本文第六部分性能测试文档4、5、6。

3. 吞吐量

我把吞吐量定义为“单位时间内系统处理的客户请求的数量”,直接体现软件系统的性能承载能力,对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。我们在以下方面利用这个指标:

(1)用来协助设计性能测试场景,衡量性能测试是否达到了预计的设计目标、比如J2EE应用系统的连接池、数据库事务发生频率、事务发生次数。

(2) 用来协助分析性能瓶颈、参照本文第二部分总的RBI方法。

4. 性能计数器

性能计数器式描述服务器或操作系统性能的一些数据指标、例如对WINDOWS来说使用内存数、CPU使 3

用率、进程时间等都是常见的计数器。

对于性能计数器这个指标来说、需要考虑到的不但有硬件计数器、web服务器计数器、Weblogic服务器计数器、Servlet性能计数器、EJB2的性能计数器、JSF性能计数器、JMS性能计数器。找到这些指标是使用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、提供优化建议才是性能计数器使用的关键。性能计数器复杂而繁多、与代码上下文环境、系统配置情况、系统架构、开发方式、使用到的规范实现、工具、类库版本都有紧密的联系、在此不作赘述。

5. 思考时间

我把思考时间确定为“休眠时间”。从业务系统的角度来说,这个时间指的是用户在惊醒操作时、每个请求之间的时间间隔、从自动化测试的角度来说、要真实的测试模拟用户操作、就必须在测试脚本中让各个操作之间等待一段时间、体现在脚本上就是在操作之间放置一个Think的函数,体现为脚本中两个请求语句之间的间隔时间、不同的测试工具提供了不同的函数或方法来实现思考时间、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。

5.2. 测试设计

用户层:

主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上,测试系统对用户支持的情况,用户界面的规范性、友好性、可操作性,以及数据的安全性。主要包括:用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。

用户界面测试

在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下,测试用户界面的风格是否满足用户要求,例如:界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。 可维护性测试

可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。例如:对支持远程维护系统的功能或工具的测试。

安全性测试

这里的安全性主要包括了两部分:数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统,其他不符合规格的数据不能够访问系统;核实只有规格规定的操作权限才可以访问系统,其他不符合规格的操作权限不能够访问系统;

应用层:

针对产品工程应用或行业应用的测试。重点站在系统应用的角度,模拟实际应用环境,对系统的兼容性、可靠性、性能等进行的测试。

系统性能测试

针对整个系统的测试,包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程;强度测试是在资源情况低的情况下,找出因资源不足或资源争用而导致的错误;破坏性测试重点关注超出系统正常负荷N倍情况下,错误出现状态和出现比率以及错误的恢复能力。

系统可靠性、稳定性测试

4

一定负荷的长期使用环境下,系统可靠性、稳定性。

系统兼容性测试

系统中软件与各种硬件设备兼容性,与操作系统兼容性、与支撑软件的兼容性。

系统组网测试

组网环境下,系统软件对接入设备的支持情况。包括功能实现及群集性能。

系统安装升级测试

安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如,正常情况下,第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安装手册、安装脚本等也需要关注。

5.3. 测试执行准备

故障转移和恢复测试可确保测试对象能成功完成转移,并能从导致意外数据损失或数据完整性破环的各种硬件、软件、网络故障中恢复数据。故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统至于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出(I/O)故障或无效的数据库指针和关键字)。然后调用恢复进程并检测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。

5.4. 测试执行

1.前提条件确保测试项目的功能正常,如导航,数据输入,处理、检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程,这是目前的测试重点。

执行用例及原始数据记录

2. 提交测试问题单和测试报告

3. 回归及验收测试

4. 输出工件

利用有效的和无效的数据来执行各个用例流,以核实以下内容:

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

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

6. 实施计划

6.1. 工作量估计

根据工作内容和项目任务对包括测试设计的工作量、测试执行和测试总结的工作量,以人月或人日计, 并详细注释测试设计、测试执行和测试总结工作所占的比重。软件测试工作量应为开发工作量的30%-40%为宜。

5

图书馆管理系统软件测试计划

图书馆管理系统软件测试计划

6.2. 下表列出了在此测试活动的人员安排:

图书馆管理系统软件测试计划

6.3. 6.4. 可交付工件

本节列出了将要创建的各种文档、工具和报告,及其创建人员、交付对象和交付时间。

7. 风险管理

L=Low(风险与处理的优先级为低) M=Middle(风险与处理的优先级为中) H=High(风险与处理的优先级为高)

图书馆管理系统软件测试计划

6

2.问题严重度描述

图书馆管理系统软件测试计划

7

 

第二篇:08级软件二班 马月 人事管理系统软件测试计划

七、测试计划

1.引言... 1

1.1编写目的... 1

1.2项目背景... 2

1.3定义... 2

1.4参考资料... 2

2.任务概述... 2

2.1目标... 2

2.2运行环境... 2

2.3需求概述... 2

2.4条件与限制... 2

3.计划... 3

3.1测试方案... 3

3.2测试项目... 3

3.3测试准备... 3

3.4测试机构及人员... 3

4.测试项目说明... 3

4.1测试项目名称及测试内容... 3

4.2测试用例... 3

4.3进度... 3

4.4条件... 3

4.5测试资料... 3

5.评价... 3

5.1范围... 3

5.2准则... 3

1.引言

1.1编写目的

在开发大型软件的漫长过程中,面对极其错综复杂的问题,人的主观认识不可能完全符合客观现实,与工程密切相关的各类人员之间的通信和配合也不可能完美无缺。因此,在软件生命周期的每个阶段都不可避免地会产生差错。尤其对于人事管理系统这类会影响人们生活.财产的工程软件,必须尽量减少差错,以免造成严重的损失。测试是“为了发现程序中的错误而执行程序的过程”。测试的目的就是在软件投入生产性运行之前,尽可能多的发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤,它是对软件规格说明.设计和编码的最后复审,也是必不可少的关键步骤。

1.2项目背景

本项目(人事管理系统)时由XXX公司委托,由<>负责开发。

1.3定义

事务流:数据进入模块后可能有多种路径进行处理。

主键:数据库表中的关键域。值互不相同。

外部主键:数据库表中与其他表主键关联的域。

ROLLBACK: 数据库的错误恢复机制。

1.4参考资料

1.  人事管理系统项目计划任务书                    XXX公司               

2. 人事管理系统项目开发计划                   《》软件开发小组        

3. 用户操作手册(初稿)                             《》软件开发小组 

4. 软件工程及其应用      周苏、王文等              天津科学技术出版社

5. 软件工程               张海藩                  清华大学出版社   

2.任务概述

2.1目标

测试是“为了尽可能的发现软件中的错误,而不是为了证明程序的正确性”, 测试的目的就是在软件投入生产性运行之前,按照测试的原则就要求,尽可能多的发现软件中的错误。

2.2运行环境

硬件要求:PI 133以上处理器,最低32M内存,300M以上硬盘剩余空

间。

运行环境:win98/winNT4.0/win2000/winxp 

2.3需求概述

XX公司为方便人事管理,需开发一个人事管理系统。为便于职工信息查询以及工资情况统计,XX公司把职工的信息,包括姓名、性别、年龄,工资等信息输入机票人事管理系统的数据库,然后在管理终端可以对数据进行查询和修改操作。

要求系统能有效、快速、安全、可靠和无误的完成上述操作。并要求系统界面要简单明了,易于操作,程序利于维护。

2.4条件与限制

必须在保证各硬件设备.软件系统齐备的情况下,资金充足,人员齐备,各方面互相配合,齐心协力,共同完成。

3.计划

3.1测试方案

测试方案是测试阶段的关键技术问题。为了提高测试效率降低测试成本,本测试方案采用黑盒法设计基本的测试方案。在黑盒法测试方案中,采用等价划分技术,把所有可能的输入数据(有效的和无效的)划分成几等价类,其划分类在以下的输入中再详述。

3.2测试项目

身份认证模块

    人员信息查询模块

    人员信息维护模块

人员信息统计模块

    工资查询模块

    工资维护模块

(这里以人员信息维护为例子)

3.3测试准备

在测试前,与各模块的主要负责人共同协商讨论,以概要设计说明书.详细设计说明书作为总的提纲,选择合适的输入输出数据,并加以意义列举说明。

3.4测试机构及人员

测试机构由XXX工作组组成,人员有软件开发小组全体人员。

4.测试项目说明

人员信息维护模块见《人员信息维护模块》

4.1测试项目名称及测试内容

测试项目:

waitforsignal()是否可以接受用户操作信息。

Add() 是否可以在数据窗口中增加新的空白行。

Delete()是否可以删除选中行。

Modify()是否可以将选中行变为可编辑状态。

Cancle() 返回上一界面。

Reset()清空可编辑行

Ok()保存当前数据窗口的内容到数据库。

4.2测试用例

4.2.1输入

4.2.2输出

  1.点击《增加》按钮,数据窗口中出现新的空白行。

 

 输入编号为001的新的信息,将与已有信息发生冲突,系统给出提示。

点击《确定》后,输入合法数据,可以通过。

  2.输入以上数据,有一项内容为空时给出提示,说明数据不完整。

  3.对于非法输入情况报告错误,如上例中编号为Aaa。

  4.格式错误,如最后一个用例,出生日期为19870908,不符合日期格式。

  5.点击《重置》按钮,可编辑项清空。

  6.点击《取消》按钮,返回上一级界面。

4.2.3步骤及操作

按照测试用例输入用户ID,操作员编码和用户口令,点击《确定》。如果打算中途退出,点击《取消》,系统将返回XXX公司微机网络管理系统主菜单。

4.2.4允许偏差

所有测试结果要按照预期输出进行,不可以有任何偏差。

4.3进度

详细设计完成之后,一天完成测试计划,第二天完成测试

4.4条件

符合系统运行条件的设备即可;

    由开发者进行测试。

4.5测试资料

数据要求说明书

    概要设计说明书

    详细设计说明书

    测试计划

5.评价

5.1范围

由于各个模块是相对独立进行测试,只能证明单独模块设计比较完善,所以需要最后进行组合测试,确保模块可以协调工作。

5.2准则

我们要知道测试是软件开发过程中一个非常重要的环节,一各好的软件必须经过无数次的测试。软件测试是保证软件质量的关键步骤。所以在测试过程中必须抱着不骄不躁.谦虚谨慎的态度,努力发现每一个出现的错误,并要仔细寻找能够发现尽可能多的错误的测试用例,不要以为你已经发现所有错误,往往没有发现的错误跟已经发现的错误是成比例的。

相关推荐