软件测试转正总结精选(九篇)

第1篇：软件测试转正总结范文

关键词：航空装备，测试程序集TPS，板卡测试

 

0引言随着科学技术的快速发展，特别是数字技术及各种大规模集成电路的广泛应用，我海军航空电子装备发生了巨大变化，组成结构越来越复杂，功能越来越强大，技术含量越来越高，可靠性也有明显提高，但是，装备的三级修理难度却越来越大，“木桶—短板效应”越来越明显，已经成为一个十分普遍的问题，甚至可以说，已经成为提高装备完好率和飞机出勤率的主要瓶颈之一。

为提高部队的维修、保障水平，适应现代战争对后勤的综合保障能力的要求，借鉴国外军用机载设备的综合维护经验，我们研制开发了基于TPS的航空装备板卡测试系统。

1系统组成系统主要由硬件平台、软件平台、测试程序集TPS和附件等组成，如图1所示。

图1系统组成示意图

硬件平台主要包括：测控计算机(TCC)、总线控制器、测试资源、PXI机箱、VXI机箱、矩阵开关、阵列接口、通用信号转接装置、专用适配器/板、高精度电源、连接电缆、相应的附件和机柜等。

软件平台是整个系统指控中心，是系统能有条不紊协同工作的重要保证。系统软件平台由多个功能相对独立的模块或系统组成，负责控制协调系统中测试仪器、激励模拟仪器的工作、测试过程的激励模拟和数据采集，以及运用诊断知识对故障进行推理等，完成对被测外场可更换单元（LRU-Line Replace Unit）、电路板（SRU-Shop Replace Unit或PCB，包括数字、模拟、数/模混合三种类型）的测试和故障定位隔离。

测试程序集TPS是测试程序(TP)、接口装置(ID)和测试程序文档(TPD)的集合。

附件主要有电缆、打印机、设备小车、工作台等。

2系统硬件设计根据被测武器装备LRU和PCB的特点和种类，我们确立了以功能测试为主，辅以其它方法的测试方案。系统采用统一的系统测试软件，PXI、VXI总线和GPIB总线混合式结构形式，标准定义的适配器结构、阵列接口、矩阵开关和机架结构，将计算机资源和系统测试资源等各组成单元有机连接在一起，系统主控计算机软件系统通过标准接口软件实现对PXI总线仪器、VXI总线仪器和GPIB总线仪器的统一调度和控制，产生仿真测试所需的激励，通过通用信号转接箱和专用适配器加载至被测板边缘连接器的相应端子，同时获取相应的响应数据，通过诊断软件的分析、判断，完成故障定位，同时对故障进行模型分析、故障树分析，提取新的故障模式进行故障仿真，并对故障树进行修正。从而自动地或手动地完成对被检单元的测试和诊断。免费论文参考网。航空装备板卡测试系统的硬件结构如图2所示。

图2航空装备板卡测试系统的硬件结构图

2.1测控计算机(TCC)测控计算机（TCC）由计算机主机、显示器、鼠标、打印机等设备组成。计算机主机内含有MXI-2(或1394)总线接口卡、GPIB总线接口卡、显卡等。测试控制计算机是NAAE-GPTDS的测试、控制中心。

2.2测试资源根据初步确定的信号特征，系统的测试资源包括：零槽控制模块、ARINC429总线模块、1553B总线模块、八通道串口、VXI四通道示波器、函数信号发生器、数据采集模块、数字多用表、任意波信号发生器、D/A模块、A/D模块、开关量I/O模块、矩阵开关、继电器模块、射频开关、大功率继电器模块、程控电阻模块、总线模拟控制器、各种导航信号模拟器、雷达信号模拟器、导弹模拟器、程控交流电源、程控直流电源、固定直流电源等多种测试资源(PXI、VXI模块)。

2.3阵列接口阵列接口是信号输入输出的通道，是测试系统与适配器的连接界面。阵列接口应采用VPC 90系列阵列接口，参考ARINC608A的标准。设计过程中，通道的数量应考虑系统以后的扩展能力，要预留一定的通道数量。

2.4矩阵开关矩阵开关实现测试资源信号的切换。

2.5通用信号转接装置通用信号转接装置主要用于PCB与系统阵列接口之间的测试信号转接与调理，包括：插件板转接器、信号转接调理器，结构如图6所示。免费论文参考网。整个转接与信号调理装置规划为五个区：总电源区、插件板区、信号调理区、程控电源区和资源连接区。

2.6接口适配器(TUA)该接口适配器主要完成LRU和ATE系统阵列接口之间的电气、机械连接装置，其功能是实现信号的调理、匹配和转接。必须根据各个被测试对象的实际情况自行研制。不同的被测设备必须通过相应的适配器才能接入系统进行检测。

2.7连接电缆外部连接电缆主要功能是为被测试单元连接到ATE的接口适配器提供电气、机械的连接，连接电缆的制作应当符合国军标的有关要求。为了防止在连接机载设备出现差错，在设计时对于连接电缆插头相同的应采取防差错设计。

3系统软件设计航空装备板卡测试系统的系统软件是系统的灵魂，是系统正常、可靠运行的基础。在充分分析航空装备板卡测试系统的功能需求的基础上，采用层次化、模块化设计方法和成熟的技术进行系统软件的设计和开发。系统软件具有良好的可视化人机界面，使用方便。

为了保证系统软件的顺利开发，按照软件工程的思想，进行系统软件的需求分析、概要设计、详细设计及各阶段软件的文档编制及管理，在开发过程中采用项目管理软件对系统软件开发分阶段实施及管理。

3.1操作系统与软件开发环境操作系统选用Windows2000。

开发环境：测试软件的开发主要采用Lab Windows/CVI，同时采用VB、VC等通用开发软件进行开发。测试程序集TPS开发采用专用的开发工具（如Top Test、PAWS等）进行开发。免费论文参考网。数据库的开发采用Microsoft Access。

3.2系统软件的结构与组成系统的软件主要由测试系统集成软件、系统自检、系统校准、执行软件、测试诊断开发平台软件、在线帮助、系统数据库管理软件和系统数据库组成。

航空装备板卡测试系统的系统软件采用层次化、模块化设计方法，是面向信号的测试系统软件。软件的结构如图3所示。

图3航空装备板卡测试系统系统软件层次结构及组成

3.3TPS测试程序的设计测试应用层是系统软件的顶层，实现被测试单元测试，并提供人机对话及操作界面。该层含有全部被测试单元的测试程序集(TPS)。

(1) 测试程序集(TPS)的定义及其功能

TPS是测试程序(TP)、接口装置(ID)和测试程序文档(TPD)的集合。

测试程序是航空装备板卡测试系统针对被检测单元的测试过程而编写的执行具体检测任务的软件，在测控内核模块提供的测试函数的基础上完成对设备的检测、测试和故障诊断并输出结果。

接口装置是指阵列接口和接口适配器所描述的信号路径、电气连接去向等，这些内容将在测试程序编程时通过定义常量、变量或编写程序实现。

测试程序文档是测试程序的说明和一些辅助资料，对测试过程中的某些信息、接口装置的相关信息加以说明，如测试通道、测试连接关系和需操作人员干预的信息等。测试程序文档是系统测试程序开发的重要的组成部分，在系统的开发过程中应当重视文档的建设和管理。

(2) TPS的基本设计要求

测试程序应当操作简单、实用，测试资源控制方便，测试过程稳定、准确和测试数据精确、可信。

在设计测试程序时，按专业进行模块化设计，采用标准C语言编程，源代码不涉及具体的测试资源信息，这样使测试程序的结构明了、通用性好，具有良好的稳定性和可移植性。

(3) TPS界面

TPS界面是人机对话和测试结果输出的界面，是航空装备板卡测试系统的重要组成部分。TPS界面采用图形窗口的形式，以鼠标化操作为主，配合少量的键盘操作(输入文字、数字、必要的热键)。

(4) TPS模块组成

航空装备板卡测试系统的TPS按被测设备的成品组件LRU和电路板PCB进行模块分配。基本分配原则是一个LRU就有一个TPS，一个PCB就有一个TPS。单项TPS模块中的各项测试及完成的其它功能按树状结构进行逐级分解。

LRU单元TPS总体模块的大致划分如图4所示。同样可按照PCB板进行划分共若干个TPS。

图4单项TPS的基本模块结构

4系统工作模式为了能够适应各种类型的被测PCB，同时更进一步提高系统测量精度、自诊断精度、故障覆盖率和故障定位精度，系统设计了4种工作模式。

l全自动工作模式：对于部分可测试性较好的PCB，系统从PCB边缘连接器可以获得故障定位所需的全部信息，此时系统根据已开发的测试诊断程序，自动完成全过程操作，完成故障定位任务，同时诊断结果存入相应数据库，并形成诊断报告；

l半自动工作模式：对于部分不能通过被测PCB边缘连接器获得全部诊断信息的，系统按照诊断流程的提示，提示操作人员使用元器件夹具、探针笔进行测试或提供人机对话方式获取其余信息，提供给诊断分析程序完成故障定位任务；

l自检工作模式：为了提高系统的可靠性和使用效率，系统设计了上电自检、人工启动自检和定期自检三种自诊断方式。系统在加电时，能够自动进行自检测试程序；能够定期自检测试，也可以由人工启动进行自检测试。自检测试结果输出或自动存档；

l人工测试模式：对于微波电路的故障诊断系统采用人工测试诊断方式，另外操作人员需要临时完成一个小TPS设计与实施，或需要对某种故障模式进行仿真等临时任务，系统提供手动测试方式，操作人员根据系统向导提示按步骤完成仪器配置、测试流程配置等工作，或使用仪器软面板完成临时测试任务。

5结束语航空装备板卡测试系统从硬件结构到测试软件都符合ATE的统一标准，通用性好，易于实现；而且具有一定的灵活性，便于使用。能满足二级和三级维修保障需求。对降低维修费用、提高装备的完好率具有十分重要的意义，军事和经济效益是明显的。

参考文献：

[1]邱智，王玉峰等. 机载设备自动测试系统平台设计[J].测控技术.2005，vol(24),NO1.

[2]王凯让，吕洁光等. 通用电路板自动测试与故障诊断系统[J].宇航计测技术.2005，vol(25),NO1.

[3]周鑫，何昭. 信号发生器通用自动测试系统软件的研制[J].计量技术.2005，NO4.

第2篇：软件测试转正总结范文

边界扫描测试的物理基础是IEEEl149.1边界扫描测试总线和设计在器件内的边界扫描结构，标准的边界扫描结构如图2所示。其中边界扫描测试总线由测试数据输入(TDI)、测试数据输出(TDO)、测试时钟(TCK)、测试模式选择(TMS)和复位信号(TRST)五根信号线组成。而标准的边界扫描结构就是在器件内部的核心逻辑I／O引脚增加了边界扫描单元(BSC)，同时还增加了和边界扫描测试相关的指令寄存器、数据寄存器、测试访问端口TAP控制器等电路。在测试状态时，边界扫描结构可以对数据寄存器或指令寄存器进行操作，即从TDI端u把测试矢量移入边界扫描单元，从TDO端口把测试响应移出。

总体设计方案

便携式边外扫描故障诊断仪需要根据被测系统电路的描述文件生成边界扫描测试矢量，然后转换为IEEE1149.1边界扫描测试总线信号自动加载到被测系统中，同时从TDI引脚自动读取边界扫描测试响应进行分析处理，根据边界扫描相应算法作出故障诊断决策及定位隔离，最后通过LCD显示诊断结果。本文采用片上可编程系统解决方案将便携式故障诊断仪进行软硬件协同设计在一片FPGA上，使所设计的电路系统在其规模、可靠性、体积、功耗、上市周期、开发成本、产品维护及硬件升级等多方面实现最优化(整体结构示意图如图3所示)。

本文采用Altera公司嵌入软核Nios处理器的FPGA作为载体来实现边界扫描敝障诊断仪的SOPC系统。边界扫描故障诊断仪主要实现边界扫描测试矢量的生成、JTAG总线信号发生器、边界扫描故障诊断应用软件、故障显示等功能，是便携式边界扫描故障诊断系统的核心。利用SOPC Builder创建Nios软核CPU并进行参数化配置，同时构建储存器、计时器、LCD接口组件、IEEEl149.1测试总线用户逻辑为一体的SOPC系统，边界扫描故障诊断片上可编程系统内部模块配置图如图4所示。

本文利用向导式界面灵活定制边界扫描故障诊断系统，采用标准型NiosII软核处理器，井添加了4K字节的指令缓存Cache。同时为了方便调试边界扫描故障诊断系统的软硬件，在处理器模块中添加JTAG调试单元，在SOPC系统软硬件调试成功且能独立运行后，也可以将JTAG调试单元去掉。

可复用IEEEl149.1测试总线控制器IP核是边界扫描测试控制器的核心，也是整个边界扫描测试平台设计的关键所在。本文设计的IEEEl149.1测试总线控制器IP核主要功能包括：产生边界扫描测试时钟TCK、对被测系统电路输出TMS控制序列、读取被测系统的测试响应和加载测试矢量、与SOPC系统中的微处理器进行通讯及测试数据交换和在TCK和TMS配合下控制被测系统中TAP控制器完成边界扫描测试的全部过程。

在IP核的开发过程中采用IC的设计思想，首先根据功能需求确定外部接口，然后划分内部结构单元，通过实现内部每个小单元的功能，最后组合完成JTAG总线控制IP核的整个设计，JTAG总线控制逻辑内部体系结构图如图5所示。其中TDO缓冲模块主要由FIFO、计数器、并/串转换及控制部分组成。

系统软件开发

μc/cs操作系统移植

将μC/OS-II移植到Nios软核CPU平台上，只需修改与处理器相关的代码OS_CPU.H、OS_CPU_A.ASM、OS_CPU_C.C三个文件。同时根据本系统的功能需要，用OS_CFG.H配置内核设置系统的基本情况以及整个实时系统所需要内核和用户的头文件INCLUDES.H。根据各个任务的重要性和时间关键性，设定每个任务的优先级，以便任务调度之用。

故障诊断软件

故障诊断软件首先根据预先固化在Flash存储器中的被测系统的边界扫描描述文件(BSDL)和网络表等描述文件生成两个测试数据文件：系统链路信息文件和器件间互连网络节点文件。同时还需要获得测试器件物理引脚号码和器件边界扫描单元的对应关系。然后根据相应的边界扫描测试算法和不同的测试内容生成测试数据：测试指令代码、完整性测试数据、互连测试数据、芯片功能测试数据并且加载到被测系统扫描链路中及读取边界扫描测试响应。其次分析处理测试响应数据，剔除扫描链中垃圾数据，提取获取故障诊断有用信息。最后根据测试内容不同，进行扫描链路完备性测试故障诊断、互连测试故障诊断、器件功能测试故障诊断、簇测试故障诊断作出诊断结果。边界扫描测试故障

第3篇：软件测试转正总结范文

虚拟仪器具有良好的系统开放性和扩展性，能够在有限的硬件基础上通过软件开发实现多样化的测试设备搭配。本文主要论述虚拟仪器测试设备的软硬件组成，自动测试系统的开发以及虚拟仪器测试设备的校准。

【关键词】虚拟仪器 专用测试设备 PXI总线

1 虚拟仪器的发展概况

1.1 虚拟仪器的概念

虚拟仪器（Virtual Instruments，VI）的概念最初是由美国国家仪器公司在上世纪八十年代提出，一般认为是在计算机基础上通过增加相关的硬件和软件而构成不同的仪器，实现各种用户定义的仪器或测试功能。

1.2 虚拟仪器的组成

虚拟仪器通常由硬件设备与接口、功能实现软件和人机交互界面组成。硬件设备与接口可以是各种以计算机为基础胡扩展类设备，或者是其他各种可直接、间接程控的设备；功能实现软件根据仪器的功能定义对硬件功能进行整合，从而实现仪器功能；人机交互见面提供了传统仪器面板所进行的操作和显示功能。

2 虚拟仪器技术在测试设备中的应用

虚拟仪器技术的优势在可由用户定义专用测试设备，且功能灵活，构建简便，特别契合专用测试设备开发需求。虚拟仪器把强大的计算处理能力和测量、控制能力结合在一起，可通过软件实现对数据胡实时分析处理。

2.1 虚拟仪器测试设备的总线接口选择

现阶段虚拟仪器的接口总线类型多样，有数据采集卡式（DAQ）虚拟仪器、串口虚拟仪器、USB虚拟仪器、GPIB虚拟仪器、VXI虚拟仪器、PXI虚拟仪器。

综合性能、价格等多方面因素，推荐使用PXI总线。PXI总线规范是在PCI总线规范上发展而来的，具有传递数据量大、传输率高等性能特点，并且增加了专用的系统参考时钟、触发总线等，以此满足仪器领域高精度的定时、同步与数据通信要求。相比较同样用于测试系统开发的VXI总线，PXI总线具有更小巧的体积、更低廉的成本以及更好的标准操作系统框架。

2.2 基于PXI总线的虚拟仪器测试设备

2.2.1 硬件方面主要包括功能板卡选择和接口电路设计

功能板卡的选择主要取决于测试设备需要实现的功能，可以根据测试的具体参数，在保证测试通道和测试精度的前提下选择合适的板卡。常见的数据采集卡、数字表卡、矩阵卡等功能板卡在功能上足以保证常用的测试设备需求，能够比较便捷地搭建所需的测试设备。

接口电路是测试设备和被测设备之间的连接部分，也是专用测试设备与通用测试设备区别最大的地方，主要是被测信号的多样性和特殊性所决定的。精确高效稳定的接口电路设计是虚拟仪器测试设备功能实现的基础，被测信号的类型、量值、精度等诸多因素都是在设计接口电路时要考虑的，基本原则是让被测信号能够被完整准确的读取。

2.2.2 软件方面现在常用的是LabVIEW之类的图形化G语言编制

开发人员不再需要在硬件驱动和函数套用上消耗过多的精力，只要调用相应模块并进行图形化连接就能很便捷的完成测试程序的编制，但要注意过多的未经优化的嵌套循环会严重影响G语言程序的运行效率。

2.3 基于虚拟仪器的自动测试系统

现在的虚拟仪器测试设备已经逐渐从单一的测量设备发展到了自动测试系统，所谓自动测试系统是指采用计算机控制，能自动完成激励、测量、数据处理并显示或输出测试结果的系统。虚拟仪器自动测试系统能够最大限度的发挥计算机的数据处理优势提高测试效率，同时具备良好的开放性，能够便捷的实现测试系统的功能扩展和功能转换。

虚拟仪器自动测试系统与虚拟仪器测试设备的硬件和软件都存在较大的区别。

硬件方面，除了要有被测信号采集通道外，还需要提供被测试备的输入信号甚至是工作电源，让被测设备能蛟诓馐曰肪持卸懒⒐ぷ鳎从而保证测试过程的完整性和有效性。

测试软件是自动测试系统的核心，功能完善的测试软件除了能够判定被测设备的工作状态，还能进行故障定位。实现故障定位的途径主要有两个，一是设置合理的中间采集点，监控对被测设备工作过程，通过各采集点的工作状态定位故障，需要对被测设备的工作原理有比较透彻的认识，能够准确的选定采集点；二是能够积累足够多的故障案例，通过“查表法”进行故障定位。

3 虚拟仪器测试设备的校准

虚拟仪器测试设备的校准计量是一个新兴的课题，鉴于虚拟仪器测试设备的多样性和灵活性，对其校准的方法还没有一致的校准规范和标准。

传统设备计量所使用的“端对端”比较的计量方法只适用于实现简单测量功能的虚拟仪器测试设备，对虚拟仪器自动测试系统就很难准确完整地反映设备的工作状态和精准程度。

首先是对组成虚拟仪器的功能板卡进行校准，这部分板卡都有明确的独立功能，通常都会提供明确的校准规范和标准，能够使用传统手段进行校准。

其次测试软件中的数据处理和算法等可能影响的是精度的因素在设计时已经考虑，只需要对软件版本是否现行有效进行确认即可。

再次是对接口电路部分的工作状态进行检查校正，因为接口电路部分对信号转换时存在的误差和错误会直接影响测试结果的准确性，接口电路通常由各种电子线路组合而成，可以通过传统的校正方法进行校正。

做好以上几点，结合正确的操作使用，应该就能够保证虚拟仪器测试设备的测试精度。

4 结束语

虚拟仪器从概念的提出到广泛运用，体现了计算机技术对传统工业技术的革命性推进。虚拟仪器作为新兴的仪器设备形式，用户可以自由定义其功能结构，构建灵活，转换快捷，特别适用于专用测试设备各式各样的测试需求。利用虚拟仪器思想搭建的测试设备提高了测量精度和速度，成本消耗较低，今后将是专用测试设备发展的重点方向。

参考文献

[1]武治海，吉顺祥，王方明.基于虚拟仪器的测试仪应用研究[J].仪表技术，2007（10）.

[2]刘帅，曹成俊，李志强.PXI总线技术在虚拟仪器中的运用[J].计算机与数字工程，2008（08）.

[3]李明辉，刘连生，曲培树.基于虚拟仪器的自动测试系统研究[J].电子测试，2008.

第4篇：软件测试转正总结范文

关键词：光纤放线 动态测试 传感器 labview

中图分类号：TN818 文献标识码：A 文章编号：1007-9416（2013）12-0136-03

高速放线解脱力实时测试系统是地面模拟放线装置的一部分，用于测试主放线台高速放线时光纤受力的实时变化，并对测试数据进行分析处理。将放线力测试数据与相应的放线速度和光损耗测试数据结合，可以对光缆的动态性能作出较为完善的分析[1]。在放线过程由于光纤发生断纤、放线不顺利等问题，需要研究解脱力的大小变化，光纤放线解脱力是放线试验一个重要的力学参数，解脱力直接影响放线试验的成功与否，要研究解脱力的变化必须在放线试验时对其进行实时测量。而解脱力的大小与方向随时间不停变化，用一般的方法很难进行测量，因此有必要设计系统对解脱力进行测量，研究其在放线试验时的变化。通过对测试结果的分析，可近一步提高放线效果。

1 光纤放线解脱力测试原理

1.1 放线解脱力的特性分析

在地面模拟放线试验中，光纤以螺旋形状紧密的缠绕在线包上，形成一层一层的线圈并且匝与匝之间在缠绕时用粘结剂使其整齐的排列。光纤在线包上多层分布，每层光纤要求排列紧密均匀，各匝之间间隙相等，以保证下一层的正确缠绕。而在放线试验时光纤从线包上一层一层的脱落下来，在即将脱离线包的光纤与下层的光纤和相邻匝的光纤之间存在相互力作用，本文测量的解脱力就是光纤从线包上脱落是的产生的应力。

1.2 测试原理

（1）轴向力的测量原理。测量系统采用电阻应变式力传感器，电阻应变式力传感器的原理是当被测力作用在弹性元件并引起其中弹性体的变形，进而使弹性体上应变片的阻值发生改变，电阻的变化通过测量电桥的处理，转化成与之成线性关系的电压输出，根据输出电压的变化即可得出被测力的大小[2]，当放线试验进行时线包受到放线方向的轴向拉力时，将线包将与传感器连接，此时产生的轴向拉力将力传递到拉力传感器上，传感器中的传感元件产生于拉力成比例的应变，使电阻产生相应的变形，电阻的变化破坏了电桥平衡，由此输出电压信号。即拉应力的变化转化为电压的变化，再由传感器输出拉力信号。信号经放大处理后由数据采集卡输出所需要的电压信号。（2）切向力测量原理。放线试验中解脱力产生的沿线包缠绕光纤切向的分力为切向分力，其对线包有旋转运动的作用，从而产生了旋转扭矩。由力学关系可知扭矩等于力与力臂的乘积，测量切向力就转化成测量切向力对线包产生的扭矩。选择扭矩传感器同样可以测得切向力。

2 硬件的选择

（1）传感器选择。拉力传感器系统采用PPM225-LS1-1系列应变式拉压力传感器，采用S型弹性元件结构，它具有优良的自然线性，其精度高，抗偏载侧向能力强。其主要技术指标为；量程0～5kg，灵敏度2.0±0.01mV/V，综合精度±0.02%FS（线性+滞后+重复性），蠕变±0.03%FS/30min，供电电压10VDC，允许过负荷150%FS，扭矩传感器采用PPM-N1B扭矩传感器，它适用于非连续旋转的扭矩力值的测量与控制；既可以测量静态扭矩，也可以测量动态扭矩；检测精度高，稳定性好，抗干扰性强；体积小，重量轻，易于安装；不需反复调零即可连续测量正反向扭矩。其主要参数如下：额定载荷0～5N.m，综合精度0.2%FS（线性+滞后+重复性），蠕变±0.3%F·S/30min，灵敏度1.0mV/V，允许过负荷150%FS，供电电压10VDC。（2）数据采集卡的选择。NI USB-6212是一款总线供电USB M系列多功能DAQ模块，在高采样率下也能保持高精度。该模块提供了16路模拟输入；400 kS/s采样率；2路模拟输出；32路数字I/O线；每通道有4个可编程输入范围（±0.2V-±10V） ；数字触发；2个计数器/定时器。

3 测量系统方案

本测试系统是硬件及软件相结合构成动态力测试分析的一个系统，以传感器、放大器、数据采集卡等硬件组成实际测试系统硬件，由计算机软件为动态测试数据采集机分析处理系统。测量方案如图2所示。

放线解脱力用测量切向分力的扭矩传感器和测量轴向分力的拉力传感器共同测量，根据传感器工作原理， 拉力传感器将沿线包轴向力转化为电信号输出，扭矩传感器将沿绕线方向的切向力转化为电信号输出，数据采集装置采集到经过调理的信号。通过一定信号传输技术将数据传到计算机上，在虚拟仪器LabVIEW平台上实现数据的显示与再处理。

4 软件设计

4.1 软件结构

根据测试软件的要求，要实现轴向力与切向力测量的数据采集系统，整个软件系统模块划分要根据应用需要对系统总体框架和系统功能进行分解形成模块。根据系统功能要求，本系统开发了三个功能模块，包括数据采集、数据存储、数据分析及回放。每一个模块都有它独立的功能，数据采集模块对数据采集卡直接操作，负责读取采集卡中采集的数据，以动态曲线和数字同时显示。数据分析模块可以实现历史数据进行回放、最值等功能。数据存储模块可以实现数据保存，通过和数据库的连接，将数据存入数据库中。图3为系统软件的框架结构。

软件部分是测试系统的核心，本系统拟采用美国NI公司的 LabVIEW开发平台。 该软件界面操作方便，合乎传统仪器的操作习惯；模块化设计，程序的可读性、可移植性、可扩充性强[4]。根据测试系统需求，本系统的软件设计主要完成拉力信号和扭矩信号双通道数据的采集、实时显示、数据分析、数据回放与存储等功能。

4.2 软件设计

如上文所述，数据采集系统需要实现两个通道上两个方向应力的测量，本系统软件程序主要包括三个方面的内容如图 ：（1）解脱力数据采集及曲线显示，它的主要功能是通过数据采集卡将滤波后的信号采集，通过labview程序将其读取，并绘制拉力和扭矩的实时曲线；（2）数据保存与数据回放，它的主要功能是将采集到的数据保存称为数据文件，并可以通过数据回放的功能随时查看先前的测量结果；（3）测量数据分析，它的功能是对一次测量的全部数据进行统计分析。得出这组测量值的统计数据包括最大值、最小值、以及实时数值等。测量系统软件的前面板如图4所示，测量软件程序框图如图5所示，数据回放程序如图6所示。

5 结语

本系统以 LabVIEW软件为开发平台工控机及数据采集卡为硬件平台， 开发了一套动态应力测试系统。通过研究解脱力特性把解脱力性分解两分力，再根据两种相应的传感器将分力转换成电信号，借助labview平台设计解脱力数据实时采集与保存、历史数据读取等功能的软件组成测量系统，完成放线解脱力的测量系统的设计，为光纤放线过程中动态解脱力的实时测量提供了解决方案。

参考文献

[1]杨帆.制导光缆高速放线过程中受力测试技术研究[D].南京：南京理工大学，2004.

[2]陶宝祺，王妮.电阻应变式传感器[M].北京：国防工业出版社，1993：38-39，316-317.

第5篇：软件测试转正总结范文

关键词：形式化方法；Z语言；业务基础软件平台；软件工程；装备管理

中图分类号：TP301.2 文献标识码：A

1 绪论

伴随武器装备建设的快速发展，装备管理流程化、规范化的迫切需要，装备管理信息系统在现代装备保障中的作用日益突出。为适应装备管理模式持续改革、装备管理业务不断升级的需要，装备管理信息系统软件必须持续升级快速更新。但由于软件规模增大、复杂度增加，开发进度严重滞后、经费失控、质量糟糕等问题十分突出，传统的开发方法已不能适应业务需求加速变化的形势需要。

解决和处理软件开发问题有两大方法。软件工程方法建立了多种软件开发过程模型，从不同角度解决软件开发问题，试图控制进度、成本，提高软件质量。但由于需求描述不清、理解有误而导致的改正成本成指数增加，开发问题积重难返。形式化方法[1]为准确描述需求提供了一种全新而有效的技术途径，但该方面的研究限于理论研究层面多，在实际工业项目的应用相对较少。

本文将形式化方法与软件工程化思想有机结合，以工作流引擎和规则引擎技术为支撑，基于Z语言构建了装备管理业务基础软件平台，通过形式化方法精确描述业务需求、业务基础平台加速软件开发进程、自动化测试提升软件质量，探索解决装备管理软件开发问题的途径。

2 研究现状及存在问题

软件开发问题主要分为理论方法和技术方法两大基本研究方向。技术方法以软件工程化研究为主，按照“软件工厂”模式提高软件生产效率，实用性很强，得到了产业界的广泛支持。随着软件的规模越来越大，复杂度越来越高，很难保证软件的可靠性和软件的开发效率。理论方法以形式化方法研究为主，目标是使系统具有较高的可信度和正确性，但实用性较差，难以投入实际应用。

2.1软件工程方法

1968年NATO提出“运用系统的、规范的和可定量的方法来开发、运行和维护软件”的工程化思想，主要包括方法、工具和过程三大要素。四十多年来，软件工程虽然取得丰硕成果，但进度安排和成本估算不准，需求不清、变动大，质量低、难维护等问题依然日益严重，软件需求、开发进度管理和软件质量已成为软件工程化面临的三个主要难题。

上世纪八十年代中期软件需求工程[2]被提出，Herb Krasner给出了需求工程五阶段生命周期的定义，Matthias Jarke和Klaus Pohl给出了需求工程包括获取、表示和验证三阶段的生命周期定义。需求工程逐渐成为研究热点问题之一。“基于知识的需求工程”[3]把AI （Artificial Intelligence，人工智能）技术应用到需求工程领域，具有一个知识库和推理机制，在此基础上进行需求分析，检测其活动。美国南加州大学开发的一个基于知识的需求检测工具QARCC。“形式化需求分析方法”[4]是使用一种形式化语言进行语言公式的形式推理，用于检查语法的良构性并证明某些属性，其主要优势在于可以减少二义性、提高准确性、为验证打好基础、允许对需求进行推理等。

为解决开发进度问题，软件设计方法方面的研究成果众多，可分为重量级方法和轻量级方法。重量级方法产生大量的正式文档，强调以开发过程为中心，主要包括ISO9000、CMM和统一软体开发过程（RUP）等。轻量级方法没有对大量正式文档的要求，主要包括“极限编程”和“敏捷流程”等。面向方面的程序设计（AOP）被认为是近年来另外一个重要发展方向。

为解决软件质量问题，以软件测试为主要研究方向取得飞速发展。统计表明：在典型的软件开发项目中，测试工作量往往占软件开发总工作量的40%以上[5]。软件测试阶段在整个软件开发周期中所占的比重日益增大。软件测试环境复杂、分析工作量大，手工测试效率低，自动化测试逐渐取代手工方式成为主流测试方法。自动化测试具有效率高、成本低、效果好、可以复用等优点。自动化测试工具主要有Robot、Winrunner和QACenter等。此外，采用形式化方法描述并证明软件需求形式化规格说明，通过程序正确性证明、形式化推理分析、模型检验等方法证明软件正确并提高软件的质量，但这些方法处于研究阶段较多，存在一定的局限性，还没有达到工程化应用要求，软件测试仍将是提高软件质量的重要方法。

2.2形式化方法

形式化方法（Formal Method）是建立在严格数学基础上的软件开发方法，以精确的语义描述软件系统，在此基础上进行自动生成、转化及验证。20世纪60年代“软件危机”以来，在推动软件工程化以外，形式化方法的研究及应用也取得了长足发展。

形式化方法通常可分为五类[6]：（1）基于模型的方法，如：Z、Object-Z、VDM、B等。（2） 代数方法，如：OBJ、Larch规约语言、CLEAR等。（3）过程代数方法，如：通信顺序过程CSP、通信系统演算CCS、通信过程代数（ACP）、计时CSP（TCSP）、时序排序规约语言（LOTOS）等。（4）基于逻辑的方法，如：时序逻辑、Hoare逻辑等。（5）基于网络的方法，如：Petri网、状态图等。

形式化方法的应用可分为三个层次[7]：形式规格说明、用形式化开发和形式化校验产生程序和完全使用机器校验的定理证明。形式化方法在开发大型软件系统和解决特殊问题等方面存在局限性，且缺乏工具支持，但形式化方法对于改进软件质量是十分重要的，一定会成为解决软件开发问题的有效途径之一。

2.3业务基础软件平台

信息管理系统复杂、业务需求变化频繁、工程量大。传统开发模式是在底层技术平台上直接构建系统，特点是编码式开发和一次性开发持续运行，因此导致软件僵化，业务组件无法重构，效率低下。现代开发模式要求按需求定制；组件化设计，实现软件复用；易调整，可配置，实现柔性设计；开放性架构与标准化接口，实现持续集成等。各类应用系统开发实践逐渐形成了基于平台的快速开发方法。业务基础软件平台[8]主要指以业务导向和驱动、可快速构建应用软件的开发平台，是业务管理类应用软件的通用基础平台，主要产品有：用友UAP、普元EOS、金蝶BOS、东软金算盘UP和E6，以及SAP NetWeaver等。

2.4Z语言

Z语言[9]是基于一阶谓词逻辑和集合论的形式规约说明语言，适合用于编写计算机系统规格说明，主要特点是：可推理和证明、是结构化的、可使用自然语言、和模型可求精实现，不足是缺乏关于计时或并发行为的描述能力。

Z语言形式规约是一个强类型系统。Z形式规约的数据类型可分为基本类型和复合类型。Z形式规约的构型主要包括抽象状态构型、操作构型、声明使用构型、谓词使用构型、重命名构型和类属构型等，其中最主要的是说明软件系统的状态构型和说明状态转化的操作构型。

构型由声明和谓词两部分组成，有水平和垂直两种表示形式。水平形式：[声明|谓词]；垂直形式可理解性和可读性更强：

2.5存在的主要问题

可以看出，软件开发过程存在的主要问题包括：

（1）形式化方法在软件开发过程中的应用还不普及，对需求表述研究应用的多，对软件需求到软件代码自动化转换研究的少，进展不明显。

（2）业务基础平台的发展取得了很大进步，尤其以工作流技术为核心的平台实现了面向功能到面向业务过程的变化，针对业务规则的配置修改变得灵活了，但业务规则的提取依然复杂，软件开发过程依然很繁琐，自动化程度很低。

（3）形式化方法与业务基础平台的结合研究尚未开展，仍然没有两者良好结合的应用实例。

3 平台体系结构与设计

（1）Z语言的引入

业务基础软件平台将非功能性需求通过系统基础功能模块的形式实现，在统一的需求分析、设计开发和高强度产品级测试的基础上，对质量提供有力保证，并通过持续的更新升级以进一步提升质量。功能性需求受到装备发展、管理理念和思想的进步等因素影响，处于不断的变化发展之中。基于业务流程和业务规则的业务基础软件平台，将流程和规则与软件分离，具备流程自定义和规则自维护能力，提高了应对软件变化的能力。基于流程图和自然语言的业务需求描述不精确的问题依然存在，伴随需求的变化更新，错误的累积效应将放大显现。引入Z语言的形式化方法精确描述业务需求，形成与业务流程和业务规则的转换机制，将为解决软件开发问题提供一种新的方法途径。

（2）Z-EMP平台体系结构

Z-EMP平台设计理念是：针对功能性业务需求发展变化大、规则复杂，引入形式化方法消除需求的不确定性，通过求精转换技术，结合工作流引擎和规则引擎，形成可运行的系统业务功能；针对非功能性业务需求变化小、实现负杂，基于基础软件平台的系统公共功能，通过功能模块组合，形成可运行的系统公共功能。

Z-EMP平台综合运用工作流管理系统、商用智能和规则引擎等技术，通过形式化方法准确描述业务需求，求精转化为业务流程和业务规则，基于规则引擎和工作流引擎等运行平台运行，形成装备管理软件系统。

业务基础软件平台的体系结构如图1所示，分为用户接口层、引擎层、业务逻辑层和持久化层。用户接口层是一个软件平台最重要的组成之一，是用户和软件平台交流的媒介。引擎层是业务基础软件平台的核心，综合运用工作流引擎JBPM和规则引擎Droofs，协调调度业务流程和业务逻辑API接口。业务逻辑层是业务基础软件平台的业务支撑层，逐步固化和组合业务逻辑API接口供引擎层调度。持久化层通过对象关系映像技术ORM（Object/Realtional Mapper）来进行数据持久化。

（3）Z-EMP平台设计

Z-EMP平台包括四个部分：需求分析平台、快速开发平台、运行支撑平台和测试平台，从软件生命周期来看，涵盖了需求分析、设计、编码、测试、部署运营等多个阶段。 软件开发人员从输入形式化需求规格到完成测试整个软件开发过程的大部分工作均可提供支持。该平台的实现在满足快速开发和灵活定制需求的前提下，还应当注重实用性、经济性、可行性，因此应利用一些开源软件，在此基础上进一步扩展提升，为平台的开发提供支持。

平台的技术方案总体考虑如下：

（l）平台总体采用J2EE架构。J2EE具有跨平台、可伸缩、灵活、易维护等特点，作为平台的开发体系具有独特的优势。

（2）通用环境支持常用开源及商用数据库和服务器。通用环境支持是保证基于平台的应用快速完成开发、部署的重要基础，应该尽可能多的提供对这些服务器和数据库的支持，供用户按需配置。

（3）平台通用语言采用JAVA，接口和配置文件采用XML语言。

（4）平台开发工具以Eclipse为主，结合其他专用工具。基于Java、开源的Eclipse可扩展开发平台是主流的Java开发工具之一。Eclipse开发工具提供了主框架和一组服务，用于组件化构建开发环境，通过加入组件用户可无约束的扩展功能，这正好也符合了业务基础软件平台运行环境多变和功能特别复杂的需要。其他专用工具有Ant和FreeMaker扩展引擎开发工具和JDK、Tomcat和Mysql等基本运行环境专用软件。

3.4.1需求分析平台设计

需求分析平台通过对预置的形式化需求规范的扩展分析，以流程描述为基础，以基于Z语言的形式化需求描述为核心，提供完整的需求分析报告。图2给出了需求分析平台模块整体设计结构图。

需求分析平台用于设计开发人员与业务人员沟通交流业务需求并形成需求规范的一套工具组件，其基本工作流程是：

（1）获取分析业务对象，构建对象集。

（2）状态构型描述。

（3）获取分析业务操作，构建操作集。

（4）操作流程分析，操作构型描述。

（5）构建声明集，声明构型描述。

（6）构建谓词集，谓词构型描述。

（7）组合构型和框架构型描述。

（8）引用模板生成形式化需求文档。

（9）Z类型检查，形式化分析推理，修正形式化需求。

平台需求的形式化分析与设计主要将平台化装备管理需求通过形式化分析与设计形成形式化需求模板，将装备管理信息系统的功能需求抽象形成装备管理基础业务软件平台的通用需求，使用Z语言进行形式化描述，构成形式化需求模板的基础文件。形式化需求模板是Z-EMP需求分析平台的组成部分，由平台一同管理维护。用户使用平台进行信息系统的需求分析时，只在模板基础上，进一步分析描述特殊需求。

形式化需求模板引用的方法和主要内容。引用形式化需求模板时，用户只需选择引用形式化需求模板，即可将平台内建的形式化需求描述全部继承，并在此基础上，进一步进行需求分析和描述，并形成Z语言描述的形式化需求文档。Z语言编辑器采用Z/EVES2.1工具，遵循该编辑的符号规范。

3.4.2快速开发平台设计

快速开发平台包括布局定义、流程定义和规则抽取三大模块。布局定义模块通过布局定义设计应用系统的用户界面，并与后端处理的业务逻辑组件接口关联，形成基本的操作应用。流程定义模块通过业务流程的图形化定义，将孤立、单一的业务处理活动按照业务需求构造成业务活动流程，基于工作流引擎驱动流程的运行。规则抽取模块以形式化需求描述为基础，通过规则抽取与转换等一系列操作步骤，将业务规则固化形成规则库，基于规则引擎驱动业务规则的注入与运行。对一些特殊的业务规则和业务逻辑，开发用户应继续扩展编写有关代码，实现业务功能。规则抽取与应用依赖于规则引擎系统，采用开源Drools规则引擎系统实现规则注入、解析与应用等，是快速开发平台实现的关键技术问题。

快速开发分为引擎驱动和生成源代码两种基本模式。引擎模式是指通过开发平台设计出应用模板并到平台引擎，运行时，平台引擎驱动应用模板设计的相关业务操作，完成业务处理过程。生成源代码模式主要通过一个开发平台的设计器定义业务模块，辅助生成源代码框架，用户基于源代码框架继续编写、修改源代码实现业务逻辑。

本平台快速开发模式综合了两种基本模式的优点，以引擎模式实现装备管理业务流程、通用业务逻辑和业务规则的快速开发，以生成组件代码模式提供进一步修改业务逻辑组件的扩展接口，实现特殊业务逻辑的快速开发，大大提高了开发效率。

快速开发流程如图3所示。

3.4.3运行支撑平台设计

运行支撑平台也称为运行时框架，是应用系统运行的支撑环境，包括应用系统支持环境和数据支撑环境，主要包括：用户接口（界面层）组件、工作流引擎组件、规则引擎组件、业务逻辑组件、业务规则组件、持久化组件等，共同协作为应用系统的运行提供基础支持。

应用系统运行支撑环境基于Tomact6.0构建。为提高Z-EMP平台应用系统环境的适应性，应用系统设计时，一是自动继承服务器基础应用环境，二是要提供环境自定义接口，自主选择运行环境配置参数。

用户类型不同，对数据库的使用需求也将不同。数据支撑环境应支持不同的数据库系统，如Oracle、MS SQL server、DB2、Postgresql和Mysql等。此外，还应具有在不同类型的数据库系统之间实现迁移的能力。Z-EMP平台提供的数据库支持环境能够隐藏不同类型数据库系统之间的差别，对于平台来说数据库系统是透明的。

3.4.4测试平台设计

一个完善的自动化测试系统一般会包括：生成测试用例、测试用例接口、驱动被测软件程序、主控程序、记录出错步骤、bug库等，其中，生成测试用例模块是自动化测试系统的主要难点[10]。测试用例对达成测试目的来说是至关重要的。好的测试用例可以提高测试的质量和工作效率。可以说，生成完备的、恰当的测试用例是整个测试平台设计的重要内容。

测试平台设计依据形式化需求规格说明生成测试用例遵循状态覆盖准则和状态变迁覆盖准则。状态覆盖准则依据形式化需求规格说明，设计足够多的测试用例使的状态构型中的所有状态在测试用例套中至少出现一次。状态变迁覆盖准则依据形式化需求规格说明，设计足够多的测试用例保证抽象状态构型中的状态转换全部覆盖，或者说最少确保有一个测试用例能够覆盖测试状态转换过程一次。

测试平台测试基于形式化需求Z语言规格说明自动生成测试用例，主要分三步：

（1）预处理用Z语言描述的形式化规格说明，识别出输入变量和输出变量的约束条件，以及变量之间的约束关系，并简化转换成线性谓词。

（2）以线性谓词为基础转换为线性不等式组，求解线性不等式组以得到对应取值范围的边界极点。

（3）找出取值范围的边界附近的点，进行输出变量到输入变量的逆变换以最终得到测试用例。

4 平台应用实现与验证

Z-EMP平台是采用形式化方法和快速开发平台两种技术路线综合解决软件开发问题的研究型平台，将形式化方法和软件工程化方法有机结合，将形式化方法拓展延伸到了设计开发阶段，这一基本思路实现了快速开发平台的敏捷性与形式化方法的准确性统一。基于Z-EMP平台的软件开发是一种全新的软件开发新思维，开发流程如图4所示。

AA-MIS系统是装备全寿命管理信息系统，从装备筹措、储存、保管、维修、训练、使用到报废全业务过程，使用对象为机关和部队相关工作人员。该系统设计装备型号多、涉及保障单位分布广，业务复杂、专业性强等诸多特点，而且当前武器装备建设出于转型发展阶段，新装备新型号陆续装备部队。装备管理需求处于不断变化发展之中，基于传统开发模式开发的信息系统已经不适应当前使用需求，必须形成软件持续优化和快速服务能力以保证软件服务质量，有效完成装备效能化管理使命。

基于Z-EMP平台开发的AA-MIS系统主要完成了业务流程的图形化快速定义，适应业务流程的变化发展；业务规则复杂的质量控制模块的形式化描述，开发了质量控制整套逻辑接口组件，具备了基于平台快速实现形式化需求的能力；基于形式化需求辅助生成了部分测试用例，实际应用到系统的测试过程，尤其在逻辑覆盖测试上发挥了一定作用。AA-MIS系统的开发应用较好了验证了Z-EMP平台研究方向的正确性和平台实现的可能性。

5 总结

本文首先分析了软件工程和形式化方法的优势和不足，介绍了业务基础软件平台的思想，首次提出将形式化方法和Z语言引入到快速开发平台综合解决软件需求与开发的问题，给出了Z-EMP平台体系结构和总体设计，最后结合AA-MIS系统开发，验证了Z-EMP平台的研究方向和设计思想，Z-EMP平台适合作为装备管理业务基础软件平台持续开展研究，以解决装备管理信息系统软件开发问题。

由于客观原因，基于Z语言的业务基础平台的研究仅仅是一个初步的探索与尝试，许多认识与思考还很粗浅。在形式规范重用和Z语言工具等方面，需要进一步加强研究。

参考文献：

[1] 李莹，吴江琴.软件工程形式化方法与语言[M].杭州：浙江大学出版社，2010，3-4.

[2] 吴军华.软件工程—理论、方法与实践[M].西安：西安电子科技大学出版社，2010，1-17，58-73.

[3] Karl E. Wiegers.陆丽娜，等，译.软件需求（Software Requirements）[M].北京：机械工业出版社，2000，42-65.

[4] 夏建勋，唐红武.需求分析的Z语言形式化方法[J].科学技术与工程，2008，8（8）：2245-2248.

[5] PATTON R.软件测试[M].北京：机械工业出版社，2002，1-96.

[6] Barroca L.M，Mcdermid J.A，Formal methods： Use and Relevance for The Development of Safety Critical Systems[J].The Computer Journal，1992，35：579-599.

[7] 蔡立志.基于形式化的软件测试复用若干关键技术的研究[D].上海大学，2009.

[8] 闫中玉.基于业务基础软件平台的企业建模方法的研究与应用[D].江苏大学，2007.

[9] 王宏生.Z形式规约的自动求精研究[M].北京：国防工业出版社，2009，15-16.

[10] 邹北骥，等.基于形式规约的软件测试用例自动生成技术研究[J].湖南大学学报（自然科学版），2004，31（3）：81-85.

作者简介：

孙桂领（1980-），男，工程师，硕士.主要研究领域：形式化建模

与应用、软件工程、装备管理、信息系统与信息管理等.

第6篇：软件测试转正总结范文

摘要:分析了当前国内外软件测试的发展现状,并由此引出了软件第三方测试;讲述了目前软件第三方测试在国内的应用现状及其在具体实施中存在的问题;基于软件第三方测试在国内具体实施中存在的问题总结了几点建议;最后对软件第三方测试的未来发展作出了展望。

关键词: 软件第三方测试;质量评测;开发成本;规范;验收

中图分类号:TP311文献标识码:A文章编号:1009-3044(2009)28-7982-03

Problem Analysis and Suggestions for Third-Party Software Testing

ZHOU Ping,WU Wei-wei

(Tongji university, Shanghai 201804, China)

Abstract: This paper analyzed the development situation of software testing in foreign and domestic,and then arrived at the third-party software testing. It next introduced the present application situation of third-party software testing in domestic. Then, it focused on the problems existing in the executing process of third-party software testing. Based on the problems those were discussed, it proposed some suggestions for the long-term development of third-party software testing and prospected the future of it.

Key words: third-party software testing; quality evaluation; development cost; specification; acceptance

随着社会对信息化依赖程度的不断加深,软件的种类和数量也越来越多,软件行业也因此由“卖方市场”转变为“买方市场”。在供过于求的情况下,软件用户必然会对软件质量提出更高的要求。国家应用软件产品质量监督检验中心总工程师鞠琳博士在《提升软件质量,推进行业信息化》主题演讲中提到美国国家标准和技术机构(NIST)近期的一项研究发现:软件的自身缺陷使美国经济每年要付出近600亿美元的代价,其中80%的资金被开发人员用于确定和纠正软件缺陷。据调查,国际上软件开发人员与测试人员的比例大都在1:1,软件测试收入占软件总产值的20%,而国内软件产业尚未形成这种状态。

1 国内外软件测试工程发展现状

软件测试是许多软件交付用户前的最后一个环节,是保证软件质量的主要手段[1]。国外的软件厂商极为重视软件测试工作,软件开发成本中的30%-50%用于软件测试。为打造Windows 2000,微软用了250多个项目经理、1700多个开发人员,而测试人员则用了3200人,测试人员几乎是开发人员的两倍[2]。每修改一个错误,都要花费大量时间和精力确保没有新错误产生。目前,国外软件测试工作已经演变为一门独立的学科,囊括了配置方案、测试机制、跨平台策略和产品性能、稳定性等独立的知识模块。

虽然国内许多大中型软件企业已经开始意识到软件质量的重要性,很多软件企业也已经配备了质量保证体系以及企业内部的测试队伍,但在软件项目面临时间压力、必须加快研制速度的情况下,通常测试会成为换取项目进度的牺牲品[3]。除此之外,由于许多企业软件工程过程管理不力,甚至缺乏管理,致使软件产品文档和资料不齐全,缺乏统一标准,消化理解困难,特别严重的是,有时小的需求错误,经过多次开发放大,到后来牵一发动全身以至于不可收拾。

令人欣喜的是,随着软件产业的发展,国内越来越多的第三方测试机构应运而生。第三方测试作为独立的测试服务机构,其相对于软件开发企业的内部测试及用户测试具有很多优势。首先,第三方测试以合同的形式制约了测试方,使得它与开发方之间存在某种“对立”的关系,所以它不会刻意维护开发方的利益,能够保证测试的客观性;其次,独立测试在长期的工作过程中势必能够积累大量的实践经验,形成自己的专业优势。并且软件工程测试也是技术含量很高的工作,需要有专业队伍加以研究,并进行工程实践。长期的实践积累加持续深入地学习,使得第三方测试具有难以比拟的优越性。再次,第三方测试机构的主要任务就是进行独立测试工作,这使得测试工作在经费、人力和计划方面更有保证。不会因为开发的压力而减少对测试的投人,降低测试的充分性,可以避免目前开发单位普遍存在的重开发、轻测试的现象。最后,开发人员由于对软件产品的设计、编码等过程都比较熟悉,容易养成思维定势[4],以至于在测试过程中思路比较有限,采用第三方测试能有效地避免这一问题。

伴随着软件生产规模的扩大和用户对软件质量要求的提高,第三方测试的优势也将日益明显,在今后的发展中软件第三方测试必然会得到更多软件用户和软件企业的认可。

2 软件第三方测试的应用现状

从国外的经验来看,软件测试工作已逐渐由专业的第三方来承担。第三方测试工程主要包括需求分析审查、设计审查、代码审查、单元测试、功能测试、性能测试、可恢复性测试、资源消耗测试、并发测试、健壮性测试、安全测试、安装配置测试、可移植性测试、文档测试以及最终的验收测试等十余项。测试并不仅仅是为了要找出错误,测试方还需要对错误进行归类和总结[5]。通过分析错误产生的原因和错误的分布特征,可以帮助项目管理者发现当前所采用的软件过程的缺陷,以便改进,从而更好地帮助用户。

软件第三方测试是软件开发方和用户出于不同目的共同选择。随着软件全球化竞争的日益加剧,用户对软件质量的要求也随之提高。为了提高软件质量,降低软件开发成本,许多软件开发方已经逐步将部分测试业务交给第三方负责。与此同时,对于应用软件、甚至系统软件,大多数用户都不是很熟悉其特性,质量评测基本难以进行,迫切需要专业的机构对开发方提供的软件给予客观的测试。正是由于采用第三方测试可以保证测试的独立性、客观性及第三方具有的测试的专业性使得第三方测试越来越成为用户的首选。

目前在国内,虽然软件第三方测试的发展还处于起步阶段,但已经有许多软件企业开始认识到软件质量的重要性,选择第三方测试的软件企业和用户都越来越多。在一些重要计算机软件应用领域,如金融、安全、航空、航天以及军事等方面,已经有不少用户开始颁布测试规定,要求第三方测试,并在逐步将软件测试通过合同关系委托第三方承担[6]。在通信领域,手机等产品的软件需要第三方测试后才可交付使用。在已经进行的一些工程项目当中,软件测试都取得了确保软件产品质量的预期效果,逐步被软件用户和软件企业所认可。

3 软件第三方测试在实施中遇到的问题

目前,软件第三方测试在国内已经兴起,随着社会信息化程度的提高、软件大生产的发展,软件第三方测试必将在国内盛行。但由于软件第三方测试在国内还处于起步阶段,在具体的实施中不可避免地遇到了如下一些困难和问题。

1)软件企业对测试仍不够重视,重开发、轻测试的现象在国内许多软件企业中仍普遍存在。由于对软件测试的不重视,常常导致软件产品的售后服务费用大大增加,从而使得软件产品的成本大幅度提高。成本的增加又导致软件公司考虑到资金问题不愿意增加投入为软件做第三方测试,即使做,给第三方软件测试公司的报价也是极低的。软件企业陷入了这样的死循环,作为软件测试的第三方,面临的问题是回报低但工作量又十分庞大,使得软件测试公司没有盈利的空间,这就成为制约第三方测试公司发展的一个瓶颈。

2)用户和测试机构都还不够成熟,对第三方的认识还比较粗浅,工程实施过程比较随意,项目水平不尽如人意。

3)用户、开发方和第三方的责任与权利常常划分不明确。在实际的第三方测试实施过程中,有些用户甚至软件开发商,容易将软件质量的高低完全寄托于第三方评测服务商,一旦软件达不到系统设计的质量效果,就归罪于第三方。这种认识很打击测试人员的积极性,软件中的错误可能发生在软件项目的各个环节,软件测试只能确认软件存在错误,不能保证软件没有错误,软件测试不可能发现全部的错误。

4)三方关系的协调问题。软件第三方测试的形式一般是第三方评测服务商与软件用户之间签订合同,但实际工作中往往需要软件开发方的密切配合,因此能否处理好用户、开发商与第三方之间的关系,在很大程度上影响第三方测试的效率和质量。

5)许多国家机构也发现软件第三方测试市场,他们对企业软件进行测试,发放国家认可的证书。这就给民间的第三方软件测试公司的成立带来了很大的压力,这些企业的创办者经过测试很难给企业发放这些证书。所以许多软件企业纷纷停止这项业务,而转入更容易赚钱的其他项目,比如软件测试培训。而需要第三方软件测试的企业也找国家直属的企业进行产品认证。

6)软件大企业测试的竞争。许多产品往往都需要进行第三方测试,比如软件本地化测试。微软的产品,生产一个就要产生世界各地的本地化版本,如果这些工作都让微软来做,得不偿失。而国内许多大企业,他们一直与这些大的国际企业有着长年的友好关系。他们往往可以接下这种测试任务,在社会上招聘测试工程师,宣称赴某大公司工作,然而项目一旦完毕,就将这些人员解散。

总之,由于没有建立起一套正规的游戏规则,给软件第三方软件测试的发展带来了许多不利因素。虽然业界已经认识到了第三方测试的重要性,但是在目前条件下第三方测试发展的道路仍旧十分艰难。

4 软件第三方测试发展的一些建议

软件第三方测试是测试工程未来的发展趋势,但由于第三方测试在国内尚处于起步阶段,其在具体的实施过程中不可避免地遇到了种种困难和问题。针对目前第三方测试在实际项目实施中遇到的问题,笔者给出以下几点建议。

1)切实提高软件企业及软件用户的产品质量意识。不论是对于软件企业还是软件用户,质量管理的薄弱都会为其带来不可估量的损失。对软件企业而言,如果因软件质量的不过关,导致用户蒙受损失,其必将失去客户的信任,从而影响自身的发展。对软件用户而言,严格的软件质量控制关系到自身的切身利益。软件质量缺陷问题为软件使用方带来诸多不便、甚至让软件用户蒙受巨额损失的例子比比皆是[7]。因此,作为专业测试的第三方,必须加大软件质量意识方面的宣传,只有软件企业和软件用户的质量意识提高了,软件第三方测试才会有更大的发展空间。

2)规范软件第三方测试市场。面对日益增大的市场需求,不少软件第三方测评中心纷纷建立,甚至有些企业购买一两套自动化测试工具就成立了软件测试中心。其结果可想而知,测试过的软件质量不过关,用户不满意,导致用户失去了对第三方测试的信任,制约了第三方测试的发展。笔者建议不要盲目建立测试机构,搞重复建设。要规范软件测试市场,对测试结构进行整合,建立较大规模的权威测评机构,做到测试不是走过场,真正达到提高软件质量的目的。

3)制定合理的项目验收标准。项目验收的技术标准是第三方合同中必须重点解决的关键问题。合理、明确、符合软件测试技术特点的验收标准,能够明确测试方的责任,无论是对测试方还是用户都有好处。验收标准应面向测试的整个过程并具有可操作性,这样便于测试完成后用户的验收[8]。对大型系统的第三方测试建议重点面向有效性指标制定验收标准。

4)加大软件测试人才建设。在国外,有三年以上开发经验的人员才可以转做软件测试工作。而国内恰恰相反,往往是刚刚参加工作的新人被安排在测试的岗位上,导致测试人员的业务素质普遍较低。2004年原国家信息产业部联合五部委颁布124号文件,强调要“加快培养软件测试人才,开展软件评测技术的研究”为软件测试人才的培养提供了政策支持。虽然近年来,国内众多的高校、职业培训机构都在加强专门的软件测试人才的培养并且取得了一些成绩,但软件测试人才缺乏问题仍未解决。只有加大软件测试人才建设,实现我国软件测试人才供需平衡的良性发展结构,才能有力促进我国软件产业蓬勃发展。

5)用户参与。用户方的充分参与既可以让测试中的许多具体问题得到迅速的解决,又可以对测试起到监督的作用,保证测试全面细致地进行。此外,测试方采用的测试思路及其制定的验收标准等都需要得到用户的认可,所以测试过程中应尽量调动用户积极参与,这样既能让用户更好地理解和接受测试方的测试思路及验收标准等,又能让用户起到协调第三方与开发方关系的作用,从而提高测试的效率。

5 总结

虽然目前第三方测试还刚刚兴起,但第三方测试服务相对于软件企业内部测试及用户测试,拥有不可比拟的优势。随着软件企业和软件用户的质量意识不断提高,以及用户对软件测试服务的需求增大,软件第三方测试服务必将在国内得到蓬勃发展。

参考文献:

[1] 王峰,郑彦兴,包阳.软件第三方测评[J].计算机研究与发展,2008(45):345-350.

[2] 陈宏刚,熊明华,林斌等.软件开发过程与案例[M].北京:清华大学出版社,2003.

[3] 苏正泉.软件测试的10个认识误区[J].电脑知识与技术,2006,(14):149.

[4] 郭树端.软件第三方测试的意义及可行性分析[J].电子产品可靠性与环境试验,2003,(02):47-49.

[5] 王萍.软件测试的重要性[J].软件导刊,2009,(04):20-21.

[6] 巨振乐,赵明辉.正在兴起的软件测试外包[J].时代经贸,2009,(Z1):54-58.

第7篇：软件测试转正总结范文

关键词：多平台　计算机软件　测试方法

科技不断变更，软件行业凸显了日渐剧烈的竞争态势。提升编写质量，不可缺失后续的测试。唯有经过测试，才可缩减潜在的若干偏差，规避编写流程内的误差。软件越是复杂，漏洞及弊病将会越多，不可予以忽视。添加测试流程，虽然没能根除一切的偏差，却能修复漏洞，增添更为完善的体验。搭设了多平台，考量了真实情形下的软件特性，确保最佳质量。

一、解析测试内涵

微机不断被更新，软件测试特有的科目也被创设出来，日益受到注重。编写软件之初，受到本体这样的性能约束，软件占到了偏窄的总空间，构架也很简易。这种情形下，并没能增设软件测试。在这一时段内，编写依循的语言较为简易，层级也不够高，常选汇编类的偏低语言。采纳这类语言，没能搭配最适宜的测试类平台。技术进展的态势下，软件留存下来的数值总量递增，执行流程也渐趋复杂。日常编写提升了固有的要求，软件更为复杂。现有软件常常占到了多GB，复杂架构内的疑难也变得更多。例如：微软构建起来的操作体系融汇了最为优良的编写类人才，能够汇编软件。然而，这种编写获取的软件仍旧暗藏漏洞，存在多样弊病。常常更新补丁，填补体系之内的这些漏洞。设定更新公告，也会添加明晰的说明，修补前个版本之中的弊病。历经长时段的进展，技术日渐被完善。计算机体系内，软件被看成必备的，运转流程不可缺失搭配的软件。互联网在进展，软件被融汇于平日的生活。常规运用之中，软件若存有偏差漏洞将会干扰运用，带来不良反应。规避这种弊病，编写终结后应能再次予以测查，衡量软件的多重特性。依照自身特性，拟定的测试流程要融汇多样性能。面对着多平台，选取多类测试。

二、软件测试必备的价值

软件运转流程含有偏差，常会自发关闭，或没能及时去响应。起初发现偏差，用户还能忍受这一软件；但偏差变多时，用户将会替换现有的软件，筛选其他软件。即便编写可得的软件拥有了针对性，也会出于这样的漏洞而被替换，干扰日常运行。软件受到更换，缩减了可获取的编写收益，也影响了印象。采纳软件测试，是为修补潜在漏洞。从用户视角看，漏洞影响着应有的体验，干扰常规运用。软件测试显出了多样化，含有测试实例。解析现存环境，考虑了细分出来的软件特性来拟定参数，完善多样性能。测试构建起来的环境有着逼真的特性，运转环境趋向于真实。真实环境之下，才可确认测得的数值是精准的。针对公司及用户，软件测试都凸显了自身价值。着手去编写时，要考量总体架构下的软件特性。经由测试流程不可除去一切的弊病，但至少查验得出了运转路径下的疑难，创造更优的体验。

三、测试依托的多样平台

1.搭设必备的测试平台。

研发软件平台是为提升成效，测试可得更精准的数值。初始测试时，经由编写得出的新软件会筛选某些参数。参数被输入后，查验后续的运行态势。借助这种流程，查出了运转之中的软件差错。然而，这种测试可得的精准性仍没能提升，仅仅可查出根本性能的弊病，却没能依循逻辑的路径来发觉差错。测试流程偏复杂，不易予以掌控。新测试步骤内，细分了软件特有的多样内涵，分别予以测定。这样的状态下，为了增添总的成效、缩减编写耗费的总时间，软件测试依托的一切流程将被汇聚于某一平台，增添了集成性。构建测试平台，这种平台融汇着自身架构、拟定的标准、规程以及筛选的工具。设定语法规则、模块特有的自身性能。针对筛选的某一任务，设定了执行时段内的测试。常选分步测定，内在的多重模块增添了彼此的关联。模块可调配彼此，实现互相依赖。可用各类工具，调用必备的新软件。

2.平台自身特性。

提升测试实效，要搭配更为适宜的测试环境。软件密切关联着布设的这种环境，在不同体系内，软件凸显了彼此特性的差别。例如：应用类的软件不可脱离网络，依赖现有网络。为此测试时，要创设可用的网络状态。测试平台要添加本体的隔离特性，可以隔离干扰。集成化状态下，软件配有多样的本体特性。针对细分出来的特性着手来测定，规避模块干扰。测试流程应被融汇于构建起来的同一平台，测定全面性能。旧式测试之中常会拟定逻辑，分别测得本体的逻辑及性能。缺失联合测定，流程不够完善。新式的平台内，一次即可测得关联的所有内涵，全面辨别特性。测得精准数值，便于查出潜藏的漏洞，记录而后修补。

3.现有的常见平台。

市面售卖的测试类平台可被分成多类，考虑真实需要，选取最优的某一平台。例如：“测试中心”特有的新平台凸显了通用的优势，面对多样软件，可被随时安设而后运行。依托这种平台，缩减了拟定的研发时段，增添测试实效。然而，它适宜一切的软件，没能明晰自身特性。可分多重模块，它们配有本体的独特性能。ALM这样的平台也有着集成内涵，区分编写语言，构建起来的研发体系增添了针对性。测试获取的成效更为优良，正被广泛采纳。

四、多平台架构下的测试

1.多平台的价值。

现有平台多被看成通用的，并非针对性的。对比常用平台，通用平台没能凸显细化的测试成效，但涵盖着更广的范畴。设计这类平台，开发流程都有着彼此差异。面对同类软件，安设不同平台即可凸显测得的不同数值。这就可以得出：借助某一平台，可获取的偏差仍是有限的，很难涵盖着一切的漏洞。然而，若能整合多重的平台，就添加了全面性，查出独特漏洞。协同多类平台，测得的偏差将会是最多的。为此，多平台日渐被推广。软件研发时，软件都会存有弊病，不可予以避免。唯有强化测试，整合多类平台，才能真正去降低差错。对比单一平台，多平有的优势不可忽略。

2.新式流程及步骤。

安设多个平台，协同测定新编写的软件差错，尤为侧重彼此的整合。如果缺失协同，将会缺失根本的效能。开发主体有着差异，交互界面不同，平日调用软件的习性都会不同。平台在配合时，常会显出矛盾。着手测试以前，就要识别软件这样的特性。依照自身特性，筛选最佳的协同途径。多重平台密切协同，全面测得漏洞，也更能便利接续的修复，提升测试的总体实效。适当选取平台，增添了测得信息的精准，价值不可忽略。采纳专门平台，测得了软件搭配的专门性能，更拥有针对性，测试步骤更为细致。选取核心模块，便于测出关联的一切性能。初始选取时，应能侧重拥有针对性的这类平台，规避通用平台。这是由于，若全部拟定了通用情形的平台，软件特性将被忽略。调用某一平台，寻找最大范畴的漏洞，而后接着予以测试，直至不再查出这样的漏洞。重复如上流程，直至多平台都不再测出偏差，才可终结测试。

五、结语

借助软件测试来缩减弊病及偏差，确保软件合格。研发初始时段，软件有着较为简易的自身构架，测试依循的流程也不够完备。技术更新之中，测试依托的多样工具被融汇于一体，搭设集成平台。协同多个平台，提升了综合范畴的测试水准，随时即可调配某一平台以便供应测试，提升了精准性。

参考文献：

[1]付宇.基于多平台的计算机软件测试方法分析[J].电脑知识与技术,2014（09）:1981-1982.

[2]易敏捷.基于多平台的计算机软件测试方法分析[J].科技传播,2013（20）:202-203.

[3]兰娅勋.基于多平台的计算机软件测试方法[J].科技创新导报,2015（19）:59.

第8篇：软件测试转正总结范文

【关键词】 天线测试系统 矢量网络分析仪 虚拟仪器技术

由于无线电仪器设备的广泛使用，形式各样的天线渐渐推广到各领域。在实际运用中，天线是否满足性能要求取决于其增益、方向性、波瓣宽度等参数，因此天线的真实性能多数通过外场测试环境来测试。测试过程中普遍会遇到难以把握转台和吊杆装置的转动角度、无法准确计算天线参数性能等问题，由此我们研究了一套远场天线自动测试系统。

一、天线测试系统的构成

这套系统改进了原有的传统测试方法，建立了一套具有智能控制、快速采集、高速处理数据与报告和打印相结合的自动测试系统。而且该系统改善了传统的基础算法，能测算出远场测试与环境之间存在的误差，增强了天线测试数据的可靠性。

远场天线自动测试系统硬件这部分主要包括：AV36580A矢量网络分析仪、天线测试转台和吊杆、监视器、转台/吊杆驱动控制器和打印机。该套系统的工作方式如下：首先同时利用转台/吊杆驱动控制器控制转台/吊杆运动测量角度参数；然后使用矢量网络分析仪发射标准天线和接收待测天线；最后处理工控机采集的幅度和角度参数的数据。由此可以绘制出方向图并准确计算出天线参数性能，远场天线自动测试系统总体结构如图1所示。

二、天线测试系统的运作流程

远场天线自动测试系统运作功能主要是由工控机上的测试软件完成，运作详细流程如下：

1、确保远场天线自动测试系统机柜中的信号线路、射频电缆正常连接，并保证机柜接地。

2、打开工控机上的远场天线自动测试系统，通过指示灯检查各项设备，保证操作系统发挥正常。

3、设置天线自动测试系统发射功率、扫频范围、转台/吊杆终止角度、频率点数、误差补偿参数、转台运行速率、储存文件与路径等参数，然后运行测试系统。

4、运行天线自动测试，得到天线方向的实时数据和测试的频率信息，并呈现出频点之间的不同转换。

5、自动测试系统完成之后，得到了天线性能参数的测试效果，然后保存测试数据，打印出天线测试报告。

6、把测试系统复原，留待下一次天线自动测试。

三、测量算法处理

由于地面反射波的作用，传统远场天线有着难以精确测量的缺点。测试场环境中受到电磁干扰的影响，为了提高天线性能的测试准确度，可以分析误差来源并修改。进行天线测试过程中，受方向图和天线增益的深刻影响。

3.1修正天线方向图的误差

天线方向图的误差主要有两种：一是由于天线相位中心与转台转轴不重合而导致的角度误差；二是安装天线时，由天线发射功率测量不精确而导致的角度误差。前者的误差是因为天线摆放位置差异引起了标准值的偏离，计算公式为：

θ1= d/R （ sinα2-sinα1 ）≈（2d/R）cos（θ/2+α1） sinθ/2

公式中：d为天线相位中心偏离其旋转轴的距离；R为远场距离。后者的误差是测量功率方向时，因为内外部因素的影响，矢量分析仪会出现一些误差。

3.2修正天线增益误差

在测试远场天线时，因为工作频率各异，测量增益的方法也会有所不同。增益测量通常是采用馈线与收发天线的功率传输公式进行计算，但会出现阻抗失配误差。根据大量的推算表明，发现测量天线增益与矢量网络分析仪信号接收机、信号源负载失配之间存在着必不可分的关联。所以，首先要算出总失配因子要运用发射天线和电压驻波，才能计算出天线增益。

四、验证

建立系统以后，就进入了系统调试验证阶段。远场天线测试系统软件把虚拟仪器、MATLAB和数据库等技术完美融合在一起，从而实现了该软件能够智能测验、处理复杂算法和输出报告。除此以外，该软件功能还包括读取原始记录、叠加显示多频点方向图和实时显示方向图等，有力的提高了天线测试技术。系统实体柜结构和操作界面如图2（1）、D2（2）所示。

五、结束语

本文探讨传统远场天线测试之中已有的难题，通过使用虚拟仪器技术以优化测试方案。此外，还运用Matlab、数据库等软件和改进计算参数的方法，从而得到一种科学有效的自动天线测试系统。

参 考 文 献

[1] 耿国磊，别红霞.基于LabVIEW的高阻自动测量系统[J].电子测量与仪器学报，2009，23（3）：70-75.

第9篇：软件测试转正总结范文

[关键词]Rational 软件测试 软件设计

Rational 软件开发平台集成了软件工程的最佳经验、工具和服务。利用 Rational 软件开发平台,各组织机构可以获得更快的反应能力和更强的适应性,并可以集中精力关注核心任务,在随需应变的时代取得更大的发展。Rational 基于标准的跨平台解决方案有助于软件开发团队创建和扩展业务应用程序、嵌入式系统及软件产品。

一、Rational软件现状

软件生态系统是随需应变时代的动力,而软件开发能力对于构建并改善软件生态系统至关重要。软件生态系统指的是:能够创造战略优势、迅速适应不断变化的业务需求并具备高度可靠性与伸缩性的应用程序。通过提高他们的软件开发能力,IBM 的 Rational 软件可以帮助各组织机构创造商业价值。

一个软件开发过程从需求分析到设计建模,到架构,到质量管理、配置管理,到测试,一直到最后交付,中间涉及到了众多环节,光Rational产品家族就有20多个工具分别用来解决软件开发过程中不同阶段、不同种类的问题。而这个过程还涉及到各种各样的相关人员,开发者、项目经理、架构师、产品经理、测试人员、客户等等,他们都要参与进来,互相交互,共同合作。Rational中国区产品经理宁德军认为是流程的统一和后台存储库的统一。以前开发过程各模块都有自己单独的数据库,例如有需求库、编程管理库、配置变更库等,这些数据库还没有实现统一,不能方便的交换、调取数据。虽然之前的Rational产品线在一定程度上进行了统一,但是整体的统一还是没有做到。对于Rational原有产品线的客户,IBM软件集团Rational总经理Daniel Sabbah表示,IBM 会继续支持原有的产品线,保证新老产品共同发展,新的客户会在新的Jazz平台上,老的客户会根据他们的需求逐步过渡的新的平台上,或者继续在原有平台上,保证原Rational产品的客户投资得到保障。

二、Rational统一过程

Rational统一过程(RUP),是一种迭代的、以架构为中心、用例驱动的软件开发方法,也是一种明确定义和结构良好的软件过程,使用UML(unified Modeling Language,统一建模语言)作为过程建模标准。其总体构架包括两个结构,其中动态结构代表过程的时间坐标,它从生命周期、阶段、迭代和里程碑的角度阐述了开发过程,揭示一个项目的生命周期,包括初始、细化、构建、移交四个部分;静态结构描述过程元素(活动、规程、制品和角色)在逻辑上如何组织在一起构成核心的过程规程,涉及业务建、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理以及环境等九个核心工作流程。动态结构的每一个部分都可根据实际情况决定是否包括这些核心工作流程。

三、Rational软件测试

随着传统测试策略愈发难以适应当前复杂的软件开发需要,甚至还存在导致各种问题及错误的风险,自动化测试愈来愈受到软件开发及测试人员的重视。自动化测试的一般定义为:各种测试活动的管理与实施。包括测试脚本的开发与执行,以便使用某种自动化测试工具来验证测试需求自动化软件测试技术可以克服传统测试技术的许多问题。其依据的是一套严密的测试法则和评估标准,具有完整的自动测试过程。它可以避免测试人员惯性思维所导致的测试疏漏,减少由于手工测试中繁复的重复工作所导致的人为差错。自动测试易于实现错误信息的追踪和场景的再现,且测试活动的自动化在许多情况下可以获得最大的实用价值,尤其在自动化测试的测试用例开发和组装阶段,测试脚本很可能被重复调用。因此,采用自动化测试可以获得很高的经济回报。但是,软件测试自动化并非适用于所有软件项目开发。首先,采取自动化测试策略的软件需求变动不可过于频繁。有时针对项目各模块的稳定性差异,自动化测试和手工测试往往被配合使用。其次,项目周期一个决定性因素,自动化测试不适用于短期项目。第三点便是自动化测试脚本是否可以重复使用,从而提高软件的商业价值在以上前提成立的基础之上,自动化测试就显示出其针对传统手工测试的优势所在。值得注意的是,自动化测试与传统测试之问并非对立关系,自动化测试是技术人员在传统测试的技术基础上不断探索和逐步改进而来的。两者相辅相成。在软件测试中,根据软件实际情况选择正确的测试策略也是一个相当重要的议题。

四、Rational系统设计

为了实现以上系统功能,利用Rational Rose对系统进行概要设计,方便地确定系统的类及类之间的关系在概要设计阶段,确定了完成系统功能所需的类及类之问的关系,至于每个类的属性和方法的具体设计等就要在详细设计阶段进行。

由于面向对象的分析与设计方法不仅与人类认识世界的客观事物相符,而且其逻辑业务的分析与设计与数据库的分析与设计相一致。Rational Rose中设计好了类的属性后,即可通过Rational Rose将类转换成数据模型,并进一步自动生成数据库及表结构或数据库及表结构的生成代码。由业务逻辑模型转换为数据模型后,可通过Rational Rose将数据模型转换成数据库及表结构的或生成数据库及表结构的脚本(SQL语句),然后运行生成的脚本即可生成数据库及表结构。有了以上的类、类的属性、类的方法及数据库以后,即可以对实现系统各种功能的类的方法的实现进行设计。

通过Rational Rose对管理系统进行分析与设计,使分析设计员与客户的交流更加直观、可视和易懂;使分析人员更加集中精力进行系统的分析与设计,而不至于过分关注如何表达某些概念。总之,Rational Rose是一种方便、快捷和可视的软件开发工具。

参考文献: