搜档网
当前位置:搜档网 › 软件测试课程设计报告(模板)

软件测试课程设计报告(模板)

软件测试课程设计报告(模板)
软件测试课程设计报告(模板)

课程设计

课程名称软件测试技术

题目名称充软件测试

专业班级软件工程

学生姓名

学号

指导教师褚伟

二O—六年五月二十四日

目录

1. 测试需求分析 (3)

1.1 系统概述 (4)

1.2 测试需求 (4)

2. 测试概要 (5)

3. 测试计划 (5)

3.1 测试方案的选择 (5)

3.2 测试方案: (7)

3.3 测试项目 (7)

3.4 测试准备 (7)

3.5 测试覆盖率要求 (7)

4. 测试项目说明 (8)

4.1 测试项目名称及测试内容 (8)

4.2 测试用例 (9)

5. 对软件功能的结论 (24)

5.1 功能1(系统登录) (24)

5.2 功能2(图书管理测试) (24)

5.3 功能3(图书查询测试) (24)

5.4 功能4(系统管理测试) (24)

5.5 功能5(借书测试) (24)

5.6 功能6(还书测试) (25)

6. 测试评价与结论 (25)

6.1 能力 (25)

6.2 缺陷和限制 (25)

6.3 建议 (25)

7. 总结 (26)

8. 参考资料 (27)

摘要(中英文)

1. 测试需求分析

1.1 系统概述

本图书管理系统是一款功能非常强大的图书管理软件,本系统在继承了以往系统版本优点的基础上做了进一步优化;在功能上,本系统不仅包含图书管理的常用功能(如书籍管理、期刊管理、物品管理、读者管理、借、还、预借、续借和统计分析等等功能),而且还增加了条码的生成和打印功能(不仅为使用者省去了购买价格昂贵的条码专用打印机的费用,而且条码产生更方便,与系统结合更紧密)。

考虑到很多单位和学校有现成的身份IC 卡(校园卡、会员卡等),为了有效的利用这些已有资源,让使用者使用更方便,我们特在系统中加入了会员卡管理功能,这样,图书管理员不仅可以通过读者编号进行借阅操作,也可以通过已有的身份卡(配合刷卡机或者条码扫描抢使

用)来完成操作;在系统的办卡管理中有新办卡、换卡和注销卡等功能,彻底解决丢卡后的安全隐患问题(向制卡公司定制卡时,一般会要求每张卡的ID号都不同,所以一旦换卡了,原来的会员卡就作废了,即使丢失卡被别人捡到也不能进行正常的借阅操作)。

本系统具有操作简单,易学易用的特点。在开发过程中,我们总结了多年使用电脑管理图书馆业务的经验,注意到工作人员在使用电脑时容易发生的人为错误,因而使系统具有较强的容错和排错功能,而且本系统自带了一些常用的资料库(如中图分类库,出版社库等,系统会自动根据图书的标准ISEN码检索出当前图书的出版社名称和出版地点等,从而实现图书的自动录入的功能),使得用户在录入图书资料时更轻松;系统也自带了通用数据导入功能,可以非常简单地把用户以前的已有资料或者通过采集器采集到的数据资料导入到本系统中,避免了大量的重复劳动。经过长时间的不断测试和完善,系统的安全性和稳定性得到保证。

本系统完全可以配合条码扫描枪使用,操作会更流畅,更简单。

技术简介:本系统采用Adaptive Server Anywhere数据库、C/S结构,完全支持多用户操作;可运行于Windows9x/WindowsNT/2000/Xp/2003 平台,有良好的兼容性、先进性与扩充性;可在线升级。

系统特点:操作简单、界面清晰、功能强大、运行稳定快速、系统资源占用少。

1.2 测试需求

本次测试针对开发的图书馆管理系统进行,包括功能测试,界面测试,图书管理测试,信息查

询测试,借书测试,还书测试,用户、管理员管理测试。按照规格需求说明书中的功能进行测

试,在测试过程中发现软件的漏洞不足并予以改正。

2. 测试概要

3. 测试计划

3.1测试方案的选择

测试的方法:在这里我们有黑盒、白盒、静态、动态、回归、单元和集成测试等方法。黑盒测试:黑盒测试又称功能测试或者数据驱动测试。黑盒测试是根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

软件测试人员以用户的角度,通过各种输入和观察软件的各种输出结果来发现

软件存在的缺陷,而不关心程序具体如何实现的一种软件测试方法。

白盒测试:

白盒测试又称结构测试或者逻辑驱动测试。白盒测试是把测试对象看作一个打

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

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

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

静态方法是指不运行被测程序本身,仅通过分析或检查源程序的文法、结构、过程、

接口等来检查程序的正确性。静态方法通过程序静态特性的分析,找出欠缺和可疑之处,例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错,并为测试用例选取提供指导

动态测试:

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

回归测试:

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

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

根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的,特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码,因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试,而且还要测试有可能受影响的所有功能。

单元测试:

单元测试是最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。这个工作不容易做好,除非应用系统有一个设计很好的体系结构;还可能需要开发测试驱动器模块或测试套

具。集成

测试:

集成测试是指一个应用系统的各个部件的联合测试,以决定他们能否在一起共

同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前,单元测试需要完成。

集成测试是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。此外,如果程序由多个进程组成,应该成对测试它们,而不是同时测试所有进程。

集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元,并确保每个单元的生存能力的测试计划,可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别

测试用例的选取原则:

一:测试用例必须具有代表性、典型性。二:测试用例要有“浓缩性” ,即精要、综合。三:尽量避免含糊的测试用例。

四:尽量将具有类似效果的测试用例抽象并归类。五:尽量避免冗长和复杂的测试用例。

3.2 测试方案:

采用黑盒测试方法。对功能进行逐一测试,在输入合理及不合理的数据后测试系统的正常运作情况。

3.3 测试项目

测试1:系统登录测试

测试2:图书管理测试

测试3:信息查询测试

测试4:系统管理测试

测试5:借书测试

测试6:还书测试

3.4 测试准备

计划测试项目,设计合理的测试用例。

3.5 测试覆盖率要求

(1)对源代码的测试覆盖率要求在这里我们争取对软件关键模块的语句覆盖率要达到100%,分支覆盖要达到85% 以上。从而使系统的整体代码覆盖率能够达到87%以上。

(2)对需求的测试覆盖率要求

在这里争取测试用例的执行率要在100%,即所有用例都要执行一遍,测试用例的通

过率要达到95%以上

相关主题