２０１２年７月 第ｌ５卷第１３期 中国管理信息化 Ｃｈｉｎａ Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎｉｚａｔｉｏｎ Ｊｕ１．，２０１２ Ｖ０１．１５．Ｎｏ．１３ 基于软件架构的回归测试 罗心熠．潘 爽 （锦州石化公司，辽宁锦州１２１００１） ［摘要］当对可靠的系统结构化的时候，除了通过构建的方式来改善系统的可靠性（如容错和多余的机制）外，对于系统的 评估也同样重要．并由此来认可系统的可靠性。现有很多不同的方法来评估系统的可靠性。测试因而成为一种重要的方 式 目前关于软件结构测试的工作表明。应用一致性测试技术产生可信度是可能的，这种可信度是在软件架构中可期望的 行为，指定了架构描述语言。这项工作中，探讨了为了减少重复测试而修改系统的费用，回归测试可以怎样被系统化地应 用在软件架构层面上．评估了进化的系统的回归测试性。考虑了评估“自顶向下”和“自底向上”等进化方法．是否通过简单 修改就能够符合初始的架构．这样的修改是否能够符合进化的架构。将回归测试应用在软件架构层面上将有助于评估和 认定其是否具有更高的可信度 ［关键词］软件架构（ＳＡ）；可靠性系统；回归测试；分析 ｄｏｉ：１０．３９６９／ｊ．ｉｓｓｎ．１６７３—０１９４．２０１２．１３．０３１ ［中图分类号】ＴＰ３ｌｌ５ 【文献标识码］Ａ １ 回归测试背景 ［文章编号】１６７３—０１９４（２０１２）１３－００５５一Ｏ２ 提出，加上对不同行为的识别需求。 本文着重研究如何为Ｐ 选择一种相关的测试用例子集．又 件架构层面上而不是在代码层面上 换句话说．用选择架构化的 首先由于软件总在时刻变化着．软件的不断演化．例如软件 对软件的要求也从未停止过 －软件的每次改变都会引入潜在的 的开发、维护、升级都需要修改一些软件的结构和代码，而人类 叫做回归测试选择问题，描述一种回归测试选择方法．它是在软 风险，这是软件演化的缺陷。其次，人类对软件变化有了一些新 层面测试用例代替选择代码层面的测试用例 的要求．关心软件修改后的功能是否达到预期以及原有的功能 ４基于软件架构的回归测试 是否被损害［１－３］ 基于软件架构的回归测试包含以下两个阶段：（１）基于软件 架构的测试。特别地，应用一种基于软件架构的一致性测试方 针对以上要求．选择使用回归测试来解决。回归测试是一种 验证已变更系统的完整性与正确性的测试技术 ２回归测试的定义及意义 法。（２）基于软件架构的回归测试选择。这个阶段被分解以满足 目的ｌ和目的２ 图１总结了基于软件架构一致性和回归测试所需要的行 ４．１基于软件架构的一致性测试 回归测试是对之前已测试过、经过修改的程序进行重新测 没有发现的错误 回归测试的意义是：（１）保证软件维护时未更改的代码功能 试．以保证该修改没有引入新的错误或者由于更改而发现之前 为。本文主要研究基于软件架构的回归测试 这项工作是基于软件架构一致性测试的一般框架的．目的 是测试已给出的软件架构实施的一致性 这个框架分为５个步骤．如图ｌ中间的部分所示 不会受到影响。（２）保证软件模块区域和持续维护过程与回归测 试的协作关系，使得回归测试成为一个每月、每周、每日的常规 活动。（３）实现软件整个生命周期的测试。 ３回归测试 第０步：它开始于软件架构规范的拓扑学和行为学．这里的 行为通过一种基于机器的形式体系状态来模仿。下面．利用标签 的过渡（ＬＴＳ）来模仿组件的行为 首先简单介绍传统的基于代码的回归测试选择方法的作 用．以便了解软件架构回归测试选择方法的基础。关注于选择性 基于软件架构的回归测试方法（在第四部分提出）。 试的代码中出现新的错误 传统的方法是把它分解为两个阶段 （１）测试软件Ｐ相对于一种指定的测试集Ｔ。（２）当推行了一种 组Ｔ 是正确的可靠性 第１步：提出了一个通过观测得到的方法为了实现一种测 是把无关的行为从这个视角中隐藏起来。标签的过渡（ＬＴＳ）模型 有这样高层的行为／组件是需要测试的 第２步：一种基于架构层面的测试用例（ＡＴＣ）以架构事件的 时候期望发生的架构事件。此定义分解为两个关键词：行为序 列，它代表了所期望的行为和初始事件．它是允许发生的结构化 的回归测试方法．然后再重新采用相同的逻辑步骤来提出一种 试标准，这种标准来源于与测试目的相关视角在软件架构中．而 回归测试的目的在于验证修改的软件并确定不会在先前测 被提取出来，就产生了一种抽象标签的过渡（ＡＬＴＳ），用来说明只 新版本Ｐ 时．对已修改的版本Ｐ 的回归测试提出Ｐ 相对于测试 有序序列被定义了．这种事件是当一个确定的初始事件执行的 在最简单的回归测试方法中．有一种叫做复制所有的测试 Ｔ 中包含Ｔ中的所有在Ｔ中的测试用例。并且Ｐ 运行在Ｔ’上 在 输入。获得一个ＡＴＣｓ充分集合需要得到一个合适的包含了 回归测试选择方法上．ｒＩ’，被选出作为一种跟Ｔ相关的子集，假设 ＡＬＴＳ完整路径的集合＿５＿ 有ｔ∈Ｔ，ｔ包含于Ｔ ．如果它有可能在Ｐ 中生成的结果与在Ｐ中 第３步：自然地，这样的ＡＴＣｓ与可执行的代码层面测试用 通过一种“绘图”方法．它能够将软件层面函数的测试转化为代 不同。对不同回归测试选择方法的实证研究和分析在文献『４］中 例截然不同，因为在软件架构和代码之间的差距 处理这个问题 码层面测试用例 ［收稿日期］２０１２—０５—０６ ＣＨＩＮＡ ＭＡＮＡＧＥＭＥＮＴＩＮＦＯＲＭＡＴＩＯＮＩＺＡＴＩＯＮ｜ｓｓ 企业管理信息化 第４步：最后．代码运行在可识别的 测试用例上 通过分析执行的踪迹来决 定系统在所选择的结构测试中实施得是 否正确．采用结构化的模型作为一种测 试数据库来识别代码用例成功或失败 这样的方法已经得到公认．但是重 复的测试行为对于系统的发展而言无疑 花销太大了．因此需要以更少花销开发 一种基于软件架构的测试方法 本文提 出一种方法来处理系统的发展．重复使 用原始的测试结果来重新测试已修改的 结构并以更少的花销来完成 ４．２目的１：测试对于初始软件架构Ｐ 的 一致性 让假设基于软件架构一致性的测试 已经提出Ｐ符合已给出的软件架构的一 致性．．当Ｐ进化到Ｐ 之后．如何来测试Ｐ 对于相同架构的一致 性．．采用的方法是将基于软件架构测试方法和现存的基于代码 的回归测试方法相融合的。通过一种行为图表，代码层面的回归 测试能够与基于软件层面的一致性测试相融合来选择一个新的 测试套组Ｔ ： 图１ 基于软件回归测试方案流程图 测试传统代码相似的改革中．无论什么时候一个ＡＴＣ在Ｓ”中被 修改的ＬＴＳ软件架构中遍历一次的时候．它需要在Ｓ”中重新测 试 图１（最左边）总结了目的２如何通过不同的行为被意识到． ．ａ：新的软件架构规则。演变的系统Ｓ”被结构化的规则提出 ｂ：测试标准 测试标准（之前应用在Ｓ中）被用在Ｓ”上。 Ａ：产生图表Ｐ，大多数普通的用于代码回归测试的方法是 为了通过图表来结构化地表达Ｐ 在修改之后．Ｐ 也被描述成一 ｃ：比较。架构的规则与识别出的拓扑改变相比较（也就是增 加的／删除的组件或修改的配置）和行为的改变（也就是经过改 变的部件） ｄ：为Ｓ 选择结构化的测试用例。那些来自于软件架构的被 结构的改变影响的ＡＴＣ８被选择在Ｐ， 上重新测试．为了ｓ 的实 施 注意到任何在这步丢弃的ＡＴＣ都可以代表很多被消除的代 码层面的测试用例．因此很大程度上减少了重复测试的花销 ｅ：识别代码层面测试用例。一旦已经识别了需要用在Ｓ”中 的回归测试ＡＴＣｓ．为了Ｓ 需要把架构的测试用例转化到代码层 张图表 在软件架构中．图表也通过组合成分行为的ＬＴＳ模型来 获得．同时在结构中结构化那些成分组织 Ｂ：把ＧＰ和ＧＰ 相比较，在基于回归测试的传统代码中，通 过比较Ｐ和Ｐ 的代码图表，识别代码的改变怎样影响到图表中。 在软件架构 中．这种改变根据在ＬＴＳ中节点和边来识别。 Ｃ：记录覆盖范围，通过测试用例的执行测试历史记录被构 建出来 通过测试用例在Ｐ上执行代码的过程，记录一连串的节 点／电弧 面的测试用例．以便为了Ｐ，，选择ｒｒ，， 这一步类似于在第三步中基 于软件架构的测试 ｆ：测试执行。在Ｔ，，已经被Ｓ”选择之后 需要在 中运行ｒｒ，然 Ｄ：测试用例选择Ｐ 。从测试历史和图表比较中积累的信息 被应用于识别将要在Ｐ 中再次运行的Ｔ中的测试用例。如果在 ｔ∈Ｔ中Ｐ的执行包含了在Ｐ 中修改的节点．那么ｔ需要在Ｐ 中 后评估执行基于软件架构回归测试的结果 这一步跟第四步中 基于软件架构的测试很相似 重新运行。 一旦Ｔ 被选择了．ｔ ∈Ｔ 就在Ｐ 中运行并把结果收集起来． 主要参考文献 然后和一种数据库相比较来确定测试是失败还是成功。与基于 传统代码方法的一种主要的区别是．在基于软件架构回归测试 的数据库是软件结构自己本身 事实上．当ｔ 在Ｐ 中运行的时候， 如果它的执行不允许所期望的情况再次出现，那么测试会失败。 更多情况．代码层面的测试用例总是被形式化的函数和结构化 的需求驱动得很好 ［１］Ｒ Ｊ Ａｌｌｅｎ，Ｒ Ｄｏｕｅｎｃｅ，Ｄ Ｇａｄａｎ．Ｓｐｅｃｉ￣ｉｎｇ ａｎｄ Ａｎａｌｙｚｉｎｇ Ｄｙｎａｍｉｃ Ｓｏｆｔｗａｒｅ Ａｒｃｈｉｔｅｃｔｕｒｅｓ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １９９８ Ｃｏｎｆｅｒｅｎｃｅ Ｏｉｌ Ｆｕｎｄａｍｅｎｔｌａ Ａｐｐｒｏａｃｈｅｓ ｔｏ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ（ＦＡＳＥ’９８），Ｍａｒｃｈ １９９８． 期望从这个方法中得到的好处有两层：（１）作为传统的回归 测试．为Ｐ 减少了测试套组的规模．剪掉了所有在Ｐ 中不需要被 再次应用的那些测试。（２）当发现了一致性错误的时候，能够搜 集关于如何来适应初始架构的信息。 ４Ｉ３目的２：测试进化得到的架构的一致性 ［２］Ｓ Ｂｅｙｄｅｄａ，ａｎｄ Ｖ Ｇｒｕｈｎ．Ｉｎｔｅｇｒａｔｉｎｇ Ｗｈｉｔｅ—ａｎｄ Ｂｌａｃｋ—Ｂｏｘ Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ Ｃｌａｓｓ－Ｌｅｖｅｌ Ｒｅｇｒｅｓｓｉｏｎ Ｔｅｓｔｉｎｇ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ＣＯＭＰＳＡＣ ２００１， ２００１：３５７—３６２． ［３］Ａ Ｂｕｃｃｈｉａｒｏｎｅ，Ｈ Ｍｕｃｃｉｎｉ，Ｐ Ｐｅｌｌｉｃｃｉｏｎｅ，ａｎｄ Ｐ Ｐｉｅｒｉｎｉ．Ｍｏｄｅｌ— Ｃｈｅｃｋｉｎｇ Ｐｌｕｓ Ｔｅｓｔｉｎｇ：Ｆｒｏｍ Ｓｏｆｔｗａｒｅ Ａｒｃｈｉｔｅｃｔｕｒｅ Ａｎａｌｙｓｉｓ ｔｏ Ｃｏｄｅ Ｔｅｓｔｉｎｇ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋ ｏｎ Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ Ｔｅｓｔｉｎｇ Ｍｅｔｈｏｄｏｌｏｇｉｅｓ（ＩＴＭ’ｏ４），Ｏｃｔｏｂｅｒ２００４． 让再次假设基于软件架构一致性测试已经声明了Ｐ的实施 应符合已给出的软件架构。采用的方法是根据比较两者的架构 ［４］ＵＣＩ．Ｔｈｅ Ｃ２ Ｓｔｙｌｅ［ＥＢ／ＯＬ］．ｈｔｔｐ：／／ｗｗｗ．ｉｃｓ．ｕｃｉ．ｅｄｕ／ｐｕｂ／ａｒｃｈ／ｃ２．ｈｔｍ１． 的规范来识别软件结构改变／未改变的位置 结构和行为的改变 ［５］Ｍ Ｄｉａｓ，Ｍ Ｖｉｅｉｒａ，Ｄ Ｒｉｃｈａｒｄｓｏｎ．Ａｎａｌｙｚｉｎｇ Ｓｏｆｔｗａｒｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｗｉｔｈ 都被考虑在内 特别的．对于Ｓ和Ｓ”的ＬＴＳ￥被比较之后的区别 通过两张图表（利用一种“ｄｉｆ”算法）来识别。在一次与基于回归 ｓ６｛ＣＨＩＮＡ ＭＡＮＡＧＥＭＥＮＴ ｌＮＦｏＲＭＡＴｌＯＮｌｚＡＴｌｏＮ Ａｒｇｕｓ－Ｉ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２２ｎｄ Ｉｎｔｅｍａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ（ＩＣＳＥ ２０００），Ｌｉｍｅｒｉｃｋ，Ｉｒｅｌａｎｄ，Ｊｕｎｅ ２０００．
