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

                           《图书管理系统》

一、简介
1.目的
为了验证图书管理系统的图书管理模块能否正常实现,以图书管理系统作为测试对象,展开系统测试。
2.背景
图书管理系统包括图书录入、图书修改、图书删除、图书查询等九个子系统,用于管理图书馆日常运作的整个过程。各子系统所处理的业务前后衔接,数据共享。
在这里插入图片描述

3.范围
1.图书管理模块

二、测试需求
1.数据库测试;
2.功能性测试;
3.性能测试;

三、测试风险
1.质量需求或产品的特性理解不准确,造成测试范围分析的误差,结果某些地方始
终测试不到或验证的标准不对。
2.测试用例没有得到百分之百的执行,如有些测试用例被有意或无意的遗漏。
3.需求的临时或突然变化,导致设计的修改和代码的重写,测试时间不够。
4.测试用例设计不到位,忽视了一些边界条件、深层次的逻辑、用户场景等。
5.测试环境,一般不可能和实际运行环境完全一致,造成测试结果的误差。
6.有些缺陷出现频率不是百分之百,不容易被发现;如果代码质量差,软件缺陷很
多,被漏检的缺陷可能性就大。
前面三种风险是可以避免的,而 4~6 的四种风险是不能避免的,可以降到最低。最后
一种回归测试风险是可以避免,但出于时间或成本的考虑,一般也是存在的。
针对上述软件测试的风险,有一些有效的测试风险控制方法,如:
测试环境不对可以通过事先列出要检查的所有条目,在测试环境设置好后,由其他人员53
按已列出条目逐条检查。
有些测试风险可能带来的后果非常严重,能否将它转化为其他一些不会引起严重后果的
低风险。如产品发布前夕,在某个不是很重要的新功能上发现一个严重的缺陷,如果修正这
个缺陷,很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大,对
策是去掉那个新功能,转移这种风险。
有些风险不可避免,就设法降低风险,如“程序中未发现的缺陷”这种风险总是存在,
我们就要通过提高测试用例的覆盖率(如达到 99.9%)来降低这种风险。
为了避免、转移或降低风险,事先要做好风险管理计划和控制风险的策略,并对风险的
处理还要制订一些应急的、有效的处理方案。

四、测试策略
1.数据和数据库完整性测试
数据库和数据库进程应作为<项目名称>中的子系统来进行测试。在测试这些子系统时,
不应将测试对象的用户界面用做数据的接口。对于数据库管理系统(DBMS),还需要进行
深入的研究,以确定可以支持以下测试的工具和方法。数据库测试如表 2-2 所示。
表 2-2 数据库测试说明

发布文章的话表格不能直接复制到上面(下边那些有的, 都是带表格的是表格里的数据),想要带有表格的标准格式就下载一下我发布过的资源,软件测试——图书管理系统的测试计划书吧

在这里插入图片描述

测试目标
确保数据库访问方法和进程正常运行,数据不会遭到损坏。
方法
 调用各个数据库访问方法和进程,并在其中填充有效的和无效
的数据或对数据的请求。
 检查数据库,确保数据已按预期的方式填充,并且所有数据库
事件都按正常方式出现:或者检查所返回的数据,确保为正当
的理由检索到了正确的数据:
完成标准 所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭
到损坏。

需考虑的特殊事项
 测试可能需要 DBMS 开发环境或驱动程序以便在数据库中直
接输入或修改数据、
 进程应该以手工方式调用。
 应使用小型或最小的数据库(其中的记录数很有限)来使所有
无法接受的事件具有更大的可见性。

2.功能测试
测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有
测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正
确实施。这种类型的测试基于黑盒方法,即通过图形图书管理界面与应用程序交互并分
析输出结果来验证应用程序及其内部进程。表 2-3 列出的是每个应用程序推荐的测试方法概
要。
表 2-3 功能测试说明表

测试目标 确保测试对象的功能正常,其中包括数据添加、修改、删除和查询。
方法 利用有效的和无效的数据来执行各个用例、用例流或功能,以核实
以下内容:
 在使用有效数据时得到预期的结果。
 在使用无效数据时显示相应的错误消息或警告消息。
 各业务规则都得到了正确的应用。
完成标准
 所计划的测试已全部执行。
 所发现的缺陷已全部解决。
需考虑的特殊事项
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素
(内部的或外部的)。

3.性能评价
性能评价是一种性能测试,它对响应时间、事务处理速率和其他与时间相关的需求进行
评测和评估。性能评价的目标是核实性能需求是否都已满足。实施和执行性能评价的目的是
将测试对象的性能为当做条件(如工作量或硬件配置)的一种函数来进行评价和微调。性能
测试如表 2-6 所示。
注:以下事务均指“逻辑业务事务”。这种事务被定义为将由系统的某个主角通过使用
测试对象来执行的特定用例,例如,添加或修改某个合同。
表 2-6 性能测试说明表

测试目标
核实所指定的事务或业务功能在以下情况下的性能行为:
 正常的预期工作量。
 预期的最繁重工作量。

方法
使用为功能或业务周期测试制定的测试过程。
通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事
务的迭代次数。
脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基
准),并在多台客户机(虚拟的或实际的客户机,请参见下面的“需
考虑的特殊事项”)上重复。

完成标准  单个事务或单个用户:在每个事务所预期或要求的时间范围内
成功地完成测试脚本,没有发生任何故障。
 多个事务或多个用户:在可接受的时间范围内成功地完成测试
脚本,没有发生任何故障。
需考虑的特殊事项
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作,其中包括:
直接将“事务强行分配到”服务器上,这通常以“结构化查询
语言”(SQL)调用的形式来实现。
通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)56
客户机。此负载可通过“远程终端仿真”(Remote Terminal Emulation)
工具来实现。此技术还可用于在网络中加载“流量”。
使用多台实际客户机(每台客户机都运行测试脚本)在系统上
添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行,以便
实现完全的控制和精确的评测。
性能测试所用的数据库应该是与实际大小相同或等比例缩放的
数据库。

五、测试工具
此项目将使用表 2-14 所示的工具。
注:可以视情况删除或添加项目。
表 2-14 测试工具
工具 厂商 版本

测试管理 Quality Center HP
10.0

功能性测试
QTP
HP
12.0

性能测试
LoadRunner
HP
12.0

六、资源
1.人力资源
表 2-15 列出了在此项目的人员配备方面所做的各种假定。
表 2-15 人力资源说明表

人力资源
角色
推荐的最少资源 具体职责或注释

测试组长
1 负责拟订软件项目的测试计划和方案,提供
测试技术指导,组织测试资源,安排测试计
划实施,提交测试分析报告,总结整个测试
活动。

测试设计员 1 参与制订测试计划,生成测试模型,在面向
对象的设计系统中确定并定义测试类的操
作、属性和关联关系。
确定测试用例,指导测试实施,参与测试评
估和测试分析报告的编写。
测试员
1 执行实施测试,填写测试记录,记录结果和
缺陷。

2.系统资源
表 2-16 列出了测试项目所需的系统资源。
此时并不完全了解测试系统的具体元素。建议让系统模拟生产环境,并在适当的情况下
减小访问量和数据库大小。

表 2-16 系统资源说明表

系统资源
服务器名 172.16.112.177
数据库名 sa
客户端测试 PC 172.16.112.177

七、测试进度和里程碑
1.项目测试进度
以下测试工作任务的起止时间为:
① 图书录入功能
② 图书修改功能
③ 图书删除功能
④ 图书查询功能

2.测试里程碑
对<项目名称>的测试应包括上面各节所述的各项测试的测试活动。应该为这些测试确
定单独的项目里程碑,如表 2-17 所示,以通知项目的状态和成果。
表 2-17 测试里程碑说明表
里程碑任务 工作量 开始日期 结束日期
图书录入功能
图书修改功能
图书删除功能
图书查询功能

八、可交付工件
这部分内容列出了将要创建的各种文档、工具和报告,及其创建人员、交付对象和交付时间。例如,测试计划说明书、测试用例或测试脚本、开发的测试工具、测试日志、缺陷报
告、测试分析报告、测试总结等。
(1)概述
① 测试目的
提供一个对项目软件进行测试的总体安排和进度计划,确定现有项目的信息和应测试的
软件标明推荐的测试需求(高层次)和可采用的测试策略,并对这些策略加以说明确定所需
的资源,并对测试的工作量进行估计,列出测试项目的可交付元素。
② 测试范围
描述测试的各个阶段,例如,单元测试、集成测试或系统测试,并说明本计划所针对的
测试类型(如功能测试或性能测试)。简要地列出测试对象中将接受测试或将不接受测试的
些特性和功能。
如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施,则列出
所有这些假设。列出可能会影响测试设计、开发或实施的所有风险或意外事件。列出可能会
影响测试设计、开发或实施的所有约束。
③ 限制条件
a. 设备所用到的设备类型、数量和预定使用时间。
b. 软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件,
如测试驱动程序、测试监控程序、仿真程序、桩模块等。
c. 列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术水平
及有关的预备知识,包括一些特殊要求,如倒班操作和数据输入人员。
④ 参考文档
列出制作此测试计划所依据的文档,例如,需求规约、设计规约,概要或详细设计、业
务流程、数据流程等。列出要用到的参考资料。
(2)测试摘要
① 测试目标
② 资源和工具
a. 资源
项目使用的资源,及其主要职责、知识或技能。
b. 工具
列出测试所使用的测试工具或自主开发的测试软件,说明运用这些工具或开发软件测试
对象的何种特性。
③ 送测要求
④ 测试种类
(3)测试风险
(4)暂停标准和再启动要求
(5)测试任务和进度
列出要测试中的每一项测试内容,例如:
模块功能测试;
接口正确性测试;
数据文件存取的测试;
运行时间的测试;
设计约束和极限的测试等。
并针对每项测试内容给出测试条件,如:
所用到的设备、数量和预定使用时间;
给出对这项测试的进度安排,包括进行测试的日期和工作内容(如熟悉环境、培训、准
备输入数据等)。
(6)测试提交物
① 测试计划
② 测试用例
③ 缺陷记录
④ 测试总结

  • 23
    点赞
  • 258
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

轩辕椿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值