基于软件架构的回归测试

［摘 要］ 当对可靠的系统结构化的时候，除了通过构建的方式来改善系统的可靠性（如容错和多余的机制）外，对于系统的评估也同样重要，并由此来认可系统的可靠性。现有很多不同的方法来评估系统的可靠性，测试因而成为一种重要的方式。目前关于软件结构测试的工作表明，应用一致性测试技术产生可信度是可能的，这种可信度是在软件架构中可期望的行为，指定了架构描述语言。这项工作中，探讨了为了减少重复测试而修改系统的费用，回归测试可以怎样被系统化地应用在软件架构层面上，评估了进化的系统的回归测试性。考虑了评估“自顶向下”和“自底向上”等进化方法，是否通过简单修改就能够符合初始的架构，这样的修改是否能够符合进化的架构。将回归测试应用在软件架构层面上将有助于评估和认定其是否具有更高的可信度。

［关键词］ 软件架构（SA）； 可靠性系统； 回归测试； 分析

doi : 10 . 3969 / j . issn . 1673 - 0194 . 2012 . 13. 031

［中图分类号］ TP311.5 ［文献标识码］ A ［文章编号］ 1673 - 0194（2012）13- 0055- 02

１ 回归测试背景

首先由于软件总在时刻变化着，软件的不断演化，例如软件的开发、维护、升级都需要修改一些软件的结构和代码，而人类对软件的要求也从未停止过。软件的每次改变都会引入潜在的风险，这是软件演化的缺陷。其次，人类对软件变化有了一些新的要求，关心软件修改后的功能是否达到预期以及原有的功能是否被损害［１－３］。

针对以上要求，选择使用回归测试来解决。回归测试是一种验证已变更系统的完整性与正确性的测试技术。

２ 回归测试的定义及意义

回归测试是对之前已测试过、经过修改的程序进行重新测试，以保证该修改没有引入新的错误或者由于更改而发现之前没有发现的错误。

回归测试的意义是：（１） 保证软件维护时未更改的代码功能不会受到影响。（２） 保证软件模块区域和持续维护过程与回归测试的协作关系，使得回归测试成为一个每月、每周、每日的常规活动。（３） 实现软件整个生命周期的测试。

３ 回归测试

首先简单介绍传统的基于代码的回归测试选择方法的作用，以便了解软件架构回归测试选择方法的基础。关注于选择性的回归测试方法，然后再重新采用相同的逻辑步骤来提出一种基于软件架构的回归测试方法（在第四部分提出）。

回归测试的目的在于验证修改的软件并确定不会在先前测试的代码中出现新的错误。传统的方法是把它分解为两个阶段。（１） 测试软件Ｐ相对于一种指定的测试集Ｔ。（２） 当推行了一种新版本Ｐ′时，对已修改的版本Ｐ′的回归测试提出Ｐ′相对于测试组Ｔ′是正确的可靠性。

在最简单的回归测试方法中，有一种叫做复制所有的测试。Ｔ′中包含Ｔ中的所有在Ｔ中的测试用例，并且Ｐ′ 运行在Ｔ′上。在回归测试选择方法上，Ｔ′被选出作为一种跟Ｔ相关的子集，假设有ｔ∈Ｔ，ｔ包含于Ｔ′，如果它有可能在Ｐ′中生成的结果与在Ｐ中不同。对不同回归测试选择方法的实证研究和分析在文献［４］中提出，加上对不同行为的识别需求。

本文着重研究如何为Ｐ′选择一种相关的测试用例子集，又叫做回归测试选择问题，描述一种回归测试选择方法，它是在软件架构层面上而不是在代码层面上。换句话说，用选择架构化的层面测试用例代替选择代码层面的测试用例。

４ 基于软件架构的回归测试

基于软件架构的回归测试包含以下两个阶段：（１） 基于软件架构的测试。特别地，应用一种基于软件架构的一致性测试方法。（２） 基于软件架构的回归测试选择。这个阶段被分解以满足目的１和目的２。

图１总结了基于软件架构一致性和回归测试所需要的行为。本文主要研究基于软件架构的回归测试。

４．１ 基于软件架构的一致性测试

这项工作是基于软件架构一致性测试的一般框架的，目的是测试已给出的软件架构实施的一致性。

这个框架分为5个步骤，如图１中间的部分所示。

第０步：它开始于软件架构规范的拓扑学和行为学，这里的行为通过一种基于机器的形式体系状态来模仿。下面，利用标签的过渡（ＬＴＳ）来模仿组件的行为。

第１步：提出了一个通过观测得到的方法为了实现一种测试标准，这种标准来源于与测试目的相关视角在软件架构中，而是把无关的行为从这个视角中隐藏起来。标签的过渡（ＬＴＳ）模型被提取出来，就产生了一种抽象标签的过渡（ＡＬＴＳ），用来说明只有这样高层的行为／组件是需要测试的。

第２步：一种基于架构层面的测试用例（ＡＴＣ）以架构事件的有序序列被定义了，这种事件是当一个确定的初始事件执行的时候期望发生的架构事件。此定义分解为两个关键词：行为序列，它代表了所期望的行为和初始事件，它是允许发生的结构化输入。获得一个ＡＴＣｓ充分集合需要得到一个合适的包含了ＡＬＴＳ完整路径的集合［５］。

第３步：自然地，这样的ＡＴＣｓ与可执行的代码层面测试用例截然不同，因为在软件架构和代码之间的差距。处理这个问题通过一种“绘图”方法，它能够将软件层面函数的测试转化为代码层面测试用例。

第４步：最后，代码运行在可识别的测试用例上。通过分析执行的踪迹来决定系统在所选择的结构测试中实施得是否正确，采用结构化的模型作为一种测试数据库来识别代码用例成功或失败。

这样的方法已经得到公认，但是重复的测试行为对于系统的发展而言无疑花销太大了，因此需要以更少花销开发一种基于软件架构的测试方法。本文提出一种方法来处理系统的发展，重复使用原始的测试结果来重新测试已修改的结构并以更少的花销来完成。

４．２ 目的１：测试对于初始软件架构Ｐ′的一致性

让假设基于软件架构一致性的测试已经提出Ｐ符合已给出的软件架构的一致性。当Ｐ进化到Ｐ′之后，如何来测试Ｐ′对于相同架构的一致性。采用的方法是将基于软件架构测试方法和现存的基于代码的回归测试方法相融合的。通过一种行为图表，代码层面的回归测试能够与基于软件层面的一致性测试相融合来选择一个新的测试套组Ｔ′：

Ａ： 产生图表Ｐ，大多数普通的用于代码回归测试的方法是为了通过图表来结构化地表达Ｐ。在修改之后，Ｐ′也被描述成一张图表。在软件架构中，图表也通过组合成分行为的ＬＴＳ模型来获得，同时在结构中结构化那些成分组织。

Ｂ：把ＧＰ和ＧＰ′相比较，在基于回归测试的传统代码中，通过比较Ｐ和Ｐ′的代码图表，识别代码的改变怎样影响到图表中。在软件架构中，这种改变根据在ＬＴＳ中节点和边来识别。

Ｃ：记录覆盖范围，通过测试用例的执行测试历史记录被构建出来。通过测试用例在Ｐ上执行代码的过程，记录一连串的节点／电弧。

Ｄ：测试用例选择Ｐ′。从测试历史和图表比较中积累的信息被应用于识别将要在Ｐ′中再次运行的Ｔ中的测试用例。如果在ｔ∈Ｔ中Ｐ的执行包含了在Ｐ′中修改的节点，那么ｔ需要在Ｐ′中重新运行。

一旦Ｔ′被选择了，ｔ′∈Ｔ′就在Ｐ′中运行并把结果收集起来，然后和一种数据库相比较来确定测试是失败还是成功。与基于传统代码方法的一种主要的区别是，在基于软件架构回归测试的数据库是软件结构自己本身。事实上，当ｔ′在Ｐ′中运行的时候，如果它的执行不允许所期望的情况再次出现，那么测试会失败。更多情况，代码层面的测试用例总是被形式化的函数和结构化的需求驱动得很好。

期望从这个方法中得到的好处有两层：（１） 作为传统的回归测试，为Ｐ′减少了测试套组的规模，剪掉了所有在Ｐ′中不需要被再次应用的那些测试。（２） 当发现了一致性错误的时候，能够搜集关于如何来适应初始架构的信息。

４．３ 目的２：测试进化得到的架构的一致性

让再次假设基于软件架构一致性测试已经声明了Ｐ的实施应符合已给出的软件架构。采用的方法是根据比较两者的架构的规范来识别软件结构改变／未改变的位置。结构和行为的改变都被考虑在内。特别的，对于Ｓ和Ｓ″的ＬＴＳｓ被比较之后的区别通过两张图表（利用一种“ｄｉｆｆ”算法）来识别。在一次与基于回归测试传统代码相似的改革中，无论什么时候一个ＡＴＣ在Ｓ″中被修改的ＬＴＳ软件架构中遍历一次的时候，它需要在Ｓ″中重新测试。图１（最左边）总结了目的２如何通过不同的行为被意识到。

ａ： 新的软件架构规则。演变的系统Ｓ″被结构化的规则提出。

ｂ： 测试标准。测试标准（之前应用在Ｓ中）被用在Ｓ″上。

ｃ： 比较。架构的规则与识别出的拓扑改变相比较（也就是增加的／删除的组件或修改的配置）和行为的改变（也就是经过改变的部件）

ｄ：为Ｓ″选择结构化的测试用例。那些来自于软件架构的被结构的改变影响的ＡＴＣｓ被选择在Ｐ″上重新测试，为了Ｓ″的实施。注意到任何在这步丢弃的ＡＴＣ都可以代表很多被消除的代码层面的测试用例，因此很大程度上减少了重复测试的花销。

ｅ： 识别代码层面测试用例。一旦已经识别了需要用在Ｓ″中的回归测试ＡＴＣｓ，为了Ｓ″需要把架构的测试用例转化到代码层面的测试用例，以便为了Ｐ″选择Ｔ″。这一步类似于在第三步中基于软件架构的测试。

ｆ： 测试执行。在Ｔ″已经被Ｓ″选择之后，需要在Ｐ″中运行Ｔ″然后评估执行基于软件架构回归测试的结果。这一步跟第四步中基于软件架构的测试很相似。