实现和测试(精选十篇)
实现和测试 篇1
2003年IEC发布IEC 61850Ed 1.0,定义了IEC 61850标准,该标准可使不同厂家制造的智能电子设备(IED)实现互操作,2009年开始,IEC61850Ed 2.0也陆续开始发布,Ed 2.0是对Ed 1.0进行全面的修订和扩展,IEC 61850标准已被广泛用于变电站自动化系统当中。通过IEC TC57WG10以及IEC,IEEE,CIGRE等组织的合作,将IEC 61850应用扩展至发电厂、输变电设备检测、配电自动化系统和分布式能源等领域。目前IEC61850已经成为智能电网建设的重要基础性标准之一,IEC 61850本身也演变为一个庞大的技术体系[1,2,3]。
在实际工程中,由于各个厂家对协议标准理解的不一致,实现方法不同,导致出厂设备并不能完全符合IEC 61850标准,从而给实际的互操作性带来了问题。因此,IEC 61850的一致性测试是确保同一厂家或不同厂家的IED之间能够相互操作的关键,也是IED开发过程中的重要环节[4],而IEC61850的第10部分IEC 61850-10也对一致性标准检测提出了严格的测试要求。根据IEC 61850-10的规定,一致性测试主要包括数据模型测试、配置文件测试和抽象通信服务接口(ACSI)模型和服务映射测试等。
IEC 61850服务器一致性测试是智能电网中产品质量保证链的重要环节,是保障智能变电站内智能设备产品质量的重要手段。
一致性测试通常采用KEMA公司的一致性测试软件(UniCA sim61850simulator)进行测试,该软件基于IEC 61850-10编写用例,所有用例采用VB编写并完全开源,用户可根据自己的需求进行修改以实现二次开发的目的,但目前在Ed 1.0测试的使用过程中,还存在以下问题:(1)测试用例不包含硬件设备的调用接口,自动化程度不足,被测智能设备和测试软件系统之间没有形成完全闭环,测试过程中需要测试人员手动变化多种物理量,影响了测试的效率;(2)目前一致性测试软件采用PC机共端口模拟制造报文规范(MMS)和通用面向对象变电站事件(GOOSE)服务,不符合国内MMS和GOOSE分层分板卡的架构;(3)目前一致性测试软件涵盖大部分服务的测试用例,尚不能支持日志、采样值(SV)和国内规范[5]。
针对这些问题,本文在综合已有一致性测试技术的基础上,开发一套支持软硬件闭环的一致性测试系统,系统包括软硬件的平台部分和用例部分。软硬件平台的搭建既要满足实际工程中使用的Ed1.0测试的需求,也要满足Ed 2.0和国内扩展应用的需求,测试用例也相应包括了Ed 1.0和Ed 2.0及国内扩展应用部分。本文主要针对测试平台和Ed 1.0测试用例进行说明,并对实际装置进行了测试用例验证,Ed 2.0和国内扩展应用部分的介绍和验证则在系列文章的第二篇进行说明。
1 技术方案及相关原理
目前,在智能变电站的IEC 61850一致性检测方面,能同时全面兼容国内外标准测试的还较少,加之IEC 61850标准自身在通信功能、模型、设备与模型对应等方面的不足,已有的平台依然有待完善。本文在测试用例设计以及测试方法上充分考虑了IEC 61850-10Ed 1.0规范,增加了可内部通信的硬件设备,采用Qt、动态库DLL和Python语言等技术来完成相关一致性测试任务。Python脚本是一种面向对象、解释型计算机程序设计语言,用于完成对测试用例的规则编写。Qt是跨平台的C++图形用户界面应用程序框架,实现Python脚本的编辑和执行[6]。测试用例涵盖连接服务、控制服务、定值服务、报告服务、文件服务、GOOSE服务[7]等,并引入了SV发布和订阅的测试用例,填补了业内相关应用的空白。
在连接服务、控制服务、定值服务、报告服务和文件服务的测试用例实现上,测试软件运行的PC侧端口与被测设备端口通过以太网进行直接通信。
在GOOSE/SV报文测试方面,将MMS报文引入测试,通过与IED进行直接的MMS通信,获取其对应的MMS报文进行辅助分析。由于PC的实时性和处理能力限制,无法直接与被测设备通信,因而需要引入配套的一致性测试硬件平台。一致性测试硬件平台主要用于与被测设备进行GOOSE和SV报文通信,并协助一致性测试软件平台进行某些测试项目必需的激励输出。测试用例中通过SV,GOOSE,MMS报文的配合和组合使用,从而实现对智能变电站的IEC 61850一致性测试结果的自动分析[8,9]。下面以过程层GOOSE和站控层GOOSE为例对GOOSE闭环一致性测试原理进行说明。
1.1 过程层GOOSE测试
过程层GOOSE测试平台搭建示意图如图1所示,展示了MMS和GOOSE不共用通信口情况。
对应闭环测试方法框图如图2所示,包括一致性测试软件平台(安装在PC端)、一致性测试硬件平台、被测设备、交换机及对时源组成闭环测试系统。一致性测试软件通过内部协议与硬件平台进行通信,一致性测试硬件平台可与被测设备之间发布和订阅GOOSE报文,并可将接收到的GOOSE报文转送给软件平台;测试软件平台亦可与被测设备进行MMS通信,获取被测设备的MMS报告;对时源向测试软件和被测设备进行简单网络时间协议(SNTP)对时;测试软件通过测试硬件对被测设备进行GOOSE数据的发布和订阅,同时将被测设备的MMS数据接入,通过数据关联关系和数值比对,进而完成对被测设备的闭环测试[10,11,12]。
具体过程层GOOSE闭环测试过程如下。
1)直接与被测设备进行MMS通信,获取被测设备的MMS报文。
2)根据MMS编解码动态库对接收到的MMS报文进行解码。
3)通过一致性测试硬件对被测设备进行GOOSE报文的发布和订阅。
4)根据GOOSE编解码动态库对接收到的GOOSE报文进行解码。
5)根据Python脚本的规则对上述完成解码的MMS报文和GOOSE报文进行判断,获取一致性测试结果。
1.2 站控层GOOSE测试
站控层GOOSE测试平台搭建示意图如图3所示,其展示了MMS和GOOSE共用通信口情况。对应的闭环测试方法框图如图4所示,一致性测试软件(安装在PC机)、被测设备、交换机及对时源组成闭环测试系统:测试软件可以直接通过PC机输出和接收GOOSE(如果是站控层采用光口需要借助光电转换器);测试软件与被测设备进行MMS通信,获取被测设备的MMS报告;对时源对测试软件和被测设备进行SNTP对时;测试软件通过PC对被测设备进行GOOSE数据的发布和订阅,同时将被测设备的MMS数据接入,通过协同比对,从而完成对被测设备的闭环测试[10,11,12]。
具体站控层GOOSE闭环测试过程如下。
1)直接获取被测设备的MMS报文和GOOSE报文。
2)根据MMS编解码动态库对MMS报文进行解码。
3)根据GOOSE编解码动态库对GOOSE报文进行解码。
4)根据Python脚本的规则对上述完成解码的MMS报文和GOOSE报文进行判断,获取一致性测试结果。
2 智能变电站IEC 61850一致性闭环检测平台
2.1 总体结构设计
一致性测试系统主要包括被测智能设备、软件平台、硬件平台、网络报文分析仪、对时设备。其中软件平台具有客户端通信仿真器功能,与硬件平台进行内部通信的功能,还具有MMS报文获取分析的功能。
如图5所示,软件平台通过以太网与被测试设备相连,通过另外的以太网与硬件平台单独连接,硬件平台通过电缆或光纤的方式与被测试设备相连,软件平台和硬件平台相互交互共同成为测试主体,形成完全闭环的测试环境。
系统采用全自动测试,充分利用硬件资源,通过预先编制的测试计划,根据测试脚本智能控制硬件设备的输入和输出,减少人为因素的干扰,排除测试的随机性和盲目性。
一致性检测系统通常配置通信记录与分析子系统,如KEMA配置61850Analyzer分析软件,本系统通过软件平台集成MMS报文获取分析功能,由于涉及大量过程层的GOOSE和SV测试报文,因此还配置了网络报文记录分析仪,如图5所示。
测试结束后,系统能够以测试模块/测试用例/日期的多级目录方式自动记录测试信息,包括测试执行过程中的调试信息、测试的判断结果和整个执行过程中的MMS报文。由于过程层GOOSE和SV报文采用外置网络报文记录分析仪进行记录,不便与本软件平台内部通信,且考虑到SV报文容量较大,因此本系统暂不考虑存储过程层报文。
2.2 硬件平台设计
硬件平台由多块过程层通信板卡、常规开入/开出板卡、内部以太网高速通道组成,同时支持通信板卡的灵活增减和分布式管理,如图6所示。
过程层通信板卡是集通信编解码、通信接口、通信管理、参数配置多种功能于一体的板卡,支持与被测试设备的GOOSE和SV两种通信报文通信,采用DSP和ARM双核处理器、现场可编程门阵列(FPGA)、网路交换芯片的硬件架构,采用Sqlite数据库、Linux2.6、虚拟内存、虚拟控制器局域网络(CAN)的软件架构。常规开入/开出板卡每块板卡含有6路开入,5路开出。内部以太网高速通道是将各个硬件板卡通过内部以太网互联互通,支持内部数据的以太网方式交互。
硬件平台主要功能有以下两个方面。
1)用于为被测设备提供环境仿真。具体提供GOOSE数字信号输出或常规开出功能,提供SV数字信号输出,从而满足不同类型智能设备测试的需求。应用范围包括如定值服务中的模拟远方压板投入,控制服务中模拟开关位置信息、报告服务中开关量的定时触发等。
2)协助完成GOOSE和SV的发布和订阅功能的一致性测试。接收软件平台控制命令按照一定的配置要求完成GOOSE和SV的发布,由于需要满足正反测试用例,因此硬件平台支持模拟正常的报文和定制化的异常报文的发送;硬件平台能够接收GOOSE和SV的报文,DSP经过实时解码判断后,向软件平台推送判断结果。
2.3 软件平台设计
一致性测试软件平台采用Windows操作系统,提供友好的人机界面,由Qt环境、测试用例库、Python脚本、IEC 61850通信库、内部通信库组成。Qt环境是Python脚本、测试用例、各类通信库的协同环境容器,支持跨平台快速移植,包括人机界面、全局测试参数、脚本管理、模型管理、测试结果输出、告警结果输出,如附录A图A1所示。
软件平台主要功能有以下3个方面。
1)通信仿真器。软件平台可模拟IEC 61850客户端向被测设备发送各种类型的请求报文,测试过程中,可根据要求选择执行部分或全部测试用例,记录和处理被测设备的反馈信息,输出透明测试信息,自动根据预定逻辑给出结果分析。
2)与硬件平台交互。软件平台可通过内部通信协议与硬件平台通信,可控制硬件平台,完成GOOSE和SV及硬接点的输入、输出;同时支持解析硬件平台推送的GOOSE和SV判断结果。
3)MMS报文获取分析。软件平台通过调用免费的WinPcap编程接口,可实现测试用例在开始执行时启动捕获,结束执行时停止捕获,从而获取整个执行过程的MMS报文。报文可存储为pcap格式,支持Wireshark等网络分析工具进行解析分析。
2.4 闭环方式
改进后的IEC 61850一致性测试系统可实现3种闭环方式:纯软件闭环测试方式、软硬件闭环单向测试方式、软硬件闭环双向测试方式。
1)纯软件闭环测试方式:关联服务、服务器服务、数据集服务、取代服务、日志服务、对时服务、文件服务等不涉及硬件操作的测试用例,可仅采用软件平台实现纯软件闭环测试。这种模式同常见的一致性测试系统测试方式是一致的。
2)软硬件闭环单向测试方式:定值服务、报告服务、控制服务涉及采用硬件来仿真常规或数字物理量的触发,即硬件平台单方向向被测设备发送模拟开关量、模拟量,可采用测试软件平台和硬件平台相结合的方式实现软硬件闭环单向测试。这种模式为改进后的一致性测试系统的特有模式,常见的一致性测试方式中需要通过继保测试仪进行人工模拟,无法实现定时自动触发。
3)软硬件闭环双向测试方式:GOOSE和SV服务涉及采用硬件发布和订阅的数字信号,需要硬件平台与被测设备双向互动,既能够接收被测设备的发送信息,也能对被测设备模拟各类信息,可采用测试软件平台和硬件平台相结合的方式实现软硬件闭环双向测试。这种模式也为改进后的一致性测试系统的特有模式,而常见的方式无法进行过程层GOOSE的测试,也缺少SV发送和订阅的测试。
3 平台测试及用例
本文所涉及的IEC 61850一致性闭环测试主要包括连接服务、控制服务、定值服务、报告服务、文件服务、GOOSE服务、SV服务等。其中除过程层GOOSE服务和SV服务因受制于网络架构和PC架构限制,需借助硬件平台辅助方能完成测试之外,其余均可直接由软件平台与被测设备进行直接通信完成。硬件辅助平台将在后续工作中完成,本文使用若干典型服务对软件平台进行独立测试,如控制服务、定值服务、报告服务和文件服务,所有的测试用例依照UCA编写的测试步骤进行编写[13,14]。
软件测试平台搭建于Macbook Air MJVG2CH/A,在OSX Yosemite系统下使用Parallels Desktop 10.2.0虚拟Windows 7sp1x64环境,winpcap版本号为4.1.3。使用以太网卡与受测设备进行直接连接。受测设备选用某公司生产的超高压输电线路成套保护装置。
3.1 连接服务
连接服务主要用来测试设备IEC 61850模型的应用关联能力,其基本测试用例包括3个肯定测试用例和4个否定测试用例。
附录A图A2所示为软件的连接测试用例执行情况,该用例用于测试设备的关联及释放TPAA关联(参见DL/T 860.72—2004的7.4节),测试执行完后软件会自动给出测试结论。
3.2 数据服务
数据服务用于验证受测设备的服务器、逻辑设备、逻辑节点、数据和数据属性模型,包含8个肯定测试和4个否定测试用例。
此处选择请求具有不匹配数据类型(如intfloat)的SetDataValues服务(参见DL/T 860.72—2004的10.4.3节)用例作为测试例,其结果如附录A图A3所示,软件自动检查受测设备返回的错误信息,并进行判断,得出结论。值得注意的是,根据测试结果,受测设备并未通过这一测试,虽然受测设备也拒绝了数据写入,但返回的原因代码却与期望不同。这里测试报错并给出了结论:能向bitstring数据内写入浮点类数据,但会造成写入出错,且返回错误的原因码不正确。
3.3 控制服务
控制服务用于验证受测设备的控制模型,包含5个肯定测试用例和9个否定测试用例以及22个附加测试用例。附录A图A4所示的是在Ctlmodel=4下的控制模式测试,软件平台尝试发送一个控制对象选择,再发送控制对象执行,远程将一个Bool数据由F状态改为T状态,之后通过读取控制报告获取控制结果并根据结果进行判定,得出测试结论。
3.4 定值服务
定值服务用来验证受测设备的定值组控制模型,包含4个肯定测试用例和4个否定测试用例。
本文用例使用定值组状态切换检验(参见DL/T 860.72—2004的13章和图18),从第一个定值组开始,逐个进行自动定值区域切换检验,结果如附录A中图A5所示。因用例使用的受测设备包含30个定值组,测试显示界面过于冗长,故只给出了测试结论用例。程序自动读取定值区路径和数量,并进行自动测试,根据结果输出结论,全程无需任何人工参与。
4 结语
针对目前智能变电站IEC 61850一致性检测不能进行闭环测试,测试方法以及用户无法根据实际需求在一致性测试平台上自行开发新的测试用例等问题,本文提出了一种智能变电站IEC 61850一致性闭环测试方法,对其进行了整体的平台设计论证,并对软件平台进行了Ed 1.0的用例测试。测试情况表明,软件平台性能稳定,能自动完成所需的闭环测试,显著减少测试中的人工干预,相对于传统的一致性测试系统提高了一致性测试的执行效率并加强了测试的可靠度和严谨性。此外,Ed 2.0的系列标准已经发布,国内智能变电站规范不断更新和发展,在本文一致性测试平台基础上,进一步研究Ed 2.0和国内扩展应用的测试用例,也是智能变电站设备测试的迫切需求。
布线技术之轻松实现裸线测试 篇2
随着科技的发展,您可能会认为基于裸线(指一个护套中的两条或更多负荷电力和/或载有低速信号的导线)的简易测试设备即将过时,一项针对布线安装行业的抽样调查表明:在分布式的音响、安全、房间控制及自动操作系统运用更广泛的情况下,裸线安装业务有可能会增长。
裸线测试--验证端对端的连通性
连通性测试是裸线测试的最基本测试项目之一,用以搜寻贯穿每条导线的连续路径。进行连通性测试时,你可使用基于电阻的万用表,短接导线的末端以确保完整的回路。当连接扬声器之类的设备时,你可能需要测试电阻系数。而连接安全设备时,可能要测试开关的切换状况。检验切换状况时通常辅以闭合电路的音响表示,许多万用表,如福禄克万用表都具备这种功能。这种最基本的测试也可以由目前的很多种感应式音频发生器来完成,如福禄克网络的MicroNetBlink?.这种音频发生器配备了一个简单的LED显示器,使一般的连通性测试变得轻而易举。
裸线测试--极性测试
与连通性测试情况类似的是极性测试。通常使用万用表进行极性测试,但具有这一功能的感应式音频发生器也能够轻松完成该测试。福禄克网络的Micro Net Blink能够通过彩色LED灯清晰地显示极性。通常情况下,低电压极性测试主要用于电话线缆和安保监控摄像机的电源或信号线。
裸线测试--长度测量
到短路或开路点的距离是故障检测的重要信息,同时也是原料管理和安装商计算收费的重要信息。长度可以通过三种途径以电子化方式测得。第一种方法是将两条导线短接在一起,然后测量电阻并把测出的数值转换成长度。不幸的是这种方式需要使用一根短接电缆,因此很少被使用。
您也可以通过电容测出长度。就像电阻一样,两条导线之间的电容会因长度的不同而变化,而通过电容测量长度的好处是你不必将两条导线短接在一起。福禄克网络的620局域网电缆测试仪、Net Tool网络万用表和Link Runner链路通等产品即可使用电容测量线缆的长度,
第三种方法是使用时域反射(TDR)技术,这与使用电波探测器测试铜线类似。把电波向下发送至线缆,当遇到导线间的开路或短路时,电波会反射回来。记录下电波发送至返回的时间就可得出线缆的长度。
传输的时间因不同类型电缆的传播速率常数差异而不同,这个常数通常会标注在线缆盒上,但使用线缆参考长度的TDR也可算出精度合理的常数。Micro Scanner Pro电缆验测仪、DSP-4300及OMNIscanner2数字式电缆分析仪等产品都具有TDR功能。
裸线测试--故障检测及原料管理
原料使用的基本管理是一项日常的任务,每个工作日之初都要检测要使用的线盒中或线轴上线缆的长度。如果使用TDR或电容性测试仪,就无需将线缆末端短接。记下数值,然后确认其长度足够你所需的线缆长度。一天的工作结束时,要再次检查线盒中或线轴上线缆的长度,把这次测出的长度从工作开始之前测出的数字中减去,即得到了这一天所使用线缆的长度。
长度测试的另一个例子是在结束工作之前进行故障检测。假如你在用TDR进行配线连通性检测时,突然发现在10米外有短路情况,但您的记录中,该链路应该有50米长。这可能是干砌墙安装人员恰好把钉子钉在了某个点上,而你也许能够发现短路位置并修复它(双绞线的情况则不同,你需要替换线缆)。
裸线测试--使用音频发生器和探头定位电缆故障
你如何才能发现线缆上那个钉着钉子的点呢?你的TDR显示它在十英尺远的地方吗?你可以用一台福禄克网络的Micro Net Blink Kit之类的感应式音频发生器和探头来进行测试。将音频发生器连在两条导线上并给它们通电,线缆会传送出一个穿过干砌墙的信号,然后用福禄克网络的MicroProbe音频探头捕获这个1000赫兹的信号,并转换成音频信号以快速找到故障点。
对你的工作来说,捕捉这样一个信号既有利又不利。你可以通过这个信号探测墙体中的导线,但如果碰到两条并列的线缆就可能遇到麻烦。其中一条未通电的线缆可能会捕获通电线缆的信号,使你很难辨别它们。为避免这种麻烦,布线时要在两条裸线之间留出一定距离。此外,线缆会收集荧光灯或正在运行的机器发出的噪音,为保证查线的速度应尽量降低这些噪音。
实现和测试 篇3
摘要:为了削弱面向服务的应用系统中业务流程对服务模块的强依赖关系,降低系统集成测试阶段问题服务对集成过程的影响,提出了基于模拟服务的辅助集成测试方法,设计了面向服务的辅助集成测试系统模型,以缓解面向服务的体系结构下系统集成测试阶段面临的巨大压力。根据辅助集成测试系统模型中阐述的模拟服务生命周期以及构建模拟服务的关键过程,实现了系统原型研制并构建了SOAP类型模拟服务,验证了辅助集成测试方法有效性。
关键词:集成测试;模拟服务;SOAP服务;测试用例;服务生成
中图分类号:TP311.52
在面向服务的体系结构[1](Service-oriented architecture,SOA)下,通过对业务单元进行服务封装,提高了系统中模块的复用率,也解耦了模块间的相互关系。虽然应用系统被拆分并封装成服务,但是系统业务流程依然对服务模块具有强依赖关系,随着服务的增多,导致服务集成过程变得缓慢而脆弱。首先,服务间通过网络进行通信,不但提高了集成测试环境的构建成本,而且增加了模块间的调试难度;其次,采用多团队或引入第三方单位的合作研制方式,加重了集成测试阶段的协调工作,通常会由于某个服务自身存在问题、研制团队失误或第三方研制单位的缺席而导致集成测试节点的延期,最终扰乱整个应用系统的研发过程,为集成测试带来巨大的压力[2]。
目前,面向服务系统的集成测试较多地侧重于单个服务的接口测试方面[3],以保证服务接口功能的正确性,从而降低服务相互间集成时出现问题的概率,但无法从根本上解决集成测试过程中存在的问题。针对这一状况,本文从辅助服务间交互测试的角度出发,利用模拟服务配合被集成服务完成集成过程,有效地缓解了集成测试阶段的压力。
1 面向服务的系统集成测试定义
系统集成测试[4],也叫组装测试或联合测试,即将程序模块采用一次性或增殖方式组装起来,对模块间的接口进行正确性检验的测试工作。面向服务系统的集成测试是在面向服务的体系架构下,对应用系统中的服务模块进行组装,以验证各服务间接口的功能正确性,确保应用系统中各服务间的互联互通互操作。
面向服务的系统集成测试将单个服务模块集成到应用系统中进行测试,可以是一次性的集成(非增量式集成),也可以是逐个的扩展集成(增量式集成),直到完成整个应用系统测试。服务的集成测试要求被集成的服务按照设计要求通过单元测试,保证单个服务的高质量要求,但经过单元测试的服务不足以保证整个系统的质量,有许多隐蔽的失效是高质量模块间发生非预期交互而产生的,所以服务集成测试的必要性在于保证能够单独工作的服务连接起来也能正常工作。此外,在某些开发模式中,如迭代式开发,服务的设计和实现是迭代进行的,在这种情况下,服務服务集成测试的意义还在于它能间接地验证概要设计是否具有可行性。
2 模拟服务辅助集成测试原理
模拟服务是一种服务真实存在的服务提供者,模拟服务存在一个或多个被模拟的目标服务,模拟服务对外提供与目标服务相同的服务接口,两者对于同一服务调用请求(接口调用参数相同)返回一致的响应结果。与真实服务不同的是,模拟服务不关心目标服务的业务逻辑,仅仅采用请求参数匹配的方法来得到应该返回的结果数据,这样模拟服务即可替代目标服务及目标服务依赖的所有服务,屏蔽了目标服务的实现细节。如图1所示,某示例应用系统中A服务依赖B和C服务,B服务又依赖于D和E服务。
通常在服务的集成测试过程中,若需对A服务进行测试,那么必须首先构建出A服务的整颗依赖树,即B、C、D和E服务的实例。采用模拟服务辅助集成测试方法,在A服务需要进行集成测试时,只需如图中构建模拟B服务替代B、D、E服务实例以及用模拟C服务替代C服务实例,如此测试环境中的实例数量缩减为A服务、模拟B服务以及模拟C服务三个。模拟服务的应用可以辅助和简化系统集成测试的整个过程,具体会体现在如下四个方面:
(1)简化集成测试环境,方便被集成测试服务组件依赖服务环境的部署与搭建;
(2)方便集成测试过程中问题的排查与定位,快速地应对突发情况;
(3)降低服务集成测试过程对关键服务的依赖程度,避免如第三方接口、在线集成组件等对测试过程的影响,提高测试的效率;
(4)缩短软件系统开发的生命周期[5]。
3 面向服务的辅助集成测试系统设计
3.1 辅助集成测试系统模型
辅助集成测试系统,用于生成、发布以及管理用于集成测试的模拟服务,本着自动化构建模拟服务的设计原则,为用户提供简易的操作方法,以应对系统集成测试过程中的频发状况。辅助集成测试系统独立于被集成测试服务,其存在的目的是为被集成测试服务提供依赖的服务环境,如图2所示,为辅助集成测试系统的模型设计图。
辅助集成测试系统负责管理模拟服务的整个生命周期,模型中主要阐述了测试数据准备、模拟服务生成以及模拟服务运行三个阶段的设计工作,测试数据准备阶段明确了集成测试前应准备的模拟服务接口用例样本和样本任务编排数据,模拟服务生成阶段指明了测试过程中模拟服务的构建流程,模拟服务运行阶段设计了模拟服务提供服务的关键过程。
3.2 测试数据准备
系统集成测试前,通常存在一定的准备时间,用于进行测试环境的准备工作。模型中的测试数据准备阶段设定在系统集成测试前,为集成测试过程准备必要的辅助集成测试数据,这些准备数据的目的是使得集成测试过程快速而有效,保障集成测试过程的可靠性,做到有条不紊地应对突发状况。
辅助集成测试系统主要包含两个方面数据的准备工作,一方面是准备被模拟服务的测试用例数据(图2中的服务接口用例样本),另一方面是准备模拟服务接口用例的任务编排数据。通常情况下,服务接口在执行请求操作时会按照参数处理、执行业务和返回响应数据三个步骤进行,如图3所示,在辅助集成测试系统中需对应准备请求样本数据、任务数据和响应样本数据。请求样本数据和响应样本数据为接口的测试用例数据,并以成对的方式出现,数据的来源可以是测试用例文档的提取数据、用户人员的录入数据以及自动生成工具的生成数据[6]。任务编排数据用于描述模拟服务接口在特定的请求样本数据下需要执行的一系列任务信息,如第三方服务调用、计时返回等,任务编排数据可以模拟目标服务的功能特性,这一过程需要通过特定的任务编排工具进行操作。
3.3 模拟服务生成
在模拟服务的生成阶段中,辅助集成测试系统需要为测试人员提供能够简单而快速地构建模拟服务的服务生成工具,负责根据测试数据准备阶段的准备数据创构建模拟服务。
服务生成工具从被模拟服务接口的用例样本出发,筛选出测试结果表现正常(能够反应被模拟服务正常情况下应具有的请求、响应数据特性)的用例数据作为模拟对象,并且从这些对象中提取模拟服务接口的元信息用于服务的构建依据。通常,由于一个服务接口往往存在多个用例样本,所以提取出的接口元信息需要通过归并操作来简化模拟服务接口的数量,这一过程会提高模拟服务的质量及执行效率。
辅助集成测试系统提供服务构建器用于根据提取出的接口元信息生成模拟服务的接口定义,再将接口的用例样本匹配逻辑以及任务执行逻辑注入至服务接口的实现中,即可完成对模拟服务接口的实现。最后,生成的模拟服务接口及其实现将经过编译与装载过程,等待模拟服务进入发布阶段。
3.4 模拟服务运行
模拟服务经过生成阶段被装载至内存中,而在模拟服务发布阶段,测试人员只需指定服务的发布地址以及绑定端口等部署信息,即可准备进行模拟服务的发布。由于辅助集成测试系统模型中设计集成了用于发布模拟服务的嵌入式服务容器,所以模拟服务可以快速地被部署和发布,嵌入式的服务容器也更加方便了对模拟服务的管理工作。
已发布的模拟服务由于没有真实的业务实现,当存在服务调用时,模拟服务执行注入的样本匹配逻辑完成响应数据的查询工作,同时在匹配目的用例样本后,根据植入的任务执行逻辑完成与用例样本关联的编排任务,最后将匹配的结果反馈至服务调用处。模拟服务的运行时序图如图4所示。
4 模型应用与原型系统实现
面向服务的体系结构下,基于HTTP协议的Web服务作为面向服务的一种实现方式,已广泛应用于企业的系统开发过程,而Web服务中当以SOAP(简单对象访问协议)服务技术历史最为悠久[7]。如图5所示,为辅助集成测试系统模型的原型系统部署图,下面将阐述系统中基于HTTP协议的SOAP模拟服务的自动构建和发布过程,介绍原型系统的实现细节。
4.1 模拟服务接口提取
SOAP服务以XML的形式封装服务请求消息[8],如图6展示了用于用户添加请求的SOAP消息信封,通过协议绑定技术该消息将被映射为调用服务实现POJO(简单Java对象)的addUser接口。
辅助集成测试系统采用图中加黑片段XML数据作为服务接口的一个请求样本数据,构建名为addUser的POJO方法,其输入参数为User对象,对象包含name、age和married三个属性。理想状态下,User对象三个属性的类型分别为String、int和boolean,但是辅助集成测试系统识别三个属性均为String类型,得到一个拥有三个String类型属性的User对象,因为基于Document/literal实现的SOAP服务消息中并不携带数据的类型信息[9],所以它不影响对象的数据绑定,如此简化了模拟服务的构建过程。同样,采用上述方法可以从响应样本数据中提取方法返回值类型,完成模拟服务接口元信息的提取过程。
4.2 模拟服务构建
模拟服务在接收到请求消息后,通过数据绑定技术将请求消息绑定至服务实现POJO的方法参数上,完成目标接口的匹配,这一过程采用CXF框架(Apache CXF服务框架)自动完成[10]。
模拟服务通过调用样本匹配引擎和任務查询引擎进行关联数据查询,二者采用独立运行的Web服务方式供模拟服务调用,下面为模拟服务的添加用户接口实现代码:
其中,Finder类封装了样本匹配引擎和任务查询引擎的查询接口,并提供了简单的调用接口findSample和findTasks,方便在创建模拟服务时植入统一的调用代码。在运行过程中,根据Java的反射机制finder实例可以明确当前服务的位置,再由接口的参数匹配确定具体的样本用例,用例样本匹配过程涉及Java基本类型和自定义对象类型的深度匹配,可以借助于规则引擎[11],本文采用的是将参数对象顺序进行序列化后比较的方法[12]。最后,模拟服务顺序遍历查询出的样本编排任务信息,并依次执行任务,完成后将查询出的响应消息返回。
4.3 服务发布与管理
通过动态生成和编译后的模拟服务实体被载入至内存,测试人员在设定模拟服务的部署位置、发布端口等信息后,模拟服务交由CXF以反射的方式进行发布,即可为外部请求者提供服务。模拟服务运行时依赖的样本匹配引擎与任务查询引擎通过独立的Web服务方式运行,为集成测试过程中的模拟服务提供查询服务。最后,模拟服务的管理包含两个方面,一方面是模拟服务启停状态的控制,通过调用CXF的服务控制接口可以很好的完成这方面工作;另一方面是样本数据和任务数据的管理,由于两个查询引擎采用独立的服务方式运行,所以提供简易的数据管理工具即可。
4.4 实际应用效果
经实践证明,模拟服务在系统集成测试阶段能够有效地应对关键服务模块出现问题的情况,使得集成测试过程持续且快速。模拟服务屏蔽了应用系统下复杂的测试环境,同样为无法进行在线集成的线上接口提供了便利的解决方案。如图7所示,为辅助集成测试系统的主界面图。
5 结束语
本文从构建模拟服务的独特角度出发,提出了面向服务的辅助集成测试系统模型,通过模拟服务从容地应对了集成测试环境中服务数量多、服务环境复杂而带来的一系列问题,使得服务集成过程快速而可靠,有效地缓解了集成测试阶段的压力。文中总结了模拟服务创建及发布的整个生命周期,明确了模型中各模块的对于构建模拟服务至关重要的作用,然而尚未提及如接口归并、样本匹配等关键模块的高效实现方法,当样本数据量异常庞大时,这些模块将严重影响模拟服务的性能,为了能够提供高效并且可靠的模拟服务,这一方面仍需加以关注。
参考文献:
[1]凌晓东.综述[J].计算机应用与软件,2007(10):122-124.
[2]杨利利,李必信.Web服务测试问题综述[J].计算机科学,2008(09):258-265.
[3]冯细光,刘建勋.Web服务测试技术综述[J].微计算机应用,2010(01):111-126.
[4]兰景英.软件集成测试技术研究[J].信息技术,2006(08):102-105.
[5]Bobby Woolf.Streamline SOA Development using Service Mocks[J].IBM developerWorks,2005.
[6]马春燕,朱怡安,陆伟.Web服务自动化测试技术[J].计算机科学,2012(01):162-169.
[7]沙为超.基于Web服务的SOA应用研究[J].安徽大学,2007.
[8]张仙伟,张璟.Web服务的核心技术之一——SOAP协议[J].电子科技,2010(03):93-96.
[9]李海峰,杨小虎.基于风格与风格消息的服务性能比较[J].计算机应用与软件,2007(01):80-117.
[10]彭邦伦.利用JAX—WS开发Web Service[J].电脑编程技巧与维护,2008(12):21-23.
[11]刘伟.Java规则引擎——Drools的介绍及应用[J].微计算机应用,2005(06):79-83.
[12]晏立,沈銳.Java序列化技术的探讨[J].红河学院学报,2011(04):37-39.
[13]张羽丰.面向服务的Web服务测试框架研究与实现[J].国防科学技术大学,2008.
[14]罗作民,朱燕,程明.Web服务测试工具SOAPUI及其分析[J].计算机应用与软件,2010(05):155-157.
[15]秦锋,李乔,郑啸.Web服务测试的一种实现[J].计算机技术与发展,2007(08):239-242.
[16]严思静,常红春,刘钢,唐奋飞,冯国军.Web服务测试工具的设计[J].硅谷,2010(08):60-64.
作者简介:徐亮亮,男,研究生在读,研究方向:军用软件集成;宋剑锋,男,博士;田飞,男,研究生,研究方向:军用软件集成。
实现和测试 篇4
与模拟T/R组件相比, 多通道数字阵列模块的组成和功能非常复杂, 不再只是实现发射、回波信号的幅度和相位调理。在接收状态下, 输出信号不再是通过同轴电缆传输的模拟信号, 而是通过光缆传输的高速大容量I/Q数据, 矢量网络分析仪等传统测试设备已经无法与数字阵列模块进行连接, 也就无法对其性能标进行测试, 所有接收通道性能指标都依赖于对I/Q数据的分析和计算, 这是数字阵列模块与模拟T/R组件在测试方面最大的不同, 也是最大的测试难点所在。因此, 必须寻求一种新的测试解决思路和手段。
2 接收通道测试需求
虽然在技术体制和实现方式上与模拟T/R组件有较大的不同, 但是数字阵列模块接收通道的测试参数类型基本是一致的, 主要有接收增益、隔离度、接收延时、噪声系数和通道间幅相一致性等。
3 接收通道测试方法
测试实现的总体思路为:在主控计算机的控制下, 首先通过光缆和状态控制单元完成被测模块的工作状态控制, 然后在同步信号的作用下, 信号发生器输出的射频激励信号通过开关功分单元输入至被测模块中, 而被测模块输出的I/Q数据进入接收分析单元进行数字信号处理, 最后对计算结果进行补偿, 如考虑射频传输通道的插损等, 最终得到接收通道的性能指标 (见图1) 。噪声系数的测试与上述过程基本一致, 只是它不需要开关功分单元的参与。
在多通道数字阵列模块接收通道测试过程中, 有工作状态控制、高速I/Q数据接收/分析、被测模块与测试仪器同步等几个关键问题需要解决, 下面分别进行论述。
3.1 工作状态控制的实现方法
与模拟T/R组件相比, 多通道数字阵列模块工作状态的控制机理虽大致相同, 但载体实现形式区别于传统的低速总线, 代之以光缆作为数据传输的高速通道, 这也是为了满足后续大容量I/Q数据的高效传输, 具体包括触发同步、收发切换、幅相调整、波形数据、控制数据、同步数据以及数据复接等。
基于FPGA芯片内置的ROCKET I/O硬核可以很好地实现高速串行数据的光纤传输。该硬核是一种高速的串行收发器, 调用各功能模块资源, 加以合理配置即可实现数据链路的可靠传输。在此基础上, 按照约定的协议格式将控制数据、波形数据、同步数据和收发状态控制等发送到被测模块中, 以此可以实现各种复杂工作状态的控制 (见图2) 。
同时, 在FPGA芯片和外围电路的基础上, 其实也较容易进行功能扩展。如加上DAC芯片和低通滤波电路可以产生同步信号, 又如在外围增加RAM电路就是实现高速I/Q数据接收/ 分析的硬件基础。
3.2 高速I/Q数据接收/分析的实现方法
FPGA芯片中ROCKET I/O模块的发送通道可以用来实现被测组件的状态控制, 而其接收通道则可以用来接收被测模块的高速I/Q数据, 当然这是发送过程的逆过程, 接收到的I/Q数据送往RAM区中进行缓存和分析处理。至于缓存多少数据, 这可以根据测试需求并通过管理软件进行控制。
接收通道的性能指标的测试实现最终依赖于I/Q数据的计算和分析。从实现过程来讲, 主要可分为数据拆分、数据抽取、FFT运算和通道性能最终计算等几个步骤 (见图3) 。
3.3 被测模块和测试仪器同步的实现方法
对于接收测试来说, 接收延时的测试需要基于一个同步的机制, 其它指标可以在连续波模式下进行, 并不需要同步信号的参与。
与模拟T/R组件需要输入同步信号不同, 数字阵列模块是根据接收到同步数据在其内部产生同步信号而实现同步的, 而且也没有同步信号的输出端口, 也就是说数字阵列模块无法直接同步测试仪器。既然不能直接实现同步, 那么就利用一个间接方式来实现, 即产生一个测试同步信号, 先实现与多通道数字阵列模块的同步, 再利用该信号实现与测试仪器的同步, 从而最终实现被测模块和测试仪器之间的同步。
具体的实现方法为:状态控制电路在对被测模块进行工作状态控制的同一个时钟信号上升沿输出测试同步信号数据, 该数据输入至DAC电路进行数模转换, 即输出一路与被测模块工作状态同步的测试同步信号, 该路同步信号即可输入至测试仪器中, 从而间接实现了被测模块和测试仪器的同步。
3.4 多通道射频激励信号输入的实现方法
在模拟T/R组件接收通道测试时, 一般是通过开关的切换分时给不同的通道施加射频激励信号。但是, 在多通道数字阵列模块测试时, 通过开关切换依次注入信号的方式实际上是行不通的。原因为:如果某个时刻只有一路通道有激励信号, 而接收通道I/Q数据是所有通道复接后通过一根光缆输出的, 那么只有部分数据是有效的。若要计算相应的性能指标, 必须进行有效的数据分离, 不但效率低, 也必将占用大量存储空间;同时, 分时测试也无法实现通道间相位一致性指标的测试, 虽能进行幅度一致性的测试, 但是由于受温度等因素的影响, 分时测试所得的幅度一致性指标在准确度上也会有所降低。因此, 对于多通道数字阵列模块接收通道的测试需要采用多通道射频激励信号同时注入的模式。
4 实际测试与应用
基于以上的实现方法, 针对某S波段16通道数字阵列模块搭建了接收通道测试验证系统 (见图4) 。该系统由3 台AV1464A信号发生器 (其中两台用来产生本振信号) 、1 台AV1761 电源、状态控制单元 (包含I/Q数据接收/ 分析和同步信号产生单元) 、时钟单元、16 通道开关功分单元、主控计算机等组成。
利用搭建的测试验证系统对某S波段16通道数字阵列模块的性能指标进行了测试。因通道数量和指标类型较多, 下表仅仅列出了一个通道两个频点接收增益、隔离度、延时和灵敏度的测试数据, 测试结果符合设计要求。
5 结论
通过深入研究数字阵列模块的工作原理, 积极利用当今大规模集成电路、微波技术和光电技术的研究成果, 充分挖掘电子测量仪器的功能, 提出了数字阵列模块接收通道测试的实现方法, 搭建了完整的测试验证系统, 测试结果满足实际需求, 与模块设计值相吻合。此外, 软件运行稳定可靠。通过以上方式, 解决了多通道数字阵列模块因数字化、光纤化和集成化带来的接收通道测试难题。
摘要:多通道数字阵列模块接收通道的输出信号为通过光缆传输的高速I/Q数据, 所有接收通道的性能指标测试都依赖于对1/Q数据的分析和计算。为解决因数字化、集成化带来的接收通道测试难题, 根据当今大规模集成电路、微波技术和光电技术的研究成果, 提出了一种基于高速I/Q数据接收/分析、复杂工作状态控制、被测模块与测试仪器同步、多通道射频激励信号输入的测试实现方法。实际测试证明方法可行有效, 也具有一定的推广应用价值。
关键词:数字阵列模块,接收通道,I/Q数据同步
参考文献
[1]成超.宽带数字T/R组件发射通道实现技术研究[D].电子科技大学, 2009:30.
实现和测试 篇5
关键词:软件自动化测试;自动化管理系统的框架构建;设计与实现
中图分类号:TP311.5
软件测试自动化管理系统不仅能测试数字化资产管理,方便数据在整个测试期间内循环使用,而且大大提高了测试效率,使得测试人员能有足够时间致力于研发更好、更快的测试新产品。自动化测试的目的就是减轻手工测试时的工作量,力争在最短时间内节省最多人力、物力资源,最终达到保证软件质量的目的。
1 软件自动化测试的优点
相比一般测试软件来说,软件测试主要有这三方面的优点。第一,软件测试能完成一些手工测试难以完成的项目。比如大数据量测试、压力测试、模拟系统测试等,都是一些手工测试无法驾驭的;第二,软件自动化测试能降低风险,提高软件产品质量。自动化测试相比手工测试成本较低,人力使用量少,大大降低了资金风险,以最少的花费取得最大的收益;第三,自动化测试具有统一性和可循环性。自动化测试时使用相同脚本,所以每次测试都能保证一致性,这点是手工测试无法做到的。
2 软件测试自动化管理系统的结构
软件测试自动化管理系统的结构其实就是通过一些假设和概念,以此为根据来为软件测试自动化管理系统提供支持的实际组成。
2.1 脚本模块结构。脚本模块结构的构建需要一系列相对较小、独立的脚本来表示一些程序和函数的帮助,然后采用分级方式来将这些脚本组成较大的测试,最终构成一个特殊的测试用列,自动化测试脚本有结构脚本和共享脚本。结构脚本中含有脚本执行的命令,在一定情況下,这些命令成为控制结构或调用结构。结构脚本的主要特点体现在控制性上,控制整个自动化流程的进行;共享脚本是脚本能同时被多个测试用例利用,实现脚本资源共享。共享脚本不仅稳定性好,而且可以循环利用,减少工程量。
2.2 测试库结构。测试库框架的结构与脚本模块框架差不多,不同的是测试库结构将待测试应用程序分解成函数和过程而不是脚本。实现功能的个体由脚本变成了函数,这些功能函数被储存在一个库中,这个库就被叫做测试库。当测试进行时,就可以调动测试库函数来执行程序。图1就是通过TCL语言实现测试库结构的自动测试化用例。
2.3 混合型测试结构。从字面上来说,混合型测试结构就是结合多个测试结构特点,取其精华以形成的一种框架结构。软件自动化测试管理系统是以关键字驱动为主要框架的系统,并以脚本模块和测试库结构为辅,较好解决了框架单一,功能简单的问题。图2就较好概括了混合型测试结构的工作原理。
3 软件测试自动化管理系统的设计与实现
自动化测试系统(Automated Testing System,ATS)主要以混合型测试自动测试框架为主,支持自动化测试系统完成一些基础设备操作的一类测试管理系统。ATS是一个与具体测试业务和被测对象无关的一个测试平台,可以被任何对象和测试业务所利用。其实真正和测试业务有联系的是ATS中的API,它为测试提供了一个统一的框架,使得测试具有统一性和稳定性。而且ATS还支持脚本管理,利用ATS提供的API较为方便的编写出测试脚本,提高测试效率。在ATS中,测试脚本主要分为三个部分:Test case、Test suite 和Test job。软件测试自动化管理系统ATS的设计结构总共由5个模块构成:User Interface、Request Handler Manager、Job Controller、Execution Server、Suite Execute Layer。下文主要对其中的2个模块做具体分析。
3.1 Request Handler Manager。ATS主要采用B/S结构,用户在使用软件自动化测试系统中只需打开Web浏览器,而不要安装客户软件就能完成测试,方便快捷了人们的工作。用户在界面上的所有操作都会以数据形式由Web浏览器发送到Web服务器上。但是,Web浏览器不能记住所有操作从而会大大降低系统机动性和延伸性。Request Handler Manager就能很好解决这问题,由它来记住操作和处理器之间的关系,Web浏览器只需接到指令就好。
3.2 Execution Server。Execution Server的主要特点是执行job。因为job由多个suite组成,所以Execution Server需要给每个job提供一个suite队列,然后来执行程序。但是Execution Server不会主动处理,它通常是接到请求后才会执行操作流程,扮演着一个被动者的身份。图3就完整的描述了Execution Server整个执行过程。
4 结束语
综上所述,软件自动化测试管理系统是软件开发的一个重要环节,将直接决定着软件质量和办事效率。但是软件本身就存在多变性和复杂性,相应的自动化测试系统要不断更新和改善,才能提高软件质量,从而方便人们生活。另外,软件开发技术人员要不断丰富自身专业知识和提高技术能力,为软件测试行业带来新的生机与活力。
参考文献:
[1]严少清,陈革,万年红.软件测试自动化管理系统的设计与实现[J].计算机工程,2002,09:152-153.
[2]江鲸.软件自动化测试系统的研究与实现[D].电子科技大学,2006.
作者简介:张思亚(1990-),女,贵州遵义人,本科在读,研究方向:计算机科学与技术(软件工程)。
实现和测试 篇6
针对传统的测试系统诸多不足,美国国防部提出了一项新技术:合成仪器。合成仪器是一种模块化的硬件和软件测试方案,将单独的硬件和软件测试模块连接成一个系统仿真传统仪器,产生一种形态可变的通用系统架构。它的核心思想是将传统仪器分割成为一些基本功能模块:信号调理、上变频器、下变频器、DAC、ADC。将这些仪器中相同的部分模块化,“合成”它们的测量功能到一组功能模块上,采用软件无线电思想,并通过软件实现这组功能模块的控制,实现一种或多种传统测试设备的功能。相对传统仪器,合成仪器的硬件结构由几种标准硬件组成,标准硬件与不受限制的DSP软件结合工作,实现大量传统仪器的功能。
2 Test Center测试平台的仪器控制插件
Test Center测试平台软件是由中国电子科技集团第四十一研究所研发的测试程序管理和开发工具。它用于开发和管理测试程序集,用户不需要编写代码,只需要拖放各种功能插件(仪器控制插件、报表插件、数据库插件等)到相应的节点上,设置测试树的流程控制,就可以开发出所需的测试程序。
测试平台通过仪器控制插件来控制仪器,插件是多个软件模块(包含COM组件、ActiveX控件、网页)的集合,提供了仪器设置和显示测量结果的用户界面,通过调用符合IVI规范的仪器驱动,控制这些通用仪器。其中,ActiveX控件提供应用界面实现同用户的交互,将用户设置的信息保存到Test Center的测试序列文件中。COM组件是在自动测试运行时被调用相关方法驱动仪器,实现测试目的,将测试结果存放到测试序列文件中。
3 合成仪器插件架构
合成仪器的体系采用了分层结构,为了提供更大的灵活性,每个合成仪器模块提供了单独的合成仪器驱动程序。该分层结构的基础是各层之间的标准接口,合成仪器模块提供的驱动接口,都必须是符合IVI标准规范,这样才能保证测试程序的可移植性,以及仪器的互换性。
利用下变频器和数字化仪硬件资源,开发相应的合成仪器控制插件,可以实现频谱分析仪、网络分析仪和示波器几种不同的合成仪器。利用函数发生器和上变频器硬件资源,开发相应的合成仪器控制插件,可以实现射频信号源等合成仪器。
4 合成频谱仪插件的实现
本文中的合成频谱分析仪是利用中电科四十一研究所研制的下变频器模块和数字化仪模块合成实现的,计算机通过网络交换设备同时控制下变频模块和数字化仪模块,下变频模块为数字化仪模块提供中频信号,同时提供同步信号与外触发信号保证同时启动下变频器的本振电路和数字化仪的数据采集电路,中频信号经数字化仪模块得到的采样数据送往计算机中进行软件分析处理,实现频谱分析功能。硬件结构框图如图1所示。
本文中软件采用C#和MATLAB混合编程实现,充分利用了.NET框架的开发能力和MATLAB的计算能力的各自优势,极大的提高开发效率。软件架构如图2所示:
软件结构主要包括5个部分:仪器控制模块、数据处理模块、数据显示模块、用户设置模块、MATLAB引擎。
用户设置模块:接收用户对仪器的各种设置,保存这些设置到测试序列文件中,从测试序列文件中读取这些设置,并将这些设置传递到仪器控制模块。
仪器控制模块:根据用户设置对两个合成仪器模块进行程控得到信号的时域采样数据,并将采样数据送到数据处理模块进行数据分析。
数据处理模块:是整个软件系统的关键所在,主要功能是调用MATLAB引擎对从数字化仪模块接收的数据进行频谱分析和数字滤波。由于数字化仪模块得到的采样数据是时域信号数据,需要对时域信号数据进行快速傅立叶变换(FFT),得到输入信号的幅频特性,然后在频域数据的基础上进行频谱分析和数据的显示。
数据显示模块:负责显示数据处理模块传入的频谱特征数据。
5 结束语
本文介绍的合成频谱分析仪插件实现了台式频谱分析仪的频谱分析功能,满足系统的测试需求。软件采用C#和MATLAB混合编程实现,充分利用了.NET框架的开发能力和MATLAB的计算能力的各自优势,提高了开发效率,降低了开发成本,为其他合成仪器插件开发摸索了道路,结合不同的数据处理模块和数据显示模块,即开发合成示波器和合成矢量网络分析仪插件。
摘要:合成仪器是一种模块化的硬件和软件测试方案,在自动测试系统中占据重要地位。本文介绍了合成仪器的概念、体系架构及特点,以及Test Center测试平台中的仪器插件,详细地阐述了如何设计和实现Test Center合成频谱仪插件。
关键词:合成仪器,自动测试系统,Test Center测试平台,插件
参考文献
[1]杨川,崔少辉,方丹.并行测试中合成仪器的应用研究[J].仪表技术,2009年10期.
实现和测试 篇7
一个应用程序可以包含若干个Activity。可以让某个Activity对象使用Intent对象来启动其它的Activity对象。
2 Intent类的一个构造方法
Intent(Context packge Context,Class<?cls):该构造方法的参数packge Context是当前应用程序所在的上下文,参数cls是打算启动的Activity对象的类的名字。
例如:
假设,已经有如下类的声明:
class Calculator extends Activity
class Main Calculator extends Activity
那么,下面这条语句
Intent intent=new Intent(this,Main Calculator.class);
作用是:当前类的对象(Calculator类的当前对象this),打算启动的Activity对象的类的名字是Main Calculator。
接下来的语句
start Activity(intent);
作用是:实现两个Activity之间的切换。从当前的Activity,启动另外一个Activity,即Main Calculator。
3一个Activity对象使用Intent对象来启动另一个Activity对象的实例
【例1】在Android中实现简单的计算能力测试系统。计算随机给出的两位数的加减法算术题,要求用户回答,答对的提示“正确”,答错的提示“错误”。随时给出答题的正确率。
(1)第一个Activity的相关程序,文件Calculator.java:
(2)第二个Activity的相关程序,文件Main Calculator.java:
(3)配置文件Android Manifest.xml,在</application>之前,新增加Activity语句如下:
单击图1的“欢迎测试”按钮,出现的第二个Activity的初始界面如图2所示。
第二个Activity,单击“出题”按钮,输入运算结果,然后单击“判断”按钮,运行结果如图3所示。
4结束语
通过学习Android中Intent类的构造方法,我们可以使用Intent类的构造方法来创建Intent类的对象,实现同一个应用程序中多个Activity对象的切换,从而实现更多的功能。
这个简单的计算能力测试系统的界面welcome.xml和test.xml比较简单,在这里就不介绍了。另外,这个系统还可以扩展,实现乘、除等计算功能。限于篇幅,不再详细讲解了。
摘要:介绍了Android中Intent类的一个构造方法,使用这个构造方法来创建Intent类的对象,实现同一个应用程序中多个Activity对象的切换,从而实现更多的功能。
关键词:计算,测试,Android,Activity,Intent
参考文献
[1]耿祥义,张跃平.Android手机程序设计实用教程[M].北京:清华大学出版社,2013.
[2]李刚.疯狂Android讲义[M].北京:电子工业出版社,2013.
实现和测试 篇8
民用飞机电源系统为机载设备提供并分配电功率, 是飞机重要组成部分。根据飞机电源系统试验要求, 测试系统需在飞机地面验证试验时完成电源系统供电特性参数测试, 其中稳态参数包括稳态电压、电流、相移、三相电压不平衡等。
本文基于NI公司的数采硬件和LABVIEW软件, 设计了飞机配电稳态参数测试系统, 该系统构建了100路测试通道, 对飞机电气特性参数的测量方法符合MIL-STD-704E标准的要求, 参数测试的软件算法参考ISO12384的定义。
1 系统构架
系统采用模块化结构, 主要由上位机、控制器、时钟同步卡、数据采集卡、RAID控制器、磁盘阵列及信号调理箱等组成, 如图1所示。待测电压电流信号经信号调理后由数据采集卡进行模数转换并在RAID控制器控制下高速写入磁盘阵列, 保证了数据的完整性和有效性。数据的分析处理由上位机实时分析或在事后读取、回放并通过软件按预定算法计算完成。
2 硬件结构
2.1 数据采集卡
采集卡选用NI公司PXIe-6368板卡, 每块板块配置16个差分输入通道, 每通道配置一个16位ADC, 采样率2 MS/s, 总模拟输入吞吐率32 MS/s, 采样数据实时传输到存储器。
2.2 控制器
嵌入式控制器选用NI公司PXIe-8133控制器, 该控制器配置为1.73 GHz四核处理器, 8 GB内存, PLX8632芯片组, 系统带宽和插槽带宽分别为8 GB/s和2 GB/s。同时, 该处理器有2个10/100/1000Based-TX以太网接口和4个高速USB接口, 具有高速数据传输的能力。
2.3 磁盘阵列
磁盘阵列选用NI公司的PXI-8264, 并与NI 8262板卡配合, 数据传输速率为600 MB/s, 容量3 TB, 内部集成RAID控制器, 具有不同数据存储模式, 配置x4的PCI Express接口, 能与处理器高速连接。系统数据存储采用数据流盘技术, 测试数据通过总线经过控制器内存并行写入由12块RAID硬盘组成的磁盘阵列中。
2.4 时钟同步卡
采集机箱之间采用内置同步模块同步, 驱动PXI星形触发线, 导入并导出PXI背板时钟和触发器, 生成高精度的直流到105 MHz DDS时钟, 为仪器生成具有高稳定性的TCXO 10 MHz参考时钟。2台机箱其中1台为主同步机箱, 配置一块主同步卡, 另外1台为从机箱, 配置一块从同步卡, 型号PXI-6672。上位机发出采集指令后, 主机箱发出时钟信号, 从机箱接收后所有通道同步采集, 保证时钟一致性, 利于分析各项参数。该同步方式不仅能使多个采集机箱同步, 还能使采集机箱和外部仪器及设备同步。
2.5 信号调理箱
由于电源系统被测信号或大或小, 不适合直接传送给数据采集卡, 所以必须对被测信号进行调理使其幅值在数据采集卡允许的范围之内。信号调理箱完成被测信号的衰减、转换和调理, 将准确、可靠和安全的测试信号传输给数据采集卡。调理板原理图如图2所示。
3 数据采集及处理方法
3.1 系统数据采集方法
为保证交流三相电压、电流同时进行测量, 采样通道不能少于6路, 电压电流采样频率不低于100 kHz, 可测交流稳态电压、电流、相移、三相电压不平衡等稳态参数。频率采样采用测周期法测频, 即利用计算机计数方式 (软件过零计数) 测频率。采样频率不低于100 kHz。
3.2 测试数据处理方法
交流稳态参数分析主要进行电压有效值、电流有效值、频率、波峰参数、偏离系数、三相电压平均值、三相电压不平衡值、三相电压的相位差等计算。按照ISO12384的要求, 采样频率应不低于72 kHz, 本软件设置为100 kHz, 采样完成后, 对数据进行保存。然后进行波数选择以处理数据, 该程序在进行初始计算周波数的选择后, 对选择的数据进行分析计算, 三相数据一次计算完毕。
交流稳态参数分析方法按ISO12384标准进行, 其中稳态交流电压计算公式[1]如下:
undefined
式中:
U——稳态交流电压, 单位为伏 (V) ;
Tw——小于并最接近1 s期间整数个电压周波所对应的时间, 单位为秒 (s) ;
Δt——采样周期, 单位为秒 (s) ;
n ——总采样次数 (nΔt≈Tw) ;
i ——采样序列, i=1, 2, 3, …, n;
ui——采样点的电压瞬时值, 单位为伏 (V) 。
4 软件结构
4.1 软件功能
测试系统软件基于LABVIEW平台, 完成被测信号的采集、存储, 进入稳态参数分析模块计算。按MIL-STD-704E标准进行测量和分析, 参数测试精度及算法按照ISO12384标准执行。测试结果可以自动生成报表, 输出相应的标准曲线, 打印实测的有关波形, 还具有存盘功能, 可分析历史数据。
测试软件分为实时分析、事后分析和生成报表三个部分。实时分析部分用于实时测试时监视系统状态, 进行特性分析。事后分析用于试验数据的回放以及事后分析处理, 此时根据记录的历史数据, 回放原始波形, 并进行相应参数分析。实时分析或事后分析完成后, 可生成分析结果报表, 报表包含波形及分析数据, 以图片形式输出。根据系统需求定义画出系统流程图如图3所示。
4.2 软件实现
测试软件采用LABVIEW开发, 该开发平台基于图形编程, 拥有开放式的系统互联结构, 数据轻松共享, 并带有丰富的数据处理分析工具包, 开发者可进行模块化设计, 方便易用。软件主界面如图4所示。
软件运行时, 点击“实时采集”按钮, 进行数据的实时分析, 在弹出窗口中选择保存采集的原始数据并进行分析, 结果将在界面上显示。也可选择事后分析, 将之前保存的原始数据文件进行回放分析, 然后显示出计算结果。需要生成报表文件时, 点击“报表生成”, 测试结果报表的以图片形式进行保存。
5 结语
本文实现的稳态参数测试系统功能正常, 性能稳定, 人机界面友好, 操作简单。实际运行表明, 该系统精度满足标准要求, 测试结果数据准确, 不仅提升了飞机电气系统稳态参数的测量能力, 而且提升了我国飞机电气系统试验能力。
摘要:本文根据民用飞机电气稳态参数测试要求, 利用LABVIEW软件和PXI总线技术设计并实现了飞机电气稳态参数测试系统。实际运行表明, 该系统精度满足标准要求, 测试结果数据准确, 对民用飞机电气系统有很高的应用价值。
关键词:飞机电气系统,稳态参数测试,PXI总线,LABVIEW
参考文献
自动化测试实现研究 篇9
关键词:自动化测试,实现,需求
软件测试一个特点是重复性,重复测试让我们产生厌倦心理,因此人们想到用工具来解决重复的问题。另外手工还存在精确性的问题,尤其是面对大量数据需要检查时候,人工的比较和搜索存在效率问题,易出错,覆盖面低。手工测试存在效率问题,这在软件产品的研发后期阶段尤其明显,随着功能日趋增多,需要检查的点和测试内容也越来越多,人工回归测试难度增大,很难在短时间完成大面积测试覆盖。当然,手工测试也有不可替代的地方,比如测试用例的设计,界面和用户体验性测试,正确性的检查,而自动化通过计算能力,不知疲倦地运行,对于数据能精确运行。因此,在需要重复执行界面操作、计算、数值比较、搜索等方面。我们需要充分利用自动化测试工具的高效率来帮助测试人员完成测试用例的执行,加快回归速度,提高测试覆盖率。
1 自动化测试准备
在进行项目自动化测试之前,首先要考虑以下5个方面,其次是衡量项目开展自动化的一些条件。
(1)测试自动化类似于软件开发过程
录制/回放脚本开发方式是不可能应付所有自动化测试需求的,因此需要测试人员掌握必要的开发知识和代码。
(2)测试自动化是一个长期的过程
自动化测试只有长期多次运行才能体现出价值,同时需要考虑自动化测试维护成本。
(3)确保自动化测试的资源,包括人员和技能
最好有专门的自动化测试工程师来保证测试自动化持续,需要对项目负责,设计测试框架和脚本结构,解决各种测试脚本开发问题。
(4)循序渐进开展自动化测试
(5)确保测试过程的成熟度
2 自动化测试开展
自动化测试只有在多次运行后,才能体现出自动化的优势,只有不断地运行自动测试,才能有效预防缺陷,减轻测试人员手工的回归测试工作量,如果一个项目是短期的,则不适合开展,另外,不宜在一个进度非常紧迫的项目中开展自动化测试。
自动化测试不应该在界面尚未稳定的时候开始,但是此时可以着手准备自动化测试计划和准备工作,自动化测试工具评估使用。
首先分析项目的特点,软件系统采用的开发工具、语言、技术平台等,结合测试的类型,测试的要求,同时还要了解目前存在的各种测试工具的情况,根据选择的测试工具,进行试用,制订一份详细的测试工具使用计划。
3 自动化测试工具
软件测试可以按照自动化工具类型进行分类,软件自动化测试工具是实现软件自动化测试必不可少的关键,因此,选择一个优秀的、适合自己的测试项目的测试工具是实现成功自动化测试的第一步。
3.1 按用途分类
软件自动化测试工具按安装用途可分为
·测试管理工具
·自动化功能测试工具
·性能测试工具
·单元测试工具
·白盒测试工具
·测试用例设计工具
自动化测试工具可基于GUI层面进行测试,也可基于代码层面进行测试,只要实现了自动化执行测试用例,自动检测测试数据的测试工具,替代人工进行测试步骤的执行,从而验证应用程序是否满足了特定功能的测试工具。
3.2 基于代码层面的功能自动化测试工具
基于代码层面的功能自动化测试工具主要是一些单元测试工具,例如junit,这些工具直接访问被测试的应用程序的代码,对其中的类和函数进行调用,输入各种测试数据,检查函数的返回值,通过比较返回值与期待值是否一致来判断测试是否通过。
3.3 基于浏览器和DOM对象模型的功能自动化测试工具
例如selenium,这些测试工具直接访问Web浏览器,利用脚本语言操作浏览器和Web页面中包含的DOM对象,从而达到模拟用户控制浏览导航、页面元素的操作等效果,并直接获取DOM对象的属性,从而获得Web页面元素的各种属性,通过这些属性判断测试步骤结果是否正确。
3.4 基于GUI对象识别的测试工具
目前,大部分自动化功能测试工具,尤其是商业的测试工具,如QTP都是基于GUI对象识别技术来设计的,基于GUI层面的测试需要与各种节目元素打交道,而且不同的编程语言和开发工具在界面的表现、事件的响应上都略有不同。
QTP同样是通过查找应用程序界面中的各个控件的属性来判断是否与测试对象匹配,还可以根据控件的类型,把其拥有的可操作方法列举出来,针对不同平台和语言编写的控件,依据该控件与其他控件能区分的属性来判断其身份,例如控件的类名、控件的文本等。
QTP自动化测试工具是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试,主要是用于回归测试和测试同一软件的新版本。因此在测试前要考虑好如何对应用程序进行测试,例如要测试哪些功能、操作步骤、输入数据和期望的输出数据等。Quick Test针对的是GUI应用程序,包括传统的Windows应用程序,以及现在越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术,简单高效,并具备测试用例可重用的特点。其中包括:创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。
4 自动化测试基本流程
基本流程图如下。
4.1 制订测试计划
在展开自动化测试之前,我们需要做个测试计划,明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求,并确保测试所需的人力、硬件、数据等资源都准备充分。
4.2 分析测试需求
用例设计者根据测试计划和需求说明书,分析测试需求,设计测试需求树,以便用例设计时能够覆盖所有的需求点。一般来讲,基于Web功能测试需要覆盖以下几个方面:
(1)页面链接测试,确保各个链接正常;
(2)页面控件测试,确保各个控件可靠;
(3)页面功能测试,确保各项操作正常;
(4)数据处理测试,确保数据显示准确、处理精确可靠;
(5)模块业务逻辑测试,确保各个业务流程畅通。
4.3 设计测试用例
通过分析测试需求,设计出能够覆盖所有需求点的测试用例,形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行,所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时,要将登录系统的用户、密码、产品、客户等参数信息独立出来形成测试数据,便于脚本开发。
4.4 搭建测试环境
自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件,添加对象。测试环境的搭建,包括被测系统的部署、测试硬件的调用、测试工具的安装盒设置、网络环境的布置等。
4.5 编写测试脚本
根据自动化测试用例和问题的难易程度,采取适当的脚本开发方法编写测试脚本。一般先通过录制的方式获取测试所需要的页面控件,然后再用结构化语句控制脚本的执行,插入检查点和异常判定反馈语句,将公共普遍的功能独立成共享脚本,必要时对数据进行参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后,需要反复执行,不断调试,直到运行正常为止。脚本的编写和命名要符合管理规范,以便统一管理和维护。
4.6 分析测试结果、记录测试问题
应该及时分析自动化测试结果,建议测试人员每天抽出一定时间,对自动化测试结果进行分析,以便尽早地发现缺陷。如果采用开源自动化测试工具,建议对其进行二次开发,以便与测试部门选定的缺陷管理工具紧密结合。理想情况下,自动化测试案例运行失败后,自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一点时间,确认这些自动上报的缺陷,是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复,如果不是系统缺陷,就检查自动化测试脚本或者测试环境。
4.7 跟踪测试BUG
测试记录的BUG要记录到缺陷管理工具中去,以便定期跟踪处理。开发人员修复后,需要对此问题执行回归测试,就是重复执行一次该问题对应的脚本,执行通过则关闭,否则继续修改。如果问题的修改方案与客户达成一致,但与原来的需求有所偏离,那么在回归测试前,还需要对脚本进行必要的修改和调试。
5 自动化测试架构
真正的自动化测试框架可以不是一个程序,它仅仅是一种思想和方法的集合,说白了,就是一个架构,它定义了几层架构,定义了各层互相通信的方式。通过这个架构我们才能在上面进行拓展我们的测试对象(核心体)、测试库(链接库)、测试用例集(各个windows进程)、测试用例(线程),而其之间通过参数的传递进行通信(即相当于系统中的消息传递)。
5.1 几种自动化测试框架思想
(1)模块化思想
就是将一个测试用例中的几个不同的测试点拆分并且将其单个点的测试步骤进行了封装,形成了一个模块。
例如:一个测试用例要对一个登录程序进行测试,其中包括:用户名输入、密码输入以及确定登录。
那么就可以将用户名输入、密码输入、确定登录、取消登录四个操作分别封装在四个不同的模块中。测试时,只需调用其模块即可。这样的话,当一个模块有变化,你只需单独维护那个模块即可,也可以根据模块的不同组合成不同的测试用例。
(2)库思想
就是模块化思想的升华,其为应用程序的测试创造了库文件(可以是APIs、DLLs等),这些库文件为一系列函数的集合。其与模块化思想不同的是,其拓展了接口思想,即可以通过接口去传递参数,而不是一个封死的模块,可以说是一个多了一个“门”的交互型模块。
例如:登录场景,只是将用户名输入、密码输入、确定登录、取消登录封装成一个库,这个库含有一个函数Login,这个函数Login接收两个参数“用户名、密码”,对输入不同的用户名和密码可以进行不同的测试用例。也可以用另外一个函数Cancle。
(3)数据驱动思想
就是变量不变的数据驱动结果,不同的数据导致了不同的结果的产生。而对于数据的导入,可以通过很多方式,例如:Excle表、XML(用在Web中)、数据库(DB)、CSV文件、TXT等都可以。
(4)关键字驱动思想
关键字驱动就是一种面向对象的思想,例如:QTP、RFT中,对象可以为一个数据或者一个关键字,对对象的抓取,可以将其测试对象封装为一个关键字,这样可以对其关键对象进行各种操作了,不同的对象可以驱动不同的测试流向与结果。
5.2 自动化测试发展
(1)第一代自动化测试,即自动化测试思想刚开始诞生时,依靠的是传统的“录制—回放”技术,这种技术与现在的工具的“录制—回放”思想不一样,其实就是一个“模拟”的过程,即模拟对PC的操作而形成的,其基于你对键盘的输入与对鼠标的操作,原理与按键精灵等类似,这种机制对环境的依赖性太强,对变化性太过敏感,因此不可能发展成一种规模。
(2)第二代自动化测试,即脚本化的自动化测试,利用脚本进行结构化的自动化测试,此可以应用于CLI与API的自动化测试,在此就开始集成了模块化与库思想。
(3)第三代自动化测试,开始产生了各种自动化测试思想,包括数据驱动与关键字驱动思想,其伴随着对象化思想的产生,也造就了现在一系列的自动化测试软件,其中都集成了这些思想,从这时候开始,自动化就开始实现了一定的规模,开始运用在各个行业,并且发展趋势越来越快。
5.3 构建自动化测试框架的策略
做一个自动化测试框架主要是从分层上去考虑,而不是简简单单地应用一种思想,它是各种思想的集合体。而其中,可以贯穿着自动化测试的各种思想,例如:对象层中有关键字的思想、可以将对象库标示在Excel表中进行管理,或者应用动态搜索的方式传递对象识别参数。tasks层中可以封装各种方法,形成一个大型的方法库,而每个方法中可以应用数据驱动的思想。
6 结论
自动化测试的优点是能够很快、很广泛地查找缺陷,同时可以做很多重复性的工作,自动化功能测试工具无须大量的软件测试人员手动地再次执行测试用例,极大地提高了工作效率。可以执行一些手工测试困难或不可能进行的测试。比如,对于大量用户的测试,不可能同时让足够多的测试人员同时进行测试,但是却可以通过自动化测试模拟同时有许多用户,从而达到测试的目的。更好地利用资源。将烦琐的任务自动化,可以提高准确性和测试人员的积极性,将测试技术人员解脱出来投入更多精力设计更好的测试用例。
参考文献
[1]张月亲.建立自动化测试系统的必要性[J].国外电子测量技术,2000(6).
[2]常征.功能测试中自动化测试框架的分析与应用[D].北京:北京林业大学,2007.
学业水平测试的启示和思考 篇10
江苏省南通中等专业学校是南通市比较有代表性的一所职中,学校开设有五年制大专和三年制中专(包括少部分对口单招班),生源遍布整个南通大市,入学成绩差距很大。全校共有948名学生参加了数学学业水平测试,最终成绩按等级分布(百分比)如下:
就数学学科而言,南通中专2012级学生学业水平测试的成绩分布与全市的整体情况大致相当。对比2012级学生入学时的数学中考成绩(学业水平测试数学满分与中考数学满分皆为150分),两次测试各得分段的人数分布情况如下:
尽管该项工作完成得较为圆满,但学业水平测试的推广仍面临诸多的困难。
一、学生整体的数学学习基础薄弱是目前最大的难题
从试点情况来看,测试成绩90分(及格)以上的达到89%,合格(合格率95%)的最低控制线为58分,看似不错,但这里面有两个重要因素必须考虑到:一是命题范围狭窄,90%以上的题目集中在6套模拟试卷上;二是考试由各个学校自行组织监考,这也容易对最后的测试结果造成偏差。
根据学生的入学成绩分析,入学成绩90分(及格)以上的不到44%,60分以上的不到67%,而30分以下的接近10%,20分以下的接近5%。这最后的10%(包括更多)的学生数学学习的困难可想而知,他们不太可能通过教师正常的课堂教学掌握现行教材中最基础的知识和最基本的技能,他们较好的学测成绩不是来源于对知识和技能的理解掌握,而是对模拟试题的死记硬背,这与数学学习规律背道而驰。
二、部分学生数学学习的积极性难以激发
在中考数学成绩不理想的学生中,有少部分是由于智力原因,绝大多数则是对数学学习不感兴趣(产生的原因也很复杂),初中阶段没有很好地学习,与数学学习有关的基础知识和基本技能匮乏。这部分学生进入中职学校后,对学习数学内心抵触,而且他们已经养成了逃避学习的习惯,教师很难用有效的手段来激发他们学习的积极性。
三、就业班级数学教学内容与难度控制难以把握
因为就业班级学生的数学基础参差不齐,且有相当一部分学生的基础薄弱,数学教学必须兼顾到学业水平测试的要求,降低难度,压缩内容,这就容易使得原本基础比较好的学生没压力、吃不饱而逐渐丧失对数学学习的兴趣。如何把平时的教学和学业水平测试的要求有机融合,需要广大教师潜心研究。
四、教学课时不足的矛盾比较突出
学业水平测试科目包括公共基础课程、专业理论课程和专业技能课程,科目多,内容也不少。以数学为例,四册教材共18章内容,要照顾到绝大多数学生能很好地通过学业水平测试,需要有足够的课时量。目前各专业的教学周数不一,公共基础课程学业水平测试(试点)安排在第三学期结束之前,教学课时不足的矛盾显得尤为突出。
当然,数学学业水平测试还面临学校领导认识不到位、教师数量不足、教学效率低下、公共基础课程得不到应有的重视等困难,这些都需要我们找到各种途径加以克服。
在学业水平测试试点工作开展之前,中职学校就业班的数学课程一般只在一年级安排,周课时2~4节不等,教学内容往往是结合专业特点在一、二两册教材中加以选择,缺少地区性的统一测试,有的甚至一个学校都很难统一,自教自考,教学质量无法控制,成为名副其实的“副科”,其他公共基础课程的情况也类似,这就严重影响了学生全面素质的提高。因此,建立中等职业学校学业水平测试制度势在必行。
针对目前数学学业水平测试面临的困难,笔者提出几点建议:
(一)明确学业水平测试结果的运用
应把学测结果与学分计算、毕业、升学等挂钩,让学生清楚学业水平测试结果对自己未来的影响,从而增强学习的主动性。
(二)实施分层教学
对就业班来说,实行走班制、实施分层教学能有效地缓解数学教学内容与难度控制难以把握的困难,使数学教学更具针对性,更适合学生的基础,有利于充分调动学生学习数学的积极性。当然,实行走班制无疑会增加中职学生管理的难度,但这是个趋势,必须加强研究。
(三)加强学测科目统筹,允许学生自主选择测试科目
在中职生中,确有极少数学生缺乏数学学习的能力,他们的数学能力甚至不如小学高年级的一般学生,让这部分学生参加数学学业水平测试对其而言是个巨大的折磨,其他学测科目也会有类似的情况。因此,在明确学业水平测试结果运用的基础上,应加强学测科目的统筹,允许学生自主选择一定的学测科目,并制定特殊的政策,为那些特殊学生(弱智、低能、残疾和有严重疾病等)开辟绿色通道。
另外,对学生参加学测科目(包括公共基础课程、专业理论课程和专业技能课程)的最佳数量也可以开展相关研究,注意公共基础课程和专业理论课程及专业技能课程的平衡。
(四)建立试题库
数学学业水平测试试点工作取得成功的关键就是明确了试题的范围,否则,无论如何命题,测试结果都很难预料,学生测试合格很大可能是取决于运气而不是水平。然而这次测试试点的试题范围太狭窄,不利于平时教学活动的开展。中心组和基地精心编制复习指导用书《数学测试要点及过关训练》和全真模拟题的初衷是建立试题库,但因为时间紧,又要保证试点成功,所以复习指导用书在确定命题范围时被舍弃。既要保证数学教学活动的正常开展,又要保证学业水平测试的效用,必须建立内容全面、有一定题量的试题库。如何建立一个较高质量的试题库有待于深入研究和实施改进。
(五)改革教材
为方便分层教学的实施和学业水平测试的开展,进一步提高中职数学教材的基础性、实用性和职业性,可以组织专家对现有的教材进行大胆的改革。改革后的教材应充分考虑层次性和选择性,要尽量压缩不必要的内容,以更好地适应中职学生的数学学习实际。
(六)改革试卷成绩与等级转换模式
对数学学业水平测试试卷成绩与等级转换也可开展研究。例如试卷分为两部分,第一部分是基础部分,满分100分,这部分成绩用于区分合格与不合格;第二部分是提高部分,满分50分,在合格的学生中与第一部分分数合并,用于区别A、B、C等级。这样做的好处是不拘泥于5%的不合格率。