无线电台视频传输测试报告
西安新东源电气有限公司
20##-1-27
目录
1.前言... 2
1.1 目的... 2
1.2 测试计划... 3
1.3 参考资料... 4
2. 测试资源消耗... 4
3. 测试过程分析... 4
3.1 测试环境... 4
3.1.1 服务器端... 4
3.1.2 客户端... 4
3.2 测试类型... 5
3.2.1 集成测试... 5
3.2.2 回归测试:... 5
3.3 测试方法及测试用例... 5
3.3.1 奥鹏题库管理系统项目测试方法... 5
3.3.2 功能测试:... 5
3.3.3 安全性和访问控制测试:... 6
3.3.4 流程测试... 7
3.3.5 数据测试... 8
3.4 测试阶段问题分析... 8
3.4.1 回归测试... 8
3.4.2 编写用列... 8
3.4.3 编写需求距阵... 8
3.4.4 人员问题;... 9
3.4.5 测试版本问题... 9
4. 缺陷分布状况... 9
4.1 缺陷定义... 9
4.2 缺陷分析... 10
5. 测试总评价... 10
1.前言
1.1 目的
本测试报告是初始阶段报告,目的在于总结无线电台视频传输测试结果及分析测试结果,描述系统是否符合需求。
1.2 测试计划
原定计划对无线电台视频传输进行以下测试,详细请查看附件测试计划。
1.功能测试
测试对象的功能测试,侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目的在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒方法,即通过图形用户界面 (GUI) 与应用程序交互并分析输出结果来验证应用程序及其内部进程。
2.数据和数据库完整性测试
数据库和数据库进程作为一个子系统来进行测试。在将测试对象的用户界面用作数据的接口的同时,还将考虑对数据库管理系统(DBMS)进行相关的测试
3.接口测试
由于XX其它系统协同工作,所以系统在实际工作中会协作其它系统,同时系统内部功能模块的调用
4.安全性和访问控制测试
由于Xx主要用于XX,对于安全性要求较高。对于整个系统,需要完整的权限控制,防止某些人恶意的攻击系统,修改原始记录。同时对于数据库中的数据需要定时备份,防止系统数据丢失。此外,系统要求用户在登陆时需要身份验证,严格区分每个角色的使用权限, 安全性的访问控制测试主要集中在对用户权限管理测试模块中。
5.故障转移和恢复测试
出现故障时及时完成系统恢复,并方便地找到产生故障的原因和位置,进行局部修改。具有对于系统数据丢失的补救措施,保证系统的安全性,可靠性。 此项测试主要集中在数据备份\恢复功能模块中。
6.性能测试
采用测试工具LoadRunner进行测试,测试包括:负载测试、强度测试和稳定性测试。找出系统瓶颈,并进行优化,但系统能达到,要求XX个用户并发情况下,响应时间小于等于XX秒。系统支持最高XX个并发,在XXM带宽下,支持XX左右用户的同时访问。
7.系统部署测试
系统开发测试完毕后,进行系统部署测试,确保系统的正常运行
1.3 参考资料
2. 测试资源消耗
3. 测试过程分析
3.1 测试环境
3.1.1 服务器端
软件:
服务器操作系统:
Web发布容器:
数据库平台:
硬件:
3.1.2 客户端
软件:
服务器操作系统:
IE :
硬件:
附件:测试环境说明
3.2 测试类型
被测系统主要测试类型
3.2.1 无线电台视频传输测试
无线电台视频传输项目测试过程中分二阶段完成,第一阶段进行利用大天线5公里测试;第二阶段进行小天线3公里测试。
3.2.2 回归测试:
3.3 测试方法及测试用例
3.3.1 无线电台视频传输项目测试方法
功能测试方面,无线电台视频传输项目集成测试阶段主要采用黑盒和灰盒测试的方法;对于页面控制采用黑盒测试的方法;对于数据正确性采用灰盒测试的方法,业务流程方面,几个模块来进行测试。
3.3.2 功能测试:
主要采用黑盒测试方面,对无线电台视频传输的功能和界面进行测试。功能测试用例,分模块来编写,测试用例无线电台视频传输条; 并执行,对测试结果进行记录提交BUG
测试统计表
附附件:执行功能测试用例明细
附件:执行情况统计表
3.3.3 安全性和访问控制测试:
主要采用黑盒测试方法,对XX用户权限进行测试,以不同的角色和权限进行登录对不同功能进行查看,测试主要是编写不同的场景,再根据场景设计进行测试,总共完成场景设计XX个场景并执行,对测试结果进行记录提交BUG
权限用列表
附件: 执行权限用例明细
3.3.4 流程测试
主要采用黑盒测试方法,对《奥鹏题库管理系统》流程进行测试,以不同的流程进行编写不同的场景,再根据场景设计进行测试,总共完成场景设计1360个场景并执行,对测试结果进行记录提交BUG
关联用例执行明细表
附件: 关联用例执行明细表
3.3.5 数据测试
主要采用黑盒和灰盒测试方法,对XX数据进行测试,以录入不同的试题,生成不同的试卷进行设计场景,再根据场景设计进行测试,总共完成场景设计XX个场景并执行,对测试结果进行记录提交BUG
数据测试明细表
附件:数据测试明细表
3.4 测试阶段问题分析
3.4.1 回归测试
由于XX开发完毕,并采用升级方式进行,由于升级新版本还没开发完,因此测试过程所提交的BUG没有进行回归测试:
3.4.2 编写用列
在对功能测试用例编写过程中,对用例编写时用例错误和描述不清,导致重新编写
3.4.3 编写需求距阵
由于需求和现有的系统有太大差异,直接采用现有的系统导致原需求距阵不可用,并二次参照实际系统进行矩阵编写。由于参照系统未测试中版本、二次编写的矩阵未经用户确认。导致矩阵可用性下降
3.4.4 人员问题;
测试过程中和测试人员之间对于测试点产生了分歧,使工作不能顺利完成
3.4.5 测试版本问题
在客户提交的测试版本不明确,进行测试,导致测试效率降低
4. 缺陷分布状况
4.1 缺陷定义
1级—严重错误,包括以下各种错误:
? 由于程序所引起的死机,非法退出;
? 死循环;
? 数据库发生死锁;
? 因错误操作导致的程序中断;
? 功能错误;
? 与数据库连接错误;
? 数据通讯错误;
? 页面出现黄页;
? 业务流程;
? 程序错误;
? 程序接口错误;
? 数据库的表、业务规则、缺省值未加完整性等约束条件;
2级一般性错误,包括以下各种错误:
? 操作界面错误(包括数据窗口内列名定义、含义是否一致);
? 打印内容、格式错误;
? 简单的输入限制未放在前台进行控制;
? 删除操作未给出提示;
? 数据库表中有过多的空字段;
3级—较小错误,包括以下各种错误:
? 界面不规范;
? 辅助说明描述不清楚;
? 输入输出不规范;
? 长操作未给用户提示;
? 提示窗口文字未采用行业术语;
? 可输入区域和只读区域没有明显的区分标志;
? 测试建议;
? 缺陷汇总
4.2 缺陷分析
对于缺陷的分析:
5. 测试总评价
第二篇:软件测试计划参考模板
软件测试计划模板
分类: 软件测试基础 20##-07-03 11:46 9751人阅读 评论(5) 收藏 举报
第1章引言
1.1目的
简述本计划的目的,旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。
测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外,清晰的文档结构能使任何一个读者在浏览计划的前面几页后,就能对项目有一个大概的认识。测试计划只是测试的一个框架,很多细节需要跟开发人员或其他人员沟通,因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。
1.2名词解释
列出本计划中使用的专用术语及其定义
列出本计划中使用的全部缩略语全称及其定义
1.3参考资料
列出本计划各处参考的经过核准的全部文档和主要文献。
1.4测试摘要
这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员(比如经理或开发项目的负责人)。
1.4.1 重点事项
列出测试的重点事项。可以将问题按重要程度和优先级罗列出来,然后在后面的章节中再对这些问题进行详细说明,这样就能让对这些问题有重要影响的人员知道问题的所在
1.4.2 争议事项
简要说明争议事项。
1.4.3 风险评估
通过对技术文档的阅读,对被测系统可能存在的问题:系统设计,数据库设计,响应时间,计费策略,因测试环境不足可能存在的测试缺陷事先评估出来,以指导测试方案,进行有重点的测试.
1.4.4 时间进度
简要说明测试开始时间与发布时间。
1.4.5 测试目标
简要说明测试发布的质量目标:
测试计划中所有测试方法和模块已经执行通过
所有的测试案例已经执行过
所有的重要等级为1/2的Bug已经解决并由测试验证
第2章项目背景
2.1测试范围
说明本计划涵盖的测试范围,比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的,什么是不要测试的是非常重要的。明确规定这些问题后,测试人员对该做什么有一个清晰的认识。
(1)简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
(2)如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施,则列出所有这些假设。
(3)列出可能会影响测试设计、开发或实施的所有风险或意外事件。
(4)列出可能会影响测试设计、开发或实施的所有约束。
提示和技巧:
需要测试和特别注意测试那些部分?
测试是否专么针对与某些问题的解决?
哪些部分不需要测试,为什么?
哪些部分需要推迟测试,为什么?
是否要验证每个模块的稳定性?
测试的优先级和先后顺序
2.2测试目标
系统目标对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通,以取得相关资料。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后,要确保所有的测试人员都知道项目和系统的目标。
通常情况下项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标,你将无法完成部分任务。而且,你会发现很难将对产品的认识向别人转述。
2.3联系方式
列出项目参与人员的职务、姓名、E-mail 和电话。
2.4风险及约束
列出测试过程中可能存在的一些风险和制约因素,并给出规避方案。如:
Ä由于客观存在的设备、网络等资源原因,使得测试不全面。明确说明哪些资源欠缺,产生什么约束
Ä由于研发模式为现场定制,且上线时间压力大,使得测试不充分。明确说明在此中约束下,测试如何应对
Ä只针对专门的客户群需求的测试。明确说明此约束下的客户群和业务范围。
2.5测试文档
列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置,测试完成后应产生的文档。
2.5.1测试参考文档
2.5.2测试提交文档
第3章质量目标
描述本阶段测试目标和要求。质量目标应该包括产品的质量目标和测试小组的质量目标。
质量不仅是衡量系统的功能或性能是否正常。对系统来说,在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具,应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如,系统是否能够正式发行?在代码完成后,应该修复那些缺陷?在系统完成后那种类型的测试是最合适的?
3.1产品质量目标
可以是产品的质量达到什么样的目标,产品的流程联通性达到什么样的要求。
3.2测试质量目标
评价测试质量的目标可以有:
第4章资源需求
4.1培训资料
4.2测试环境
4.2.1硬件测试环境
描述建立测试环境所需要的设备、用途及软件部署计划。
“机型(配置)”:此处说明所需设备的机型要求以及内存、CPU、硬盘大小的最低要求。
“用途及特殊说明”:此设备的用途,如数据库服务器,web服务器,后台开发等;如有特殊约束,如开放外部端口,封闭某端口,进行性能测试等,也写在此列;
“软件及版本”:详细说明每台设备上部署的自开发和第三方软件的名称和版本号,以便系统管理员按照此计划分配测试资源;
“预计空间”:说明第三方软件和应用程序的预计空间;
“环境约束说明”:建立此环境时的特殊约束。如需要开发外部访问端口,需要进行性能测试等。
4.2.2软件测试环境
4.3测试工具
此项目将列出测试使用的工具以及用途:
第5章测试策略
5.1 整体测试策略
本节的目的是说明计划中使用的基本的测试过程。
使用里程碑技术在测试过程中验证每个模块,测试人员在需求阶段参与测试工作,进行需求review、设计review、测试案例设计和测试开发,在系统开发完成之后,正式执行测试。产品达到软件产品质量要求和测试要求后发布,并提交相关的测试文档。
5.2开始/中断/完成标准
说明中断/开始/完成测试的标准。
5.3测试类型
5.4 测试技术
第6章测试计划
6.1进度计划
在此章节,对各阶段的测试给出里程碑计划,包括阶段、里程碑、资源等。
6.1.1测试时间进度
6.1.2测试里程碑
6.2测试准备
6.2.1 测试环境准备
6.2.2 安装测试
6.2.3 烟雾测试
6.3 具体测试实施任务和时间人员安排