测试计划Test Plan范例.docx
《测试计划Test Plan范例.docx》由会员分享,可在线阅读,更多相关《测试计划Test Plan范例.docx(14页珍藏版)》请在冰豆网上搜索。
测试计划TestPlan范例
大学图书管理系统
测试计划
版本历史
版本/状态
修订人
起止日期
审核人
简要说明
V1.0
王莉
2009-8-27
建立
V1.1
王莉
2009-9-15
盛安平
修订
1.简介
该测试计划介绍了如何测试大学图书管理系统。
它提供了测试范围、测试策略,人员安排等详细信息。
1.1目的
这份文档的目标是详细描述对“大学图书管理系统”进行功能测试的过程。
本文档所关注的特征来自于软件设计规格说明书。
(关于大学图书管理系统的功能描述,请参阅软件设计规格说明书。
)
1.2背景
为了提高从事图书管理工作的管理员的工作效率,开发了大学图书管理系统。
这个系统能满足用户Login/Logout。
具有管理员账户权限的管理员可以执行添加、管理图书主要功能:
完成新图书的添加、查询、维护,借阅登记、借阅维护等功能,能按图书编号、名称、出版社进行模糊查询,能记录每本图书的借阅情况等。
操作简单、界面友好;确保信息的准确性,动态性,安全性。
大学图书管理系统是基于ASP.NET的技术,客户端的要求也很低。
1.3范围
测试阶段包括单元测试,集成测试,系统测试,性能测试,验收测试及对测试进行评估。
本计划所提到的测试类型是需求阶段的测试,即对大学图书管理系统进行功能验证的测试过程。
1.3.1准备测试的特征
以下特征将被测试,以确保“大学图书管理系统”能满足规定的需求:
1)用户Login、Logout
●用户Login、Logout
✧Login
✧Logout
●管理员的权限
✧管理员的权限:
添加,删除,修改,查询
2)图书信息的添加,删除,修改
●图书的添加,删除,修改
✧添加新的图书信息
✧删除已经添加的图书信息
✧修改已经添加的图书信息
●图书借阅情况的添加、修改
✧添加新的图书借阅情况
✧修改已经添加的图书借阅状态
✧修改已经添加的图书借阅信息
4)图书的查询
●图书编号、名称、出版社的查询
✧图书编号的查询,编号唯一的
✧图书名称的查询
✧图书作者的查询
表5-3-1测试列表和测试范围
新功能
相关模块
回归测试范围
测试人员
登录系统(login)
N/A(new)
N/A
图书管理首页
N/A(new)
N/A
图书添加
N/A(new)
N/A
图书查询
N/A(new)
N/A
图书维护
N/A(new)
N/A
借阅登记
N/A(new)
N/A
借阅维护
N/A(new)
N/A
登出系统(logout)
N/A(new)
N/A
1.3.2不准备测试的特征
以下功能和系统配置时不需要测试的:
1)本次测试将不考虑关系数据库(MySQL)的安装和功能。
假定数据库已安装并处于可操作的状态假定数据库表结构是准确的,包含需求规格说明书中定义的规定类型和字段的宽度。
这些需求在准备和安装文档中有详细说明。
2.测试参考文档和测试提交文档
2.1测试参考文档
●大学图书管理系统产品需求文挡
●大学图书管理系统软件设计规格说明书
2.2测试提交文档
本次测试完成后的提交文档包括:
●测试计划
●测试规格说明文档
●测试用例设计文挡
●测试Bug列表
●测试小结
●测试分析报告
3.测试进度
表5-3-2测试进度安排表
测试活动
计划开始日期
实际开始日期
结束日期
制定测试计划
单元测试30天
集成测试15天
系统测试8天
性能测试2天
用户验收测试5天
对测试进行评估1天
产品发布
4.测试资源
4.1人力资源
下表列出了在此项目的人员配备方面所作的各种假定。
注:
可适当地删除或添加角色项。
表5-3-3人力资源安排表
角色
所推荐的最少资源(所分配的专职角色数量)
具体职责或注释
测试设计人员
2-3
制定和维护测试计划,设计测试用例及测试过程,生成测试分析报告
测试人员
3-4
执行集成测试和系统测试,记录测试结果
设计人员
1
设计测试需要的驱动程序和稳定桩
编码人员
2-3
编写测试驱动程序和稳定桩,执行单元测试
4.2测试环境
下表列出了测试的系统环境
表5-3-4测试环境综合表
软件环境(相关软件、操作系统等)
操作系统:
Windows2000/XP以上版本;
应用服务器和Web服务器:
IIS5以上
数据库系统:
MySQL
客户端软件:
MSInternetExplorer或Firefox等浏览器和office软件。
硬件环境(网络、设备等)
对兼做应用服务器、Web服务器和数据库服务器的机器配置要求较高:
256M以上内存,PIII500MHz以上CPU,10G以上可用硬盘空间;
客户机只要能使用浏览器和Office软件即可。
网络条件和设备:
网路连接卡或调制解调器。
4.3测试工具
此项目将列出测试使用的工具:
表5-3-5测试工具列表
用途
工具
生产厂商/自产
版本
性能测试工具
AQTime
AutomatedQA
6.2
功能测试工具
Selinum
开源组织
1.0
5.系统风险
可能出现的风险如下:
●bug的修复情况
●模块功能的实现情况
●系统整体功能的实现情况
●代码的编写质量
●人员经验以及对软件的熟悉度
●开发人员、测试人员关于项目约定的执行情况
●人员调整导致研发周期延迟
●开发时间的缩短导致某些测试计划无法执行
6.测试策略
测试策略提供了对测试对象进行测试的推荐方法。
下面列出了本系统测试的各个阶段可能用到的测试方法。
测试案例流程图:
如图5-6-1所示。
图5-6-1图书管理系统功能图
6.1接口测试
表5-3-6接口测试
测试目标
确保接口调用的正确性
测试范围:
所有软件、硬件接口,记录输入输出数据
技术:
开始标准:
完成标准:
测试重点和优先级:
需考虑的特殊事项:
接口的限制条件
6.2集成测试
集成测试主要目的是检测系统是否达到设计需求,对业务流程及数据流的处理是否符合标准,检测系统对业务流程处理是否存在逻辑不严谨及错误,检测需求是否存在不合理的标准及要求。
此阶段测试是基于功能完成的测试。
表5-3-7集成测试
测试目标
检测需求中业务流程,数据流的正确性
测试范围
需求中明确的业务流程,或组合不同功能模块而形成一个大的功能。
技术
利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
开始标准
在完成某个集成测试时必须达到标准
完成标准
所计划的测试已全部执行。
所发现的缺陷已全部解决。
测试重点和优先级
测试重点指在测试过程中需着重测试的地方,优先级可以根据需求及严重来定
需考虑的特殊事项
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)
6.3功能测试
对测试对象的功能测试应侧重于所有可直接追踪到业务功能和业务规则的测试需求。
此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。
以下为各种应用程序列出了推荐使用的测试概要:
表5-3-8功能测试
测试目标
确保测试的功能正常,其中包括导航,数据输入,处理和检索等功能。
测试范围
需求说明书中要求的各项功能
技术
利用有效的和无效的数据来执行各个用例,以核实以下内容:
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
开始标准
完成标准
测试重点和优先级
需考虑的特殊事项
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)
6.4用户界面测试
用MSInternetExplorer和Firefox对图形用户界面进行测试。
要求在两种浏览器上对所将使有功能进行测试。
表5-3-9界面测试
测试目标
通过测试进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab键、鼠标移动、和快捷键)的使用。
窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准。
测试范围
技术
为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。
开始标准
完成标准
成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准
测试重点和优先级
需考虑的特殊事项
6.5性能评测
性能评测是一种性能测试,它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。
性能评测的目标是核实性能需求是否都已满足。
表5-3-10性能测试
测试目标
核实所指定的事务或业务功能在以下情况下的性能行为:
正常的预期工作量
预期的最繁重工作量
测试范围
技术
使用为功能或业务周期测试制定的测试过程。
通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代数量。
脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多个客户机(虚拟的或实际的客户机,请参见下面的“需要考虑的特殊事项”)上重复。
开始标准
完成标准
单个事务或单个用户:
在每个事务所预期时间范围内成功地完成测试脚本,没有发生任何故障。
多个事务或多个用户:
在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。
测试重点和优先级
需考虑的特殊事项
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作,其中包括:
性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。
性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。
6.6容量测试
容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
本系统需要为生成一份报表而处理一组数据库记录,那么容量测试就需要使用一个大型的测试数据库。
检验该软件是否正常运行并生成了正确的报表。
表5-3-11容量测试
测试目标
核实测试对象在以下高容量条件下能否正常运行:
连接或模拟了最大(实际或实际允许)数量的客户机,所有客户机在长时间内执行相同的、且情况(性能)最坏的业务功能。
已达到最大的数据库大小(实际的或按比例缩放的),而且同时执行多个查询或报表事务。
测试范围
技术
使用为性能评测或负载测试制定的测试。
应该使用多台客户机来运行相同的测试或互补的测试,以便在长时间内产生最繁重的事务量或最差的事务组合(创建最大的数据库大小(实际的、按比例缩放的、或填充了代表性数据的数据库),并使用多台客户机在长时间内同时运行查询和报表事务。
开始标准
完成标准
所计划的测试已全部执行,而且达到或超出指定的系统限制时没有出现任何软件故障。
测试重点和优先级
需考虑的特殊事项
对于上述的高容量条件,哪个时间段是可以接受的时间?
6.7安全性测试
侧重于安全性的两个关键方面:
应用程序级别的安全性,包括对数据或业务功能的访问。
系统级别的安全性,包括对系统的登录。
应用程序级别的安全性可确保:
在预期的安全性情况下,用户只能访问特定的功能模块。
系统级别的安全性可确保:
只有具备系统访问权限的用户才能访问应用程序。
表5-3-12安全测试
测试目标
应用程序级别的安全性:
核实用户只能访问其所属用户类型已被授权访问的那些功能或数据。
系统级别的安全性:
核实只有具备系统和应用程序访问权限的用户才能访问系统和应用程序。
测试范围
技术
应用程序级别的安全性:
确定并列出各用户类型及其被授权访问的功能或数据。
为各用户类型创建测试,并通过创建各用户类型所特有的事务来核实其权限。
修改用户类型并为相同的用户重新运行测试。
对于每种用户类型,确保正确地提供或拒绝了这些附加的功能或数据。
系统级别的访问:
请参见以下的“需考虑的特殊事项”。
开始标准
完成标准
各种已知的用户类型都可访问相应的功能或数据,而且所有事务都按照预期的方式运行,并在先前的应用程序功能测试中运行了所有的事务。
测试重点和优先级
需考虑的特殊事项
需与相应的网络或系统管理员一起对系统访问权进行检查和讨论。
7.问题跟踪
和规格说明书上定义不一致的,或者不符合常规的地方都属于bug,应该提交给相关人员进行修订。
8.计划文档审阅
这个计划文档需要被下列人员审阅并给出确认意见。
[PM/EM]:
xxx
[DEVowner]:
xxx
[QAowner]:
xxx