29、接口定制组件的测试方法

接口定制组件的测试方法

1. 组件化软件开发与定制概述

组件化软件开发（CBSD）旨在通过复用现有组件来降低软件开发成本和时间。与传统软件开发不同，组件是CBSD中系统的构建单元。为了在系统中复用组件，复用者的规范需要与开发者的规范相匹配。若开发者的规范符合复用者的需求，组件可直接复用；但开发者很难提前知晓组件的所有未来复用场景，所以能完全满足新应用的组件较少。为降低开发成本，组件可在适应性修改后复用，复用者通常需要定制组件以满足特定应用需求。

组件定制一般指根据个体规范进行构建、适配或修改。其过程包括：为特定需求修改组件；进行必要更改以使组件在特殊平台上运行；升级特定组件以获得更好性能或更高质量。定制不一定意味着软件完全适应新需求，部分修改即可。CBSD的成功高度依赖开发过程中使用的可复用组件的质量，为使定制组件可复用且可靠，需要新的测试方法，因为测试定制组件与测试传统软件可能有很大不同。

2. 相关研究

近年来，有一些关于组件定制的方法。如有人使用面向方面编程、基于软件架构或生成式编程来定制组件。这些研究从编程到架构等不同层面进行组件定制，并讨论了组件定制的问题，包括组件粒度对定制的影响、定制时间和成本等。还有人提出了定制组件非功能特性的方法。

为确保软件系统质量，定制组件在复用前必须再次测试。有针对组件复用者测试的研究，但测试对象多为未修改的组件。基于黑盒类、白盒类和组件的特定定义，有人提出了不同的定制代码插入方式和测试方法。也有人将定制分为一般化定制、特殊化定制和重构定制三类，并讨论了这些定制活动的影响和相应的测试技术。

基于组件封装和复用的需求，所有组件模型都必须定义组件的接口和实现。接口描述了成功复用组件的信息，实现是可在新应用中复用的计算结构。若组件源代码可用，复用者可修改源代码；否则，只能通过组件接口或可执行代码插桩进行定制。与源代码或可执行代码定制相比，接口定制无需修改组件的内部逻辑和代码，实现简单且成本低。随着EJB、COM +和Web服务技术的出现，大量组件通过网络直接提供服务，这些在线组件通常不提供源代码，接口定制成为组件复用的主要方法。

现有组件定制研究中的定制和测试方法无法处理一些通过接口的修改，如语义和协议定制。本文提出的定制和测试方法与现有研究不同，为便于解决接口定制组件测试中的难题，在组件接口规范模型中定义并添加了额外信息，还提出了基于接口规范模型的定制运算符和测试复用原则。

3. 组件接口规范模型

对于基于组件的软件，接口是唯一的交互点，组件间的交互必须通过接口进行，因此接口规范是组件定制和测试的基础。一个全面的组件接口模型应包括语法规范、语义规范和协议规范。语法规范描述接口方法的名称、参数和返回类型；语义规范指示开发者和复用者之间交互数据的契约，如参数的值范围；协议规范描述组件间交互的行为信息，如组件的交互方式。

现有的接口模型定义语言，如CORBA的IDL、COM的MIDL和Web服务定义语言，只能描述语法规范。缺乏语义规范和协议规范会导致数据模糊以及组件功能和行为描述不准确。为便于组件的定制和测试，对组件接口规范模型进行了扩展。

3.1 组件接口规范的元素和层次结构

提出了一个层次化的组件接口规范模型，扩展模型包含四个部分：
- 语法规范：包括功能描述和非功能描述。
- 语义规范：包含契约信息，可部分代表软件的规范，有助于理解和组合组件。
- 协议规范：标识复合或单个组件及其URL地址。
- 测试规范：定义组件的测试信息，包括测试用例、测试时间和测试评估。

扩展组件接口规范的详细语法如下：

InterfaceSpecification ::= <SyntacticSpecification> [SemanticSpecification] [ProtocolSpecification] [TestingSpecification]
SyntacticSpecification ::= <FunctionalDescription> [NonFunctionalDescription]
SemanticSpecification ::= <Contract>
ProtocolSpecification ::=  (<CompositeComponent>| <SingleComponent>) [ProcessURL]
TestingSpecification ::=   [TestCase][TestingTime] [TestingEvaluation]
FunctionalDescription ::= <FunctionalInformation> <ParameterInformation> [TextDescription]
NonFunctionalDescription ::= [ReliabilityInformation] [AdditionalInformation]
Contract ::=     [Precondition][Invariant][Postcondition]
FunctionalInformation ::=  <FunctionalName><ReturnType>
ParameterInformation ::=  <ParamerterName><ParameterType>
ReliabilityInformation ::=  [Cost][Time][Reputation]
AdditionalInformation ::= [Creator][Version][Domain][Deadline]

3.2 组件接口规范元素之间的关系

组件接口规范元素之间存在三种关系：
1. 层次关系 ：这是两个相邻抽象级别元素之间的关系，如契约是语义规范的低层次元素，功能信息是功能名称的高层次元素，是一对多的关系。
2. 关联关系 ：这是测试规范元素与其他三种规范元素之间的关系，如测试规范与协议规范相关联，是一对多的关系，意味着测试信息基于语法规范、语义规范和协议规范生成。
3. 依赖关系 ：这是语法规范元素与语义规范元素之间的关系，如契约依赖于功能信息，是多对多的关系。

层次关系和依赖关系可用于检查开发者和复用者定义规范时的合理性和有效性，关联关系指示测试信息与其他组件规范之间的映射，是测试复用的基础。

4. 接口规范的定制机制

软件组件在新环境中可以通过多种方式进行定制。需要对组件进行定制，以调整组件规范使其符合复用者的规范。如果没有组件定制的规范，由于缺乏新的测试方法和定制组件的覆盖标准，很难找到系统的解决方案来支持定制组件的验证。

基于上述组件接口规范模型，分析了可能的定制类型，并针对不同的组件接口规范提出了三种定制方法，每种定制方法都定义了一组定制运算符，每个定制运算符代表对组件不同类型接口规范的特定修改。

规范类型	定制运算符	含义
语法规范	COI	Cut Out Interface
语法规范	MMR	Modify Method Return-type
语法规范	MPN	Modify Parameter Name
语法规范	MPT	Modify Parameter Type
语法规范	APN	Add Parameter Number
语法规范	DPN	Decrease Parameter Number
语法规范	MQI	Modify QoS Information
语义规范	SPR	Strengthen PRecondition
语义规范	WPR	Weaken PRecondition
语义规范	SPO	Strengthen POstcondition
语义规范	WPO	Weaken POstcondition
语义规范	SIV	Strengthen InVariant
语义规范	WIV	Weaken InVariant
语义规范	SAC	Stuck-At Contract
协议规范	CTS	Composite To Single
协议规范	MCC	Modify Composite Configuration
协议规范	STC	Single To Composite
协议规范	MSC	Modify Single Configuration

复用者可以根据上述三种定制方法和相关运算符，有规律地定制组件的接口规范以满足应用需求。

5. 接口定制组件的测试方法

通常，同一个组件可能存在两种规范，且它们往往不完全匹配。定制可以使组件适应应用并调和两种规范之间的差异。测试组件时，复用者有两种选择：从头开始测试或定制组件并确保定制不会对软件组件产生不利影响。前者耗时且成本高，后者则面临如何生成测试数据和评估充分性等新挑战。

5.1 接口定制组件的测试过程

为降低测试时间和成本，在测试定制组件时将复用组件开发者的测试信息。测试复用的研究主要集中在测试设计和测试过程的复用。基于前面定义的测试规范元素与其他规范元素之间的关系，提出了接口定制组件的测试方法，其过程如下：

graph LR
    A[Relationship Determination] --> B[Specification Analysis]
    B --> C[Testing Reuse]
    B --> D[Testing Generation]

对于每个定制组件，使用以下步骤复用和生成测试信息：
1. 关系确定 ：获取原始规范与测试信息之间的关系，确定原始规范对应的测试信息。
2. 规范分析 ：分析定制前后规范的差异。
3. 测试复用 ：复用未更改规范的先前测试信息。
4. 测试生成 ：为更改的规范生成新的测试信息。

不同的定制方法在测试组件时存在差异，根据定制运算符定义的修改模式，基于三种规范定制定义了复用原则。

5.2 语法规范定制的测试复用原则

定制运算符	测试复用原则
COI	复用剩余接口的先前测试信息
MMR	复用先前的测试信息
MPN	复用未更改参数的先前测试信息，为更改的参数生成新的测试信息
MPT	复用未更改参数的先前测试信息，根据参数类型为更改的参数生成新的测试信息
APN	复用初始参数的先前测试信息，为添加的参数生成新的测试信息
DPN	复用剩余参数的先前测试信息
MQI	生成新的测试信息

5.3 语义规范定制的测试复用原则

定制运算符	测试复用原则
SPR	根据新的前置条件有选择地复用先前的测试信息
WPR	复用先前的测试信息，根据新的前置条件生成新的测试信息
SPO	根据新的后置条件有选择地复用先前的测试信息
WPO	复用先前的测试信息，根据新的后置条件生成新的测试信息
SIV	根据新的不变式有选择地复用先前的测试信息
WIV	复用先前的测试信息，根据新的不变式生成新的测试信息
SAC	根据契约的值有选择地复用先前的测试信息

5.4 协议规范定制的测试复用原则

定制运算符	测试复用原则
CTS	复用复合组件起始组件的先前测试信息，为单个组件生成新的测试信息
MCC	复用未更改组件的先前测试信息，为替换的组件生成新的测试信息
STC	复用单个组件的先前测试信息，为复合组件生成新的测试信息
MSC	生成新的测试信息

在之前的研究中提出了一种结合基于功能和基于错误的测试数据生成的组件测试方法，可用于上述测试复用原则，也可用于为更改的规范生成新的测试信息。

6. 案例研究

基于Microsoft .NET平台开发了一个Web服务定制和测试的原型工具，并在运行Windows 2003 Server的2.26G Hz Pentium4系统上进行了一些实验。

6.1 实验组件

实验使用了三个测试对象，包括TriTyp、Deal和Permutation。基于原始规范进行了语法和语义规范的定制，使用六个定制运算符定义了定制规范。
|Web Services|Function|Original specification|Customization operators|Customized specification|
| ---- | ---- | ---- | ---- | ---- |
|TriTyp|determining the type of triangles based on the inputs of three sides|int a, int b, int c
0<a<100∧ 0<b<100∧ 0<c<100|DPN
SPR|int a, int b
0<a<50∧0<b<50 ∧0<c<50|
|Deal|transforming the Proper fraction to the sum of Egypt scores|int a, int b
a>0 ∧b>0∧ a SAC|int a, int b, int c\
TRUE| |Permutation|calculating the value of $_{n}^{m}P$|int m, int n\
m>0 ∧n>0|MPN
SIV|int m, int b
m>1 ∧n>1|

使用两种方法为应用了定制运算符的定制组件生成测试数据：再生意味着根据新规范重新生成定制组件的测试数据；复用意味着使用上述测试复用原则生成定制组件的测试数据。

6.2 结果与分析

使用之前提出的方法，每个被测Web服务的有效等价类和无效等价类的测试数据数量均为3。语法和语义规范定制的实验结果如下：

语法定制实验结果
|Web Services|Test data generation method|Condition Coverage Score (%)|Branch Coverage Score (%)|Path Coverage Score (%)|Number of test case|Time of generate test case (ms)|Time of execute test case (ms)|
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|TriTyp|Regeneration|80|92|100|2479|103|37|
|TriTyp|Reuse|81.6|92|100|825|80|19|
|Deal|Regeneration|74.3|88|100|95|62|12|
|Deal|Reuse|76|88|100|58|44|7|
|Permutation|Regeneration|42|22.5|36|78|47|3|
|Permutation|Reuse|42|24|31.3|82|50|4|

语义定制实验结果
|Web Services|Test data generation method|Condition Coverage Score (%)|Branch Coverage Score (%)|Path Coverage Score (%)|Number of test case|Time of generate test case (ms)|Time of execute test case (ms)|
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|TriTyp|Regeneration|83|100|100|3375|126|42|
|TriTyp|Reuse|83|100|100|729|74|16|
|Deal|Regeneration|85.7|85.7|100|49|53|2|
|Deal|Reuse|87|87|100|63|60|3|
|Permutation|Regeneration|37.5|19|12.5|81|59|5|
|Permutation|Reuse|34.4|38.1|31.3|72|57|3|

从实验结果可以看出，在语法和语义定制中，大多数情况下再生方法产生的测试数据比复用方法多，这意味着再生在测试定制组件时花费的时间和成本更多。同时，复用方法产生的测试数据的三种覆盖分数（条件覆盖分数、分支覆盖分数和路径覆盖分数）大多与再生方法产生的测试数据相等，在语义定制测试Permutation时，复用方法的分支覆盖分数和路径覆盖分数高于再生方法。

接口定制组件的测试方法

7. 实验结果可视化分析

为了更直观地展示实验结果，我们将测试用例数量和覆盖分数进行可视化呈现。

7.1 测试用例数量可视化

以下是语法和语义定制中测试用例数量的可视化图表。

图1：语法定制中测试用例数量

图2：语义定制中测试用例数量

从图中可以清晰地看到，无论是语法定制还是语义定制，再生方法生成的测试用例数量大多多于复用方法，这直观地体现了再生方法在测试定制组件时可能会消耗更多的资源。

7.2 覆盖分数可视化

下面是语法和语义定制中测试用例覆盖分数的可视化图表。

图3：语法定制中测试用例覆盖分数

图4：语义定制中测试用例覆盖分数

从图中可以看出，复用方法产生的测试数据的三种覆盖分数（条件覆盖分数、分支覆盖分数和路径覆盖分数）大多与再生方法产生的测试数据相等。在语义定制测试Permutation时，复用方法的分支覆盖分数和路径覆盖分数高于再生方法，这表明复用方法在某些情况下不仅能节省资源，还能取得较好的测试效果。

8. 总结与展望

通过上述研究和实验，我们可以得出以下结论：
- 提出的组件接口规范模型扩展了现有的接口规范，包含了语法、语义、协议和测试规范四个部分，并且明确了各元素之间的关系，为组件定制和测试提供了更全面的基础。
- 基于该模型定义的定制运算符和测试复用原则，能够有规律地定制组件接口规范，并在测试定制组件时复用开发者的测试信息，有效降低了测试时间和成本。
- 实验结果表明，复用方法在大多数情况下能够在保证测试覆盖分数的同时，减少测试用例的生成数量，从而节省测试资源。

未来，我们可以从以下几个方面进一步开展研究：
- 进一步优化测试复用原则，使其能够更好地适应更多复杂的组件定制场景。
- 探索如何将该方法应用到更多类型的组件和软件系统中，扩大其适用范围。
- 研究如何结合人工智能和机器学习技术，自动生成更高效的测试用例，提高测试的准确性和效率。

总之，接口定制组件的测试方法为组件化软件开发中的组件定制和测试提供了一种有效的解决方案，未来的研究将不断完善和拓展该方法，以满足不断发展的软件开发需求。