基于自动机模型的构件集成软件测试要素的提取
开篇：润墨网以专业的文秘视角，为您筛选了一篇基于自动机模型的构件集成软件测试要素的提取范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘要：分析了构件化软件接口、事件、上下文及内容依赖关系在集成测试中的作用，以及提取该四要素的难度；针对构件化软件的自身特点提出了一种有限状态自动机模型，利用该模型实施对四要素的提取，并通过实例验证了该模型的有效性。
关键词：构件化软件；有限状态自动机；测试要素；正则表达式
中图分类号：TP311.5文献标识码：A
文章编号：1001-9081(2007)04-0857-03
0引言
基于构件的软件开发技术着重于重用已有的构件来生成新的系统。然而，由于各个构件不同的实现技术，不同的通信方式，不详尽的规格说明以及源代码的不可见，使得对已有构件的重用、组合变得较为复杂，同时也为构件的集成测试带来了较大的挑战。
构件化软件的显著特性就是通过把能实现一定功能的构件集成起来以完成总体功能和需求，所以集成测试的中心环节是测试构件间交互操作是否正确。构件之间的交互可以通过直接的方式也可以通过间接的方式。直接交互就是通过构件接口实现构件之间的交互，而间接交互则是通过事件序列而产生。不同的上下文对构件的使用和输出是非常有影响的，两个接口的调用顺序不同同样也影响到构件的使用结果。因此，在考虑构件化软件的集成测试时，下面几个因素不可避免地要考虑到：接口，事件，上下文依赖关系和内容依赖关系[1]。接口和事件是测试的基本元素。从构件规范说明中相对容易获得构件接口；识别事件则必须知道激发事件的接口和对应着事件的被调用接口，事件激发或执行的行为表现为集成构件间的交互性，所以只要可以对构件接口间的交互进行建模，事件就不难获取。在缺乏第三方构件源码的情况下，内容依赖关系和上下文依赖关系的提取是比较困难的。而这两个要素在侦测构件集成错误上比接口与事件更加有效。因此，研究如何利用可获取的资源而不依赖于第三方构件源码来提取这两个要素是十分重要的。本文针对构件化软件的自身特点提出了一种有限状态自动机模型，分析和阐述了四要素在自动机模型中的提取与转化。
为了有效地测试系统，分析特定系统中可能发生的错误以及起因是非常重要的。本文将主要讨论构件交互错误。文献[1]将构件交互错误分为构件间错误与互用性错误。互用性错误包含三个级别：系统级互用性错误、程序级互用性错误和规约级互用性错误。我们依据错误的起因和影响将上述两大类错误进行了继承与细化。
1)构件间错误：在构件化软件系统中，即使单个构件已被单独测试过，当把它们集成到一起，仍可能存在潜在的错误。与多个构件相关的错误被称为构件间错误。例如，若干方法相互调用时所需的内存容量大于实际可获取的内存容量，尽管每个方法单独运行可被满足。
2)与底层对象相关的错误：一个构件是在系统特定的环境下同本系统中的其他构件发生交互。在系统环境下，操作系统、虚拟机、解释器和动态库等系统所使用的应用和服务影响着系统的运行。两个构件在无意识的状态下通过这些底层对象发生的交互是一种潜在错误源。这种不兼容的交互是很难被定位的，而且很少在依赖集中提及。
3)程序级互用性错误：当构件是被不同的程序设计语言编写时，由于程序设计语言之间的兼容性问题可能引起错误。例如，VC++与VB对浮点数的处理不相同，由此引起的不兼容问题经常会碰到。
4)构件交互的语义错误：语义错误包括歪曲的行为错误，歪曲的参数错误，歪曲的事件生成错误和歪曲的交互协议错误。歪曲的行为错误是指某个构件请求的服务和对应构件提供的服务不相同。歪曲的参数错误是指某个构件对另一个构件提供的接口参数的错误使用。歪曲的事件生成错误是指对某种事件进行处理的构件在不具备触发该事件的情况下错误地接收到该事件。歪曲的交互协议错误是指对某个构件的请求序列违反了该构件自身定义的协议。语义范畴中的这四类错误可能在程序的实际运行中不会出现错误，但是系统的功能逻辑却会有较大偏差。
通过上述分析可以看出，产生这些错误所涉及的因素主要是接口、执行的事件及相应的依赖关系。
接口和事件接口是构件与其环境交互的门户。事件的触发是构件执行动作的前提。它们是构件集成测试的基本要素。
依赖关系虽然构件是单独开发的，但并不意味着它没有外部依赖。一个对外界表现独立的构件，它只提供服务而并不需要外界提供服务或资源，也就是说它并不被外部环境所影响。然而，在构件化软件系统中很少有构件运行于这样的条件下。事实上，一定的依赖是必需的和所期望的。构件化软件在不同的情况下向构件请求相应的服务，再根据服务执行的结果决定需要执行的动作。宏观上的这种控制流依赖关系在微观上则表现为事件之间的上下文依赖关系。即对于某个执行路径，存在对事件e1的触发会导致直接或间接触发事件e2。构件接口的一次调用相当于是执行一个函数的调用。当声明在接口I1中的一个函数与声明在另一个接口I2中的另一个函数间有某些数据依赖关系，则显示两接口I1和I2间有内容依赖关系。上下文依赖关系包含了接口和事件中更复杂的关系，反映了构件之间的协作关系，因此测试上下文依赖关系适合于识别由不同构件间不恰当的交互引起的错误。内容依赖关系反映了接口之间存在的数据依赖关系，它可以为侦测构件交互中的错误提供有价值的附加信息。
从构件规范说明中相对容易可以获得构件接口信息；通过对构件接口间的交互进行建模，事件的获取也并不困难；然而如何提取系统中的内容依赖关系和上下文依赖关系并将其有效地用于实际的测试工作是本文研究的重点。本文首先描述一种构件集成自动机模型，它涵盖了上述的四要素；然后重点介绍了内容依赖关系和上下文依赖关系在此自动机模型中的提取与转化。
2基于有限状态机的测试要素提取
2.1构件集成自动机模型
经典的自动机理论[2]最基本的两个概念是事件和状态。构成自动机的事件和状态常对应于真实物理系统本身特点定义的事件和状态,可用于表示系统中部件交互的行为。本文中的事件主要映射为构件或粘贴代码执行某项任务所返回的结果；而对事件的响应则视为一个状态。一个事件只能引发一个响应状态，多个不同的事件可能导致同一个响应状态发生。基于上述事件和状态的定义，本文的构件集成自动机模型定义为：Sys=。
2.2测试要素的提取与转化
上节建立的自动机模型涵盖了与构件交互相关的接口、事件和上下文依赖关系，内容依赖关系这四要素。接口的调用可从状态序列中导出，而事件则被抽象成为了自动机模型的有穷输入符号集合的元素。上下文依赖关系表现的是事件间的关联关系，它贯穿于系统的计算。自动机模型描述的是系统的控制流，每一条控制流反映了系统的一个功能逻辑。构成自动机模型的正则表达式基本式的集合双射于系统需求中功能逻辑的集合。对应于每个正则表达式基本式的计算是构件集合在相应的上下文中呈现出的不同行为。计算中的字符序列t0t1…覆盖了系统中的上下文依赖序列。在不同的计算中同时包含的字符子序列即为上下文依赖序列，序列中的事件之间存在上下文依赖关系。
2.3实例描述
在信息管理系统中，人员管理是不可或缺的一部分。本节结合“添加员工信息”子功能实例来阐述测试要素如何在自动机模型中进行提取。图1是“添加员工信息”的时序图，其中frmMain和frmNewEmployee是用户和第三方构件的接口，构件EmployeeInfo，OperateDB和Validation为第三方构件，它们的源代码不可见。
首先需要为这个子功能建立起自动机模型。在2.1节我们将自动机模型中的事件与状态分别对应于构件或粘贴代码执行某项任务所返回的结果与对该结果的一个响应。参与者Admin首先发出新增职工信息的事件给frmMain，frmMain通过调用方法AddEmployee()来响应这个事件，系统的状态发生变化，由初始状态进入某一状态。在AddEmployee()响应这个事件后，会产生创建新增窗口事件并发送给frmNewEmployee，Create()方法响应这个事件，系统的状态又发生改变。随着事件的发送与产生，系统的状态也在不断改变。根据这种对应方法，由图1可以得到该子功能的自动机状态图，如图2。
本例所触发的事件和接口的调用在图2中很清晰地呈现了出来；上下文依赖序列在正则表达式R同样显式地给出。计算是状态与事件的组合序列，从一个状态出发进入某一状态的状态与事件序列可能包含在多个计算中。在这些计算中包含的共同的事件子序列便对应着上下文关系。计算代表的构件行为语言对应于某个正则表达式基本式。在R中，(e1e2e3e4e5)是四个基本正则表达式中都存在的事件调用序列；(e6,e7)是数据库查询通过后需要调用的事件序列；(e8,e9)是对象校验合法后需要调用的事件序列。R中的每个基本正则表达式对应的可被接受的计算中的字符序列分别覆盖了这些序列中的一个或多个。
3结语
有限状态自动机模型很好地将构件系统的功能逻辑与构件行为紧密地结合起来，不仅为测试人员研究四要素提供了有力支持，而且使得测试人员可以有效地利用四要素来研究构件化系统的行为。目前的工作是建立在理论基础之上的，下一步的工作将研究如何为构件化软件系统自动建立起自动机模型，在实际的测试工作中发挥它的效用。
本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。