集成测试十篇

集成测试篇1

关键词：软件测试；集成测试；调用图；MM-路径

中图分类号：TP317文献标识码：A文章编号：1007-9599 (2012) 03-0000-02

Analysis of Integration Testing of Software Testing

Hou Yanfang,Chu Shulai

(Zhoukou Vocational and Technical College,Zhoukou466001,China)

Abstract:The integration testing plays a very important role in software testing,the concept of integration testing,integration testing strategy and the main types of integration testing (phase) briefly discusses the analysis of several key integration testing.

Keywords:Software testing;Integration testing;Call graph;MM-path

软件测试作为软件质量保证的关键技术之一，其目的就是能够有效地发现软件中的错误或缺陷。集成测试是软件测试中处于组件测试和系统测试之间一个非常重要的环节，这是因为所有组件都经过测试并能正常运行并不意味着这些组件放到一起经过集成后还能正常运行，正是基于这一点，很多大的软件公司成立了专门关注集成测试的测试团队，如能恰当实施，集成测试能大大减少一些在系统测试阶段才会发现的缺陷。

一、集成测试的概念

（一）集成测试的定义

集成测试是构造软件体系结构的系统化技术，同时也是进行一些旨在发现与接口相关的错误的测试。其目标是利用已通过单元测试的构件建立设计中描述的程序结构。

（二）集成测试遵循的原则

集成测试遵循的原则主要包括：所有公共接口都要被测试到；关键模块必须进行充分的测试；集成测试应当按一定的层次进行；集成测试的策略选择应当综合考虑质量、成本和进度之间的关系；集成测试应当尽早开始，并已总体设计为基础；在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通；当接口发生修改时，涉及的相关接口必须进行再测试；测试执行结果应当如实的记录；集成测试应根据集成测试计划和方案进行，不能随意测试；项目管理者应保证审核测试用例。

（三）集成测试的任务

集成测试的主要任务包括：将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失；将各个子功能组合起来，检查能否达到预期要求的各项功能；一个模块的功能是否会对另一个模块的功能产生不利的影响；全局数据结构是否有问题，会不会被异常修改；单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。

（四）集成测试的文档

软件集成的总体计划和特定的测试描述应该在测试规约中文档化。这个文档包含测试计划和测试规程，它是软件过程的工作产品，也是软件配置的一部分。

下列准则和相应的测试可应用于所有的测试阶段：接口一致性。当每个模块（或簇）引入程序结构中时，要对其内部和外部接口进行测试；功能有效性。执行的测试旨在发现功能错误；信息内容。执行的测试旨在发现与局部或全局数据结构相关的错误；性能。执行的测试旨在验证软件设计期间建立的性能边界。

测试计划主要包括：集成测试的进度，确定每个阶段的开始和结束时间；附加软件（桩模块及驱动模块）的简要描述侧重于专门进行的工作的特征；描述测试环境和资源；特殊的硬件配置、特殊的仿真器和专门的测试工具或技术也是需要讨论的问题；详细测试规程。

测试规约：集成策略（包含在测试计划中）和测试细节（在测试规程中描述）是最基本的成分，因此必须要有。

二、集成测试的策略

驱动模块（Driver）：用来模拟待测模块的上级模块。驱动模块在集成测试中接受测试数据，将相关的数据传送给待测模块，启动待测模块，并打印出相应的结果。桩模块（Stub）：也称为存根程序，用以模拟待测模块工作过程中所调用的模块。桩模块由待测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验待测模块与下级模块的接口。

一般可分为非增量集成和增量式集成，其中增量集成指的是程序以小增量的方式逐步进行构造和测试，这样错误易于分离和纠正，更易于对接口进行彻底测试，而且可以运用系统化的测试方法，传统的将增量测试策略分为自顶向下集成、自底向上集成以及三明治集成。

三、集成测试的主要类型（阶段）

（一）基于功能分解的集成

在讨论集成测试时，测试方法都基于采用树或文字形式来表示的功能分解。这类讨论不可避免地要深入到将要集成的模块的顺序。

1.自顶向下集成（从树顶开始向下）。深度优先集成是首先集成结构中主控路径下的所有模块。

2.自底向上集成（从树底开始向上）。自底向上集成是自顶向下顺序的“镜像”，不同的是，桩由模拟功能分解树上一层单元的驱动模块替代。在自底向上集成中，首先从分解树的叶子开始，并用特别编写的驱动模块进行测试。驱动模块中的一次性代码比桩中的少。大多数系统在接近叶子节点时都有相当高的扇出数，因此在自底向上集成顺序中，不需要同样数量的驱动模块，不过代价是驱动模块都比较复杂。

3.三明治集成（前两种方法的某种组合）。三明治集成测试是将自顶向下测试与自底向上测试两种模式有机结合起来，采用并行的自顶向下、自底向上集成方式，形成的方法。三明治集成测试更重要的是采取持续集成的策略。桩和驱动的开发工作都比较小，不过代价是作为大爆炸集成的后果，在一定程度上增加了定位缺陷的难度。

（二）基于功能分解方法的优缺点

1.自顶向下集成，其优点：在于它可以自然地做到逐步求精，一开始就能让测试者看到系统的框架。缺点：需要提供桩模块，桩模块是对被调用子模块的模拟，可能不能反映真实情况，因此测试有可能不充分。

由于被调用模拟子模块不能模拟数据，如果模块间的数据流不能构成有向无环图，一些模块的测试数据便难以生成。同时，观察和解释测试输出往往也是困难的。

2.自底向上集成，其优点：由于驱动模块模拟了所有调用参数，即便数据流并未构成有向无环图，生成测试数据也没有困难。如果关键的模块是在结构图的底部，那么自底向上测试是有优越性的。缺点：直到最后一个模块被加入进去之后才能看到整个程序(系统)的框架。

3.三明治集成测试采用自顶向下、自底向上集成相结合的方式，并采取持续集成的策略，有助于尽早发现缺陷，也有利于提高工作效率。

4.功能分解缺点。为了满足项目管理的需要，而不是为了满足软件开发人员的需要。桩或驱动的开发工作量，此外还有重新测试所需工作量的问题。对于自顶向下集成，需要开发（节点-1个）桩模块；对于自底向上集成，需要开发（节点-叶子）个驱动模块。

（三）基于调用图的集成

基于调用图的集成一般分为成对集成和相邻集成。基于调用图方法的优点：偏离了纯结构基础，转向行为基础，因此底层假设是一种改进；这些技术还免除了桩／驱动器开发工作量；与以构建和合成为特征的开发匹配得很好。缺点：缺陷隔离问题，尤其是对有大量邻居的情况；清除缺陷后，意味着以前测试过的包含已变更代码的邻居，都需要重新进行测试。

（四）基于路径的集成

将集成测试的侧重点由测试单独开发并通过测试的单元之间的接口，转移到这些单元的交互上，即它们的“协同功能”上。接口是结构性的，而交互是功能性的。

MM-路径是功能性测试和结构性测试的一种混合，其优点：它与实际系统行为结合紧密，而不依赖于基于分解和调用图集成的结构性推动。基于路径集成测试也适用于面向对象的软件测试。缺点：需要更多的工作量标识MM-路径。这种工作量可能会与桩和驱动的开发所需工作量有偏差。

（五）面向对象环境中的集成测试

两种不同的策略：

1.基于线程的测试(thread-based testing）。

2.基于使用的测试（use-based testing）。

驱动程序和桩程序：驱动程序可用于测试低层中的操作和整组类的测试。驱动程序也可用于代替用户界面以便在界面实现之前就可以进行系统功能的测试。桩程序可用于在需要类间的协作但其中的一个或多个协作类仍未完全实现的情况下。

四、结语

集成测试既是一种测试类型也是一个测试阶段，因为集成定义为一组交互，因此组件之间的所有已定义的交互都需要测试，体系结构和设计可以提供系统内部的交互细节，但是测试一个系统与另一个系统之间的交互要求对这些系统一起工作的方式有深刻理解，此时的集成测试是一个阶段。由于集成测试的目标是模块之间的交互，这种测试就像白盒、黑盒及其它类型的测试一样，也有一套技术和方法，因此集成测试也被看作是一种测试类型。

参考文献：

[1]周燕,宋敬华.面向对象的集成测试顺序的研究[J].计算机测量与控制,2010,9

[2]张云岗,刘春茂.软件测试技术浅析[J].技术与市场,2011,2

[3]朱家云.浅析软件测试[J].信息系统工程,2011,4

[4王丽达.论软件系统的测试[J].经济研究导刊,2011,14

[5]刘欣.软件测试方法分析与实践[D].北京邮电大学,2009

[6]赵,孙宁.软件测试技术：基于案例的测试[M].北京:机械工业出版社,2011

集成测试篇2

关键词:集成测试;测试覆盖率;功能簇

中图分类号:TN407 文献标识码:A 文章编号:1007-9599 (2012) 13-0000-02

一、集成测试的一般定位及范围

随着软件行业的发展,软件系统涵盖了日常生活、生产的各个方面,复杂的软件系统的测试保证越来越成为实现软件需求目标的重要方面。

软件测试根据测试介入时机和测试对象的范围,一般可分为:单元测试、集成测试、系统测试。其中,集成测试是在单元测试的基础上,将所有模块按照设计要求组装成为子系统,进行集成测试。实践表明,一些模块虽然能够单独的工作,但并不能保证连接起来也能正常的工作。 程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。图1为不同开发阶段驱动的测试类型图。

不同类型的测试的实质是选取不同的测试范围和对象,对对象的属性 (功能分支及其他属性)进行验证的过程。好的测试是针对测试目标选取一个较优的测试对象及范围的组合,以获得较高的测试投入与产出比例,通过对测试目标实现尽量完整的测试覆盖度, 达成测试目标。软件测试没有绝对的覆盖,也不存在无尽的测试资源。

传统的集成测试,属于白盒测试的一种。其主要的问题包括如下方面:

1.较大的测试开销:由于集成测试采用将一个实体分解为多个实体的方式进行,测试接口的数量成级数增加,开销较大,通常的集成测试都是选择性的针对核心功能模块进行。

2.测试输入及构建要求较高: 软件测试总是基于一定的测试输入基础,这里的输入,主要依赖于开发过程。由于软件工程化开发的不同水平,集成测试往往难以获得完整的设计输入,同时由于软件设计成熟度的限制,导致模块级设计的变更频繁,这些都加剧了测试需求输入的恶劣和不可控。同时由于集成测试需要构建模块级的数据环境,属于白盒测试,测试技能要求,测试时间消耗都较大,也是其难以实现高效应用的原因之一。

二、系统级集成测试

(一)系统级集成测试的特点

为了获得更好的测试效益,我们提出一种基于系统级设计构建集成测试的思路。传统集成测试主要以软件模块为测试实体对象,将产品系统打开,基于内部接口和模块级运行环境进行测试设计。系统级集成测试从本质上与传统集成测试基本一致,但是其分析方法,更多强调与系统运行的场景、业务行为、事件对软件运行的影响以及场景异常的构建。

(二)系统级集成测试的对象

系统级集成测试捕获的问题对象本质是数据接口关系,主要分为3种类型,如下图所示:

1.外部输入关联

如图2,次功能模块b的输出是主功能模块a的输入。 整个系统功能自然的形成这种接口关系。例如:初始化是系统的数据准备、装载过程;业务功能消费这些数据。

2.内部输入关联

如图2中,主功能模块的输入条件,除了界面输入,还有一些内部数据输入。这些数据输入可以通过次功能c来构造。 通过次功能c的构造,能够实现对功能a更加完整的分支覆盖。 典型的例子是:业务通讯过程,依赖于其保护密钥的更换功能,这里的保护密钥就是内部输入关联的数据。

3.背景数据依赖

这种集成关系常常是: 基于系统全局的接口,在某种功能分支运行下,发生变化,进而影响主功能模块的运行。例如某个背景数据a是主功能的依赖数据,数据a可能因为某些功能运行或者某些事件改变。从而影响主功能的运行。

例如: 某个应用系统某数据的生产任务已经启动了,但一段时间后该应用系统被删除。则其对应的数据如果没有设计回收机制,就会形成冗余数据,这些数据占据了空间,但是没有被使用。这种情况也可以被理解为一种异常测试。

集成测试所捕获的问题主要来自于上述3种情况,而这些问题,常常是最容易出现测试逃逸的方面。

三、系统级集成测试的分析方法

系统级集成测试分析依赖于白盒接口分析、黑盒场景分析2方面的有机结合,接口分析的目的是分析明确集成测试的边界和目标;而场景分析则帮助我们获得高效的需求选择依据,选取最重要的测试需求。

(一)接口分析

通过对系统级功能核心接口数据进行分析,明确集成测试的实体范围及测试的目标分支。

根据上述2.2节的分析,集成测试的本质是捕获模块内部分支上的bug,所以,集成测试分析首先应明确测试功能或模块对象,以及与之存在接口关系的相关功能或模块对象,形成功能簇。功能簇有2种来源方式:

1.由软件概要设计文档,软件分支流程图,而导出的数据接口关系。在软件系统设计中,各个分支所共有的数据以及数据接口关系,就是要测试的目标。

2.基于系统业务而划定的一组关联功能,这些共同实现某种业务的功能,通常具有密切的数据接口,输入与消费的关系。

功能簇的选取,应针对每个重点的核心功能,逐一进行分析,形成若干功能簇。这里的核心功能,常常是那些系统中,长期或者频繁运行的,与核心业务密切相关的功能。如管理系统的管理服务端,通信系统中的业务通讯功能。

(二)场景化分析

通过接口分析,明确了测试的目标接口;而动态的场景分析,则是有效的选取、过滤这些接口获得最优测试覆盖率的手段。同时也对系统级的主要异常测试设计提供的依据。

测试中常常提到分支覆盖、语句覆盖,其实最有效的是场景覆盖。因其视角最高,也能获得最好的覆盖效率。

场景分析的要素包括:业务模型、应用模式、承载环境等。是对于软件系统完整运行环境的建模和构建。

下表列出了典型的加密通信系统的主要业务及场景的关联分析表:

四、结束语

笔者在多年的产品测试实践中,体会到大量的测试逃逸来自于接口测试构造不足。软件系统的内外接口数量是巨大的,总是让测试者无法穷举和覆盖。成功有效的测试,并非依赖测试容量、压力的构建,更多的依赖于对业务的理解,以及对核心的软件设计内在机制的把握。系统级集成测试的深入分析和应用,为我们寻求高质量的测试提供了一条有效途径和思路。

集成测试篇3

一般来说，移动软件和硬件的测试是由制订协议的人员通过编制脚本调用处理(call-processing)开发的方式分别进行的，其中硬件设计工程师使用基于射频的工具在物理层上进行测试，软件工程师在操作系统和应用层上进行测试。

分离的测试方法对于语音应用是可行的，但是由于空中接口(air interface)的特性可能会使无线应用的数据发生衰减、失真和延迟，甚至达到失效的地步，这样一来分离测试的方法就无法胜任了。无线数据设备中的软件和硬件需要在一种“真实”的网络环境中进行联合测试，测试过程要像一名真正的用户在使用该设备一样。在设计的集成与验证阶段，测试工作被赋予了新的重要意义，必须要验证终端用户对最新高速数据应用的使用体验。

五个阶段

移动设备的研发周期可以从广义上分成五个阶段：设计、系统集成与验证、前一致性(preconformance)验证、一致性(conformance)验证、互操作性。每个阶段都有自身的测试需求，研发周期中所涉及的每个设计小组都有自己的测试过程和首选的测试方法。

满足各个阶段测试需求需要多种测试设备，其中主要的测试仪器包括脚本生成引擎、射频参数式测试仪和堆栈式信号测试仪。我们主要关心系统集成与验证测试工作中所涉及的这三类测试。

在系统集成与验证阶段，各个阶段的设计人员集中在一起对软件和硬件进行集成。他们需要检验各个组成单元的基本功能，验证射频与模拟器件的功能，检验设备在真实环境下的工作情况，当对设计进行修改之后还要进行回归测试(regressiontesting)。在这一阶段，在操作网络环境下测试移动部件是非常必要的。

真实条件下的测试

为支持移动数据服务，嵌入式软件的数量大大增加。例如，3G设备中可能会包含数百万行的程序代码，而原来的2G设备中所需的代码只有几千行。

为了实现互联网协议功能，应用程序栈是与信号协议并行运行的。当把应用集成到设备之中时，设计者必须确保所有的功能仍然能够正确实现。

这是通过对部件施加测试激励，测试诸如丢包率、数据吞吐量和延迟等参数来实现的。测试工作必须在尽可能接近真实的环境下进行，要使用真正的IP数据通信。

进行激励测试的一种办法就是在真实网络中进行。但是，寻找一个商用的运行网络并在各个测试阶段走出实验室进行测试并不是最可行的方法。设计者可能会受限于网络的技术格式，无法控制测试环境。

另外一种更适合于实验室测试的方法是采用一体式测试装置，这种测试装置同时具有射频和协议分析功能，能够代替真实的射频网络，作为一个基站仿真器来使用。设计者可以监测各个部件来回传输的信息，修改各种网络参数，例如射频功率、数据编码结构、数据速率和时隙(time slots)数量等。

安捷伦公司推出的8960无线通信测试装置能够运行预置调制格式的实验室应用程序，针对GSM／GPRS，EDGE、CDMA2000、lxEV-DO、W-CDMA和HSDPA技术，实现语音、视频、IP和通信应用的仿真测试功能。

该装置所具有的一套射频测试功能将参数化测量功能和首层性能测试结合起来，能够针对预定的访问信道评测无线设备的性能。

解决复杂的性能问题

在集成与验证测试工作的早期，设计者往往觉得记录协议交换信息对于优化设计或者调试错误非常有帮助。协议记录工具必须要能够实时地记录第1、2、3层的协议消息。

在设计调试过程中，测试工具还应该具备用户预定的触发与过滤功能，以帮助设计者隔离某些特殊的问题。两台测试装置进行同步记录的功能对于评测Inter-RAT handover性能是非常有用的。

在这一测试阶段，很多细微的和不是非常细微的性能问题就会出现。交换(handover)是一种非常复杂的数据调用，也是一个常见的问题来源。同时使用多个测试装置进行双单元(two―cell)仿真是实现真实交换测试的基础。

随着3G网络数据速率的增大，设计者还必须解决移动设备失效的问题，这种问题只会随着和数据吞吐量的增大而涌现出来。即使由于大气干扰而使信号发生干扰和衰落，设计者都必须搞清楚其产品中所用的微处理器是否能够处理所有输入和输出该设备的数据信息。

当做完基本的无线设计功能验证之后，设计者还必须确保：当把该移动设备接入不断扩容的个人电脑和操作系统网络中时，为终端用户提供的应用程序仍然能够正确工作。在3G蜂窝网络中传输高速的数据将会给终端用户的使用带来问题，因为大多数PC操作系统无法处理移动网络传送的数据。

随着数据速率的增加，这些问题将变得更加糟糕。网络仿真器和移动设备仅仅是整个移动数据系统中的两个组件，若想检测整个系统的问题就会给设计者提出更大的新挑战。

8960测试装置中的数据吞吐率监视器能够对发射器和接收器信道上的无线和IP数据吞吐率进行测量。设计者能够把超过实际网络性能指标的数据速率作为激励加载给待测设备，对于HSDPA能够测试高达3．6Mb／s的数据速率，对于lxEV-DO能够测试2．4Mb／s的速率，同时还可以模拟某些射频故障(如图2所示)。

除了CDMA格式的实验室应用外，设计者还可以在PC上使用安捷伦推出的Baseband Studio功能，实现信号衰落条件下的应用性能测试，并监测数据吞吐中的故障。这一功能通常需要更昂贵的测试设备来实现。

在产品生命周期中的应用

集成测试篇4

关键词：UML类图；有向赋权图；面向对象软件集成测试；ODDWG

中图分类号：TN91934文献标识码：A文章编号：1004373X（2012）18003803

集成测试的目的是通过测试来发现和接口有关的错误，即把通过了单元测试的模块组装起来测试。类间存在的多种关系是测试顺序的一个重要依据。选择不同的测试顺序将决定着测试的结果，如何寻找使得测试最为有效的测试顺序是面向对象软件集成测试的一个重要问题[12]。

本文将类图中的类内信息，类间信息提取出来，并计算每个类的内聚度，以及类间耦合度，同时把每个类看作有向图的结点，类的内聚度作为结点的权值，类间耦合度作为关系的权值，并根据动态绑定存在的条件，添加可能的类间动态线索。最后利用深度与广度结合的遍历算法遍历该有向图生成集成测试的测试序列。

1扩展有向图模型的定义

4结语

本文针对UML类图中提取的信息，计算与类相关的信息，获得对象动态加权有向图，然后从有向图中进行遍历，生成集成测试测试序列。该算法不需要去除图中的环，生成方法简单有效，在实际需要中得到了验证，但随着类图的增加，测试序列数量会加大，导致序列的生成速度有所影响。因此下一步的工作是研究如何进行更有效的遍历，同时在下一步工作中进一步研究类间耦合度和类内聚度，使得图中每个结点的权值获取和边的权值获取更加的科学。

参考文献

[1]JORGENSENPC，ERICKSONC.Objectorientedintegrationtesting[J].CACM，1994，37（9）：3038.

[2]吴静莉，韩松峰.基于UML集成测试模型的生成方法[J].微电子学与计算机，2008（7）：913.

[3]陈树峰.面向对象软件的依赖性分析与回归测试[J].计算机应用，2009（6）：2932，54.

[4]林红昌，胡觉亮.基于Petri网的软件测试用例的产生和分析[J].计算机工程与应用，2009（10）：3033.

[5]FOWLERM.UML精粹标准对象建模语言简明指南[M].徐家福，译.北京：清华大学出版社，2005.

[6]AIKC，DANIELSFJ.InterclasstestorderforobjectorientedSoftware[J].JournalofObjectOrientedProgramming，1999，12（4）：1825.

[7]LETY，JERONT，JEZEQUELJM，etal.Efficientobjectorientedintegrationandregressiontesting[J].IEEETransonReliabilitu，2000，49（1）：1225.

集成测试篇5

关键词:半实物仿真;虚拟仪器;Labview;高速磁浮;仿真测试

中图分类号:TP391.9 文献标识码:A文章编号:1009-3044(2010)22-6290-02

Study on Test Platform Integrated Simulation System for High-Speed Maglev

XIONG Zhi-jie

(Department of Software Engineering, Tongji University, Shanghai 201804, China)

Abstract: Based on the performance study and combined with the HIL simulation and virtual instruments technology, it is proposed a method for hybrid test of integrated simulation system for High-Speed Maglev. The test device is designed, which could reproduce the various running status of the Maglev system in the laboratory and carry out an integration testing on the system based on the manual testing data and the automatic testing case. The test device has been applied on Tongji University, with excellent results.

Key words: HIL simulation; virtual instrument; Labview; high-speed maglev; simulation testing

1 概述

半实物仿真又称硬件在回路仿真(Hardware-In-the-Loop Simulation,HILS),是指在条件允许的情况下尽可能在仿真回路中接入实物。以实体取代相应部分的数学模型,这样更接近实际情况,从而得到更确切的信息。这种仿真实验将对象实体的动态特性通过建立数学模型、编程,在计算机上运行。由于在回路中接入实物,因此对仿真过程有“实时实地”的要求。即半实物仿真不仅需要实时运行,还要在相应的模拟环境下运行。

随着经济的发展和人口规模的不断扩大,城市交通问题日趋严峻,已经成为世界范围内重点研究解决的问题。而高速磁浮交通因为其客运量大、周转量大、速度极快、安全性能高、受干扰小等优点,已经成为城市交通问题的首选方案。

中国磁浮列车在上海从2000年开始建设到投入运营,发展至今已经有10年的历史了,如果一直依靠国外厂家进行建设,不但在经济上将难以承受,也对国内磁浮产业的发展不利。而且德国的测试技术是基于人工的手动测试,其操作难度大,同步性要求高,效率低下,已经无法满足目前技术发展的需求。因此,吸收和消化国外先进技术,自主研制一套能对磁浮系统进行综合测试和评价的装置成为当务之急,也是为进一步建设磁浮打基础。

2 系统简介

高速磁浮半实物仿真集成实验系统是一套以28km实际工程线路为应用背景,由核心控制系统、关键设备和仿真环境构成的半实物高速磁浮交通系统技术集成实验系统,并对系统功能、性能、接口等相关集成技术进行实验研究的系统。该集成实验系统针对28km实际线路及一列车、二个分区和双端供电等工况,实现对整个高速磁浮交通运行控制及牵引控制系统进行RAMS(可靠性、可用性、可维护性和安全性)设计、系统及部件功能规范、系统及部件接口和系统及部件性能的试验,并对其进行环境故障注入条件下的系统功能和性能的测试和验证。系统总体架构图如图1。

3 仿真测试原理

本测试系统是半实物仿真技术在高速磁浮交通和测试领域的应用,是一个半实物仿真测试系统。根据高速磁浮系统的工作原理及其各子系统结构,本仿真测试平台作为整个半实物仿真系统上层的一个测试管理平台,通过对系统所有仿真设备的状态监控和故障注入、测试案例的操作实施,与半实物仿真系统中的仿真设备一起实现对系统主体设备运行控制系统和牵引控制系统的功能、性能、接口等的测试验证。

从技术角度来说,就是以计算机为控制核心,包括高速数据采集卡、信号调理电路以及一整套的软件系统,通过数据流监控、检测、控制、管理整个被测系统,通过LabVIEW图形界面监控被测系统所有需要监控的信号,通过收发数据包实现故障注入、案例测试,通过读取测试结果数据判定被测系统的性能优略、部件是否正常。半实物仿真技术既考虑了高速磁浮系统的复杂性,又结合了软件在测试方面的强大功能,实现了软件和硬件的有机结合。

4 系统硬件实现

本系统是针对磁浮系统的动态特性(要求同步误差小于0.2毫秒),并对其关键部件提供控制、监视、数据采集、显示等功能的仿真测试平台。从系统设计角度讲,半实物仿真系统应当具有面向不同工业系统,不同控制规律的仿真能力;从软件开发角度来讲,它应当具有多变量、多参数的处理能力;同时作为半实物仿真的扩展,它能够与其他硬件部件之间进行实时或非实时的通信。其核心硬件设备为两台IBM X系列服务器,一台作为应用系统服务器,另一台作为数据库系统服务器,但每台服务器都安装应用系统和数据库系统,构成服务器集群,两台服务器互为冗余,当一台服务器出现故障,立即启用另一台服务器的备份功能,这样系统就可以持续运行。仿真测试系统硬件框架图如图2。

5 软件设计

软件系统的开发平台是windows2000 server操作系统和Labview虚拟仪器软件开发环境,数据库为Oracle。系统的软件设计采用由上至下的设计方法和模块化的设计思路,即首先根据测试系统的总体方案需求,确定软件系统的总体框架;然后根据所需的不同功能划分各种功能模块,并分别设计实现各个功能模块;最后再将各个功能模块进行集成和调试,完成整个软件系统的设计与实现。

首先,本系统采用J2EE架构,引入JSF 和 Hibernate框架,形成表示层、控制层、业务层、持久层和数据层五层的实施构架。

其次,根据案例测试方法的特点及要求,开发一个B/S构架的案例测试控制系统,案例测试人员通过浏览器登录系统,然后在登录后的界面上进行编制案例、保存案例、执行案例等操作。客户端通过向服务器端发送请求,服务器根据相应请求,将该界面返回给测试人员,同时后台与数据库服务器相连,提供数据支持。测试系统主操作界面如图3。

最后,根据手动测试方法的特点及要求,开发一个基于Labview的手动测试及数据监控子系统,在软件编写中,完成各子系统功能的程序,将其做成子模块。当然每个模块也可以由更小的模块组成。车辆系统Labview程序框架图如图4所示。

6 动态测试

本系统运行时,通过主程序操作界面及Labview监控操作界面,向仿真测试系统发送控制指令,使高速磁浮半实物仿真集成系统再现列车正常运行时的牵引、供电、控制等工况,并及时采集并储存各种实时数据,实现对系统中实物设备的检测,通过被测系统向测试系统发送的工况信号与即成案例测试数据进行比对,判断高速磁浮半实物仿真集成系统各模块、各接口、各设备能够正常工作。

7 结束语

高速磁浮半实物仿真集成系统测试时所运行的仿真环境与28km实际工程线路条件下的列车实际运行环境等效,测试结果与在线状态时基本相符(局部实验数据与预先计算数据有偏差,有待进一步研究实验),这为高速磁浮的建设和运行提供了非常有用的资料。本测试系统已成功在同济大学磁浮研究中心投入实验。

通过对系统的仿真测试,可以方便地得到实物系统在不同环境下的仿真模型的运行状态,测试结果可以为进一步的磁浮研究提供重要的数据来源,而且可以为沪杭磁浮建设提供重要的实验数据。为今后中国高速磁浮的发展提供非常多的实验数据。

参考文献:

[1] 吴详明.磁浮列车[M].上海:上海科学技术出版社,2003.

[2] Cem Kaner,Jack Falk,Hungary Quoc Nguyen.计算机软件测试[M].北京:机械工业出版社,2004:40-100.

[3] Robert Edition.LabVIEW8 Student Edition[M].北京:电子工业出版社,2008:1-100.

[4] Mansoor S P,Jones D I,Bradley D A.HARDWARE-IN-THE-LOOP SIMULATION OF A PUMPED STORAGE HYDRO STATION[J].International Journal of Power and Energy Systems,2003,23(2).

[5] 程隆华,方海清.上海地铁一号线车辆牵引(制动)数学仿真计算[J].上海铁道学院学报,1999(15).

集成测试篇6

关键词 车辆比赛;辅助装备;集成工具车

中图分类号：G642.423 文献标识码：B

文章编号：1671-489X（2015）01-0024-02

1 辅助装备集成工具车项目的目的和意义

在比赛过程中，选手常常会遇到一些问题，比如：1）轮胎等很重的物品无法快速搬运，用老的笨重的方法，无法实现快速更换;2）工具多且较重，常常丢失找不到;3）赛场上，队员之间联系困难，需要保持随时沟通联络;4）多种用电设备，保证供电也是个问题。

基于此，北京理工大学学生机械创新实践中心有了做一个集成工具车的构想，其应具备以下功能：无线电联络（team radio），设置小功率发射基站，实现单工集群通讯，构建指挥和通讯平台;快速卸胎，参考国外类似工具，实现同时卸除多个螺母的功能;应急供电平台，多个电瓶组成电瓶组，以提升输出功率，通过高效正弦波逆变器提供稳定的220伏电压，并通过电压转换模块提供多组USB 5伏输出，必要时可以改为连续可调输出;设置车载工具箱，随时提供必备应急工具。

机械创新实践中心内现常驻三个创新团体，分别是方程式赛车工作室、智能车俱乐部和节能车俱乐部，目的是通过实践和参加汽车类创新比赛，提高学生的综合素质。他们在各种国内外比赛中取得优异成绩。

北京理工大学方程式赛车工作室，是其中成绩最优秀的。在汽车类科技创新比赛中，先后在第一届、第二届中国大学生方程式大赛中获得冠军;其后分别赴日本、德国参加比赛，并取得优秀成绩，创造出中国高校参赛同级别比赛的最好记录。2012年汽油机赛车排名位列世界600余所高校的88名，是唯一进入世界前100名的中国车队。

北京理工大学智能车队参与了全国大学生“飞思卡尔”杯智能汽车竞赛历次比赛，在前八届比赛中，多次获得各组别的华北赛奖项和全国赛奖项，竞赛水平位居全国高校前列。基于车辆比赛及测试的辅助装备集成工具项目的实现，将会帮助北京理工大学方程式赛车工作室创下更加优异的成绩。

2 辅助装备集成工具车项目的特色与创新点

其最大特点就是，将比赛过程中常用维修维护功能集成起来在一起，以提升工作效率。其实用性，在于集成多种功能，这需要进行多次反复的实验，进行调整和改进。其新颖性，在于以最优化的组合和最人性化的设计，专门针对方程式赛车的研究和维修，可以是独一无二的。工具车造型现代，集成车队技术工作、工作指挥平台、储存零部件和运送大型装备等功能，节省人力物力，并且占用空间少，是一个很实用的产品。而且在汽车类创新比赛中，北京理工大学是较早开始研发多功能工具车的。

3 辅助装备集成工具车研究内容、进度计划和研究方法

辅助装备集成工具车的研究内容

车辆基体原理：底盘部分采用五轮结构：四个万向轮;车底部中间安装第五个轮，为主动轮，负责辅助动力传输。制动为自行车碟刹动力传动采用带减速器的同步电机，具有可调速功能。

无线通讯原理：以中功率对讲机为基础，安装小型对讲基站，选择相同频段，给赛车和队员都配备发射接收装置，实现车队内部无缝沟通。

电动与电路设计：通过电瓶提供能源，用逆变器调节电压，通过传动装置实现车体运动，使用同步电机来限定转速。逆变器能提供220伏输出，供给电脑灯设备工作，也可给其他设备充电。

快速卸胎装置：参考国外类似工具的原理，计算扭矩，运用轮系设计改装电钻，使其达到同时卸除多个螺母的目的。

工具储存：在满足上述要求后，优化小车结构设计，充分利用空间，使随赛车的工具盒标准件能在工具车上有更人性化的储存空间和相应归类。

辅助装备集成工具车的研究计划

第一阶段：2012年9月―2013年11月，对工具车车身、结构进行设计，对方案进行修改，每周二下午组内成员进行讨论以及分工进行三维建模。

第二阶段：2012年11月―2013年1月，布置学生通过走访五金市场、网上搜索、组内头脑风暴等，对设计进行创意分析，并得出调研报告和修改纸质方案;布局构建，将多功能所需工具或部件合理设计并分布到三维模型上。

第三阶段：2013年1―4月，设计传动系统，研究“换胎枪”和无线通讯设备的原理以及对电机电瓶的有关知识的掌握，并对计划进行一定调整;对设计进行一定程度的修改。根据各学生特点，对他们做了分工：陈智舟负责无线电设备原理的研究，叶剑辉负责“换胎枪”的设计，李益民负责传动系统设计，许尧负责电机，李诗音负责电瓶。最后得出设计或研究报告。同时，建议他们进行深入调研，走访宜家、朝龙五金等大型市场，对布局和多功能整合性、加工难易程度进行调研，通过及时的调研结论，修改、整合设计，得出最终设计方案。

第四阶段：2013年5―6月，将车的整体加工组装，分为车架加工、车身加工、结构部件填充和最终组装四大部分;同时对一些细小的地方进行小修改;车的整体加工完成。

第五阶段：2013年6月―2014年6月中旬，对科创项目进行实验，分析并解决存在问题，进行总结。

车架的三维模型如图1所示。

辅助装备集成工具车的研究方法

首先，要求对现有工具车调研后，通过SolidWorks建立模型进行车体的大致钢架结构设计，对ANSYS车体进行力学结构分析，选取材料，使其承载极限达到100 kg，同时保证车体结构的稳定性，在一些紧急情况下，可以运载轮胎等重物。整车布局如图2所示。

第二，通过前期网络创意收集和反复研讨，修改钢架设计，使其兼具加工简易性、经济性，并符合美学原理。

第三，重新建立三维模型，将多功能的各部分分部先置于车上，并根据使用情况调整结构布局。

第四，经过对家居市场调研，通过整合设计，修改部件和布局，让车辆的结构设置兼备美学与简易多功能的特点。工具车最终模型如图3所示。

4 辅助装备集成工具车的最终成果及验收指标

通过一系列实验研究和改进，最终实现：

1）制作出一台多功能工具车，可以实现快速换胎、具有组成团体内的移动小型通讯功能、对移动设备进行充电、提供交流直流电源、实现常用工具的储存;

2）培养三名学生，使之能够熟练使用SolidWorks和ANSYS进行三维机械设计，将所学的知识应用于实践，培养学生的独立思考和熟练的实际操作能力。

5 结论

集成测试篇7

关键词：ISO 26262；汽车电子；测试

DOI：10.3969/j.issn.1005-5517.2013.4.005

ISO26262标准概述

功能安全标准（ISO26262）是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，主要定位在汽车行业定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准。

ISO26262从2005年11月起正式开始制定，经历了大约6年左右的时间，已于2011年11月正式颁布，成为国际标准。中国也正在积极进行相应国标的制定。

ISO26262主要内容包括：

·提供了汽车生命周期（管理，研发，生产，运行，服务，拆解）和生命周期中必要的改装活动。

·提供了决定风险等级的具体风险评估方法（汽车安全综合等级，ASILs）。

·使用ASILs方法来确定获得可接受的残余风险的必要安全要求。

·提供了确保获得足够的和可接受的安全等级的有效性和确定性措施。

功能安全受研发过程（包括具体要求，设计，执行，整合，验证，有效性和配置），生产过程和服务流程以及管理流程的影响。

安全事件总是和通常的功能和质量相关的研发活动及产品伴随在一起。ISO26262强调了研发活动和产品的安全相关方面。

符合性要求

1）如果要宣称符合ISO26262，那必须是符合其每个要求，除非有如下情况之一：

·根据ISO26262-2中，对不适用的要求进行安全行为的裁剪：

·针对不符合项，提出其说明理由，并对理由根据ISO26262-2进行评估：

2）所有安全行为的输出物都在ISO26262中有明确的规定。

3）下文中出现的列举各测试方法的表中，有不同的序号表示方法：

·连续的序号，比如1.2.3：所有的方法应被用于对应的ASIL等级，如果出现所列表中之外的方法背用于测试，则需要进行说明。

·可选的序号，比如1a，1b，1c：可以选择某个或多个方法进行测试，并优先考虑更高推荐指数的方法。如果多个方法被组合选择用于测试，则需要进行说明。

4）针对ASIL的各级，表中的每个方法都有对应推荐指数：

·“++”：最高的推荐指数

·“+”：建议使用

·“0”：不建议使用或不需使用

测试概述

ISO 26262-8中的第9节描述了“Verification”的目标、要求和建议、工作输出等。Verification是用于确保实现与需求的一致性，在安全生命周期的几个阶段中都会用到。包括概念阶段、产品开发阶段、生成和运营阶段。本文主要描述在产品开发阶段中的测试环节中，需要用到的各种测试要求和建议。

测试计划

1）在测试执行前，都需要建立测试计划，其主要包括几部分：

·测试范围：用于测试的产品内容：

·测试方法：用于测试的各种方法：

·测试标准：测试通过或失败的标准：

·测试环境：如果需要用到各种测试环境，比如仿真环境等，需要进行说明：

·测试工具：用到的各种测试工具：

·出现异常后的对策：

·回归策略：在测试对象发生变更时，指定其如何进行回归测试，比如全部回归、部分回归、和其他测试案例一起回归等。

2）测试计划的制定还需考虑到以下几个方面：

·测试方法的完整性：

·测试对象的复杂度：

·测试经验：

·测试技术的成熟性和风险。

测试规格

1）测试规格需要选择和指定用于测试的方法，并包括测试案例、测试数据和测试对象。

2）每个测试案例需要包括：

·序号：唯一的ID

·测试对象的版本号

·测试对象的条件和配置：针对测试对象的不同配置，需要选择合理的测试案例进行测试

·测试环境

·输入值和顺序

·期望行为：报刊输出值、输出范围、功能表现等

3）测试案例需要根据测试方法来分类。针对每个测试方法，除了测试案例外，还需考虑以下几方面：

·测试环境：

·相关性：

·测试资源。

测试执行和测试报告

4）按照上述章节中制定的测试计划和测试规格，进行测试的执行。

5）针对测试结果，其测试报告需包括以下几个方面：

·测试对象的ID：

·测试计划和测试规格的引用：

·测试环境、测试工具、标定数据：

·测试结果和期望值的符合度：

·测试通过或失败的结论，如果失败，还需要指明失败原因和修改建议：

·针对没有执行的测试案例，说明原因。

ISO26262中的测试阶段

ISO26262中涉及到测试的阶段共包括“硬件集成和测试”、“软件集成和测试”、“产品集成和测试”这三部分。下面章节分别介绍这三部分的要求和建议。

硬件集成和测试

ISO26262中“Part 5：ProductDevelopment：HardwareLevel”针对产品开发的硬件部分提出了专门的集成和测试要求和建议。

1 硬件集成和测试需要按照安全计划和验证要求来按计划进行：

2 硬件集成和测试需要按照产品集成和测试计划来进行：

3 针对变更，需要按照标准规定中的变更管理来对测试策略进行影响分析：

4 测试的设备可以按照国际标准（比如ISO17025）或公司标准来进行标定：

5 硬件集成测试的测试案例需要按照表1的方法进行设计：

6 针对硬件安全需求，硬件集成和测试需要对其安全机制实现的完整性和正确性进行验证，其方法如表2所不。

7 硬件集成和测试需要按照表3的方法进行外部压力环境下的鲁棒性测试。

软件集成和测试

软件单元测试

软件单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。ISO26262中规定了其相对应的要求和建议：

1 软件单元测试需按照“ISO26262-8节9中”的验证要求来有计划的定义和执行。软件单元测试的对象是具体的软件实现单元，在基于模型的软件开发过程中，软件单元测试的对象是其单元模型。

2 软件单元测试需要按照表4中列的方法进行，以完成以下目标：

·检查是否符合软件单元设计的具体要求：

·检查是否符合软硬件接口要求：

·检查功能是否正确实现：

·检查是否有异常功能：

·检查软件实现的鲁棒性，比如错误处理效率等：

·检查功能所需资源的完整性。

3 软件单元测试中的测试案例需要按照下表5中的方法进行分析设计。

4 软件单元测试中，对于需求的覆盖度、代码的覆盖度都需要进行衡量，具体方法如表6所示。如果覆盖度不够，还需要增加其他测试案例。

·代码的覆盖度都可以借助一些软件工具来实现：

·如果是基于模型的开发，其软件单元测试需要利用类似的模型的结构化覆盖指标来衡量：

·如果通过代码的打桩来进行测试覆盖度的衡量，必须保证打桩的代码和正常的代码的执行功能是一致的：

·对于覆盖度衡量目标，都需要给出一个合理理由来表示其不同的级别，对于无法覆盖的代码，可以通过检查等其他方法来进行验证。

5 软件单元测试需要尽可能的在真实的目标环境上执行，如果利用其他环境，则需要评估其与真实环境的差异、源代码和目标代码的差异，分析设计测试案例，以便在接下来的测试阶段中得到执行。

·测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。

·如果能利用目标环境中的相同处理器来运行软件单元测试案例，那是最有效的，但如果不行，则可以用处理器模拟器来代替，否则软件单元测试只能在开发系统中进行测试。

·软件单元测试可以在不同的环境中执行，比如模型在环测试（MIL）、软件在环测试（SIL）、处理器在环测试（PIL）、硬件在环测试（HIL）等。

·在基于模型的开发系统中，软件单元测试可以在模型级别进行，但模型与代码的执行比较测试必须要做，以保证模型与自动生成的代码的结果一致性。

软件集成和测试

软件集成和测试主要对实现的各软件模块进行集成，并验证其嵌入式软件实现是否符合软件架构设计。该阶段的要求和建议如下：

1 软件集成计划应该描述层次化的集成单个软件单元进软件组件中，直到嵌入式软件完全集成，并且应该考虑如下：

·软件集成功能的相互关系：

·软件集成和软硬件集成的相互关系。

注意：对于基于模型的开发，可以先集成各模型，然后对集成好的模型进行自动代码生成以完成整体软件的集成。

2 软件集成测试根据ISO26262-8：2011，第9节计划，定义并且执行。软件集成测试的测试对象是软件组件。对于基于模型的开发，测试对象可以是和软件组件相关的模型。

3 软件集成测试需要按照表7的方法进行，以完成以下目标：

·检查集成的软件是否和软件架构设计一致：

·检查集成的软件是否满足软硬件接口规格：

·验证功能的正确性：

·检查其鲁棒性，比如错误检测、错误处理机制的有效性：

·检查是否有足够的资源来支持。

4 测试案例需要按照表8中的方法进行分析设计。

5 对于软件架构级别的需求测试覆盖度，可以用来衡量测试的完整性，以及用于证明没有设计之外的功能实现。如果有需要，可以增加新的测试案例，或者提供一个合理的理由说明。

6 为了评估测试案例的完整性，同时确保没有多余的功能，根据表9列出的指标需要衡量出其结构覆盖率。如果覆盖率不够高，要么需要添加额外的测试案例，或者提供一个合理的理由说明。例如，结构覆盖率的分析可以用于发现测试案例的不足、无用代码、无效代码或者多余功能等。

·结构覆盖率可以利用工具计算出来。

·如果是基于模型的开发，结构覆盖率可以通过模型级别的模型结构覆盖率来统一计算。

7 作为产品的一部分，嵌入式软件需要被验证其包含设计的所有功能。如果嵌入式软件包含了设计之外的功能（比如用于调试的代码），则这些功能需要被验证是不影响软件的安全需求的。如果这些设计之外的功能在真实产品中保证不会被激活执行，那也是符合这个要求的：否则删除这些功能，也需要按照需求变更流程来统一处理。

8 软件集成测试需要尽可能地在真实环境中运行，如果不行，则需要评估测试环境与真实环境的差异性，并针对这些差异，在后续的阶段的真实环境的测试中设计专门的案例来执行。

·测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。

·针对各种测试，需要建立合适的测试环境。比如目标处理器的测试环境、仿真处理器的测试环境、开发测试环境等。

·软件集成测试可以利用模型在环测试（MIL）、软件在环测试（SIL）、处理器在环测试（PIL）、硬件在环测试（HIL）等测试手段进行测试。

软件安全需求验证

本阶段的目标是验证嵌入式软件符合软件安全需求，其所规定的要求和建议如下：

1 软件安全需求的验证需要制定计划，定义再执行。

2 为了验证嵌入式软件实现了软件安全需求，表10列了所需的测试环境。注意：已有的测试案例，例如在软件集成测试阶段使用的可以重用。

3 对于软件安全需求实现的测试需要在目标硬件平台上完成。

4 软件安全需求验证的结果需要考虑下面这些因素来评估：

·和预期结果一致：

·软件安全需求的覆盖率：

集成测试篇8

关键词：专家系统；自动测试；程序集合

中图分类号： TP182

文献标识码：A

0引言

我国农业专家系统的研究始于20世纪80年代初期。随后，许多科研院所开展了各种农业专家系统的研究、开发及推广应用活动。现在已形成5个农业专家系统开发平台，智能应用示范区扩大到23个，各地开发的本地化农业专家系统近200个。目前专家系统的研究正在向广度和深度推进。农业专家系统软件的质量则成为开发者与使用者共同关注的焦点问题。

在农业专家系统软件开发过程中存在不少问题：开发手段、开发方式多种多样，导致软件复杂度急剧上升；开发人员、开发部门的软件开发技术水平参差不齐；测试手段、测试方法严重滞后。进行手动对农业专家系统软件进行测试将极大的降低软件测试的效率，而且测试的质量也难以保证。采用自动测试成为一种必然。

为了更好地测试农业专家系统软件，进一步提高农业专家系统软件测试床的测试效率，本文研制开发了一个软件自

动测试工具，用来衡量农业专家系统软件的质量优劣。

1农业专家系统软件自动化测试

我们主要从软件设计和程序编码的角度对农业专家系统软件进行系统分析，从而确立自动测试的目标，提出相应的自动测试策略，建立农业专家系统软件自动测试的框架。

1.1关于程序集合

农业专家系统软件的开发手段与开发方式多种多样，数据库技术、网络技术、智能模拟技术等都融入了农业专家系统的开发过程中。同时，VC、VB、C#和Java等一大批开发语言正逐渐成为农业专家系统软件开发的主流编程语言。在开发农业专家系统软件的过程中，农业专家系统的通用性、可移植性越来越受到人们的关注;面向对象技术，软构件技术正逐渐成为提高软件开发效率的重要开发手段。

由于农业专家系统软件的复杂程度越来越高，为了缩短开发时间，提高开发效率，软件开发人员经常以模块化的方式进行程序的编码。

采用功能模块这种编程方式进行程序设计与开发，主要是因为程序编码的工作量巨大，必须由多个软件开发人员根据软件设计规范分头实施，这种将一个大的应用程序划分为几个小模块的构建方式，有利于软件开发小组内部成员的分工与合作。

这些功能模块从软件编程的角度看，又可以分为两类:一类直接嵌套在农业专家系统软件中;另一类具有独立性，即:经过软件的代码编写，并对它们进行软件的编译之后，以*.exe或*.dll为后缀的文件形式存在，一般被称为程序集合。

本文主要针对程序集合进行自动测试。下面主要讲述程序集合的特点，以及其在农业专家系统中的应用情况。

图1简单表达了程序调用过程。在程序编码过程中，这种编程方式是大量存在的。在系统运行过程中，用户的输入数据或系统事件产生的输入数据，通过程序集合中提供的接口传入，在程序集合中进行相关的处理，并输出结果。

从农业专家系统软件编程的角度看，这种程序集合的编程方式被广泛地运用在推理机、知识库、模型库的开发过程中，而推理机、知识库、模型库是农业专家系统软件不可或缺的组成部分，发挥着重要的作用。

从推理机、知识库、模型库运行机理进行分析，可以看出:农业专家系统软件一般都包含有推理机、知识库、模型库，它们包含了大量的农业领域的相关知识;并且通过软件编程技术手段，把农业相关领域的知识按照一种合理的表示方法将它们移植到计算机中。当使用者需要使用这些知识处理问题时，一般以发送信息的形式调用相应的功能模块进行运算，并得到一个对应的运算结果。如图2所示。

可以看出,返回结果的正确与否，将直接关系后面继续运行的应用程序的成败，进而导致整个农业专家系统软件运行的成败。返回结果是由推理机、知识库、模型库中相应的数据和算法的逻辑运算实现的。因此，必须对推理机、知识库、模型库进行大量的测试，即:通过发送信息，观察返回结果来发现它们存在的数据和算法的逻辑运算错误。

从软件编程的角度对推理机、知识库、模型库进行分析，可以发现:推理机、知识库、模型库中都包含有大量的处理实际功能的程序集合，大多数的程序集合的开发都遵循面向对象的软件编程技术规范。即:每一个程序集合都包含一个或多个类，每一个类中又包含多个方法，而且具体功能的实现又主要通过这些方法的调用运行去完成。程序集合中信息与数据的交互通过接口(在程序编码中表示为公共属性的方法函数)进行传递。

例一:

上例简单的展示了程序集合内部实际的程序编码方式。可以看出:一个具体功能的实现，主要通过方法的调用来完成，每一个方法的内部由大量的程序代码组成，通过程序代码的运行完成一个具体功能的运算操作过程。其入口是方法，方法以接口的形式与外界进行联系，这些接口由一个或多个不同类型的参数变量组成，提供给用户向其发送信息，从而进行相关的运算;出口是方法的返回值，用来向调用者返回结果。因此，在这样的层次中，程序集合所包含的类中所有的方法都是需要进行测试的对象单元，即:通过对方法的测试，查找其编程中产生的逻辑算法是否存在错误。

综上所述，为了保证整个农业专家系统软件的安全性、健壮性和可用性，就必须对程序集合进行足量的测试，以保证软件的质量。

1.2程序集合自动测试

农业专家系统软件中程序集合的编程特点决定了测试这种类型软件的难度大，工作量大，需要测试的对象多，测试工作复杂繁重。而对程序集合这种软件系统进行自动测试将有助于达到其提高测试质量，增进测试效率的要求。因为:

1) 自动测试具有一致性和可重复性；

2) 自动测试可以执行一些手工测试困难或者不可能做的测试；

3) 自动测试可以发挥计算机的巨大优势。

软件的自动测试就是要做到在最大限度的减少软件测试人员的负担下，提高测试的效率，提高测试的质量。

1. 3自动测试策略

对程序集合的自动化测试，概括的讲就是根据程序集合接口的特点，向其输入相应的测试数据，并自动运行，对其运行完毕后的返回值进行比较、分析，以发现程序集合中的问题，发现错误、缺陷，便于进行修改。

农业专家系统软件的自动化测试，其最终是要通过建立自动化的测试工具来实现。在研制、开发自动化测试工具的过程中，一定要针对测试的内容，对测试框架进行细致、周密的考虑，使尽可能多的测试过程通过自动测试工具来完成，尽量减少手工测试的步骤、过程，即:实现自动化测试的最大化。

1) 自动获取被测试对象信息

通过对农业专家系统软件的分析，可以发现:农业专家系统软件中包含多个程序集合，每个程序集合中又包含有大量的需要被测试的方法，每一个被测试的方法又由一到多个变量组成数据输入接口;因此，自动测试工具如果能自动捕获这些“关键”测试信息，并以此为依据产生测试案例，将会提高软件的测试效率。这是本论文所要解决的一个关键技术问题。

2) 自动生成测试案例

根据捕获的被测试对象的信息，根据软件测试人员的测试需求，自动产生完整、精确的测试案例。测试案例自动存储在测试工具的案例库中，为被测试程序经过修改后的重新测试提供了大量的数据资料。

3) 自动创建测试脚本

如果为每一个被测试对象、每一个测试案例都编程一个测试脚本，这将大大降低测试的效率，也违背了自动化测试的初衷。因此，根据被测试对象的特点，自动生成测试脚本，而无需软件开发人员手工编程，将会提高软件的测试效率。这是本论文所要解决的另一个关键技术问题。

自动创建的测试脚本应包括以下主要功能:自动连接被测程序集合、根据已经捕获的被测试对象信息自动产生驱动程序编码、自动启动被测试程序集合、在测试过程中，跟踪、监视被测试程序的运行，收集产生的错误信息和实际的返回值。

4) 自动测试策略流程

实现自动测试策略的流程如下：

• 自动获取被测程序集合中的信息；

• 自动产生测试案例；

• 自动生成测试脚本；

• 以测试脚本驱动被测程序集合，进行测试，并进行结果的自动比较与分析。

（1） 被测程序集合提交给自动测试工具之后，自动测试工具具有自动获取被测对象的功能，即:自动测试工具可以自动搜索被测程序集合中所有的方法，并把搜索到的方法的方法名，方法中包含的变量名，变量类型清晰的显示出来，便于下一步的操作和运行；

（2） 测试人员选择一个方法作为被测试对象之后，自动测试工具可针对所选择的对象特点，自动产生测试人员所需要的测试案例；

（3） 之后，自动测试工具根据产生的测试案例，自动创建测试脚本并自动执行测试脚本，对被测对象进行自动化测试；

（4） 在自动测试过程中，测试脚本一方面把测试数据传入被测方法中(通过接口调用的方式)；另一方面，测试脚本时刻监视被测程序集合的运行，并把测试结果输出，显示测试结果，便于查找缺陷；

（5） 自动测试工具可自动存储使用过的测试案例、测试脚本;当进行回归测试时，可直接使用这些以前已经使用、生成的部件，从而提高了测试的效率。

由于需求、规格和代码的不断改变，增加、删除或修改代码都需要测试，代码的改变和进化通常是持续的，有时开发者并不了解发生的所有改变，因此，只有进行测试才能确认代码的改变是否有效，新的或者修改的功能只有通过测试验征后，才能集成到系统中，从而确保这些改变不会导致系统崩溃。例如:对公有类接口和组件接口进行测试，以确保修改后的编码不影响接口协议。

当被测成员不太多时，进行手工测试，手工编码测试脚本还比较容易，但对于有许多类和成员组成的程序集合，手工编码所有的测试脚本将会耗费大量时间，而且，为了精确编码测试脚本，需要研究被测程序集合的每个方法。

测试工具的测试过程不需要人工干预，而是连续执行，并能把揭示的缺陷及时通知测试人员。这对于自动测试过程是非常有用的，而且使回归测试也更易于管理。一方面，测试工具基于存储数据完成单元验证测试;另一方面，基于预定方案，可以重新运行产生的测试脚本，实现回归测试，从而判断修改后的应用程序能否满足需求。

2系统运行实例

2.1新的测试

“新的测试”主要完成以下功能:

(1) 自动获取被测试对象信息(包括:被测试的程序文件名、类名、方法名、变量名)；

(2) 确定每一个变量的取值范围;

(3) 确定需要生成的测试案例的数值;

(4) 确定测试期望值的范围。

2.2测试案例显示

本界面显示“即将”生成的测试案例所包含的内容。软件测试人员可以修改、添加、删除测试数据，从而使测试案例满足测试的需要(如图4所示)。

2.3结果显示

自动测试完毕后，自动测试工具把测试的结果显示出来，便于测试人员进行分析、处理。

3结语

针对农业专家系统软件的特点，提出针对采用面向对象技术开发的程序集合进行测试的测试方法与解决对策；并以自动获取测试对象信息、自动生成测试脚本为本论文的研究重点，在C#.Net开发环境下实现了软件自动测试工具的开发。

通过大量的实际程序测试的实践证明，按照本文提出的软件测试方法使得对农业专家系统软件的软件测试工作由盲

集成测试篇9

【关键词】计量自动化采集终端电能表数据采集RS-232通信无线通信

为了有效的保证自动化系统的正常运行，我们首先必须要保证计量设备的质量，为了避免由于生产厂家过多，导致各个计量系统的复杂，我们在进行终端功能测试的时候，要进行相关的对比，确保各个设备之间能够进行相互通信，为实现终端测试自动化的集成，我们还必须对测试中的控制功能和测试的数据进行管理，从而实现对各类电能量采集终端以及各类电能表的匹配情况全面掌握。

1、测试管理系统总体设计

相对于传统的单一点能量采集终端测试系统，电能量采集终端综合测试系统能够根据相关的测试目的，确定自动化测试能容，同时给出相关的用例和数据，集各种测试功能于一身，并形成管理测试系统的中体构架与计量自动化系统主站形成互联。管理系统的管理平台主要包括由数据库服务系统和应用服务器组成的管理平台主机构成，其中平台的输出方式应用电源控制功能，对测试电流、额定电压以及接线方式进行一定了控制调节，而所需要的测试数据的获取方式，需要终端综合测试管理平台中具备的数据采集功能。根据网络方式进行模拟，并测取测试数据，采集终端综合测试管理平台需要根据网络方式实现测试数据的传输，并能够通过与计量自动化系统之间的互联，对指定的测试设备进行随抄，所谓的随抄指的是通过通信能够获得相关的运行数据，从而有效的对自动化系统中终端和电能表的数据进行获取。

2、测试管理系统主要功能

终端综合测试管理系统的主要功能模块包括被测试设备信息管理模块、软件库管理模块、测试方案管理模块、测试管理模块、权限管理模块以及统计查询打印模块。

2.1被测试设备信息管理

2.1.1样本库设备信息管理 样本库设备信息管理主要实现对样本库的设备信息的管理和维护，具体分为样本库设备的查询、添加、删除，样本库设备资料管理和配置信息的管理。

2.1.2设备测试信息管理 设备测试信息管理主要实现对被测试设备基本资料的管理，包括设备测试类型、设备测试方法、软件配置、通信参数、设备台帐等资料的管理。

2.2软件库管理

软件库管理是对设备的通信规约、通信程序软件和主程序软件进行管理，其主要功能介绍如下。

①可导人和管理各类设备通信规约旧。1引，并可在测试进行时选择调用。②保存各类设备的软件程序.具体包括遵循IEC60870_5.102规约[11]的通信软件和主程序软件，实现对运行设备软件版本的统一管理。

2.3技术规程规范库管理

技术规程规范库管理是指对设备进行测试所应用的规程、规范、作业程序和记录表格进行管理。其主要功能介绍如下。

①实现各类设备试验的规程管理，包括新增、删除和对应的操作记录。②实现各类设备的技术规范管理，包括新增、删除和对应的操作记录。③实现各类设备的验收作业程序管理.包括新增、删除和对应的操作记录。④实现各类终端和电能表组合的通信测试记录表管理，包括新增、删除和对应的操作记录。

2.4测试方案管理

测试方案管理主要包括对每次测试所用设备类型和规约版本、测试内容进行设置。并将任一次测试设置成可被以后的测试所重复调用。提高测试方案配置的效率。

①终端综合测试平台主机通过与终端/电能表测试台体的接口，在调用测试台体的测试用例的基础上，实现测试方案的配置管理，如增加、删除、修改等操作，生成测试方案，实现自动测试。②测试方案的设置包括对每次测试终端的台数（1～3台）以及每台终端的连接电能表块数（1～13块）的设置，但每次测试的电能表总数不超过13块。对于需测试的每台终端。均可从规约库中选择相应的标准进行测试。③实现单项测试方案和测试总方案管理。测试总方案可由若干个单项测试方案以序列形式构成。单项测试方案和测试总方案都可以作为一个测试方案被重复调用。④单项测试方案依据验收标准的每一项内容建立。其主要的测试内容有：设备性能测试，包括终端正常工作能耗测定和终端的最低工作电压测定；数据交换（一般采集与通信）测试，包括测试台体接上终端与电能表后检查终端通信与电能表通信成功率、终端对电能表采集数据完整率、终端对电能表事件（来自电能表）采集完整率；按照验收标准进行的终端功能测试，包括终端实时数据的抄读、终端历史数据的抄读、终端对时等。

2.6统计查询打印模块

统计查询打印模块能够根据我们所设定的一些条件，建立相关的系统，并对各项数据进行统计和记录，首先能够通过对系统产生的台账数据、维护数据，按照一定的条件进行储存。还可以对每一次记录的实践，根据实际情况进行统计，并能够实现测试报告的管理。同时还能够对测试结果生成的清单，查询设备的安装以及指引工作，查询出终端、电能表是否匹配，之后形成各个分类汇总的清单。

2.7权限管理模块

所谓的权限管理模块，指的是以角色管理和用户管理作为基础，从而实现对用户登录、密码等权限的多级管理。我们可以通过这样的管理方式能够进行角色的添加和删除，之后进行用户的添加和删除管理，并对所包括的密码管理以及操作权限进行维护。

3、测试管理系统特点

3.1测试结果与现场一致性 当我们发现计量自动化系统主站、终端以及电能表中存在着的一些问题，我们可以通过测试设备与现场实际运行中的一致性和现场设备的实际连接情况，采取一些措施进行解决，并确保测试终端和电能表的组合能够根据测试数据的对比，满足实际的运行要求。

3.2扩展性 终端综合测试管理平台具有一定的扩展性，它不仅能够进行接人台体的扩展，同时还能够实现对多张台体的管理工作，还能够对各项模块进行故障分析，并实现设备测试效率的提高以及对设备异常情况的跟踪分析。

3.3统一性 终端综合测试管理平台能够实现各个版本软件的统一，实现测试流程、方式以及操作方式的统一，是集各种点能量采集终端测试功能于一身优秀管理平台。

集成测试篇10

关键词：电能量遥测采集终端；电磁干扰试验仪；电能表计；变电站；电能量数据 文献标识码：A

中图分类号：TM734 文章编号：1009-2374（2015）34-0009-02 DOI：10.13535/ki.11-4406/n.2015.34.005

近年来，电能量遥测采集终端已经在变电站中全面应用，经过几年的电能量遥测采集终端运维，我们发现部分在变电站现场的终端采集数据质量不稳定，直接影响到了电能量数据的采集、线损的计算、偷窃电的分析等业务的开展。

经过分析得出，影响电能量遥测采集终端采集数据异常的主要因素有：（1）来自变电站的电磁辐射对电能量遥测采集终端的工作进行影响，影响终端的采集时候的速率，终端采集不到电能表的数，严重时甚至会导致终端采集的表码跳变，影响专线用户的结算、线损计算等功能，情况极其严重；（2）很多时候终端运行一段时间后，电能量遥测采集终端与电能表之间的通信模块经常发生通信故障，常导致终端不能采集电能表数据；（3）终端的磁盘容量溢出，电能量遥测采集终端无法采集电能表数据；（4）终端RS485输出端口信号弱，导致通信异常；（5）采集终端RS485端口信号接收能力差，导致通信异常；（6）现在电能量遥测采集终端理论上每个通道可以支持抄读16只电能表，但是当通道负载的电能表过多，则会严重影响终端的采集速率，按照719通讯规约的要求，电能量遥测采集终端每5分钟就要采一次表码和电流、电压等的瞬时量，有时候5分钟内还要采集到电表的报警数据，电表的日冻结、月冻结等，电能量遥测采集终端的采集压力是大的，如果一个通道负载的电能表过多而终端的质量差，很容易采集不到电表数据；（7）RS-485总线布线长度过长，导致采集终端通信异常；（8）RS-485总线布线方式错误，信号反射增大而导致采集终端通信异常；（9）采集终端抄表参数设置错误，导致采集终端通信异常；（10）现场有其他干扰源串入RS-485总线而导致采集终端通信异常等。以上因素经常困扰现场施工和平时的计量自动化管理，错判、误判现象很多，导致工作效率低下、施工周期长、生产成本高。所以，我们希望电能量遥测采集终端在安装前就能进行测试，尽量在检定期间排除终端的质量原因。本文根据变电站的电磁干扰的磁场强度模拟出现场的工频干扰环境，设计出电能量遥测采集终端电磁干扰试验台，有助于现场终端运维人员快速定位和处理缺陷。

1 设计原理

电能量遥测采集终端与电能表进行通信采用RS-485标准串行电气接口，使多点连接成为可能。目前计量自动化终端现场运维过程经常出现串行电能表过多影响终端抄表的数据完整率，而这有可能和变电站的电磁干扰有关。为了判断串行电能表数量对电能量遥测采集终端运行影响，判断不同磁场强度下电能量遥测采集终端运行情况的影响。表1、表2是上述常见的问题在实验室进行测试的相关情况。从实验数据中可以看出在磁场影响终端带电能表负载数量和终端的抄表成功率。

2 设计实现

上面的实验证明了磁场和串行电能表的数量对电能量遥测采集终端运行的影响，为了保证在电能量遥测采集终端安装之前能对电能量遥测采集终端进行检定，本文对装置进行了设置。

2.1 系统原理框图

图1是采集终端工频干扰试验台的原理框图：

图1 采集终端工频干扰试验台的原理框图

采集终端工频干扰试验台由后台控制系统、串口服务器、程控电流源、电磁感应线圈、遥控测试模组、开关量测试模组、端口及状态指示模组、虚拟电能表、电源控制模组、载表台等模组组成：（1）后台控制系统：由计算机及采集终端工频干扰系统应用软件组成，主要完成设置测试方案、控制试验台试验过程、设置试验参数、设置通信参数、查询及输出试验报告等工作；（2）串口服务器：主要完成串行通信端口的扩展工作；（3）程控电流源：由升流电路、电流检测、报警电路组成，在系统应用软件的控制下，按照试验要求输出不同的工频电流至交流电磁感应线圈，在交流电磁感应线圈中心区域产生对应强度的工频磁场；（4）电磁感应线圈：直径1m的多组线圈，用于产生试验所需要的工频磁场；（5）遥控测试模组：在工频磁场的实验环境下，系统应用软件向被测采集终端发出各种遥控指令，遥控测试模组根据采集终端相应端口的电平状况进行相应的电路切换，做出相应的响应，检测电路将检测结果上传至应用软件并进行相应的显示及处理；（6）开关量测试模组：在工频磁场的实验环境及系统软件的控制下，针对采集终端的不同开关量端口发出不同的开关量信号，采集终端相应输出端口的电平状态会发生改变，测试模组会根据其发生的改变做出相应的反应；（7）端口及状态指示模组：试验台的端口输出电路以及端口状态指示电路，提供被测采集终端和试验台的连接通道，并对各种通道在试验时的状态进行指示；（8）虚拟电能表：由外接多功能电能表端口电路和虚拟电能表组成，虚拟电能表由软件电能表和RS485通信电路组成。当试验台采用外接多功能表时，则由外接电能表为试验过程提供源数据，否则由虚拟电能表作为数据源接入采集终端抄表端口。虚拟电能表中的各种电量信息可进行设置；（9）载表台：用于放置壁挂式以及机架式两种类型的采集终端并提供相应的电源端口和功能端口；（10）电源控制模组：为各种功能模块及被测对象提供各种工作电源。

2.2 数据采集终端工频干扰试验仪的功能

（1）由于现在现场运行的电能量遥测采集终端包括挂壁式采集终端和机架式采集终端，试验仪可以支持测试壁挂式采集终端和机架式采集终端两种类型的采集终端；（2）可对采集终端分别进行三个相互垂直方位的工频磁场抗扰度试验；（3）工频磁场强度可设置为400A/m、300A/m、200A/m，其中400A/m是标准要求，其他两个参数可作为参考测试，依此判断被测采集终端的工频磁场抗扰度的能力；（4）在工频磁场环境下可以测试采集终端的数据采集能力及可靠性；（5）在工频磁场环境下可以测试采集终端的数据存储及处理能力；（6）在工频磁场环境下可以测试采集终端的数据上传功能；（7）在工频磁场环境下可以测试采集终端的开关量功能端口功能；（8）在工频磁场环境下可以测试采集终端的遥控功能端口的功能；（9）数据源可外接多功能电能表，也可以选用内置的虚拟电能表（默认）；（10）试验仪的工作电源为AC220V/50Hz。

3 电能量遥测采集终端电磁干扰试验仪的功能

（1）设计有专门的采集终端试验台，用于放置被测采集终端。该试验台可放置壁挂式采集终端和机架式采集终端，试验台上为两种终端按摆放方式的不同在不同位置设计了电源输入端口、电能量采集端口、主站通信端口、遥测信息输入端口、遥控信息输出端口等专门的功能测试端口；（2）工频磁场感应线圈可在水平位置和垂直位置之间进行切换；（3）设计了专用的程控工频磁场发生器，由应用软件控制而产生不同强度的工频磁场，试验过程由软件按试验方案自动换档，无需人工调节；（4）在400A/m的磁场强度下，可长时间处于工作状态，完成测试方案所规定的所有工作；（5）设计了外接多功能电能表端口，用户可根据需求选配不同的电能表。内部设计有虚拟电能表，为采集终端试验提供数据源；（6）在工频磁场的实验环境及系统软件的控制下，在此试验台上可自动完成数据采集、数据处理、参数设置和查询、数据传输、遥测与遥控等功能试验；（7）可根据需要选择试验内容，设置测试方案，整个试验过程自动进行，无需人工干预；（8）试验完成后可以自动生成测试报告。

4 结语

电能量遥测采集终端电磁干扰实验仪使电能量遥测采集终端在运行前的检定变成了现实，为电能量遥测采集终端的现场运维提供了支持，同时也为电能量遥测采集终端以后的升级提供了技术支持。

参考文献

[1] 唐成虹，宋斌，胡国，等.基于IEC 61850标准的新型变电站防误系统[J].电力系统自动化，2009，33（5）.