视频回波模拟器

软件自测报告

(内部资料  请勿外传)

航天福道高技术股份有限公司

文档变更记录

目    录

1.1 软件总体描述... 4

1.2 参考文档... 4

1.3 软件功能描述... 4

1.3.1 主动寻的状态功能... 4

1.3.2 测试状态... 4

2.1 测试概述... 6

2.1.1 测试时间... 6

2.1.2 测试地点... 6

2.1.3 测试人员... 6

2.1.4 测试环境... 6

2.1.5 测试软件版本... 7

2.2 测试步骤与记录... 7

2.2.1 测试过程... 7

通道1目标... 7

通道1目标，通道2目标... 8

通道1目标，通道2窄带噪声... 8

通道1目标，通道2欺骗干扰... 9

连续波测试... 9

固定延迟测试... 10

2.2.2 测试记录... 10

2.3 测试结论... 12

1. 总体描述

1.1 软件总体描述

本软件是视频回波模拟器的主要操作界面，通过界面的一些用户设置，经PCI将数据下载到各个控制板下，用于模拟真实雷达目标或各种干扰欺骗。

模拟器上位机和机箱的的通讯，是按照特定的接口定义协议并通过PCI通讯实现的。

1.2 参考文档

1.3 软件功能描述

本软件主要是针对两大状态数据的设置模拟：

1.         主动寻的状态。

2.         测试状态

1.3.1 主动寻的状态功能

主动寻的状态功能主要包含两个通道：通道1和通道2。

其中通道1只模拟目标，通道2能模拟：目标，窄带噪声，欺骗（速度欺骗，距离欺骗，速度距离联合欺骗）和无（表示只有目标1）。通道1和通道2的数据时同时下发的，以实现对现实目标或干扰的实时模拟。同时界面上会实时的显示目标1和目标2的状态，包括目标1和目标2的当前距离和速度。

1.3.2 测试状态

     测试状态主要包含两个功能的测试。1)连续波测试  2)固定延时测试

     这两个测试包含了一下5个参数                                                                                      

            

2. 测试过程与结果

模拟器上位机和机箱的通讯主要是通过CPCI进行的。

启动程序时，可能会耗费一分钟左右将一个二进制文件的噪声数据下载到控制板中

软件主界面如图1.1：

      

                              图  1.1（软件主界面）

这是软件的主界面，界面左边框的两个图标是切换功能设置面板的按钮，点击切换，目标状态显示的当通道1和通道2同为目标的时候，目标的距离和速度。界面的右边框是设置面板，其中中心频率是用户需要保密的，所以输入设置成加密格式，点击发送按钮下发目标数据，点击暂停按钮，停止数据下发，点击停止按钮，数据下发终止。点击退出按钮，退出程序。

2.1 测试概述

2.1.1 测试时间

 20##年 08 月 25 日

2.1.2 测试地点

本公司实验室

2.1.3 测试人员

       本公司软件组：简政荣

       本公司模拟器组：

2.1.4 测试环境

硬件配置要求:

l  CPU: 主频266以上;

l  内存1G以上;

l  硬盘：100G以上；

l  CPCI 接口的机箱

l  USB键盘鼠标；

l  数字万用表;

l  频谱仪

l  示波器

软件配置要求

l  操作系统: WindowsXP；

l  .NetFrame3.0以上运行环境；

l  WinDriver 7.0

2.1.5 测试软件版本

2.2 测试步骤与记录

2.2.1 测试过程

通道1目标

通道1为目标（通道2无，通道1只能做目标）显示如图1.2

              通道1作为目标时，需要设置的参数有：初始斜距（目标从该初始位置开始移动），初始速度(目标的开始移动的初速度)，初始加速度( 目标开始移动的加速度)，终止斜距（目标最终停止运动时的距离），回波功率（一般设置成最大值），信号脉宽                                              

                                 图1.2

设置好参数后，可以通过点击发送，暂停，停止按钮，控制数据的下发

通道1目标，通道2目标

       通道2为目标的参数设置和通道1的目标一样，如图1.3

                             图 1.3

设置好参数后，可以通过点击发送，暂停，停止按钮，控制目标1和目标2的数据同时下发

通道1目标，通道2窄带噪声

如图1.4，窄带噪声的参数包括：噪声占空比，噪声幅度，噪声带宽和噪声间断周期

                                          图 1.4

设置好通道1目标和通道2窄带噪声参数，点击发送可以控制通道1目标数据的下发和噪声参数的下发。

通道1目标，通道2欺骗干扰

如图1.5

                                   图 1.5

欺骗干扰的数据和通道1目标的数据是同时下发的，欺骗干扰的类型包括：距离拖延，速度拖引和联合拖引（速度距离联合拖引），主要的参数包括：速度，加速度，距离（当目标到达该距离是拖引开始），停拖距离（当目标到达该距离时停止拖引），回波功率，使能输出。

同时界面左边的目标状态会显示目标1的实时距离和速度和通道2欺骗干扰的距离和速度

点击界面左边的连续波测试图标按钮切换到测试状态参数设置界面。

连续波测试

点击连续波测试单选按钮，如图1.6

                               图1.6

连续波测试参数暂时包括以下几个：幅度，目标速度，多普勒频率，回波功率和延时，点击发送按钮将数据下发到机箱中。

固定延迟测试

点击固定延时测试的单选按钮，切换到固定延时参数设置界面，同连续波延时参数设置界面相同。

2.2.2 测试记录

2.3 测试结论

整个测试过程都在最后交付环境条件下完成，测试所得的数据也完全符合要求。和视频回波模拟器软件任务书相符合，可以算成功交付。

第二篇：软件性能测试报告模板

目 录

1 前言

1第一章XXXXXXXX核心业务系统性能测试概述

1.1 被测系统定义

1.1.1 功能简介

1.1.2 性能测试指标

1.2 系统结构及流程

1.2.1 系统总体结构

1.2.2 功能模块描述

1.2.3 业务流程

1.2.4 系统的关键点描述（KP）

1.3 性能测试环境

1.3.1 硬件及网络环境

1.3.2 系统装配描述

1.3.3 系统启动和管理

2 第二章 性能测试

2.1 压力测试

2.1.1 压力测试概述

2.1.2 测试目的

2.1.3 测试方法及测试用例

2.1.4 测试指标及期望

2.1.5 测试数据准备

2.1.6 运行状况记录

3第三章 测试计划及方案

2.2 测试步骤

2.2.1 被测系统调研

2.2.2 测试环境的部署

2.2.3 脚本的录制和调试

2.2.4 准备测试场景

2.2.5 准备测试数据

2.2.6 执行性能测试

2.2.7 生成测试报告

2.3 测试时间进度及人员安排

2.3.1 人员安排

3 第四章 测试报告

1 前言

目前，XXXX的XXXXXXXX核心业务系统（以下简称新业务系统）已先后在XXXX、成功上线，从而公司的XXXX信息管理逐步走上了集中管控的道路。后续，xxx等34家分公司的XXXX信息也将分布进入业务系统，从而将会势必出现新业务系统中信息大量增长的态势。

随着新业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：XXXX大数据量的“冲击”，在XXXX信息进入时，系统能稳定在什么样的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。

本《性能测试规划书》即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的XXXXXXXX核心业务系统的性能测试。

1第一章xxxx系统性能测试概述

1.1 被测系统定义

xxxx业务系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXXXXXXX核心业务系统进行的），该业务系统的主要功能包括：xxxxx

在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数，

1.1.1 功能简介

xxxxxx

主要功能如下：

Ø xxx

Ø xxxxx

Ø

1.1.2 性能测试指标

本次测试是针对XXXXXXXX核心业务系统的性能特征和系统的性能调优而进行的，主要需要获得如下的测试指标。

1、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。

2、应用系统的吞吐率：即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量。

3、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。

1.2 系统结构及流程

xxxx业务系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。

1.2.1 系统总体结构

描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。

1.2.2 功能模块

本次性能测试中各类交易都是由若干功能模块组成的，每个交易都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），在xxx业务系统中，各种交易及其包含的功能模块关系如下：

1． xxx

2． xxxx

3． xxxx

本次压力测试主要设计的功能模块以及所属的路径如下表

名称

所属交易

路径

1.2.3 业务流程

本次性能测试中，选择的各类交易的业务流程如下：

1．xxxxxx

2．xxxxxxx

3．xxxxxx：

4．xxx：

5．xxxxx

6．xxxx

查询交易的业务流程只是单一步骤的，即：输入查询条件后获取查询结果，因此在本次性能测试中只作为一个事物处理，交易流程图略。

1.2.4 关键点描述（KP）

本次性能测试的关键点，就是查看xxxx业务系统在并发压力下的表现，即：支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的交易处理能力，并找出各类交易的性能瓶颈。

1.3 性能测试环境

本次性能测试环境与真实运行环境基本一致，都运行在同样的硬件和网络环境中，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端都是通过浏览器访问应用系统。

其中具体的硬件和网络环境如下：

Ø 服务器设备：IBM 570（DBserver）， IBM 690（APserver）

Ø 操作系统： AIX

Ø 网络环境： LAN（10M）

Ø 数据库：Oracle

Ø 客户端： PC （Windows ）

网络拓扑和结构图如下：

2 第二章 性能测试

从广泛意义上讲性能测试包括：压力测试、稳定性测试、负载能力测试和可扩展性测试等。在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次XXXXXXXX核心业务系统的性能测试主要是采用通常的压力测试模式来执行的，即：逐步增加压力，查看应用系统在各种压力状况小的性能表现。

在本次性能测试中，也将使用美科利的新产品性能测试诊断工具（Diagnostic）对测试应用的各层进行监控，判断J2EE各层次的各类方法和类的调用使用时间和效率，并帮助开发人员分析J2EE应用的各类交易的性能瓶颈点。

2.1 压力测试

在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。

2.1.1 压力测试概述

本次压力测试是指针对现行的xxx核心业务系统的联机交易处理能力的测试，检验系统的吞吐率。本系统的压力测试主要是针对xxxxx，检查在日间交易高峰时期，并发用户数较多的时候的处理能力等等。

2.1.2 测试目的

压力测试的目的就是检验系统的最大吞吐量，检验现行的xxxx业务系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。

本次针对xxxx核心业务系统所进行的压力测试的测试目的为：

² 给出xxxx系统当前的性能状况

² 定位新业务系统性能瓶颈或潜在性能瓶颈

² 总结一套合理的、可操作的、适合公司现实情况的性能测试方案，为后续的性能测试工作提供基本思路。

2.1.3 测试方法及测试用例

使用美科利公司（Mercury）的性能测试软件LoadRunner，对现行的xxxx业务系统进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各台测试前台，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。

使用的测试用例包括：联机处理交易和查询交易，其中联机交易测试试用的交易包括：xxxx查询类交易包括：xxxx

测试用例列表包括：

交易种类

案例一

案例二

案例三

案例四

30%

40%

25%

10%

10%

10%

25%

0%

20%

10%

15%

0%

20%

20%

15%

10%

30%

20%

20%

80%

本次测试将依照如下场景进行测试：

用户数

功能模块

业务操作

交易配比（%)

200

400

700

1000

针对每个测试案例，都将采用逐步加压和瞬间加压两种客户端连接方式进行，查看服务器端在客户端的连接数量变化过程中对应的处理能力，测试运行安排如下：

· 每隔2秒增加1个用户连接，最多增加到200个用户，查看并记录运行情况

· 每隔2秒增加2个用户连接，最多增加到200个用户，查看并记录运行情况

· 一次性连接10个用户，查看记录运行情况

· 一次性连接100个用户，查看记录运行情况

3.3.1 第一次测试

第一次测试使用了200个并发用户，并发用户的启动信息如下：

各类交易的交易相应时间 （秒）

Color

Scale

交易名称

最小

平均

最大

1

AutoUW_Transaction

0.0

23.733

87.871

1

Confirm_Transaction

210.203

210.203

210.203

1

CTDetail_Transaction

105.878

151.032

199.477

1

EdorNoscanAppInput_Transaction

60.704

153.425

259.234

1

GeneralQuery_Transaction

0.067

13.623

39.094

1

IndividualQuery_Transaction

0.781

28.042

64.984

1

Issue_Transaction

5.145

30.6

60.22

1

Login_Transaction

4.265

115.433

246.736

1

ManualUW_Transaction

77.094

77.094

77.094

1

NBQuery_Transaction

0.334

22.348

49.625

1

PayIn_Transaction

1.503

59.944

112.639

1

PayOut_Transaction

5.256

29.178

60.279

1

PayOutQuery_Transaction

0.078

1.291

6.872

1

PEdorTypeAC_Transaction

111.253

160.054

213.544

1

PosNoScanApp_Transaction

9.254

158.276

271.381

1

POSQuery_Transaction

29.602

122.815

212.93

1

PrtNoInput_Transaction

1.722

146.879

263.094

1

Relogin_Transaction

30.16

70.939

105.24

1

ReportInput_Transaction

1.155

101.387

184.783

1

Review_Transaction

5.091

112.682

387.087

1

RiskInput_Transaction

2.821

113.049

211.427

1

vuser_end_Transaction

0.0

0.0

0.0

1

vuser_init_Transaction

0.0

0.158

2.417

1

2.084

112.373

267.659

1

0.278

6.312

15.394

1

3.75

13.56

25.925

1

0.22

6.243

15.939

1

8.531

109.639

210.746

1

1.281

8.553

15.474

1

0.093

19.469

59.271

各类交易的平均响应时间图：

可以看出随着测试的进行，交易相应时间逐渐增大，最终导致交易超时而失败。

测试中，每秒的点击率如下：

测试中每秒页面的下载速度如下：

根据上面两组数据，即：每秒的点击率和每秒下载页面的速度，可以看出，在测试执行开始4分钟以后，核心业务系统用户登录的并发数量不断在增加，但是用户登录后的数据下载量却变化不大，这样将最终导致大量的用户登录因为交易处理超时而失败。

3.3.2 第二次测试

第二次测试调整了交易处理逻辑，大大减少了用户登录的操作数目，每个用户只执行一次用户登录，然后执行对应的交易处理，交易过程中不再执行用户登录操作。

运行的并发用户数目如下图：

在用户登录过程中，交易的平均响应时间如下图：

从图中可以看出，随着并发用户数量的不断增加，所有的交易的平均响应时间都在加大，直到并发用户数不再增加，这时候所有的交易相应时间下降到一定的数值，并一直稳定在这个数值左右。

在第二次测试中，各类交易的平均响应时间如下表：（单位：秒）

Color

Scale

交易

最小

平均

最大

1

Audit_Transaction

19.481

162.12

207.627

1

AutoUW_Transaction

0.0

13.001

49.494

1

ClaimRegister_Transaction

75.599

143.641

163.978

1

Confirm_Transaction

1.131

51.427

94.585

1

CTDetail_Transaction

37.257

65.967

148.334

1

EdorNoscanAppInput_Transaction

16.504

79.919

169.239

1

EndCase_Transaction

11.88

46.546

85.658

1

GeneralQuery_Transaction

0.152

11.017

35.321

1

IndividualQuery_Transaction

0.875

14.455

40.578

1

Issue_Transaction

4.269

14.326

30.496

1

Login_Transaction

8.363

90.998

151.344

1

ManualUW_Transaction

3.262

81.311

171.284

1

NBQuery_Transaction

0.422

12.082

36.297

1

PayIn_Transaction

0.559

32.012

74.462

1

PayOut_Transaction

2.204

11.121

32.397

1

PayOutQuery_Transaction

0.079

1.255

5.328

1

PEdorTypeAC_Transaction

37.384

66.606

137.382

1

PosNoScanApp_Transaction

15.892

85.482

164.156

1

POSQuery_Transaction

10.193

57.825

132.677

1

PrtNoInput_Transaction

5.162

77.07

164.458

1

Relogin_Transaction

16.103

61.116

74.896

1

ReportInput_Transaction

4.88

66.869

138.372

1

Review_Transaction

8.67

61.846

302.131

1

RiskInput_Transaction

9.317

49.871

123.788

1

vuser_end_Transaction

0.0

0.0

0.016

1

vuser_init_Transaction

0.0

0.0

0.008

1

7.792

54.317

183.409

1

0.694

2.419

8.553

1

1.481

7.267

24.725

1

0.777

2.532

6.638

1

8.971

72.21

145.923

1

1.384

3.977

11.539

1

0.296

7.433

28.666

交易相应时间时序图如小：

图中最上方的两条曲线（即交易相应时间最慢的）分别是：xxx (Audit_Transaction) 和xxx(ClaimRegister_Transaction)，除了这两类交易，其他各类交易都是在测试初期执行较慢，随着用户登录完成以后，各类交易的平均响应时间都稳定在对应的数值上，并都保持在90秒以内。

测试中每秒的点击率如下：

途中，从20分钟开始到35分钟，点击率下降的原因是部分查询交易循环600次已经成功结束，在35分钟左右重新启动，所有出现了途中点击率下滑的现象。

下面的几幅图中，数据线下滑的原因相同。

交易的吞吐率（每秒处理数据量）如下图：

其中数据线下滑的原因同上。

4第四章 测试报告

在xxxxx核心业务系统的性能测试过程中，将分别撰写测试计划和性能测试报告，其中测试计划将在测试开始之前完成，用以指导测试、并做好各个阶段的计划和任务分配工作，在测试结束之后，根据测试结果，将生成测试报告。

两份对应的文档名称如下：

ü 《性能测试计划书》

ü 《性能测试报告》