视频会议系统测试表
视频会议系统调试情况记录表
下载更多资料https://www.doczj.com/doc/ca14638312.html,/index.html 视频会议系统 技 术 方 案 二OO七年二月
目录 第1章方案设计 (1) 1.1 项目需求 (1) 1.2 设计依据 (2) 1.3 设计原则 (3) 1.4 系统组成 (5) 1.5 产品选型 (5) 1.6 系统方案 (6) 1.6.1 组网拓扑图 (6) 1.6.2 组网说明 (8) 第2章视频会议系统功能及应用 (9) 2.1 召开远程会议 (9) 2.2 召开分组会议 (10) 2.3 召开自助式会议 (10) 2.4 桌面会议 (10) 2.5 自动降速功能 (11) 2.6 断线重邀功能 (11) 2.7 双视频流 (12) 2.8 多方混音功能 (13) 2.9 多画面显示 (13) 2.10 系统多级级联 (14) 2.11 流媒体功能 (14) 2.12 管理功能 (15) 2.13 多点控制单元MCU功能 (15) 2.14 视频会议终端功能 (17) 第3章视频会议系统管理 (19) 3.1 网络管理 (19) 3.2 会议管理 (20) 第4章系统方案特点 (23) 4.1 先进性 (23) 4.2 兼容性 (23) 4.3 扩展性 (24) 4.4 安全性 (24) 4.5 可靠性 (24) 4.6 易用性 (25) 4.7 功能丰富性 (25) 第5章设备简介 (26) 5.1 多点控制单元KDV8000A (26) 5.2 高清视频会议终端KDV8010A (33) 5.3 桌面终端软件KDV-PCMT (40) 5.4 录像与点播软件KDV-VOS (43)
我一直感觉系统测试总像马拉松总是测试不完，什么时候上线，什么时候算终点。虽然提交客户了，可是对于质量仍然心里没底，对于测试的效果没有评价的依据。后来经过高人指点，终于领悟到至关重要的精髓：明确测试目标！ 如果要将系统进行全面测试，那么就要有一套完整的测试阶段，每个阶段都以测试目标为标准，科学、有序地进行测试，那么测试效率也就会自然而然跟着提高。 测试阶段分为：测试前准备、需求分析、测试计划、测试设计、测试执行、测试结果。 1.测试前准备阶段 主要是相关业务的学习。业务知识是测试的根本依据，只有业务过关了，以后才能有效的进行测试工作。 了解业务步骤： a、了解业务名词； b、对现有系统的学习：功能点、业务场景等； c、分析现有系统数据库，了解数据的走向。 2.需求分析阶段 需求是项目开发的基础，也是测试的依据。所以需求分析一定要做。但是很多公司是没有详细的需求文档的，那如何进行需求分析呢？ 此时分析数据库就是一个非常好的方法： a、每张表的索引和约束条件； b、数据的来源、走向； c、数据的存储、变化； d、数据间的关联； e、表与表间的关系； 这些分析都可以为了解业务场景和之后的测试用例设计打好基础。 3.测试计划阶段 我们总是觉得被测试进度紧逼、计划失控、测试不完全等等状态，其实解决这些情况的最好方法就是：制定测试目标。
在计划初期先明确测试目标，制定不同层次目标的执行标准，指导后期设计不同级别的测试用例，跟踪不同级别的缺陷修改。在测试时间较紧情况下，至少可以先把保证所有功能正常操作的最低目标版本先提交给客户，不会再有手忙脚乱，心里没底的状况。 测试目标分为： 最低目标 基本目标 较高目标 最高目标等级别 可以使用表格形式来规范目标准侧，例如： 测试目标准则表 目标 测试范围 需求覆盖率 最低目标：正常的输入+正常的处理过程，有一个正确的输出 （明确的功能点全部列出来） 1.功能： 正常功能 异常功能 单功能 业务场景 非功能：16种测试类型 2.输入覆盖率： 有效无效 处理过程：基本流 备选流
______轮ECS系统测试记录 【说明：操作时请参照《用户手册》；请在“结果”栏填写“正常”或“未测”二字，若发现异常情况，请简要说明。】
雷达叠加电子海图与雷达 叠加 确保AIS 和罗经运行正常，输入到计算机的数据端口打开成功。 按下图标“”，即进入雷达叠加状态，此时，电子海图的操 作全部失效。若要退出雷达叠加状态，再按下“”即可。海 图叠加时，操作雷达量程、雷达显示模式（正北或船艏向上）、 偏心显示等按钮，观察雷达图象和海图匹配情况。 单纯雷达界面按下图标“”，即进入单纯雷达界面。退出按鼠标右键即可。 海图改正手工改正操作“海图改正→手工改正”菜单，进入“海图改正”状态； 手工在当前海图上修改/删除/添加任何内容（包括符号、线、面、 文字、水深点等）； 退出“海图改正”状态，打开相应的海图，查看该海图改正结 果。 自动更新（部分 系统有该功能） 操作“海图改正→自动更新”菜单，进入“海图自动更新”状 态（具体内容参见海图改正测试说明相应部分）。 电子海图数据文 件导入 操作“海图改正→导入S57文件”菜单，通过相应的对话框指 定S-57文件所处的位置，选择海图文件并导入； 在导航系统中可显示新导入的海图。 AIS设置根据AIS设备的参数进行设置，将在导航功能的AIS/GPS信息获 取中获得本目标信息和其他目标信息。 导航功能AIS/GPS信息获 取 打开“开启监控”开关；查看本船动态信息栏的显示内容及其 随本船运动的变化情况；查看海图上本船及目标船的标绘及运 动情况；依次选中各目标船，查看其动/静态信息、避碰信息及 其变化情况。 其它传感器数据 获取 打开“开启监控”开关；查看从本船其它设备获得的数据；打 开“传感器数据显示”开关，查看各传感器的详细数据。 船舶动态信息存 储与显示 查看本船的动态信息，并通过“显示航迹”、“航海日志查看” 等操作查看已记录的本船动态信息。 船舶动态标绘打开“开启监控”开关；查看本船和目标船图形标绘及其移动/变化情况； 操作“设置”菜单，选择‘刷新频率与其他设置’，可设置矢量 长度，查看运动矢量长度的变化等。 本船居中显示处于船舶动态监视状态时，点击“本船居中”按钮；查看本船 位置及海图显示范围的变化；设置成“本船自动居中”模式， 查看当本船即将移出当前海图窗口时，本船位置及海图显示范 围的变化。 目标船跟踪及 CPA计算 选中任意一个目标船，查看目标动态信息及避碰信息； 设置CPA报警距离，使最近的目标产生报警信息，同时选中另 一个目标船，查看目标动态信息及避碰信息； 点击“显示CPA距离圈”按钮，查看与选定目标船的会遇势态。自动标绘设定船位标绘的时间间隔（必要时调整系统时钟），查看每隔设定的时间间隔（或每到整点）是否自动在海图上标绘船位及时 间。
软件测试过程模型 发布时间: 2010-7-27 11:02 作者: 未知来源: 51Testing软件测试网采编 字体: 小中大| 上一篇下一篇| 打印| 我要投稿| 每周一问，答贴有奖 目前主流的开发模型主要有：瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发(RAD)以及Rational统一过程(RUP)等，这些模型对于软件开发过程具有很好的指导作用，但是，非常遗憾的是，在这些过程方法中，并没有充分强调测试的价值，也没有给测试以足够的重视，利用这些模型无法更好地指导测试实践。软件测试是与软件开发紧密相关的一系列有计划的系统性的活动，显然软件测试也需要测试模型去指导实践。下面对主要的模型做一些简单的介绍。 V模型 V模型是最具有代表意义的测试模型。在传统的开发模型中，比如瀑布模型，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成后的一个阶段，尽管有时测试工作会占用整个项目周期的一半的时间，但是有人仍然认为测试只是一个收尾工作，而不是主要过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如模型图中所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。 V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。 V模型指出，单元和集成测试是验证程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满
视频会议系统项目可行性分析报告 1.项目实施必要性 1.1项目背景 随着集团公司业务的不断拓展，目前已形成半年度培训交流大会，集团部门周会，部门月总结和周例会等制度，同时在领导意见传达，部门协作沟通，项目交流分析，客户演示，新人培训等方面，也经常需要通过会议、电话、网络等形式进行沟通。从集团业务发展的角度出发，上线视频会议系统，可以为公司节约大量差旅成本，也可解决常规会议中受限于时间地点等不利因素，同时还能进行桌面或者文档共享，实现会场巡查。此外视频会议系统既可以满足正式严肃的群体会议交流需要，也可以随时随地解决多方的办公协作。 1.2现状及存在问题： 随着集团公司职能部门工作细化，现有的会议或其他沟通模式已不能满足我们的办公需求，不管从集团-项目沟通的时效性，还是领导-员工的逐级管理上都存在缺陷，同时在会议、培训、交流上也无法做到多方参与，现有面对面会议或电话沟通存在以下主要缺陷： 1.1.1.无法进行多方会议，只能以传统的电话方式进行两方沟通； 1.1. 2.没有视频支持，无法了解对方所处场地或办公情况，让领导缺乏对会议 情况或人员的掌控； 1.1.3.电话沟通为单一信号源，特别是对于项目部而言，缺乏其他补充沟通的 手段，会降低沟通效率； 1.1.4.无法录制会议，缺乏对会议情况的回放了解，传达会议精神的效果大打 折扣； 1.1.5.无法实时共享文档，如PPT、WORD无法直接展示，只能通过文件分发 等方式传达，办公演示或者培训交流的效果大幅降低； 1.1.6.随意分发文件，对会议的保密性存在一定的漏洞； 1.1.7.无法较好实现移动办公实时接入需求，特别是领导在出差工程中无法通 过较为简单的设置接入现有会议；
CHAPTE 1.设备测试文档 1.1测试目标 为了充分保证系统的稳定性和先进性和系统兼容性，因此要求整个系统的核心设备－MCU和终端必须为硬件体系结构DSP芯片支撑，采用嵌入式操作系统，非windows平台，任何产品不得含有PC标志性PCI插槽和CPU等部件。 H.323为目前国际是视频会议的标准、SIP为UC统一的通讯的标准，为了保证系统的可扩展与兼容性，要求系统参测设备都同时支持H.323和SIP协议。 1080P为本系统必要指标，目前国际上承认的数字高清接口只有HDMI 、HD-SDI、DVI三种接口。视频源和视频终端能达到1080P为必要条件，因此必须具有上述高清数字接口。 1080P摄像头视频源输出分辨率必须达到1080P标准。 1.2参测产品 参测产品包括并至少包括如下内容： 1)多点控制单元（MCU）1台； 2)系统管理平台 3)网闸注册服务器 4)1080P高清视频终端3台（含高清摄像头、编解码器、麦克风） 5)桌面1080P高清终端×2（一体化设备） 6)两台PC安装软件终端，同时作为双流视频源； 7)Ipad移动客户端作为移动终端接入 8)路由交换设备各厂家自己准备
1.3测试方式 由用户统一提供显示设备，同意提供网络环境与演示环境，参测产品厂家入场，按照测试环境要求，拆机和连通摄像头与显示设备。 此次测试重点为如下内容： ?MCU、终端完全硬件架构，嵌入式操作系统，无VGA接口、PCI、内存、CPU等典型PC部件存在； ?MCU与终端都可同时支持H.323与SIP协议，并支持采用此标准发起高清呼叫； ?网闸设备对于H.323和SIP协议的支持，切换H.323和SIP协议时是否简单，无需重启设备； ?网管平台对整个系统管理和控制的能力； ?视频会议终端和摄像机必须具备国际标准高清数字输入输出接口（Hdmi/HD-SDI/DVI）； ?高清摄像机连接显示设备能够直接显示1080P显示参数； ?不同产品终端显示直连显示设备，对比实际显示效果； ?终端与监控系统的整合，实现多路视频模拟拼接传送！ ?终端点对点呼叫，提供连贯的高清视频质量；辅流共享也可以提供连贯的视频质量，多点会议时是否支持多分屏状态下终端收发均为全高清1080P30fps； ?软件终端与硬件终端互联互通的视频效果以及软件终端多平台同时支持的性能； ?低带宽下点对点呼叫，支持16:9的宽屏内容显示； ?MCU发起多点呼叫支持多分组高清会议，提供多组会议合并或者拆分，不中断会议，支持多厂家的终端和现有终端加入会议，显示中文字幕。 1.4测试时间与设备安排 每个厂家测试准备准备时间为3天，在入场准备测试之前，需要提供厂商对我公司需要提供的交换机端□数量、IP地址、线路情况进行明确说明。
消防系统的测试步骤 1、气体自动灭火系统如何测试？（10分） 答：第一步、测试前先测量启动瓶的电爆管或电磁阀控制线的电压，拆下所有区域内启动瓶的电爆管或电磁阀上的控制线。再测量控制线的电压，作好记录。在首先测试的区域启动瓶上接上测试灯泡。如有其他外接设备控制线路有必要也一同拆除。 第二步、收到储瓶间人员（已拆除启动瓶）通知后，将气体报警控制器打到“自动”状态。开始测试并用对讲机呼叫现场人员和气体房人员。 第三部、测试烟感报警，气体报警控制主机接到报警信号，此时气体报警控制器和气体灭火区域内发出声光报警信号（通知相关人员离开防护区），此时启动控制线不应有电压信号。用消防电话跟消防中心值班人员联系，看是否有该防火分区的报警信号到消防中心。 第四步、测试一个感温探测器报警，此时气体灭火区域内发出另外一组声光报警信号并输出联动其它相应设备信号（停止通风系统运行和防火阀，关闭常开防火门等）。用消防电话跟消防中心值班人员联系，看是否有该防火分区的报警信号到消防中心。 第五步、当烟、温探测器都报警时，经延时30秒（可选）后，启动瓶控制线端接的测试灯泡应亮，用万用表测量应有直流24V电压。（气体房1人听到开始测试后
准备好秒表和万用表计量所有的数据并做好记录。） 第六步、在储瓶间短接压力开关，相关防护区的放气指示灯应点亮，用消防电话跟消防中心值班人员联系，看是否有该防火分区的放气信号到消防中心。 第七步、对系统进行复位。 第八步、手动测试放气按钮，应与第四步相同（不同在于不经过延时30秒启动就直接启动了）。在同第五步、第六步同样操作。 第九步、所有设备恢复到正常监视状态，监视60分钟后（可以做保养工作及填写检测表），再用万用表测量启动瓶控制线端信号电压是否与测试前一致。应与测试前相同，则被拆各线路复原。 1．喷淋自动灭火系统的如何联动测试？（10分） 答：联动测试前，必须确认不动作的消防设备控制模块已被屏蔽或相关电源已被断开。 测试的工作人员应在未端排水装置、湿式报警阀、水泵房现场。 (一)将水泵手动测试后，水泵房人员将水泵的一次回路电源断开，留下二次回 路进行手动测试控制回路正常后，再恢复主电源。 (二)消防中心收到各位置人员通知可以测试的信号后，消防中心将报警主
视频会议及大屏测试方案 为配合统一协同通讯系统建设，检测系统设备、配套设备及软件功能。根据技术方案，对系统的MCU高清终端、电子白板、软件桌面终端各项指标进行测试，对视音频效果、会议功能等进行综合评测，同时针对网络的丢包率、内外网穿越技术进行相关评测。 一、视频会议测试 1. 演示一：终端共享文档和媒体 应用需求及测试目的： 终端可以通过外接移动介质（如U盘、移动硬盘）在会议中打开PPT Office、Excel、AVI视频媒体等文件。 当会场没有笔记本等双流输入设备时，可通过U盘等移动存储介质将需要在会议中使用的文件通过终端的移动介质接口在会议中播放给所有分会场。 2、演示二、电子白板 应用需求及测试目的： 触摸式电子白板加入会议中，把电子白板的培训内容广播给其他分会场，同时也把培训人声音和视频广播给其他分会场。 在培训会议中，通过电子白板，可模拟教学场景中小黑板的功能，在电子白板中打开文档和图片、标注、交互。 测试方式：
演示三：互联互通 应用需求及测试目的： 目前，其他单位已建设了标清视频会议系统，新建设高清会议系统，需要兼容本厂家标清会议系统，实现互联互通。 在会议中，呼叫MCU把会议加入到高清华平MCI会议中，主会场、各分会 场、多方会场实现多方通话、图像互动、双流PPT等功能 测试方式： 拼接大屏测试 先把所以相关的连接线连通，包括视频、VGA的输入/输出线、控制网线; 注意： 1.1 检查串口（RJ485）控制线、及视频输出线必须各自对应。
1.2 视频矩阵和命令控制器的RJ485 网线可任意插入通讯盒的其中一个 RJ485接口均可； 1.3在电脑里安装“ USB专RS232驱动程序，然后在“我的电脑”属性里的“硬件”的“设备管理器”里找到识别的串口COM端口。（注意：所识别到的COM端口必须在15以内，否则不能识别控制器。） 2、将控制器电源插头插入交流插座，打开控制电源开关； 3、启动电脑，在电脑里安装控制软件（由厂家提供），安装完成后，再打开“开始” 菜单中“ MTW Man agef操作软件，桌面出现以下界面：（图略，每个厂家的不一样） 3.1 ．启动系统点击“启动系统”按钮，大屏幕的各显示单元将进行信号自动分配，此时控制器及通讯盒的网络接口处的绿灯常亮，黄灯随通讯信号的变化间断闪烁。 3.2．功能 大画面实现时，可选择AV输入，VGA俞入、YUV俞入、HDM输入，根据要求自行选择信号输入，视频信号和VGA言号选择时，可实现多路视频多路VGA 信号不同的信号显示。 3.3 显示编号、自动分配 点击“显示编号”、“视频输入自动分配”、“VGA俞入自动分配”按钮， 拼接墙的各单元应该显示相对应的编号及图像。 3.4 亮度、对比度 点击亮度、对比度的“ +”或“ -”按钮（需间断的点击），可对各单元及 大画面的图像调整到满意的状态，也可点击“复位”按钮恢复到出厂设置状态。注意：要求在大画面下操作，才能实现画面的一致性。 3.5 图像模式 点击“图像模式” 按钮，可对拼接墙的各单元图像进行设置选择，分别为“标准”、“鲜艳”、“用户”等模式。 3.6 静像 点击“静像” 按钮，可对拼接墙的各单元及大画面模式下当前的图像进行设置选择开和关，便于仔细观察画面的细节 4、高级设置
XX单位高清视频会议系统现场测试方案 2009年5月
目录 一、测试说明 (3) 二、测试内容 (4) （一）高清视频终端特性测试 (4) 1、终端特性 (4) 2、终端设备接口及要求 (4) 3、终端设备音视频协议支持 (4) 4、终端设备操作及界面语言 (5) 5、标配高清摄像头控制功能测试 (5) 6、终端安全特性功能测试 (5) （二）MCU系统功能测试 (5) 1、MCU基本性能测试 (8) 2、MCU支持协议测试 (8) 3、MCU会场控制测试 (8) 4、MCU管理系统功能测试 (9) （三）MCU多点会议音视频效果测试 (9) 1、H.239双流数据功能 (10) 2、声音效果测试 (9) 3、图像效果测试 (9) 4、高清混速、混协议会议测试 (11) 5、高清分屏会议测试 (10) 6、高清AES加密会议测试 (11) （四）、简便易用性测试 (11) 1、拨号按键语音提示功能........................................................... 错误！未定义书签。 2、全中文遥控器及液晶显示提示 (5) 3、麦克风集成MUTE按纽 (5) 4、全语言语种语音文字菜单 (5) 5、参数自动协商 (7) 6、通过IP网络实现VGA双流发送 (7) 7、普通电话随时加入会议........................................................... 错误！未定义书签。 三、测试结论 (14)
第一章测试说明 1.测试对象：参加XX单位高清视频会议系统投标的厂商。 2.测试设备：与各厂商投标产品同型号的720P的高清测试设备以及相关配件，并附 带所送测视频会议产品终端、MCU和摄像头设备的彩页资料。 3.测试时间：XX月XX日。 4.测试目的：由于受测试环境及测试时间的限制，本测试只针对投标的高清视频会 议设备的性能、视觉效果、音频效果、会议功能等方面进行可操作性的测试了解，并验证各投标厂商提供的高清视频会议设备在XX单位视频会议系统的性能、质量及实际功能应用情况。 5.测试依据：根据XX单位对高清视频会议应用和重要功能需求，结合XX单位视 频会议系统建设实际情况，制定了本次测试的流程及内容。 6.测试环境：在XX单位现有的实际网络中，完全模拟实际组会模式，提供两个会 议室，分别为1个主会场，1个分会场。 7.本次测试所产生的一切费用由各厂商自己负责，测试专家费用由中标方负担。本 次标前测试现场不打分，只出最终评测报告，供现场评标专家参考打分，未参加测试的厂家或未在测试报告上签字的厂商参加投标，测试分为零分。 附：测试人提供的现场测试设备：
软件测试流程规划 一、引言 本文档规范了软件测试过程中的整体流程，明确了软件测试从开始到结束的各个阶段，以及在各阶段中的负责人、具体工作内容和必需的输入输出文档。另外，本文还介绍了各测试阶段需要的测试工具、测试点和测试步骤，并提供了各类测试文档的参考模板。 二、测试流程概述 1、流程介绍 一般来讲，软件测试是伴随着项目的立项而开始的。也就是说，软件项目一旦确立，测试工作也就开始了。在测试的过程中，前后要经过以下主要环节： 需求分析—>制定测试计划—>搭建测试环境—>测试用例设计—>测试执行—>BUG回归测试—>测试总结—>软件发布 对于以上流程环节，一般而言，需求分析属于需求分析人员的工作范畴，环境搭建、用例设计、测试执行以及回归测试等属于测试人员的工作范畴，测试负责人负责制定测试计划以及对各个环节的跟踪、实施、管理等。 2、流程图 功能测试 项目开始 需求阶段 测试计划 测试阶段 性能测试 用户界面测试 兼容性测试 安全性测试 接口测试 测试总结 软件发布
在这个阶段，主要是对于需求的收集、分析以及评估。 1.由需求分析人员统一收集需求，并整理成文档格式转发给项目经理、开发经理和测试经理； 2.项目经理召集开发经理、测试经理和需求分析人员进行会议讨论，了解具体每个需求的实际含义，并且明确各需求的有效性和可用性； 3.小组会议讨论，确定最终实现的需求和功能点，并整理出重点需求； 4.项目经理根据会议讨论结果编写需求说明，并且再次召集小组开会讨论，对需求说明进行修复、完善，并最终确定《需求规格说明书》。 负责人：项目经理 输入文档：需求说明文档 输出文档：《需求规格说明书》 四、测试计划阶段 作为测试的起始步骤和重要环节，测试计划是对测试全过程的组织、资源、原则等进行规定和约束，并制定测试全过程各个阶段的任务以及时间进度安排，并提出对各项任务的评估、风险分析和管理需求。用一句话概括就是：测试计划是从管理角度对整个测试活动进行规划和控制。 测试计划的主要内容可分以下几个方面： 1.测试概述（介绍项目测试的范围、目的以及组织形式） 2.测试进度（测试时间周期的安排） 3.测试策略（包括测试环境、测试工具及测试方法） 4.需求跟踪（确定系统测试项与需求之间的对应关系） 5.测试通过失败标准（指明测试何时通过何时结束） 6.测试挂起恢复标准（指明当测试过程无法进行下去时测试活动挂起以及恢复的标准） 7.资源分配（工作量的统计以及工作任务的安排） 8.应交付测试工作产品（明确测试需要提交的各类工作文档） 9.风险评估（预估测试存在的风险） 测试经理根据项目的总体进度、发布时间以及需求规格说明、开发计划制定相应的测试计划，完成后提交给项目经理。项目经理组织讨论会，连同开发经理、测试经理以及各模块负责人，对测试计划进行评审并确定。 负责人：测试经理 输入文档：《需求规格说明书》、《软件开发计划》 输出文档：《软件测试计划》
视频会议系统加速优化测试方案
目录 一、测试目的 (3) 二、测试工具 (3) 三、方案说明 (3) 四、测试拓扑 (4) 五、测试结果 (4) 六、效果总结 (8)
. 一、测试目的 视频会议系统的开发厂商为了尽可能的避免出现马赛克、卡顿等问题，已经对视频数据进行了相关的优化和处理，但是通过广域网传输的视频数据往往受网络线路传输质量的影响较大，尤其是网络丢包对视频会议系统影响很大，可能导致视频数据传输过程中丢帧过多，从而出现马赛克、卡顿等现象。 该测试方案主要是测试验证在丢包率高的网络环境中，通过部署天融信的加速方案对客户视频会议系统的优化加速效果。 二、测试工具 三、方案说明 该测试方案主要是线下测试方案，需要用网络损伤仪模拟不同的丢包和延时，以便验证测试不同网络环境下的加速效果。 线上测试方案与线下测试方案类似，主要差别在于实际线上测试时，本身网络具有一定的丢包和延时，通常不用专门的网络损伤仪；另外，实际线上测试还要根据客户视频会议系统的具体部署分布等情况，在MCU和视频终端都要部署天融信广域网优化网关，具体可参照《天融信视频会议加速优化方案》中的具体部署。
四、测试拓扑 如下图所示，视频终端为宝利通视频会议软件系统，中间有思博伦网络损伤仪，在两个宝利通视频系统前端分别部署天融信加速网关。 环境搭建完毕后，直接连通（无丢包、无延迟）验证视频会议系统的使用效果，可多次验证不同呼叫速率（例如1024、1920）下的视频效果，并录屏或摄像记录结果，以便进行对比分析。 五、测试结果 国内厂商的视频会议系统通常在5%丢包的网络环境下，就会出现较明显的卡顿、马赛克等现象。对于宝利通的视频会议系统，其自身的优化较好，通常在网络丢包超过10%以后，才会出现较明显的卡顿、马赛克现象。因此，下面的测试主要测试15%、20%、30%、50%网络丢包，传输速率分别为1024和1920情况下的视频会议系统加速前后的工作效果。（一）第一组 丢包：15% 延迟：200ms 呼叫速率：1024 加速前，通过Ping，测试记录网络丢包情况： （可截图） 加速前，录制视频会议系统工作效果： （存成文件） 加速后，通过Ping，测试记录网络丢包情况： （可截图） 加速后，录制视频会议系统工作效果：
DCS系统抗射频干扰能力测试记录表 用功率为5W、频率为400MHz~500MHz的步话机作干扰源，距敞开柜门测试方法及要求 的分散控制系统机柜1.5m处工作。分散控制系统应正常工作。 站号测试结论测试人 详细说明： 测试试验时间年月日时分 测试人签字 验收人签字
DCS系统电源冗余测试记录表 测试内容要求测试结论测试人第一路供电电源电压额定值±10% 第二路供电电源电压额定值±10% 第一路电源独立供电正常，无失电现象 第二路电源独立供电正常，无失电现象 第一路电源切向第二路电源供电切换时无失电现象 第二路电源切向第一路电源供电切换时无失电现象 电源状态指示和失电报警正确 数据说明： 实测的第一路供电电源电压： 实测的第一路供电电源电压： 问题说明： 测试试验时间年月日时分 测试人签字 验收人签字
DCS系统电源冗余测试记录表 测试内容要求测试结论测试人第一路供电电源电压额定值±10% 第二路供电电源电压额定值±10% 第一路电源独立供电正常，无失电死机现象 第二路电源独立供电正常，无失电死机现象 第一路电源切向第二路电源供电切换时无失电死机现象 第二路电源切向第一路电源供电切换时无失电死机现象 电源状态指示和失电报警正确 数据说明： 实测的第一路供电电源电压： 实测的第二路供电电源电压： 问题说明： 测试试验时间年月日时分 测试人签字 验收人签字
SOE功能试验记录 试验步骤 序号试验步骤及标准 1 检查SOE功能软件各项组态正常 2 根据情况选取部分或全部SOE点，按照一定顺序进行通/断试验，并做好记录3 检查工程师站是否能成功追忆SOE动作记录，并确认所记录的动作顺序正确无误 4 检查SOE时间是否与主时钟同步，正常工作 试验记录 SOE 组态检查 SOE点 通/断试验 点名动作情况(详见所附SOE打印记录) SOE时间与 主时钟同步 测试试验时间年月日时分测试人签字 验收人签字
验收和测试方案
目录 一、系统测试和验收的目的 二、系统测试和验收的组织 三、系统测试和验收的内容 1.厂验 2.到货验收 3.初验 4.终验
一、系统测试和验收的目的 我方按照合同和工程实施要求，按时高质完成项目的实施，并积极配合联通公司对系统的测试验收，以达到： ●检验我们是否遵守工程实施保证中的各项承诺，为甲方公司提供了一套合 格的会议电视系统。 ●通过测试和验收的圆满成功正式标志工程的结束和保修期的开始。 二、系统测试和验收的组织 工程的验收，将由甲方公司、丙方公司、乙方公司以及Polycom公司共同进行。甲方和项目监理组将依据合同，并按照由乙方提供的、经甲方确认的验收方案，对乙方提供的全部设备、业务系统软件及整个工程的实施进行系统的验收。 三、系统测试和验收的内容 本次工程的验收包括厂验、开箱验收、初验和终验几个阶段。 1.厂验 设备出厂前，买方可派人到工厂进行检验。我方将在出厂前提供厂验项目指标测试程序和检验方法，经买方修改和确认。厂验完成后，双方签署厂验报告。 2.到货验收 到货验收包括外包装验收和开箱验收。 我方将按照合同要求进行运输包装，相关配件同批发货和到货。在外包装验收中将根据合同供货方式在我方负责的到货地进行验收。 设备运抵安装现场后，买卖双方共同开箱验收。双方代表将负责依照合同设备清单对运抵设备进行清点和验收，并填写验收报告。验收时发现短缺、破损，买方有权要求立即负责补发和更换。 3.初验 设备安装、调试完成后，进行割接验收测试（初验）。初验前，由我方提交初验申请报告和验收规范。验收规范包括验收项目、验收指标、验收方法、验收环境和测试仪表等，并需经最终用户修改和双方确认。 双方按照初验方案，进行割接验收测试。我方将负责解决测试验收过程中出现的所有未达标问题，直至测试验收合格。 割接验收测试合格后。双方签署初验合格证书，设备入网开通试运行。试运
测试流程及测试理论方法 一、测试流程 1.软件开发流程： 需求分析—>概要设计—>详细设计—>编码开发—>测试—>维护 2.测试流程为： 单元测试/集成测试—>系统测试/自动化测试—>性能测试—>验收测试 3.目标： 3.1制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基 础流程框架。 3.2最终目标是实现软件测试规范化、标准化、自动化。 4.测试流程说明：
5.测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据；·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖。
5.1测试方法与规范 5.1.1 测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通 常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。 ?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。 ?兼容性测试 --测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S 项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部 分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。 ?冒烟测试--版本编译者 冒烟测试，英文是Smoke testing。 冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。 冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。 ?随机测试--测试人员 随机测试，英文是Ad hoc testing。
测试BUG记录表外呼前台： 项目信息 测试时间：2012年9月28日测试人员：韩娟娟 前台地址：http://192.168.0.213:8003/login.aspx 后台地址：http://192.168.0.213:8001/login.aspx 后台帐号4000810010 座席 号 2046 后台密码：666666 系统环境：2008系统浏览器：Ie8 合成地址：无 错误描述（项目测试人填写）1、错误路径：客户资料 截图：
错误描述： 1.客户资料——添加客户资料——展开，QQ信息一旦添加，就不能保存。 2.客户资料——来电记录——编辑，咨询内容不能换行输入。 3. 客户资料——查询客户资料——编辑，客户资料也不能换行输入。 备注： 修改反馈记录（格式：时间 + 修改情况） 修改人： 项目经理： 错误描述（项目测试填写）2、 错误路径：通讯录 截图： 图一图二 图三 错误描述： 1.通讯录——个人通讯录——添加，QQ信息一旦添加，就不能保存，msn格式没有验证。如图一 2.通讯录——个人通讯录——编辑，如图二备注中换行输入内容，单击“保存” 后，在列表中显示换行标记，如图三
备注： 修改反馈记录（格式：时间+ 修改情况） 修改人： 项目经理： 错误描述（项目测试人填写） 3、错误路径：知识库 截图： 图一图二 图三 错误描述： 1.知识树不能及时刷新，添加了内容后，需要重新回到此页面才能显示更新内容。 2.知识库——个人知识库——添加，若换行输入知识库内容，添加成功后，再次编 辑或查看时，出现如图二、三所示 3.知识库中个人知识库、企业知识库、共享知识库，单击“查看”时弹出页面显示
软件测试的阶段划分 可以从三个角度来将软件测试划分为多个阶段： 1. 面向软件测试操作类型的划分，如调试、集成、确认、验证、组装、验收、操作； 2. 面向软件测试对象粒度的划分，如语句、结构、单元、部件、配置项、子系统、系统、大系统； 3. 面向软件测试实施者的划分，如开发者、测试者、验收者、使用者。 软件测试阶段的步骤 每个软件测试阶段都要经历以下步骤：测试需求分析、测试过程设计、测试实现、测试实施、测试评价、测试维护。 测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ◆测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ◆测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ◆测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； b 测试过程设计：包括测试计划, 测试策略制定，测试时间安排用，测试用例编写等 c 测试实现：环境配置好了，新的版本也收到了，人员也都培训好了等等 d 测试实施：已经按照测试计划进行展开了，比如手工测试，自动化测试等 e 测试评价：对版本测试覆盖率，测试质量，人员测试工作以及前期的一些工作制定情况进行评价，评估 f 测试维护：对测试用例库，测试脚本，bu g 库等进行维护，保证延续性等 软件测试步骤
视频会议施工方案 10.1合同责任分工及工程界面 10.1.1总体分工界面 为保证*****的顺利进行，*****（供方）将负责制订工程实施进度，并对工程实施进度进行督导，及时与*****（需方）沟通，具体工程工作安排如下： 10.1.2供方承担工作 1)按照合同要求供货、验货 2)工程项目总体进度的制定 3)工程正式实施前的环境验收（包括电源供应、机架、布线、设备、网络、等准备情况） 4)主要功能调测开通 5)系统正式启动 6)对所供软件、硬件的维护、服务和技术支持 7)工程项目具体进度的协调 8)对用户的现场直接培训 9)提供项目技术文档、使用管理手册等 10)提供相关培训 11)准备设备验收、初验、终验 12)试运行期间现场支持 13)验收后的长期技术支持 10.1.3需方承担工作 1)机房的供电电源、备份电源（达到安装机架处） 2)机房设备场地准备 3)工程进度表的协商制订 4)IP地址分配确认
5)协调服务器等项目所提供设备的安装到位 6)提供工程协调负责人的名称和联系方式 7)组织工程初验和终验 10.2设备分工界面 10.2.1供方负责 1)负责集成的设备，其安装、调测（包括硬件及软件）及开通 2)安装调测时使用的工具、设备的提供 3)双方应协商制定工程进度表,公司负责按工程进度表进行施工 4)设备调试由公司负责，并提出设备调试的内容、项目、指标和方法, 对买方的技术人员提出的 问题做出解答。调试应进行详细记录、系统调试结束后, 由技术人员签字后交付验收 5)应提供测试项目、正确结果、程序和方法的草案，经双方协商后，共同拟定最终测试文件12.2.2需方负责 1)基础平台互联所必须的协调工作 2)本次工程所需相关传输线路的接入和延长电缆 3)机房设备场地、电源准备 4)提供各环节联系人名单 5)双方应协商制定工程进度表 6)提供IP地址使用现状；提供所涉及设备的口令 7)必要的人员配合 8)双方设备在互连施工中双方人员应本着友好合作态度相互配合 10.2.3 施工工程界面
软件系统测试流程 一．测试计划阶段 1.测试目标及背景 通过测试能够达到预期的用户对易用性及功能的要求，并且测试满足系统测试规范和流程，确保软件能够有序的按照计划进行系统测试。被测目标的背景描述。 2.测试范围 描述本次测试范围有哪些，那些测，那些不测。 3.组织形式 本次测试需要参与的相关部门和分组，以及其负责参与那些相关工作。 4.测试对象 XXX系统： 业务功能有哪些 用户界面要求 性能的要求 相关配置
5.需求跟踪 需求规格说明书，最终开发文档等。 6.测试通过/失败标准 通过标准： 1.测试用例100%通过 2.相关技术人员经过评审确定质量要求及相关功能均能满足用户需求 3.1星期内没有发现C类以上bug 4.用户验收用过 失败标准： 1.用例超过30%执行失败 2.存在5个以上A类缺陷 3.一星期内缺陷数目没有下降 4.用户验收没有通过 7.测试挂起及恢复条件 挂起标准： 1.存在严重影响用例执行的模块错误 2.无法正常安装被测软件 3.需求变更导致的模块调整 4.其他项目导致的人员变动 恢复标准： 1.软件已修复掉导致无法正常执行的模块缺陷 2.软件可以安装 3.需求已确定，或人力资源回归
8.测试任务安排 1.需求确认及评审，输出评审表，评审状态统计，评审记录，修正报告。 2.时间安排。 3.资源分配，人员，地点，软硬件环境，测试工具等。 9.工作量估算 10.应交付的测试工作产品 测试计划 测试方案 测试用例 预测试规范 测试规程 测试报告 性能测试分析 测试脚本 测试数据
缺陷规范 用例规范 二．测试设计阶段 1.测试用例设计方法和标准 2.输入和输出 3.时间安排 4.资源 5.风险和假设 6.角色和职责 7.预测试准备 8.测试环境搭建 9.测试数据准备 三．计划执行阶段 1.冒烟测试，来评判此版本可不可测，如果不可测退回返工，如果可测，就进行第一 轮系统测试，按照之前的方法和用例等来进行。 2.第一轮测试做好测试结果记录，提交缺陷报告，把所有bug提交给开发人员，由 他们进行修改。在开发修改bug期间，根据实际情况对测试用例进行修改和增加，开发修改bug结束，发新版本进行第二轮测试。 3.第二轮测试开始之前，先进行回归测试，验证第一轮的所有bug，然后挑几个优先 级高的重要的用例进行简单测试，然后进行第二轮测试。 4.等到缺陷率和级别低于需求和用户要求了可以进行最后一论回归测试，结束系统测 试，提交系统测试报告。
1. 测试计划：这个计划，我个人觉得应该在详细设计确定后，代码开始编写的时候进行制定，因为我是“提早开始测试工作”思路的忠实fans，虽然现在项目里都只有我一个人在这么早开始工作...... 测试计划，主要是给后面的测试工作一些指南，不能写成领导看的计划，而是要写成由做事的人看的计划 包含的内容可能有： i. 测试团队人员及分工(要确定当测试时出现缺陷界定、测试环境准备等问题时能找到指定的人员) ii. 测试开始结束时间(理想情况下，不要安排的太紧，赶工肯定会造成延期或测试不完整，可惜理想和现实的差距被规定为很大) iii. 测试环境配置(什么样的硬件条件，是否网络、设备等，系统在什么地址访问，访问权限、使用的测试数据等方面的预计和准备) iv. 测试哪些东西要说清楚，这里我建议把简单的测试大纲纳入测试计划中，一方面领导可以看到你的计划写的多详细，另一方面大纲可以很好的成为编写用例的依据 v. 怎么测试要说明白，如只做系统测试，那就要写清楚不做集成测试，如果需要集成测试，就需要写明白集成顺序。另外如果需要进行性能、文档、等其他的测试也要在这个计划中写明，虽然一般这个计划都是针对功能测试，但是如果有其他测试，也要写出来并安排时间，相应测试的相关计划等也需要指明 vi. 测试结束标志(要说明测试达到什么程度可以结束测试，不能等到把所有缺陷都找出来以后才结束，因为那将是一万年)，允许缺陷存留在系统里，我们只需要找到留多少这个度就够了 2. 测试用例：这个文档，主要描述具体的测试步骤，但实际应用中，至少目前我的项目里，由于时间的原因，很少有写的，就算写了的，也基本没有用到测试里，在这边的很多项目大都是直接来测，全凭我个人的经验来检查(在此感谢领导们对于我二把刀技术的信任_@_)。但是我想说其实他很重要，也许你不需要写的很详细，但是绝对需要通过这样的步骤来理顺思路，这个文档的好坏和实用程度，直接可以决定你是否能“用最少的工作(量和时间)，尽早的发现尽可能多的缺陷”，写这个文档需要用到一些测试方法理论，如等价类划分、边界值、这个表那个表。 3. 缺陷记录：是功能测试过程中使用频率最高的文档，用于在测试过程中记录发现的缺陷，并由开发人员作为修改缺陷的依据，以及修改后测试人员进行回测的主要依据 a) 该文当也有助于分析开发人员存在的“错误集群”现象，总结易出错的地方，对缺陷多的部分做更深入的测试，并提醒开发人员避免缺陷 b) 缺陷记录填写指南：