在线视频播放系统测试计划清单书Word格式.docx
《在线视频播放系统测试计划清单书Word格式.docx》由会员分享，可在线阅读，更多相关《在线视频播放系统测试计划清单书Word格式.docx（12页珍藏版）》请在冰点文库上搜索。
测试完成标准应以软件可以长久保持用户在线，并在播放过程中一直保持不出现较长时机卡顿，可以进行暂停播放功能为基准。
由于是初次测试，工作量应当相对较多，对代码的结构等都需要进行调整，工作量相对较高。
1.2范围
本次测试主要采用黑盒测试的方法，主要针对于本系统的功能测试模块，对于性能测试，负载测试，安全测试等其他方面的测试会根据时间和进度给予相应的测试。
2.测试参考文档和测试提交文档
2.1测试参考文档
文档
（版本/日期）
已创建或可用
已被接收或已经过复审
作者或来源
备注
可行性分析报告
是□ 否□
软件需求定义
软件系统分析
（STD,DFD,CFD,DD）
软件概要设计
软件详细设计
软件测试需求
硬件可行性分析报告
硬件需求定义
硬件概要设计
硬件原理图设计
硬件结构设计（包含PCB）
FPGA设计
硬件测试需求
PCB设计
USB驱动设计
TunerBSP设计
MCU设计
模块开发手册
测试时间表及人员安排
测试计划
测试方案
测试报告
测试分析报告
用户操作手册
安装指南
2.2测试提交文档
《在线视频播放系统测试计划书》（即本计划书）以及相关测试软件管理工具生成的测试文档。
3.测试进度
测试活动
计划开始日期
实际开始日期
结束日期
制定测试计划
设计测试
集成测试
系统测试
性能测试
安装测试
用户验收测试
对测试进行评估
产品发布
4.测试资源
4.1人力资源
角色
所推荐的最少资源（所分配的专职角色数量）
具体职责或注释
编写人
1
编写该计划书
资料收集人
收集该计划书需要用到的资料
4.2测试环境
软件环境
本系统是在WindowsXP和Windows7的环境下，使用自动化测试工具，用黑盒的测试方法手动进行测试的
Web服务器/应用服务器：
Tomcat.7x
数据库系统：
MySQL5.1
客户端软件：
IE/火狐/谷歌
硬件环境
WindowsXP：
CPU2.8GHz内存：
2G
Windows7：
CPU1.8GHz内存：
Windows8：
CPU1.8GHz内存：
4.3测试工具
用途
工具
生产厂商/自产
5.测试风险，优先级
由于有人为的手工测试，所以若测试人员的经验不足，有可能会导致测试用例覆盖不够全面。
这个问题可能还刚刚接触项目的测试人员很大可能会碰到的问题，所以级别较高。
而且书写该文档的人如果对该系统了解的不够全面也是会造成测试计划不够完备。
另外服务器在部署时，也应注意视频的格式是否会出现不兼容，以及浏览器类型和版本的问题，但这些问题不是很重要。
6.测试策略
6.1数据和数据库的完整性测试
测试目标：
确保数据库安装成功，访问过程不出现错误，查询，添加，修改等数据库操作能正常运行，数据不会遭到损坏
测试范围：
技术：
调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据（或对数据的请求）。
检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件已正常发生；
或者检查所返回的数据，确保正当的理由检索到了正确的数据
开始标准：
完成标准：
数据库成功安装，数据库的操作正常，数据不会遭到损坏
测试重点和优先级：
数据库的安装以及对数据库的操作能正常，由于数据到直接影响到几乎所有操作的进行，所以其优先级为高
需考虑的特殊事项：
应使用小型或最小的数据库（记录的数量有限）来使所有无法接受的事件具有更大的可视度。
6.2接口测试
测试目标
6.3集成测试
检测需求中业务流程，数据流的正确性
需求中明确的业务流程，或组合不同功能模块而形成一个大的功能。
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
在完成某个集成测试时必须达到标准
所计划的测试已全部执行。
所发现的缺陷已全部解决。
测试过程中需着重测试用户的登陆和视频的播放，这也是本系统的主要业务，优先级为高
在视频播放测试过程中应注意，视频的进度条调整后，视频是否还能正常播放。
6.4功能测试
确保测试的功能正常，用户可以正常登陆，视频的上传和播放能够正常实现。
利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：
所有功能都能正常使用并不会出错或者产生异常
优先级高
对用户的信息加以验证，必要的时候需要显示验证码，以防止用户信息泄露。
6.5用户界面测试
核实以下内容：
通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用
窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。
界面的各自组建和它们的事件反应
为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。
成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准
并不是所有定制或第三方对象的特征都可访问。
6.6性能测试
核实所指定的事务或业务功能在以下情况下的性能行为：
正常的预期工作量
预期的最繁重工作量
使用为功能或业务周期测试制定的测试过程。
通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。
脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。
、
单个事务或单个用户：
在每个事务所预期时间范围内成功地完成测试脚本，没有发生任何故障。
多个事务或多个用户：
在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作，其中包括：
直接将“事务强行分配到”服务器上，这通常以“结构化语言”调用的形式来实现。
通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。
此负载可通过“远程终端仿真（RemoteTerminalEmulation）工具来实现。
此技术还可用于在网络中加载“流量”。
使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。
6.7负载测试
核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。
使用为功能或业务周期测试制定的测试。
通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务发生的次数。
在可接受的时间范围内成功地完成测试，没有发生任何故障。
负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
负载测试所用的数据库应该是实际大小或相同缩放比例的数据库
6.8强度测试
无
6.9容量测试
6.10安全性和访问控制测试
6.11故障转移恢复测试
6.12配置测试
6.13安装测试
7.严重问题描述
问题严重度
描述
响应时间
高
中
低
升级会员 