webtours测试专题计划专业资料.doc

网上订票系统
测试筹划

表1-5 测试筹划阐明表
总页数

正文

附录

生效日期： 1月 14日
编制：
审核：
批准：

表1-6修订历史记录
日期
版本
阐明
作者
/1/14
<x.x>
<详细信息>
<姓名>

目录
1.简介 12
1.1目 12
1.2背景 12
1.3范畴 12
1.4使用文档 12
2.测试需求 13
3.测试风险 14
4.测试方略 14
4.1测试类型 14
4.1.1数据和数据库完整性测试 14
4.1.2功能测试 15
4.1.3业务周期测试 16
4.1.4顾客界面测试 17
4.1.5性能评价 18
4.1.6负载测试 20
4.1.7强度测试 20
4.1.8容量测试 22
4.1.9安全性和访问控制测试 23
4.1.10故障转移和恢复测试 24
4.1.11配备测试 27
4.1.12安装测试 28
5.工具- 29
6资源 29
6.1人力资源 29
6.2系统资源 30
7.测试进度和里程碑 31
7.1项目测试进度 31
7.2测试里程碑 32
8.可交付工件 32

1.简介
1.1目
〈网上订票系统〉这一“测试筹划”文档目是：
（1） 提供一种对项目软件进行测试总体安排和进度筹划，拟定既有项目信息和应测试软件构件。
（2）标明推荐测试需求（高层次）。
（3）推荐可采用测试方略，并对这些方略加以阐明。
（4）拟定所需资源，并对测试工作量进行预计。
（5）列出测试项目可交付元素
1．2背景
本项目测试对象是HP LoadRunner软件自带Web Tours网上订票系统，这是一款基于ASP.NET平台网站。基于先进.NET Framework，默认支持SOL Server数据库，可扩展支持ACCESS、MySql等各种数据库。支持基于IE、Chrome、Firefox、Opera等浏览器。
Web Tours网站重要是提供方全世界顾客进行网上订票、查看订票信息、预订机票、修改预订机票功能支持。
1．3范畴
对Web Tours网站注册、登陆、订票、查询以及退票功能进行功能测试、性能测试和界面测试
1．4使用文档
下表列出了制定测试筹划所用文档，并标明了文档可用性：
表1-7 测试筹划使用文档列表
文档
（版本/日期）
已创立或可用
已被接受或已通过复审
作者或来源
备注
测试筹划模版
是
是
教师

2.测试需求
下面列出了那些已被拟定为测试对象项目（用例、功能性需求和非功能性需求）。此列表阐明了测试对象。在此处输入一种重要测试需求高层次列表。例如：
2.1．功能测试
注册、登陆、订票、查询以及退票功能
2.2．顾客界面测试
注册、登陆、订票、查询以及退票功能
2.3．性能测试
注册、登陆、订票、查询以及退票功能
3.测试风险
软件测试风险是不可避免、总是存在，因此对测试风险管理非常重要，必要竭力减少测试中所存在风险，最大限度地保证质量和满足客户需求。在测试工作中，重要风险有：
　　1．质量需求或产品特性理解不精确，导致测试范畴分析误差，成果某些地方始终测试不到或验证原则不对；
　　2．测试用例没有得到百分之百执行，如有些测试用例被故意或无意漏掉；
　　3．需求暂时/突然变化，导致设计修改和代码重写，测试时间不够；
　　4．质量原则不都是很清晰，如合用性测试，仁者见仁、智者见智；
　　5．测试用例设计不到位，忽视了某些边界条件、深层次逻辑、顾客场景等；
　　6．测试环境，普通不也许和实际运营环境完全一致，导致测试成果误差；
　　7．有些缺陷浮现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷诸多，被漏检缺陷也许性就大；
　　8．回归测试普通不运营所有测试用例，是有选取性执行，必然带来风险。
　　前面三种风险是可以避免，而四至七四种风险是不能避免，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本考虑，普通也是存在。
　　针对上述软件测试风险，有某些有效测试风险控制办法，如：
　　测试环境不对可以通过事先列出要检查所有条目，在测试环境设立好后，由其她人员按已列出条目逐条检查； 
　　有些测试风险也许带来后果非常严重，能否将它转化为其她某些不会引起严重后果低风险。如产品发布前夕，在某个不是很重要新功能上发现一种严重缺陷，如果修正这个缺陷，很有也许引起某个原有功能上缺陷。这时解决这个缺陷所带来风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险；
　　有些风险不可避免，就设法减少风险，如“程序中未发现缺陷”这种风险总是存在，咱们就要通过提高测试用例覆盖率（如达到99.9%）来减少这种风险； 
为了避免、转移或减少风险，事先要做好风险管理筹划和控制风险方略，并对风 险解决还要制定某些应急、有效解决方案。

4.测试方略
4.1功能测试
测试对象功能测试应当侧重于可以被直接追踪到用例或业务功能和业务规则所有测试需求。这些测试目的在于核算能否对的地接受、解决和检索数据以及业务规则与否正的确施。这种类型测试基于黑盒办法，即通过图形顾客界面 (GUI) 与应用程序交互并分析输出成果来验证应用
程序及其内部进程。如下列出是每个应用程序推荐测试办法概要：
表1-9 功能测试阐明表
测试目的：
保证测试对象功能正常，其中涉及导航、数据输入、解决和检索等。
办法：
运用有效和无效数据来执行各个用例、用例流或功能，以核算如下内容：
在使用有效数据时得到预期成果。
在使用无效数据时显示相应错误消息或警告消息。
各业务规则都得到了对的应用。
完毕原则：
所筹划测试已所有执行。
所发现缺陷已所有解决。
需考虑特殊事项：
拟定或阐明那些将对功能测试实行和执行导致影响事项或因素（内部或外部）
4.2顾客界面测试
通过顾客界面 (UI) 测试来核算顾客与软件交互。UI 测试目的在于保证顾客界面向顾客提供了恰当访问和浏览测试对象功能操作。除此之外，UI 测试还要保证 UI 功能内部对象符合
预期规定，并遵循公司或行业原则。

表1-11 顾客界面测试阐明表
测试目的：
核算如下内容：
通过浏览测试对象可对的反映业务功能和需求，这种浏览涉及 窗口与窗口之间、字段与字段之间浏览，以及各种访问办法 （Tab 健、鼠标移动和快捷键）使用
窗口对象和特性（例如：菜单、大小、位置、状态和中心）都符合原则。
办法：
为每个窗口创立或修改测试，以核算各个应用程序窗口和对象都可对的地进行浏览，并处在正常对象状态。
完毕原则：
证明各个窗口都与基准版本保持一致，或符合可接受原则
需考虑特殊事项：
并不是所有定制或第三方对象特性都可访问。
4.3性能评价
性能评价是一种性能测试，它对响应时间、事务解决速率和其她与时间有关需求进行评测和评估。性能评价目的是核算性能需求与否都已满足。实行和执行性能评价目是将测试对象
性能为当作条件（例如工作量或硬件配备）一种函数来进行评价和微调。
注：如下事务均指“逻辑业务事务”。这种事务被定义为将由系统某个主角通过使用测试对象来执行特定用例，例如，添加或修改某个合同。
表1-12性能测试阐明表
测试目的：
核算所指定事务或业务功能在如下状况下性能行为：
正常预期工作量
预期最繁重工作量
办法：
使用为功能或业务周期测试制定测试过程。
通过修改数据文献来增长事务数量，或通过修改脚本来增长每项事务迭代次数。
脚本应当在一台计算机上运营（最佳是以单个顾客、单个事务为基准），并在多台客户机（虚拟或实际客户机，请参见下面“需考虑特殊事项”）上重复。
完毕原则：
单个事务或单个顾客：在每个事务所预期或规定期间范畴内 成功地完毕测试脚本，没有发生任何故障。
各种事务或各种顾客：在可接受时间范畴内成功地完毕测试 脚本，没有发生任何故障。
需考虑特殊事项：
综合性能测试还涉及在服务器上添加后台工作量。
可采用各种办法来执行此操作，其中涉及：
直接将“事务强行分派到”服务器上，这普通以“构造化查询语 言”(SQL) 调用形式来实现。
通过创立“虚拟”顾客负载来模仿许各种（普通为数百个）客 户机。 此负载可通过“远程终端仿真”(Remote Terminal Emulation) 工具来实现。 此技术还可用于在网络中加载“流 量”。
使用多台实际客户机（每台客户机都运营测试脚本）在系统上添 加负载。
性能测试应当在专用计算机上或在专用机时内执行，以便实现完全控制和精准评测。
性能测试所用数据库应当是与实际大小相似或等比例缩放数据库。]
5.工具
自动化性能测试工具：LoadRunner-11
6.资源
本节列出推荐 <网上订票系统> 项目使用资源，及其重要职责、知识或技能。
6.1人力资源
下表列出了在此项目人员配备方面所作各种假定。注：可视状况删除或添加项目。
表1-20人力资源阐明表
人力资源
角色
推荐至少资源

详细职责或注释
测试组长，

1人
负责拟定软件项目测试筹划和方案，提供测试技术指引，组织测试资源，安排测试筹划实行，提交测试分析报告，总结整个测试活动。
测试设计员

3人
参加制定测试筹划，生成测试模型，在面向对象设计系统中拟定并定义测试类操作、属性和关联关系，拟定测试用例，指引测试实行，参加测试评估和测试分析报告编写。
测试员
3人
执行实行测试，填写测试记录，记录成果和缺陷。
6.2系统资源
下表列出了测试项目所需系统资源。
此时并不完全理解测试系统详细元素。建议让系统模仿生产环境，并在恰当状况下减小访问量和数据库大小。
表1-21系统资源阐明表
系统资源
资源
名称/类型
数据库服务器

网络或子网

—服务器名服务器名

—数据库名

客户端测试 PC

—涉及特殊配备需求

测试存储库

—网络或子网

—服务器名服务器名

测试开发 PC

7.测试进度和里程碑
7.1项目测试进度
如下测试工作任务起止时间为：
（1）制定测试筹划 1.12-1.14
- 拟定测试需求
- 评估风险
- 制定测试方略
- 拟定测试资源
- 创立时间表
- 生成测试筹划
（2）设计测试 1.15-1.16
- 准备测试筹划阐明书
- 拟定并阐明测试用例
- 复审和评估测试覆盖
（3）实行测试 1.18-1.20
- 单元测试阶段
- 集成测试阶段
- 系统测试阶段
- 提交测试分析报告
（4） 测试活动总结 1.21
7.2测试里程碑
对 <网上订票系统> 测试应涉及上面各节所述各项测试测试活动。应当为这些测试拟定单独
项目里程碑，以告知项目状态和成果。
表1-22测试里程碑阐明表
里程碑任务
工作量
开始日期
结束日期
制定测试筹划
10学时
1.12
1.14
设计测试
10学时
1.15
1.16
实行测试
20学时
1.18
1.20
评估测试
4学时
1.21
1.21
8.可交付工件
这某些内容列出了将要创立各种文档、工具和报告，及其创立人员、交付对象和交付时间。如：测试筹划阐明书、测试用例或测试脚本、开发测试工具、测试日记、缺陷报告、测试分析报告、测试总结等。
8.1概述
（1）测试目
提供一种对项目软件进行测试总体安排和进度筹划，拟定既有项目信息和应测试软件构件标明推荐测试需求（高层次）推荐可采用测试方略，并对这些方略加以阐明拟定所需资源，并对测试工作量进行预计，列出测试项目可交付元素。
（2）测试范畴
描述测试各个阶段，例如：单元测试、集成测试或系统测试，并阐明本筹划所针对测试类型（如功能测试或性能测试）。简要地列出测试对象中将接受测试或将不接受测试那些特性和功能。
如果在编写此文档过程中作出某些假设也许会影响测试设计、开发或实行，则列出所有这些假设。列出也许会影响测试设计、开发或实行所有风险或意外事件。列出也许会影响测试设计、开发或实行所有约束。
（3）限制条件
a.设备所用到设备类型、数量和预定使用时间；
b.软件列出将被用来支持本项测试过程而自身又并不是被测软件构成某些软件，如测试驱动程序、测试监控程序、仿真程序、桩模块等等；
c.人员列出在测试工作期间预期可由顾客和开发任务组提供工作人员人数。技术水平及关于预备知识，涉及某些特殊规定，如倒班操作和数据键入人员。
（4）参照文档
列出制作此测试筹划所根据文档，如：需求规约、设计规约，概要或详细设计、业务流程、数据流程等。列出要用到参照资料，如：
8.2测试摘要
（1）测试目的
（2）资源和工具
a.资源
项目使用资源，及其重要职责、知识或技能。
b.工具
列出测试所使用测试工具或自主开发测试软件，阐明运用这些工具或开发软件测试对象何种特性。
列出测试所使用测试工具或自主开发测试软件，阐明运用这些工具或开发软件测试对象何种特性。
(4)送测规定
(5)测试种类
8.3测试风险
8.4暂停原则和再启动规定
8.5测试任务和进度
列出要测试中每一项测试内容，例如：
模块功能测试；
接口对的性测试；
数据文献存取测试；
运营时间测试；
设计约束和极限测试等。
并针对每项测试内容给出测试条件，如：
所用到设备、数量和预定使用时间；
给出对这项测试进度安排，涉及进行测试日期和工作内容（如熟悉环境。培训、准备输入数据等）。
8.6测试提交物
(1)测试筹划
(2)测试用例
(3)测试报告