监控系统性能测试报告

监控系统性能测试报告（精选8篇）

监控系统性能测试报告 篇1

永兴煤矿2014年6月份瓦斯监控系统性能测试报告 2014年6月5日我矿组织了通风部门，机电部门，技术部门对矿井监控系统进行了瓦斯监控系统性能测试，现将瓦斯监控系统测试结果报告如下：

1、13201采面回风瓦斯探头调试时能报警，超限置正常，报警喇叭没有语音；故障探头。

2、13201回风石门处瓦斯探头数据不能上调，最大置0.53%.3、13201回风巷工作面瓦斯探头调笑数据正常，但探头不报警，报警灯不亮，没有语音。

4、13202运输巷回风探头数据不能上调；最大值0.35%。探头显示数据与地面监控部符，地面显示0%

5、13201运输巷瓦斯探头数据不能上调；最大值0.34%。6、13201切眼探头测试正常，但显示数据与地面监控不符，测试数据1.22%，地面显示0%。

6、13201运输巷回风瓦斯探头显示数据与地面监控显示不符，探头调试数据1.21%，地面监控显示0.14%。

7、13202回风巷工作面瓦斯探头调试数据是1.22%，地面监控显示0.08%。

8、水泵房瓦斯探头显示数据为0.52，与现场实测瓦斯浓度不符，实测水泵房瓦斯浓度0.04%。

因时间关系还有部分地点未调试，根据规定检查瓦斯监控系统每7天必须进行一次探头调校、断电试验及系统功能测试，下次再进一步完善。

监控系统性能测试报告 篇2

煤矿钻机性能综合测试系统由专用计算机软、硬件和相应仪器构成, 可以监控不同类型的煤矿钻机检测设备, 生成煤矿钻机性能综合测试报表, 并能对检测数据进行后期分析和处理。该系统可满足国内煤矿钻机科研、生产和使用单位对钻机性能综合测试的迫切需要。

1综合测试系统总体方案

1.1 系统设计原则

1) 综合测试系统能够满足各型号煤矿钻机的测试需要。

2) 保证测试系统架构的合理性和完整性, 综合测试系统方案的设计必须考虑与周边设备接口的兼容性, 包括与发控设备的信息交互功能。

3) 保证系统具有良好的可靠性和维护性指标, 特别是要满足井下等恶劣条件下, 测试设备始终处于良好工作状态的需求。

4) 具备对采集的测试数据的合理表现、集中保存、基于人工智能技术的数据挖掘能力。

5) 综合测试系统必须遵循相关的技术标准。

1.2综合测试内容

煤矿钻机性能测试内容根据MT/T 356—94《煤矿井下安全钻机技术条件》, MT/T 640—1996《煤矿用安全钻机参数系列》, 《钻机质量检验标准规范》等标准文件选取, 共计27项, 具体为:给进力、锚固力、马达油压、小泵油压、推进油压、水压力、钻机推进行程、钻机推进速度、油温、泵温、马达温度、大气温度、大气湿度、冷却水流量、马达进油流量、马达回油流量、输入功率、输出功率、功率因数、整机效率、转矩、转速、轴功率、油液泵噪声、操作台噪声、马达噪声、噪声平均值。其中整机效率、轴功率、噪声平均值通过对原始数据计算得出。

2综合测试系统硬件设计

煤矿钻机综合性能测试系统的基础硬件由3部分组成:22个、9类专项检测仪器设备, 测试用计算机, 通信线路 (如图1所示) 。测试计算机通过多串口卡扩展卡外接RS232线路与专项检测仪器设备连接。可连接远程监控计算机、打印设备等。

专项检测仪器设备可由使用企业自行选定 (常用设备见表1) , 方便企业采购和使用已有设备, 提高测试系统的经济性。

通过对常用专项检测仪器设备的数据的分析, 可以分为3类:

1) 采集参数后转换为数字信号, 主动通过RS232接口向外发送。

2) 采集参数后转换为数字信号, 不主动向外发送, 需要接收到外部请求后再发送。

3) 单纯的模拟传感器, 不具有模拟到数字信号转换和传输功能。此时需要外接数显表进行A/D转换, 并进行数据传输。

测试用计算机选用PC 兼容的军用加固型控制计算机或能适应各种恶劣工业现场环境的工业控制计算机[3], 并在此基础上进行外观改造, 在机箱上集成键盘、鼠标、大尺寸LCD显示器、便携式打印机, 以方便使用和移动。

根据对煤矿钻机研发、检测、生产和质量检查等机构的调研, 被测对象与测试用的计算机之间距离不超过10 m。专项检测仪器设备基本都具有RS232或RS485接口, 因此选择连接专项检测仪器设备和测试用计算机的通信线路为RS232。如需要增加传输距离或提高复杂电磁环境下的抗干扰能力, 可选用RS485线路, 在线路两端进行RS485到RS232转换, 保证接口的同一性, 从而提高测试系统的通用性。

3综合测试系统软件开发

根据对煤矿钻机综合测试系统的需求分析, 开发出便于操作, 自动化程度高, 数据集中显示、处理和存放, 并具有一定人工智能的测试软件。系统软件基于微软公司的.NET平台, 使用C#语言, 结合SQL Server2005进行开发。

3.1软件的流程分析

测试软件通过多串口卡统一调度22个专项检测仪器设备, 实时采集煤矿钻机在同一工况下27项性能参数。针对3类常用专项检测仪器设备采取不同的通信方式, 测试程序采用不同的工作方式。

1) 设备不受控, 定时发送测试数据, 测试程序需要实时接收数据, 并保证数据的完整和正确。在煤矿钻机综合测试系统中用到的HSDZC电能测试仪就是这种类型的设备。程序处理的流程如图2所示。

2) 设备需要激活才能通信, 测试程序需要在一个测试时段内激活设备, 然后才能向设备发送命令或者接收其发送的数据, 其典型设备是JW2A转矩仪。程序的处理流程如图3所示。

3) 按照数显表的通信规则直接传输指令。HC系列设备就是这种类型, 该类型的通信方式相对简单, 但是其协议数据的有效性判断则是比较细致的。程序处理流程如图4所示。

测试时能显示实时的钻机性能参数, 并把重要参数突出显示, 能对超过正常范围的参数作出声音、图形颜色的警示。

操作人员可以对钻机运行的性能参数进行一个时间段的自动记录, 也可以手工点击记录一个时间点的数据, 生成相应的测试报告, 记录到测试数据库中, 选择打印输出。

对历史数据进行查阅、打印或者由计算机进行数据挖掘。

3.2软件的组成和作用

1) 系统管理。

设置操作员帐号、密码, 对数据库进行手工备份。

2) 参数设置。

定义连接的专项检测仪器设备及其通信规则, 设定各个参数的合理取值范围。

3) 数据采集。

与专项检测仪器设备进行通信, 获得相应的数据参数。

4) 数据记录。

自动或手工选择时间段、时间点, 生成钻机性能的综合测试报告, 并记录到数据库中以备查阅或分析。

5) 数据打印。

打印正式的测试报告, 可以动态调整企业信息等表头数据。

6) 测试报告查询。

查询、打印历史上的某次测试报告, 可选表格和图形方式。

7) 历史数据分析。

运用人工智能技术对数据库中的历史测试数据进行挖掘, 以发现潜在的知识, 帮助研发、检测人员进行详细分析。

4关键技术问题

4.1 多线程调度

由于开发的检测系统要与多个设备实现通信, 因此需要使用多线程技术。应用程序创建的线程都要在休眠状态中消耗大量时间, 以等待事件发生。其他线程可能进入休眠状态, 只被定期唤醒以轮询更改或更新状态信息。线程池通过为应用程序提供一个由系统管理的辅助线程池, 可以更为有效地使用线程[4]。

由于该系统对所有传感器的检测都是持续的, 并且每个线程都与特定设备相关联, 在与设备的通信过程中使用线程池不但起不到任何作用, 而且还会失去对特定设备的自由控制。故在本系统中仅使用线程池做数据处理工作, 而不是实现真正意义上的通信, 图5说明了通信线程与数据处理线程池的关系。

系统为每个设备保留状态信息, 并且通信线程与设备状态信息一一对应, 通过事件触发的方式调用通信线程, 使线程存在时间短, 消耗资源少。如果不单独保留设备的状态信息, 就需要将通信线程设计为持续存在, 并在通信线程内部通过阻塞来控制设备的状态。

4.2数模转换

在煤矿钻机综合性能测试系统中需要用到的部分旧式检测设备串口模块, 由于其设计缺陷或者接地不良, 在通信过程中容易受电流影响损坏, 影响系统的稳定性。部分传感器有配套的数模转换PCI卡, 但这些PCI卡的专用性非常强, 而且必须单独占用一个PCI插槽, 限制了同时接入的数量。

为解决以上问题, 使用了LU-902MR位式调节仪对部分传感设备的模拟信号作转换。LU-902MR采用当今最先进的ATMEL单片微机作主机, 减少了外围部件, 提高了可靠性;集多种输入型号于一机;采用WATCHDOG电路、软件陷阱与冗余、掉电保护、数字滤波等多种技术, 注重现场容错能力;整机抗干扰能力强;输出接口采用模块化结构, 功能配置方便灵活。接线方式见图6。这样能大大降低系统的复杂性, 提高采集效率, 在工程实践中使用LU-902MR使系统在恶劣环境下的稳定性得到显著提高。

5结语

提出并实现了一套计算机软件硬件、专项检测仪器和通信线路结合的煤矿钻机性能综合检测系统, 利用该系统能够检测煤矿钻机在同一工况下的各项性能参数, 生成煤矿钻机性能综合测试报表, 并能对历史数据进行后期分析。该系统已在1个煤炭研究院和1个钻机生产企业正式使用, 具有可观的经济效益和良好的社会效益。

参考文献

[1]邹敢.锚杆钻机的发展现状[J].煤矿机械, 2006 (3) .

[2]李晓, 任作新.矿用综合保护器插件自动测试系统设计[J].煤矿安全, 2007 (5) .

[3]郑玉航, 张合新, 王仕成.控制系统通用综合测试系统组建研究[J].宇航计测技术, 2004 (4) .

省级集中营销管理系统性能测试 篇3

关键词：性能测试；数据处理；场景设计；调优

中图分类号：TP274+.4 文献标识码：A 文章编号：1006-8937（2016）32-0086-02

1 概 述

性能测试是保证软件质量的重要手段，属于软件测试中的系统级测试， 它针对软件在继承系统中运行的性能指标进行测试， 旨在及早确定和消除新系统中的性能瓶颈[1]。

通过负载测试、压力测试等方法的性能测试，测试应用系统能否承受大量的并发用户数以及快速响应用户发送的请求，能否长时间稳定运行。在系统测试期间监控资源、获取性能指标并进行分析，找出系统在硬件、操作系统、数据库、应用软件等方面的性能瓶颈加以改善，使整个系统的性能得到改进优化[2]。

省级集中的一体化营销管理系统服务于全省广大用电客户和适于企业内部管理，具有如下特点：

①在可用性方面，需保证7×24小时不间断运行；

②在业务处理方面，应具海量数据快速处理、复杂业务流转畅顺、资料查询及时响应；

③在系统扩展性方面，需满足多层次应用、地域面积覆盖广、使用人员众多等多方要求。因此，系统的性能测试需要有完整、全面的方案。

为了获取省级集中营销系统性能指标瓶颈，提出改进、优化措施，基于已有成果，本文结合省级集中营销系统的体系结构，在设定具体测试目标基础上，提出了基于海量数据处理的测试场景具体设计原则和监控内容，通过案例分析说明了系统性能调优的具体方法。

2 性能测试概述

性能测试是通过模拟真实环境下的负载，采集系统各方面的性能数据，评估系统正常运行情况下的承受力和稳定性，分析系统的性能与存在的瓶颈。测试方法主要包括负载测试、压力测试、配置测试并发测试和可靠性测试等[3]。在测试过程中，通常需要合理的结合几种测试方法，模拟真实环境，设计不同的测场景获取更多有效的性能指标。

性能测试一般基于如下目的：

①验证系统在给定条件下是否达到设计目标或用户要求；

②探测系统在给定条件下极限处理能力；

③通过对系统各参数的调整，测试系统的最优性能配置；

④通过性能测试发现功能测试难以发现的与性能有关缺陷。

因此，对当前的系统给予相当的负载，并且能够分析系统在给定负载下的表现是实现性能测试的关键。为有效发现负载条件下的各项性能指标，需要筛选分析影响系统的主要测试性能因素，才能做到有的放矢。应用系统性能测试主要包括：响应时间、吞吐量、每秒事务数（TPS）、资源利用率、数据库性能等方面。

在进行性能测试时，需要对系统各个方面（包括系统硬件、操作系统、中间件、数据库等）统一监控，以便进行系统瓶颈的分析与优化。

3 测试方案

省级集中的营销系统为了满足高可用性、高可扩展性和高性能需求，采用了分布式协调服务ZooKeeper和自适配通信环境（ACE）技术构建通用的高性能分布式计算框架；同时，为了满足全省千家万户用电服务、电量电费计量收费的信息支撑服务要求，在系统中存放了海量的用户数据、电网数据，以及系统支持信息。测试场景的设计既要发现系统框架中用户访问的性能瓶颈，又要测试到海量数据处理的反应速度。

3.1 系统结构

基于SOA的多层架构的省级集中系统，在技术路线上采用将表示逻辑、业务逻辑与数据逻辑相分离，客户端支持PC、掌上电脑、手持电脑等设备；接入端通过负载均衡器将用户的访问按照一定的策略分配到不同的服务器群组；应用服务器将展示與运算逻辑分离，而逻辑运算服务组件采用混合模式，针对不同的服务要求采用C或Java来进行开发，以充分利用C语言及Java语言的优势；数据层通过小型机群与存储阵列实现海量数据的存放与访问。

3.2 具体测试目标

评估系统在现有软、硬件环境下可支持业务规模的系统性能。在包括多类业务场景情况下的如下指标：

①访问的平均响应时间；

②访问的最大响应时间；

③平均每秒处理访问数量；

④访问用户的成功率；

⑤规定最大用户并发数下的性能指标。

根据上述量化的指标测试，分析被测营销管理系统在不同并发用户数下的性能指标，找出系统性能瓶颈，提出改善性能方案。

3.3 测试场景设计|

性能测试的用例设计不同于功能测试用例，它只是有针对性地根据系统最可能出现瓶颈的功能点来编写，不需要覆盖整个系统需求[4]。为使性能测试的覆盖率更广泛，性能测试用例的设计需考虑单一场景测试用例和混合场景测试用例的同时存在，性能测试用例中也需考虑并发数、响应时间、持续时间、资源使用情况等关键设计值或者指标值的存在。见表1。

3.3.1 单一场景测试用例

单一场景测试用例（见表1）考察系统对于单一业务的并发处理能力，本次测试选择具有代表性、最核心的9个业务场景，按照实际数据确定并发数。

3.3.2 混合场景测试用例

在性能测试中，常见的错误观点是，认为分别优化单个操作，就能优化系统的整体性能，而事实上系统运行时，不同的操作之间往往对系统资源有互锁关系。为了模拟用户的真实体验，避免性能测试偏重于技术人员的想法，需要综合考虑整个系统的运行情况[5]。省级集中的应用系统中最具有代表性、最核心的9个单一业务场景组合起来则是有代表性、最核心的混合场景的测试用例，见表2。

按照实际数据情况确定并发数。在设计测试场景时，严格按照业务数据的处理关联和顺序，并且为真实模拟实际业务来满足测试的需要。

4 案例测试及分析

性能测试中的测试分析是难点，在应用测试实践中，需要针对具体测试结果进行分析。以下列举本方案中单一登录业务场景的测试及系统性能问题的调优方法和步骤，其中案例所用数据库为Oracle；数据库服务器操作系统为AIX；应用服务器平台为WebLogic。

4.1 测试结果

模拟实际操作员的登陆退出操作的功能，设置1 000并发循环10分钟，测试结果显示登陆的平均事务响应时间为3.139 S，HTTP返回状态全部是HTTP 200状态。

4.2 各测试结果指标分析

①系统响应：在10分钟内运行虚拟用户数一直在1000并发中，平均事务响应时间无特别大的波动，系统在此压力下运行比较稳定。

②在10分钟内每秒点击率图和吞吐量图呈现一致情况，平均每秒吞吐量为14 967 273.462Byte/s=14.27 MB/s，相对于千兆网络不会形成网络瓶颈。

③服务器性能：从Web服务器、Java组件服务器、数据库服务器资源情况来看，Web应用服务器CPU在30%左右，JAVA应用服务器CPU不超过5%，数据库服务器CPU不超过5%，服务器资源运行良好。

從上述结果中我们看到登陆功能压力测试期间运行稳定，各个系统资源没有形成明显的瓶颈。

④问题症结：平均响应时间为3.139 s，不符合要求。针对这种情况，我们对登陆事务进行网页细分进一步查看时间消耗，找到登陆中时间占比最大的页面请求，进一步排查发现登陆功能的页面请求量比较多。

4.3 系统优化

经程序代码排查，简化login.jsp页面请求、压缩grid.js文件组件，提高较大页面组件的执行效率，从而缩短响应时间，提高系统性能。调整后，登陆响应时间满足测试方案需求。

5 结 语

性能测试是应用系统上线前必须经历的过程。系统设计中的任何一个小问题都可能造成严重的性能影响，尤其针对省级集中的系统，一旦出现问题影响范围更大。在性能测试方案中，针对系统特点模拟运行真实的业务场景发现系统架构、系统设计、中间件、数据库、应用服务等各个方面的性能问题，对性能瓶颈有的放矢不断优化调整，使省级集中的营销管理系统达到设计和应用要求，为系统上线打下坚实的技术基础。

参考文献：

[1] 张永祥等.性能测试专家分析系统[J].计算机系统应用，2013，22（4）：6-9.

[2] 李怡，周国祥.基于Load Runner 的一种性能测试流程方案研究与设 计[J].计算机应用研究，2009，26（11）：4143-4145.

[3] 庄严，程绍银，廉明，等.性能测试在等级测评中的应用[J]计算机应用与 软件，2014，31（7）：55-58.

[4] 李怡，周国祥.基于Load Runner 的一种性能测试流程方案研究与设 计[J].计算机应用研究，2009，26（11）：4143-4145.

[5] 简玲.B/S系统性能测试的设计与实现[J].计算机工程，2009，35（10）：

监控系统性能测试报告 篇4

无线通信系统在光纤陀螺性能测试中的应用

以无线通信收发芯片nRF24E1为核心,开发了一种无线通信系统,实现了光纤陀螺到计算机之间无线数据传输,降低了光纤陀螺性能测试中环境引起的.误差,完善了光纤陀螺性能测试系统.系统体积小,装置简单,误码率低,运行稳定.

作 者：徐莉 刘承 XU Li LIU Cheng 作者单位：浙江大学,现代光学仪器国家重点实验室,浙江,杭州,310027刊 名：实验室研究与探索 ISTIC PKU英文刊名：RESEARCH AND EXPLORATION IN LABORATORY年，卷(期)：200726(3)分类号：V241.5关键词：无线通信 nRF24E1 射频 USB接口 光纤陀螺

《超市管理系统》测试总结报告 篇5

《软件测试》

上机5 提交成果

《超市管理系统》测试总结报告

组 号： 05 小组成员： 郭齐 刘正翔 魏彦雄 罗万娟 杨超 王浩简 项目组长： 完成日期：

郭齐

2013年05月27日

目录

一、测试概述...................................................................................................................................3

1.1编写目的.............................................................................................................................3

二、测试计划执行情况...................................................................................................................3

2.1测试类型.............................................................................................................................3 2.2运行环境............................................................................................................................4 2.3计划....................................................................................................................................4

2.3.1测试方案................................................................................................................4 2.4 测试问题总结...................................................................................................................4

三、测试结果...................................................................................................................................4

3.1登录模块测试....................................................................................................................4

3.1.1测试项目名称及测试内容....................................................................................4 3.1.2 测试用例...............................................................................................................5 3.2销售管理模块测试............................................................................................................5

3.2.1测试项目名称及测试内容....................................................................................5 3.2.2测试用例................................................................................................................5 3.3库存管理模块测试............................................................................................................6

3.3.1测试项目名称及测试内容....................................................................................6 3.3.2测试用例................................................................................................................6 3.4订货管理模块测试............................................................................................................7

3.4.1测试项目名称及测试内容....................................................................................7 3.4.2测试用例................................................................................................................7 3.5统计分析管理模块测试....................................................................................................8

3.5.1测试项目名称及测试内容....................................................................................8 3.5.2测试用例................................................................................................................8 3.6系统管理模块测试............................................................................................................9

3.6.1测试项目名称及测试内容....................................................................................9 3.6.2测试用例................................................................................................................9

四、对软件功能的结论...............................................................................................................10 4.1销售管理模块..................................................................................................................10 4.1.2限制......................................................................................................................10 4.2库存管理模块..................................................................................................................10 4.2.1能力......................................................................................................................10 4.2.2限制......................................................................................................................10 4.3 出库管理.........................................................................................................................10 4.3.1能力......................................................................................................................10 4.4统计分析管理模块..........................................................................................................11 4.4.1能力......................................................................................................................11 4.4.2限制......................................................................................................................11 4.5系统管理模块..................................................................................................................11 4.5.1能力......................................................................................................................11 4.5.2限制......................................................................................................................11

五、综合评价.................................................................................................................................12 5.1软件能力..........................................................................................................................12 5.2缺陷和限制......................................................................................................................12 5.3建议..................................................................................................................................12

美萍超市管理系统测试总结报告

一、测试概述 1.1编写目的

这份测试报告是为了测试该系统是否可行。当输入商品的信息是，测试其信息能不能被完整的保存在数据库中以备以后查询用；当输入的数据不符合要求是，看系统能不能给出提示；当价格信息修改后看修改的信息能不能被系统接受并保存到数据库；当输入新顾客的信息时，输入信息是否完整地保存在数据库中，以及当输入老顾客信息时，系统能不能显示完整的信息等等。

二、测试计划执行情况

2.1测试类型

1、用户登录测试：售货员登录销售管理系统模块，输入用户和密码，模块通过连接到数据库，对搜获管理系统中商品信息、销售信息、顾客购买商品的信息的进行检验。

库存管理员登录订货管理系统模块，模块通过连接数据库，对库存管理中的供应商信息、商品信息和特殊商品信息进行检验。

订货员登录管理系统模块，模块通过连接数据库，对订货管理系统中的供应商信息、商品信息和特殊商品信息进行检验。

统计分析员登录分析系统管理模块，模块通过连接数据库，对统计分析中的供应商信息、商品信息和特殊商品信息进行检验。

2、商品录入测试：录入商品信息，对新录入的信息在数据库中进行检验。

3、商品查询测试：输入商品编号，查询商品信息。

4、快速输入测试：商品手动输入模块，通过输入商品编号，查询数据库中商品信息表，包括商品库存量、销售量、供应商等，并显示出信息。

5、收银业务测试：对输入商品进行计价，输入所收取金额，计算出找回金额数并打印货物清单同时保存顾客购买记录。

6、订货业务测试：对库存商品存量与系统指定的库存下限比较，比对供应商 信息，统计订货商品并制定订货单。

7、统计分析业务测试：根据查询的商品信息、销售信息、供应上信息、缺货信息、报表信息和特殊商品信息等，指定报表，以及合理的销售计划表。

2.2运行环境

Windows7 2.3计划 2.3.1测试方案

说明确定测试方法和选取测试用例的原则

测试为四个阶段：单元测试、集成测试、确认测试、系统测试

单元测试：采用黑盒和白盒测试相结合的方法，对于逻辑结构复杂的模块采用白盒测试，对于以输入、输出为主的模块采用黑盒测试，以提高测试效率。集成测试：混合法（对于软件结构中较上层使用自定向下与对软件结构中比较下层使用自底向上方法结合）确认测试：

系统测试：采用人工测试方法。

2.4 测试问题总结

在整个系统测试执行期间暴露了一些问题,表现在：测试执行时间相对较少，测试通过标准要求较低；测试执行人员对管理系统不够熟悉，使用时效率偏低；测试人员对测试系统了解不透彻，测试执行时存在理解偏差，导致提交无效缺陷。

三、测试结果

3.1登录模块测试

3.1.1测试项目名称及测试内容（1）登录、密码模块测试

本测试采用黑盒测试法：为了检测不同权限的用户在 登录时，是否能进入对应的模块并得到对应有的权限，检查密码模块的正确有效 3.1.2 测试用例 测试用例1（正确输入）【输入：】用户；lc 密码：lc 【期望输出】：登录成功，显示前台销售管理窗体 【实际输出】：登录成功，显示前台销售管理窗体 测试用例2（无该用户）【输入】：用户名：aa 密码:aa 【期望输出】：提示用户名或密码错误 【实际输出】：提示用户名或密码错误 测试用例3（密码错误）【输入】：用户；lc 密码：aa 【期望输出】：提示用户名或密码错误 【实际输出】：提示用户名或密码错误 测试用例4（无输入）【输入】：用户： 密码：

【期望输出】：提示用户名或密码错误 【实际输出】：提示用户名或密码错误

3.2销售管理模块测试

3.2.1测试项目名称及测试内容

被测试是采用黑盒与白盒测试，为了检测系统的销售时的收银业务销售定价等功能的输入输出进行验证。3.2.2测试用例（1）收银业务测试 测试用例1（正确输入）【输入】：实收：50 【期望输出】：应找钱数显示的标签上，斌打印顾客货物清单 【实际输出】：应找钱数显示的标签上，斌打印顾客货物清单 测试用例2（输入比应收的少）【输入】：实收：10 【期望输出】：提示输入错误，所买货物价格高于所输入的数目，请检查 【实际输出】：提示输入错误，所买货物价格高于所输入的数目，请检查 测试用例3（输入非数字）【输入】：实收：a 【期望输出】：请输入数字 【实际输出】：请输入数字 【输入】：实收：空

【期望输出】：没有输入数字，请检查 【实际输出】：没有输入数字，请检查

3.3库存管理模块测试

3.3.1测试项目名称及测试内容

本测试是采用黑盒测试与白盒测试混合的测试方法：为了检测系统的库存管理时的入库管理，出库管理等功能的输出与输入进行验证。3.3.2测试用例

（1）商品录入测试

测试用例1（正确输入）

【输入】：条形码：001 商品名称：可口可乐 价格：2.0 【期望输出】：商品录入成功，加入商品列表

【实际输出】：商品录入成功，加入商品列表

测试用例2（已经存在的商品）

【输入】：条形码:1000001 商品名称：雪碧 价格：2.0 【期望输出】：提示商品已经存在【实际输出】：提示商品已经存在

测试用例3（需要录入的商品信息不完整）

【输入】：条形码空 商品名称：可口可乐 价格：2.0 【期望输出】：提示缺少信息/不合法

【实际输出】：提示缺少信息/不合法

测试用例4（需要录入的商品信息与已经存在的存储商品信息矛盾）

【输入】：条形码:1000001 商品名称：雪碧 价格：2.5 【期望输出】：提示缺少信息/不合法

【实际输出】：提示缺少信息/不合法

（2）商品查询测试

测试用例1（正确输入）

【输入】：条形码:1000001 【期望输出】：商品列表中显示该商品，商品名为雪碧

【实际输出】：商品列表中显示该商品，商品名为雪碧

测试用例2（无该商品）

【输入】：条形码:1000001 【期望输出】：商品列表中为空

【实际输出】：商品列表中为空

3.4订货管理模块测试

3.4.1测试项目名称及测试内容

本测试是采用黑盒测试与白盒测试混合的测试方法：为了检测系统的订业务货管理时的订货等功能的输出与输入进行验证。3.4.2测试用例

（1）订货业务测试

测试用例1（正确输入）

【输入】：条形码:1000001 【期望输出】：商品名为雪碧，库存量低于库存下限，请联系供应商A补充货源

【实际输出】：商品名为雪碧，库存量低于库存下限，请联系供应商A补充货源

测试用例2（输入条形码错误）【输入】：条形码:1000001 【期望输出】：提示没有该商品

【实际输出】：提示没有该商品

测试用例3（没有输入条形码）

【输入】：aaa 【期望输出】：输入有误，请重新输入

【实际输出】：输入有误，请重新输入

3.5统计分析管理模块测试

3.5.1测试项目名称及测试内容

本测试是采用黑盒与白盒测试混合测试，为了检测系统分析管理是的查询信息等功能的输入输出进行验证。3.5.2测试用例 测试用例1（正确输入）【输入】：条形码：1000001 【期望输出】：商品是雪碧，今天销量是30，库存还有270.【实际输出】：商品是雪碧，今天销量是30，库存还有270.测试用例2（输入条形码有误）【输入】：条形码：000001 【期望输出】：提示没有该商品 【实际输出】：提示没有该商品 测试用例3（没有输入条形码）【输入】：aaa 【期望输出】：输入有误，请重新输入 【实际输出】：输入有误，请重新输入 3.6系统管理模块测试

3.6.1测试项目名称及测试内容

本测试是采用黑盒与白盒测试;为了检测系统的系统管理时的员工管理、会员管理等功能的输入输出进行检验。3.6.2测试用例（1）员工管理

测试用例1（正确输入）【输入】：员工号：1001 【期望输出】：1001 【实际输出】：1001 测试用例2（输入员工好错误）【输入】：员工号：asdfghjkl 【期望输出】：输入非法 【实际输出】：输入非法 测试用例3（没有输入用户名）【输入】: 【期望输出】：不能为空 【实际输出】：不能为空

测试用例4（输入部门号不存在）【输入】：1234556 【期望输出】：没有该部门 【实际输出】：没有该部门

测试用例5（电话号码不符合规范）【输入】：qwer 【期望输出】：电话号码错误 【实际输出】：电话号码错误

四、对软件功能的结论

4.1销售管理模块

超市管理系统下的一个子系统，记录售货员今日处理的商品信息和会员的购买情况，处理销售过程中的商品信息并作记录。

包括售货员登录和会员登录，以及售货员的售货处理、结账处理。4.1.2限制

（1）只能在购物一开始输入会员信息，不能在扫描商品中途登录会员；（2）删除待购商品时只能一条记录全删掉，不能指定删除指定数量。4.2库存管理模块 4.2.1能力

商品信息入库功能；对商品进行入库，录入商品编号，商品名称，数量总价等信息，存入数据库中，方便以后查询，并修改数据库中库存的数量，并将其打印显示在屏幕上。4.2.2限制

我们使用的测试数值如下： 001大宝SOD蜜 30件 300元 002中华健齿白牙膏 20件 100元 成功出入数据库中，未发现任何明显错误。4.3 出库管理 4.3.1能力

商品信息出库功能：对商品进行出库，打印出商品编号，商品名称，数量，总价等信息，存入数据库中，并修改数据库中库存的数量。4.3.2限制

我们使用的测试数值如下 001 大宝SOD蜜 15件 150元 002 中华健齿白牙膏 10件 50元 成功修改数据库 剩余的库存为：

001大宝SOD蜜 15件 150元 002中华健齿白牙膏 10件 50元 成功操作，未发现任何明显错误。4.4统计分析管理模块 4.4.1能力

统计分析管理包括查询商品信息、查询销售信息、查询提应商信息、查询缺货信息、查询报表信息和查询特殊商品信息，并制作报表。

统计分析员使用体统分析功能，了解商品信息、销售信息、供应商信息、库存信息和特殊商品信息，以便能够指定合理的销售计划。4.4.2限制

（1）统计分析只能查询指定条件的数据，但不能根据结果，自动生成分析结果，或是图表显示，不直观。

（2）几个相关联的数据查询不能一次到位。还需以后改进。

4.5系统管理模块

4.5.1能力

系统管理包括维护员工信息。维护会员信息和系统维护。

系统管理员通过系统管理功能，能够了解公司员工信息。会员信息，还能够对系统进行维护工作。4.5.2限制

（1）只能对员工信息、会员信息进行管理，不能对整个系统进行维护进行维护。（2）管理员的权限的设置问题，其可以看到所有信息。

五、综合评价

5.1软件能力

超市管理系统下的一个子系统，记录销售员今日处理的商品信息和会员的购买情况，处理销售过程中的商品信息并作记录。

包括售货员登陆和会员登陆，以及售货员的收售货处理、结账处理。

商品信息入库功能：对商品进行入库，录入商品编号，商品名称，数量 总价等信息，存入数据库中，方便以后的查询，并修改数据库中库存的数量，并将其打印在显示屏幕上。

商品信息出库功能:对商品进行出库，打印出商品编号商品名称，数量 总价等信息，存入数据库中，方便以后的查询，并修改数据库中库存的数量，并将其打印在显示屏幕上。

统计分析包括查询商品信息、了解商品信息、销售信息、供应商信库存信息和特殊商品信息，以便能后定制出合格的销售计划。

5.2缺陷和限制

（1）只能在一开始输入会员信息，不能在扫描商品中途进行登录会员（2）删除待够商品时只能删除一条信息

（3）统计分析只能查询指定条件的数据，但不能根据结果自动生成分析结果。（4）几个相关联的数据查询不能一次到位，还需改进

（5）只能对员工信息、会员信息进行管理，不能对整个系统进行维护。（6）管理员的权限的设置问题，起可以看到所有信息。

5.3建议

测试设计基本覆盖了需求的各个功能模块，发现了很多编码错误以及逻辑错误，不过由于人力以及时间的不足，所以还有许多改进的地方，如白盒测试的力度还不够，有很多提高空间。

银行性能测试项目小结 篇6

本次性能测试的系统是X银行营销服务系统总行版，该系统使用的数据库服务器、应用服务器均布署在总行机房，各地分行通过 WEB 方式登录访问本系统。系统上线后的总用户数（包括各分行、支行主管，客户经理等）在 5000 左右。

该系统采用 DB2 数据库、WebLogic 应用服务器。

本次性能测试进入的条件是系统的代码已经基本完成并经过功能测试。

2、测试计划

在确定了本次性能测试的要点后，我们初步拟定一份性能测试计划，提交给客户，并获得了客户的认可。在本文中不列出项目测试计划中的所有内容，仅就主要问题进行说明。

测试范围：在真实业务局域网测试环境下，对系统实施并发性能测试的同时，监控 Web 服务器和数据库服务器的系统资源，以及数据库资源的使用情况。

测试内容：并发性能测试、系统资源监控。

测试方法与工具：采用自动测试与人工测试相结合的测试方法，测试工具使用 LoadRunner。

测试资源：测试环境及测试数据准备。

3、测试用例

确定了测试计划，我们针对该系统的特点，从中挑选出三个有代表性的功能点，作为本次性能测试的用例。我们认为作为银行的营销服务系统，最常使用且对于系统的整体性能有着较大影响的是“客户信息查询”和“客户对账单查询”两个模块。因此，我们设计了三个单交易性能测试用例，分别是：“用户签到 / 签退”、“客户信息查询”、“客户对账单查询”。然而客户却对此提出异议，他们认为我们设计的测试用例数量太少，要求我们的测试用例应包含更多的功能模块。经过会议讨论，最终我们根据客户给出的一份性能测试大纲，针对其中提出的测试内容、测试策略，以及测试目标，将单交易测试用例增加到十四个。

测试用例采用以下格式：

要求清晰地描述出详细的操作步骤。

4、测试数据

针对以上设计的测试用例，需要准备大量的业务数据。本次性能测试的环境即系统上线后真实运行的环境，所有的业务数据均来自兴业银行的真实核心系统（通过 ETL 转换），数据量已经能满足测试的需要。

由于测试用例中要求执行并发操作的时候使用不同身份的用户登录系统，因此在测试开始前需要准备一批具有不同身份的用户名（包括各分支行的主管以及客户经理），并且要有相应的操作权限。

对于“积分转移”、“积分兑换”、“礼品兑换”等等交易，则需要提供一批卡上有足够积分的客户理财卡号。

以上测试数据由兴业银行负责提供，在性能测试执行之前提供给我们。

5、测试脚本

使用性能测试工具 LoadRunner 录制并调试测试脚本，对相关的输入项进行参数化。

6、测试实施

在 LoadRunner 中执行测试脚本，实施性能测试。对于每个单交易测试脚本各执行一轮测试，并按一定的用户比例设计出一个混合交易场景，令其自动持续运行五小时左右，观察系统的性能表现。每次执行的结果文件均保存下来，待测试完成后连同性能测试报告一并交付客户确认。在此过程中，需要监视相关的系统资源使用情况，包括：应用服务器和数据库服务器的所有系统资源指标，所有数据库资源指标。

7、测试结果

经过本次性能测试，发现了系统五个主要的性能问题。我们与程序开发人员一同分析问题产生的原因，并给出改进建议，一起记录到测试报告中。其中的一个问题在性能测试报告提交客户之前已经过优化，得到显著改进。

8、测试结论

测试结果显示，系统性能能满足测试目标，交易并发数达到或超过30个，批量交易（查询记录50条以上的交易）并发数也能达到或超过10个，交易平均响应时间在2－12秒内，90％平均响应时间在2－15秒间完成。

混合交易案例持续运行 5 小时，运行结果正常，系统没有报任何错误，系统稳定，可用率应达到100％。

另外如在ETL批处理期间运行 营销服务系统，系统性能明显下降，建议ETL批处理在夜间处理，避免影响 系统的正常运行。

9、经验

在本次性能测试的过程中，我们遇到一些问题，通过解决这些问题，从中获得了一些经验。现总结如下：

问题一

在我们对系统进行测试的过程中，某些操作是相关联的。例如我们测试“查看客户资产历史” 这个交易的系统响应时间，这时需要先列出客户的基本信息，选中一个客户，点击打开另一个页面，才能查看到该客户的资产历史信息，同时，在测试脚本中需要对所选择的客户编号做一个参数化，但由于 LoadRunner 不提供像 WinRunner 或 QTP 一样识别页面对象的功能，如果在 Vugen 中直接抓取页面上显示的客户编号去参数化，实现起来将十分烦琐。考虑到在以上那两步操作中，第一步“列出客户基本信息”只是辅助的操作，而第二步操作“查看客户资产历史”才是我们要测试的功能点，因此我们忽略了这二者之间的关联性，仅对第二步操作中的客户编号进行参数化。（只要服务器端对此不加验证，甚至我们将第一步操作都忽略掉，也是可行的）。

结论： LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们只需将要测试的交易或功能点所需要组装的报文传送给后台服务器即可（因为我们关注的只是系统的性能，不是功能），而不必像功能测试那样，按部就班地重现每一步操作。

问题二

在测试过程中，我们发现有一个查询交易的系统响应速度特别慢，无论是在 Controller 中使用单个虚拟用户执行脚本，还是在 Vuser 中直接运行，情况均是如此，然而当我们用手工进行同样操作的时候，响应时间却明显地小于工具统计出来的时间，也就是说，在 LoadRunner 中模拟操作的结果与真实操作的结果明显不一致。经过反复尝试与观察，我们才终于找到问题的原因所在：该查询交易是通过客户的证件号码查询客户信息，当用户输入客户的证件号码时，如果没

有选择证件类型，系统会自动将证件类型设置为默认值“身份证”。按“证件类型 + 证件号码”为组合索引查询客户信息表，查询速度极快，而在我们录制脚本时，忽视了“证件类型”这项输入，只有“证件号码”，因此查询的效率大为降低。解决办法：只需在测试脚本中，对 CertType（“证件类型”）一项赋值为“ A ”（“身份证”），此时在 LoadRunner 中重新运行该脚本，响应速度提高，统计结果与实际完全一致！

结论： LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们在测试脚本中组装发送到服务器端的报文时，注意一定要和实际操作时的发送报文完全一致，这样才能保证测试的结果与真实情况相吻合。这就要求在测试正式开始执行时，要对测试脚本进行反复的调试，通常的做法是：在 Vugen 中执行一遍脚本，统计执行某个事务的时间，再用手工实际做一遍同样的操作，大体上比较一下，确保与实际估算的时间没有太大出入后，再逐渐增加并发用户数，正式开始性能测试。

问题三

在我们的每个测试脚本中的 init 部分，都录制了登录系统的操作，并且对登录的用户名进行了参数化，使用各种不同身份的用户（分行主管、支行主管、客户经理等）进行相同的操作。在并发测试过程中发现对某些查询交易测试的结果波动较大，系统响应时间从零点几秒到几十秒不等。经检查后发现原因在于：使用不同身份的用户登录系统后，在输入查询条件后，点击查询按钮后会将根据该用户的身份，将其所属的分行机构号、支行机构号、客户经理编号等一并提交，因此在脚本中，就必须根据不同的用户身份，分别将其对应的分支行机构号等也运用参数提交，否则在执行脚本时就会出现查询不到记录或查询速度变慢等各种问题。解决方法有三个： 1、修改脚本，使其能够依据用户的身份分别传送相应参数，2、针对不同类型的用户使用不同的脚本分别测试。3、输入参数使用统一的用户类型。在实际中，我们为了简化脚本的复杂度，节省对脚本编程的时间，采取的是第三种方法。

结论：由于 LoadRunner 的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，因此它会跳过在应用程序前台进行的校验，所以在脚本回放的时候一定要注意在脚本中提前进行这些校验或改由人工控制，以保证发送报文的正确性（如操作权限的控制等）。

问题四

测试多用户并发登录系统的时候，从虚拟用户图和事务图上发现，总有一部分用户在登录的时候要等待很长时间，用户登录的最小时间与最大时间相差非常大。于是我们在让脚本自动运行的同时，手工再登录一个用户，发现无论如何都不会发生等待的情况，多次试验的结果均是如此，也就是说 LoadRunner 测试的结果与实际结果再次发生了偏差！经过反复的调试，以及与程序开发人员沟通，我们终于发现问题的原因所在：在用户登录系统的时候，系统会自动记录登录用户的信息，并产生一个登录 ID，以此 ID 做为主键，向数据库插入记录。因此当大量用户在极短的时间内同时登录时，就有可能出现生成相同的登录 ID 的情况，此时便会造成数据库中的主键冲突，导致用户等待很长时间或登录失败。而我们手工测试时却无法做到在很短的时间内同时登录，因此很难用手工重现此种

情况。通过 LoadRunner 的模拟表现出来的状况，正是我们测试出程序存在的性能问题，并非与实际结果的偏差。

还有一个例子，在第二轮性能测试中，同样发生了类似的情况。在本系统中，如果同一个用户登录后，未正常退出超过 5 次，系统将会把该用户锁住，使其无法再次登录，而我们用于参数化的用户名个数有限，因此当脚本使用大量用户同时登录时，很容易造成同样的用户登录系统而未签退的情况发生（脚本正在执行，还未能退出），此时将会造成许多用户操作的失败。

结论：使用 LoadRunner 可以模拟出大量用户同时对系统操作的情况，而这些情况通过手工往往是很难重现出来的。例如大量用户在同时对系统做某些操作时，很容易造成数据库的死锁、锁等待、主键冲突、数据混乱等等问题，因此在做性能测试的同时，也常常可以连带测试出系统的一些隐蔽的“缺陷”。在本次性能测试中，这种例子是很多的。对待此类“缺陷”，应具体情况具体分析。有些确实是程序的 BUG，需要修正，而有些可能只是很极端的情况，只有在做压力测试时才有可能发生，可不必深究。

问题五

此问题发生在第二轮测试（即回归测试）中。在第一轮测试中发现的性能问题，经程序员修正后，我们对系统进行了第二轮性能测试，以验证其性能改进的效果。在前一轮测试中，我们发现通过选择客户级别为“未评级”时，查询的速度极慢，经过改进后，速度应有较大提高。然而在回归测试中，却依然很慢。经过对测试脚本和程序的仔细检查，才发现原来在程序中已将“未评级”这个选项去除，而我们的测试脚本的参数文件中仍然保留有该选项，因此测试的结果与前次没有区别。在参数文件中将该选项去掉后，测试结果正常，查询效率有所提高。

结论：使用录制好的测试脚本进行回归测试之前，一定要先仔细检查、了解程序的改动，对原先的测试脚本做必要的修改后，才可以重新测试，否则只是在做无用功。

10、教训

在本次测试过程中，由于经验不足，我们也得到了一些教训。前事不忘，后事之师，现总结出来与大家分享。

l 与客户的沟通做得不够，客户要求我们做的性能测试用例数量太多，我们未能据理力争，最后导致工作量过大。

l 按照原定的项目计划，我们要在系统的功能测试即将结束前进驻项目组，准备并进行性能测试。然而由于客户在功能测试的后期仍然不断的提出新需求，导致开发人员疲于奔命，系统的性能难以稳定下来，性能测试的前期准备工作也受到很大影响，不能正常开展，浪费了很多人力物力。

l 由于客户无法提供一个单独的性能测试环境，我们的性能测试工作与业务组的功能测试在同一个环境下进行，而系统的功能测试迟迟未能完成，加上 ETL（数据转换）小组对数据库资源的占用，因此我们的性能测试只能在夜间才能进行。导致时间上的浪费，使项目的成本增加。

l 没有将性能测试中发现的缺陷记录到缺陷管理工具中加以跟踪，而仅仅体现在最后的测试报告上，个人认为这是比较不规范的做法。

l 性能测试前的数据准备不够充分。客户提供测试的系统用户、身份数量有限，导致许多案例的测试只能使用少量数据进行参数化，由此带来许多本可以避免的问题。

l 测试计划及测试报告的书写格式缺乏规范，尤其测试计划书未能包含本应包含的所有内容。

l 在我们将 LoadRunner 的测试结果文件全部提交给客户的前提下，客户仍然要求我们在测试报告中将每一次测试的数据均以表格的形式填至测试报告中，此项工作的工作量十分巨大，个人认为这样做并无必要。

旋风刀架性能测试系统研究 篇7

曲轴是发动机内部最为关键的部件,曲轴精度的高低与自身结构的优劣对发动机性能具有决定性的影响[1]。曲轴的加工工艺复杂,大型曲轴制造加工工艺更加复杂,由于其自身尺寸大、质量大,所以一般需要专用机床加工[2,3]。

数控重型曲轴铣车复合加工中心是加工船舶用大型曲轴的关键设备,它能够同时满足大型曲轴对车削加工和铣削加工的需求,方便地完成曲轴径与主轴径的加工,简化曲轴加工工艺,提高加工精度。数控重型曲轴铣车复合加工机床的核心部件是分体开合式数控旋风切削刀架,旋风刀架负责完成曲轴径的精密加工,与普通车削加工不同,在其加工过程中,工件固定不动,通过刀盘的旋转带动刀架旋转,进而完成对曲轴径的加工。

在旋风切削刀架中,加工工件时工件的振动特性与U轴(刀座)精密进给精度是两项关键技术指标,对工件的加工精度具有显著影响。U轴(刀座)进给运动采用闭环控制,进给精度可达±2μm。本文通过制定测试系统方案,选用测试所需硬件以及开发测试系统软件,来完成这两项指标的精度测试。

1 测试系统设计

1.1 测试系统方案设计

结合测试任务,制定测试系统方案,如图1所示。选用KISTLER微型加速度计采集旋风刀架进行切削加工时工件在X、Y、Z三个方向加速度的变化,并通过研华公司生产的USB-4711A数据采集器接收加速度信号。采用HEIDENHAIN光栅长度计采集位移信号,并通过PIC16F877A单片机完成对长度计输出脉冲信号的辨向和计数。数据采集过程均由计算机内的测试系统软件进行控制,测试系统软件能够控制数据的采集、传输,并能实现图形绘制、数据输出等功能。

1.2 测试系统硬件结构与软件开发

1.2.1 振动加速度信号采集

(1)KISTLER微型加速度计。

本次测试采用KISTLER 8765A250M5微型三向加速度计来采集工件在X、Y、Z三个方向的加速度变化数据,它的量程范围是±250g,灵敏度为20mV/g,工作温度范围是-54～165℃,壳体与地绝缘,具有很好的灵敏度稳定性,在整个工作温度变化范围内,灵敏度的变化仅为1.6%,因此在复杂的环境下仍然可以保持较高的测试精度。采集到的数据通过三向电缆传送给KISTLER5134B电荷放大器,进而传至送数据采集器中。

(2)研华USB-4711A数据采集器。

USB-4711A数据采集器上配有FIFO,可储存高达1kB的A/D采样数据,可实现高速数据传输,采样速率可达150kB/s,能够实现单端或差分混合的模拟量输入、可编程计数器等功能,可以满足本次测试任务需要。

使用该数据采集器时,可通过三种触发方式进行数据采集:①代码编写比较简单,适合低速采集的软件触发方式;②适合高速采集的中断触发方式;③DMA触发方式,目前应用较广的是中断触发方式。本次测试采用多通道中断触发方式进行数据采集[4],数据采集流程如图2所示。

1.2.2 位移信号采集

(1)HEIDENHAIN光栅长度计。

HEIDENHAIN-MT2751是测量精度与分辨率均较高的光栅长度计,测量范围为25mm,分辨率为0.2μm,结构坚固,便于使用。当被测物体发生位置变化时,它会产生两路相差1/4周期的脉冲Ua1与Ua2,脉冲的个数正比于位移的大小,脉冲的频率正比于速度的大小,方向由两路脉冲相位确定。通过对两列脉冲的辨向计数就可以获得被测物体的位移信息。

(2)PIC16F877A单片机。

单片机通过软件计数方式对长度计输出的两路脉冲信号进行辨向计数。软件计数方式是指通过在一路脉冲信号的下降沿处判断另一路脉冲电平的高低进行加减计数[5]。位移信号采集电路如图3所示。

在此电路中,单片机的INT/RB0端口是中断触发端,检测长度计输出的一路脉冲信号中的下降沿;RB3作为另外一路信号的接收端,通过单片机内部的编程实现对RB3接收信号电平高低的判断,完成辨向计数,通过计算机内的MSComm控件完成单片机与计算机之间的串口通信,将计数值传输给计算机[6]。单片机数据采集流程如图4所示。

由于PIC16F877A是8位单片机,为扩大计数范围,程序中定义的计数值变量count是16位的。为了避免数据传输中的传输错误和丢失数据,需要将count拆分成两个字节,并制作成一个数据包发送。数据包的格式为“头标识+数据+尾标识”,用这种方法发送的数据中,如果有作为头尾标识和控制符的字节,则要转换为“控制符+字节”。在该方法中,头标识为0xDB,尾标识为0xDE,控制符为0xDC,数据包含两个字节,先发送计数值count的高八位,再发送count的低八位。当计算机端接收到数据后可作相应的处理,提取数据包中有效的数据部分。

2 试验测试与数据处理

由于厂方未能在规定的时间内完成旋风刀架的加工与装配工作,因此不能针对旋风刀架做实际测试。但为了验证测试系统的正确性与可行性,需要采用其他机床来进行替代性的试验测试。结合现有条件,分别针对实验室内的开放式五坐标数控加工机床铣削块状工件上表面时工件的振动特性与立铣床Y轴工作台进给精度进行测试。

虽然在替代性试验测试中机床的加工情况与旋风切削刀架铣削轴径表面的加工情况并不完全一致,但是从信号采集、数据处理的角度来说,所设计的测试系统运行的情况基本相同,因此替代性试验测试能够验证所设计的测试系统能否应用到实际当中。

2.1 振动性能测试

2.1.1 试验测试

此项测试针对开放式五坐标数控加工机床,当它铣削块状工件的上表面时,工件会发生一定的振动,利用固定在工作侧面的加速度计来检测工件三个方向加速度变化情况。分别采集在表1所示的两种工况下工件加速度的变化情况。

在数据采集过程中,设置采样率为400,由于在加工过程中,X方向为切削力主方向,其加速度变化幅度大于Y方向和Z方向,因此,本文只对两种工况下X方向的加速度进行数据处理,由X方向加速度数据曲线。可以看出,工件振动加速度数值变化存在着一定的规律,工件加速度的变化趋势也反映了在切削过程中工件所受合外力的变化趋势。

2.1.2 数据处理

由于测试数据中存在较多干扰信号,为了提取X方向加速度信号中的工件振动信号,排除传感器的漂移、外界噪声的干扰,有必要对数据进行处理。采用MATLAB数据处理软件对加速度数据进行分析处理。数据处理过程主要包括滤波、去均值、去趋势项[7,8],对数据进行滤波,在数据处理中主要用到了以下函数:

da=dtrend(da);%去除数据向量da中的直流分量

da=dtrend(da,n);%去除数据向量da中的n阶趋势项

da=idfilt(da,n,fz);%对数据向量da进行滤波,阶数为n,fz为截止频率的上下限

首先对数据进行傅里叶变换,计算功率谱,得到两种工况下X方向加速度频谱特性,如图5所示。通过对频谱特性的分析可知,工况1下切削振动的主能量发生在频率为100Hz左右,工况2下为100Hz和150Hz左右。测试中,奈奎斯特频率为200Hz。从图5也可以看出,信号中存在着低频振荡,影响了数据测量的精度,通过设置idfilt函数中的fz参数(实际频率与奈奎斯特频率的比值),可以过滤掉这些干扰信号,处理后得到的加速度数据曲线如图6所示。

通过对数据的处理与分析可知,在不同的主轴转速、不同的进给量、不同的吃刀量下,工件的振动加速度变化情况是不相同的。主轴转速与工件进给速度对工件的振动特性均有很大的影响。通过此项测试可知,该测试系统能够满足采集振动信号的需要。

2.2 U轴进给精度测试

2.2.1 试验测试

立铣床的工作台Y轴采用闭环控制,进给精度为±1μm。在测试中,编制数控程序使立铣床的工作台沿Y轴在不同的进给速度下做低速运动,利用长度计采集Y轴进给运动的位移数据。图7所示为进给速度为1mm/min时测试软件的显示界面,通过此项测试可以看出,所设计的测试软件运行正常,能够较好地采集、处理、保存数据。

2.2.2 数据处理

从图7所示的位移时间曲线软件界面上可以看到数据处理结果,其中采集到的数据个数N为1499,数据最大值为4.9984mm,最小值为-0.0018mm,平均值为2.4659mm,最大位移偏差Δsmax=0.0147mm,最小位移偏差Δsmin=-0.3399mm,这段位移上的位移误差为

Δs=Δsmax-Δsmin=0.3546mm

位移标准差为

$\sigma {}_{\text{s}}=\sqrt{\frac{1}{{\rm N}-1}{\displaystyle \sum _{i=1}^{{\rm N}}(}s{}_i-\widehat{s}{}_i){}^2}=0.0001$mm

由所测得的数据可以看出,测试系统软件较好地实现了对工作台进给精度的测试。但是通过试验也能够发现,测试结果有一定的误差,这是由于长度计的精度与分辨率比较高,对外界环境要求较为严格,而实际测试环境较差,周围振动、噪声等干扰信号对测试结果造成了一定的影响,因此,在以后的实际测试中,应当注意改善测试环境,减少外界环境的干扰,提高测试精度。

3 结语

为检测分体开合式旋风刀架的加工精度,本文针对其加工工件时工件的振动性能与U轴(刀座)进给精度两项指标开发了性能测试系统,完成了测试系统的硬件搭建与测试软件的开发, 结果表明,测试系统能够较好地完成对测试信号的采集与处理,能够以图形和数据文本的形式将数据进行输出。最后,通过试验测试与数据处理,验证了所开发的测试系统的正确性与可行性。

参考文献

[1]Crooks C S,Parker D D.The Importance of Crank-shaft Surface Texture to Bearing System Reliability[J].SAE Technical Paper,960983.

[2]刘玉岩,任光胜.船用柴油机的大型曲轴机械加工工艺浅析[J].机械设计制造,2008(12):242-243.Liu Yuyan,Ren Guangsheng.Analysis of MachiningTechniques of Large Crankshaft Used by Ship’sDiesel Engine[J].Machinery Design&Manufac-ture,2008(12):242-243.

[3]Lorincz J A.Flexible Crankshaft Finishing[J].Tool-ing and Production,2004,70(10):1-1.

[4]曹毅,陈漫.探讨研华32位DLL驱动程序[J].自动化技术与应用,2002,21(6):57-59.Cao Yi,Cheng Man.About the Advantech 32-BitDLL Driver[J].Techniques of Automation and Ap-plications,2002,21(6):57-59.

[5]潘明东.光电编码器输出脉冲的几种计数方法[J].电子工程师,2004,30(8):69-71.Pan Mingdong.Several Methods of Output PulseCounting for Photoelectric Encoder[J].ElectronicEngineer,2004,30(8):69-71.

[6]Penfold R.Adding MSCOMM Active-X Control toYour PC[J].Everyday Practical Electronics,2002,31(10):746-746.

[7]余萍,胡孝平.MATLAB在振动台试验数据处理中的应用[J].深圳土木与建筑,2007,4(4):109-110.Yu Ping,Hu Xiaoping.Application of MATLABSoftware in Data Processing for Vibrating TableTest[J].Journal of Water Resources and Architec-tural Engineering,2007,4(4):109-110.

企业无线网性能测试 篇8

相对于传统的802.11 a/b/g产品, 支持802.11n规格的无线设备能够获得更高的传输速率和更为宽广的信号覆盖范围,已成为无线部署的主流之选。因此,我们在性能测试中使用了两台支持双基站模式的MSM 422智能接入点,考察HP ProCurve企业级无线解决方案在802.11n部署模式下的性能表现。这两个接入点均连接至一台8端口交换机,使用PoE供电的方式进行驱动。根据日常应用的实际情况,测试用例分为“无线-有线”、“无线-无线”两种方式,分别测试1台无线终端(Laptop1)与1台服务器(Server)之间和两台关联到不同接入点的无线终端(Laptop1、Laptop2)之间的性能。

现实生活中存在着大量工作在2.4GHz频段的无线设备,为了减小信号干扰给传输性能带来的影响,802.11n无线标准也允许设备工作在5.8GHz频段。而在政策层面,我国已开放5.8GHz频段用于高速无线局域网等数据业务。鉴于此,我们将MSM 422智能接入点的无线电模组配置为802.11n模式,使其工作在5.8GHz频段(3x3 MIMO Radio)。测试用笔记本电脑内置了Intel Wireless WiFi Link 4965AGN无线网卡,支持同样的连接规格。在整个测试过程中,笔记本电脑与MSM 422之间协商的通信速率基本保持在300Mbps,并能长期保持稳定。

吞吐量是网络性能评估中最关键的指标,无线领域尤为如此。在“无线-有线”测试用例中,无线终端单线程上/下行吞吐量分别达到120Mbps/98Mbps;当采用10个线程进行测试时,上/下行吞吐量更是达到157Mbps/111Mbps。而在“无线-无线”测试用例中,由于两个节点都采用无线接入的方式,我们实测得的单线程/10线程下行传输速率分别为56Mbps和73Mbps。总体看来,这三组成绩不但大幅度超越了传统的802.11 a/b/g产品,也显著高于我们测试过的所有消费级802.11n产品,很好地体现了企业级801.11n无线解决方案的性能优势。

人们希望802.11n带来应用体验的全面提升,而愈发复杂的业务势必要对无线传输质量提出更高的要求。以基于无线网络的高清视频播放为例,除了要有充足的带宽,网络延迟与抖动也必须足够小才行。本次测试我们就模拟了这种应用,对HP ProCurve企业级无线解决方案进行了全面考察。我们使用思博伦通信提供的Spirent Warrior解决方案,通过Central Warrior控制部署在两台笔记本电脑和服务器上的Edge Warrior,先后单向传输10Mbps和40Mbps的UDP数据流(模拟高清码流,帧长1518byte),时间为30分钟。在10Mbps负载下,无论是无线端从有线端下载,还是无线端之间的传输,传输质量都非常稳定,丢包率均为0;而使用40Mbps流量进行测试时,无线端从有线端下载丢包率仍然为0,无线端之间传输则出现0.14%的丢包。通过分析实时延迟曲线,我们判断这与无线传输方式本身的不确定性导致的速率波动有关。在真实的使用环境中,只要传输时延与抖动在合理范围内,这个数量级的丢包率还是无伤大雅的。