基于容错的系统构建与测试

理论计算机科学电子笔记168（2007）77-90www.elsevier.com/locate/entcs构建基于容错的系统：从需求到测试Antonio Bucchiarone1信息科学技术研究所56100 Pisa，Italy antonio.isti.cnr.it亨利·穆奇尼和帕特里齐奥·佩利乔内拉奎拉大学{muccini，pellicci}@ di.univaq.it摘要容错是避免服务在出现故障时失效的最重要手段之一，以保证它们不会中断服务的提供。相反，软件测试是主要的故障消除技术之一，实现的目的是在软件开发过程中检测和消除软件故障，以便它们不会出现在最终产品中。本文展示了如何容错和测试可以用来验证基于组件的系统。容错要求指导容错体系结构的构建，该容错体系结构根据要求进行连续验证并提交测试。该理论已应用于一个采矿控制系统的运行实例。保留字：容错，基于容错的软件系统，软件体系结构，测试。1引言当设计复杂和关键的基于组件的软件系统（CBS）时（想想航空航天、交通、通信、能源和医疗保健系统），拒绝服务可能会产生经济后果，也可能危及人类生命。故障预防、容错、故障排除和故障预测是过去50年来为实现可靠性的各种属性而开发的四种主要手段[4]。故障预防和容错的目的是防止故障的引入或避免故障发生时的服务故障。相反，故障排除和故障预测意味着减少故障的数量，1IMT研究生院，Via San Micheletto，3 - 55100 Lucca，意大利1571-0661 © 2007 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2006.11.00478A. Bucchiarone等人理论计算机科学电子笔记168（2007）77故障的严重性，并估计目前和未来的故障发生率和后果如[10]中所讨论的，故障预防机制可能无法防止/消除所有故障的发生，而容错是实现可靠性要求的最有前途的机制。容错在存在活动故障的情况下保持正确的服务的交付，并且通常通过错误检测和随后的系统重新制定来实现。最近，一些研究已经证明了在整个系统生命周期中需要容错支持[24，9]，特别是在架构级别[5]。一些同事已经提出了他们的解决方案，通过在软件体系结构和组件级别的异常处理来实现容错（例如，[24、17、8]）。然而，仅依靠容错技术并不足以完全保证关键CBS的容错要求：事实上，意外故障或恶意安全攻击并不总是可以避免或容忍的[2]。我们的建议建议，以补充容错与故障排除技术，以减少所有这些意想不到的故障的数量和严重性。 作为软件测试的主要故障排除技术之一，我们引入了一个测试策略来评估，从而确认或改善，系统在运行时的可靠性本文的主要目标是提出一个全面的方法，根据容错需求的去验证和CBS系统。该方法从需求分析开始，以确定关键服务（在故障或攻击期间需要维护的服务）。容错决策和容错组件的软件体系结构（CBSA）模型的实现，以达到容错的要求。根据[19]中介绍的理想化容错组件模型，系统组件的正常和异常行为被指定。正常响应是指组件提供正常服务的情况，异常响应对应于组件或整个体系结构中检测到的错误。最后，从CBSA规范中提取测试用例规范，以验证实现是否符合容错要求。在正常执行期间，测试方法根据体系结构规范验证CBS是否符合正常需求。在错误执行期间，测试方法验证当故障出现时系统是否以及在多大程度第2节介绍了与该主题相关的工作第3节介绍了构建容错的基于组件的软件系统的主要活动，而细节和我们的建议应用于采矿控制案例研究在第3节中说明。四、 第5节总结了本文，并概述了未来的工作方向。2相关工作一些同事已经提出了他们的解决方案，以纳入故障tolerarnceduriningarchitecturldesign的问题。IssarnyandBanatrein[17]anddCastorFilhoet.在[11]中分享了使用软件体系结构规范作为处理异常处理的主要点[17]作者们，A. Bucchiarone等人理论计算机科学电子笔记168（2007）7779在体系结构级别对异常的定义进行把关。他们的模型考虑了在组件和连接器中实现的异常处理，以及架构（配置）级别的异常处理在[11]中，作者提出了一个关于Aereal的初步工作，这是一个框架，用于扩展具有异常信息的架构描述，定义异常如 何 在 架 构 元 素 之 间 传 播 。 其 他 方 法 （ 例 如 ， Rubiraet.[24][25][26][27][28]][29][29][29]][29][29]相反，在容错分布式系统的整个开发过程中纳入了异常行为。其他方法已经分析了如何容错CBS可以提交测试。[8]中提出的MDCE+方法将软件开发阶段中异常活动的识别、设计、实现和测试系统化。Sinha和Harrold [25]提出了一种以白盒方式测试系统异常活动的方法。这只适用于单元测试，并要求测试组件的源代码可用。M.在他的Ph.D.论文[10]确定了容错和可靠性之间的关系，但它没有提供任何测试技术来确认实现符合容错要求。不同于相关的工作，本文描述了容错和测试如何共同有助于架构一个可靠的基于组件的系统。第3章容错CBS架构：概述在我们看来，为了架构和验证容错系统，必须执行三个主要活动：• 在活动a1中，引出了需求。规定了容错要求，以便在系统损坏时确定适当的服务水平。选择故障场景（基于风险和故障的评估），以证明系统在故障情况下应如何运行。用例被指定以突出功能需求，并被扩展以指定关键服务。• 在活动a2中，已识别的需求指导选择合适的容错软件架构。与传统的软件体系结构模型不同，该规范必须提供CBSA在正常和异常情况下的行为以及如何容忍故障模型检查技术可以用来证明CBSA符合容错要求。• 在活动a3中，测试用于通过容错CBSA规范验证系统实现是否符合容错要求。测试规范从CBSA规范中提取，然后运行CBS实现以验证需求实现。80A. Bucchiarone等人理论计算机科学电子笔记168（2007）774构建容错CBS：细节与应用在本节中，我们将详细介绍已识别的活动，并将其应用于一个运行示例，同时采用基于模型的符号作为指定方法。考虑的运行示例是采矿控制系统案例研究[24]，这是一个用于采矿环境的简化系统，用于处理从矿井中提取的矿物（产生水并在空气中释放甲烷气体该系统由三个主要子系统组成：泵控制，空气提取器控制和矿物提取器控制。在下文中，我们解释并将该方法应用于抽气器控制子系统，以便更好地解释下文中详述的理论方面。4.1活动a1：容错需求识别我们从识别两类需求开始：主要需求和辅助需求。主要要求是必须始终满足的要求，而辅助要求是在降级运行模式下可以搁置的要求。在存在故障的情况下，可以以降级的方式提供辅助要求活动a1的下一步是用例图的实现。 从主要需求和辅助需求中，我们可以定义两种用例，N UC是用于描述正常功能的用例，而exc UC用于描述特殊的功能。当识别出正常和异常用例时，就可以实施适当的方法来容忍可能影响关键服务的故障。 如果在软件过程的早期发现故障，则可以提高整体系统的鲁棒性，并且可以在整个软件生产过程中识别容错责任，并在正确的抽象级别上分配。根据理想化的组件模型[19，24]，必须指定正常和异常行为，并且必须处理异常行为。当异常发生时，扩展用例会被执行以处理异常。对于每个扩展用例，Cockburn的用例模板会提供额外的文档，以明确定义异常情况、症状和恢复措施。然后可以实现异常功能，以描述故障如何以及何时发生，以及它们如何与事件的正常流程4.1.1活动a1在确定了系统的要求之后，它们被组织成主设备和辅助设备。抽气器控制子系统的要求是：REQ 1：部件必须能够从矿井中抽出空气REQ 2：如果甲烷水平变高，则必须打开抽取空气的泵;A. Bucchiarone等人理论计算机科学电子笔记168（2007）7781REQ 3：当抽气过程开启时，如果甲烷水平变得可接受，则必须将其切换为关闭;REQ4：必须监测抽气过程。REQ1、REQ2和REQ4要求被认为是主要要求，而REQ3是辅助要求。exc_SwitchAirExtractorOnexc_AirExtractorFailure<<延伸>><<延伸>><<延伸>>N_抽气exc_SwitchAirExtractorOff气流甲烷低抽气器甲烷高Fig. 1. 抽气器控制子系统用例图活动a1的下一步是用例图的实现。根据辅助需求和主要需求，我们可以定义两种用例：用于描述正常功能的NUC和用于描述异常功能的exc UC。图1显示了该案例研究的用例图。特别是，N ExtractAir用例描述了矿井内空气抽取的操作序列，并且AirFlow、AirExtractor、MethaneHigh和MethaneFlow参与者参与了此功能。4.2活动a2：容错体系结构规范软件体系结构已被广泛接受为一种非常适合的工具，以实现更好的软件质量，同时减少生产的时间和成本。特别是，软件体系结构规范代表了开发生命周期中第一个完整的系统描述。它提供了组件及其交互（连接器）的高级行为抽象，以及系统静态结构的描述典型的SA规范仅对系统的正常行为进行建模，而忽略异常行为。因此，系统可能由于某些故障而以意想不到的方式失败。在关键系统容错要求的背景82A. Bucchiarone等人理论计算机科学电子笔记168（2007）77错误恢复正常活动服务请求正常反应界面设计失败案例异常活动服务请求正常反应本地例外情况界面设计失败案例图二. 理想组件有必要在软件体系结构级引入容错信息按照理想化的容错组件模型[19，24]，当在软件架构级别处理容错时，理想的组件实现两个不同的部分：正常和异常活动（见图2）。 正常部分实现组件当组件的正常行为引发异常（称为局部异常）时，将自动调用其异常处理部分。如果异常被成功处理，组件将恢复其正常行为，否则将发出外部异常信号。当组件意识到无法提供服务时，外部异常会被通知给封闭上下文。有两种不同的外部异常：由于处理有效请求失败而导致的失败异常和由于无效服务请求而导致的接口异常根据理想化的容错组件模型，我们提出的建模语言包含了容错体系结构的结构和行为规范。结构零件描述了零部件和连接件如何由正常零件和例外零件组成，以及它们之间的关系。相反，行为部分指定了组件和连接器如何根据理想化组件模型施加的规则进行交互。作为建模工具，我们使用UML2.0。事实上，尽管在过去的几年里，SA社区已经观察到用于严格和正式SA建模和分析的架构描述语言（ADL）的激增，但行业仍然倾向于基于模型的（半正式）符号。特别是，随着UML作为建模软件系统的事实标准的引入及其在工业环境中的广泛采用，已经提出了许多扩展和概要[20，16]）。关注于结构部分，我们使用UML2.0组件图，定义了一个用于容错的概要（图3显示了一个原型化的组件图，A. Bucchiarone等人理论计算机科学电子笔记168（2007）7783联系我们罗恩图三.带容错信息的根据配置文件创建的内存）。 根据我们的概要，SA组件是一个原型化的UML组件（SAComponent）。 SA组件包含 布尔标记HasException，如果组件的描述为 容错行为，否则为false。SA组件甚至专用于构造型NormalComponent和ExceptionalComponent分别描述正常和异常行为。组件可以有端口来管理与其他组件和连接器的通信。端口还用于为信号异常的通信端口建模然后，我们有普通端口和由原型ICPorts专门化的端口，用于建模异常通信。最后，UML组件接口用于异常从正常部分传播到特殊部分，特殊部分使用立体类型HandlerInterface和RaiserInterface分别表示处理程序和引发程序。由于我们对系统的可靠性感兴趣，我们还引入了布尔标记IsCritical，如果组件是“关键的”，则该标记为true。如果一个组件实现了至少一个“关键服务”，那么它就是关键的在行为方面，我们通过UML状态图描述组件和连接器的行为。 这个模型实际上是直观的，它代表了描述单个组件行为的简单方法。异常行为必须考虑异常信号和异常管理，显示恢复措施，使系统回到无错误状态。在组件无法管理的情况下，异常行为必须显示异常如何转发到封闭上下文。需要对UML2.0状态图符号进行扩展，以便明确地对组件如何通信进行建模。转换上的标签唯一标识架构通信通道。通信允许的操作和一个问号“？"，分别对于每个具有异常部分的组件，我们有两个状态机来描述正常和异常行为。作为至少一个退出转换的目标的状态机的状态表示<>E_SwitchAirExtractorOff（关闭空气提取器）<<用户界面>><<提升器E_AirExtra界面>>ctoFailure<>特殊组件>>抽气器控制界面>><>控制站<><><><><<正常组件>>抽气器控制<<代表>><<代表>>抽油机控制<<代表>><>服务器接口抽气器OnirExtracto{IsCritical=false}Raiser接口>>{HasException=false}<> I_SwitchAirE抽气提升器接口>>{IsCritical=false}I_SwitchAir{HasException=false}<><>抽气器故障I_抽气器故障{IsCritical=false}{HasException=true}{HasException=false}{IsCritical=true}<>泵控制{IsCritical=false}{HasException=false}<>矿物提取器控制{IsCritical=false}{IsCritical=false}{HasException=false}{HasException=false}<>操作员界面{HasException=false}<>84A. Bucchiarone等人理论计算机科学电子笔记168（2007）77信号异常（从正常部分到异常部分的信号异常）被称为异常状态，并且用“exc“前缀表示。与正常/异常组件相关联的正常和异常状态机的示例可以在图4中找到。当SA被建模时，它可以根据其需求进行验证。 我们已经开发了一个用于验证SA的工具，称为CHARMY，我们的想法是扩展CHARMY来验证容错SA。CHARMY[1，15]是一个框架，旨在帮助软件架构师设计软件架构，并根据功能需求对其进行验证。状态机和场景是指定软件架构及其行为属性的源符号模型检验技术用于检验软件体系结构与功能需求之间的一致性。模型检查器SPIN [14]是CHARMY中的验证引擎;一个Prmelasp i ciapicinn和一个BuuchiAutomat a[7]，分别对软件结构和需求进行建模，都是从源符号中导出的SPIN接收这些指定的输入并执行模型检查。软件过程与框架相关联，以帮助识别和细化架构模型。最后，CHARMY是工具支持的。它提供了一个图形用户界面，有助于指定软件架构和自动化的方法。遵循CHARMY的思想，在活动a1中确定的容错场景用体系结构级别的属性序列图（PSC）[23，3]（用于指定属性的UML 2.0序列图子集的扩展）来表示，并且具体地说，它是一种面向对象的设计。这些结构模型有助于Promela原型的生成。SPIN模型检查器用于验证Promela代码（体系结构规范），以便对Bu？chiautom at a（reequirem ents）进行管理。下面列出了使当前模型检查技术适用于容错架构的主要• B-hiauageneration：如果通过CHARMY工具评估的所有公式不包括容错场景，则我们可以使用CHARMY中使用的相同规范语言;• Promela代码生成：由于容错体系结构规范引入了一些CHARMY中不存在的概念，因此我们必须更改翻译算法;• 使用SPIN的验证过程：我们希望使用与C harmy中使用的完全相同的验证和验证SPIN功能。4.2.1活动a2图3显示了采矿控制系统的SA两个是主要组件：操作员界面组件（代表操作员用户界面）和控制站（分为三个子组件：泵控制、空气提取器控制和矿物提取器控制）。泵控制器负责监控水位，抽气器控制器控制甲烷水平，A. Bucchiarone等人理论计算机科学电子笔记168（2007）7785最后，矿物开采由矿物开采控制部监控。见图4。AirExtractorControl组件行为图4显示了AirExtractorControl组件的正常行为，而图5显示了同一组件的异常行为。该部件的正常行为与从矿井中抽取空气有关。当甲烷水平高时（甲烷高==开），抽气器打开（！开关打开），当它们下降到可接受的水平时，抽气器将开关关闭（！switchO键）。我们可以有一些异常行为;例如，当没有检测到空气流量（空气流量==o）时，抽气器打开。这种情况被识别为抽气器故障。这个异常的处理是引发一个异常（！I exc AirExtractorFailure），以管理异常（！手动排除抽气器-故障EA），通过ExceptionalAirExtractor控制组件，并关闭抽气器（！switchO键）。图五. ExceptionalAirExtractorControl组件行为86A. Bucchiarone等人理论计算机科学电子笔记168（2007）774.3活动a3：容错测试根据[13]，基于模型的测试生成器接受被测软件的模型作为主要输入，以及一组指导测试用例选择的测试生成指令。它输出一个测试规范，其中包括测试人员应该在系统中引入的一组刺激以及预期的响应。当处理基于模型的软件架构测试时，被测软件的模型是架构模型本身（充当预言机），而测试生成指令可以是架构级别的序列图，描述测试目的的感兴趣的类。在基于模型的测试中，当处理基于容错架构的架构规范的测试时，需要两个主要活动：测试选择（从SA规范中选择架构级测试用例用于容错测试目的）和测试执行（测试用例在系统实现上运行）。• 活动a3.1：测试选择当从规范转移到容错系统的实现时，我们希望测试系统实现是否符合选定的架构。为此，我们必须经历一个测试选择阶段。在体系结构级别的测试选择包括识别在系统实现上运行的合适的抽象测试用例[22]。 适用性 由测试用例贡献给出，以根据测试标准发现尽可能多的故障[6]。容错软件体系结构本身代表了实际执行需要遵守的测试预言。抽象的测试用例可以细化为可执行的测试用例。在我们的上下文中，测试标准包括识别所有那些覆盖故障情况的测试用例然后，我们要测试当故障发生时，系统实现的行为是否符合容错要求，正如在容错软件架构规范中实现的那样。与更传统的基于规范的测试方法一样，测试用例被视为覆盖从基于状态机的规范产生的行为图的路径（例如，[18]）。它是通过适当地覆盖系统的状态机模型而产生的。为了识别架构级测试用例，我们从结构和行为SA规范开始：从结构模型中，我们保留了哪些服务被认为是关键的信息，以及哪些关键或例外组件实现了这样的服务。从关键和异常组件的行为模型中，我们保留了关于系统实现在运行时应该如何工作的信息。根据以下伪算法选择测试用例(i) 初始异常状态（IES）的选择：给定组件状态机，选择标有“exc“前缀的状态。这些状态表示当异常被发送到异常部分时所达到的那些状态。IES表示正常和异常系统行为之间的接口，A. Bucchiarone等人理论计算机科学电子笔记168（2007）7787在第4.2节中已经解释过了;见图6。抽气器控制组件(ii) 架构测试用例（ATC）选择：测试用例被定义为一条路径，覆盖容错SA的关键行为。ATC由两个不同的部分组成：正常ATC和异常ATC。NormalATC路径从初始状态开始并到达IES状态，并且ExceptionalATC从IES状态开始并再次到达正常状态。可以应用路径覆盖标准（例如，McCabe's，所有边，所有节点）。但是，我们建议使用更广泛的覆盖标准，以提高测试的有效性。事实上，算法选择的每条路径都将符合我们从中受到启发的理想化组件模型模式[19，24]。每个ATC路径提供两种类型的信息：强制系统进入异常状态的异常事件和充当预言机的预期行为（场景本身）。• 活动a3.2：测试执行测试执行包括强制系统引发测试异常88A. Bucchiarone等人理论计算机科学电子笔记168（2007）77情况，并评估系统如何根据架构上指定的预期行为作出反应。NormalATC提供了必须发出异常信号的信息，而ExceptionalATC提供了根据容错要求，我们计划实现的系统实现在传统系统中执行测试时，有两个主要的子活动要执行：i）识别那些强制执行所选测试用例的关于第一个要求，体系结构规范和测试用例本身描述了为了达到IES状态必须在系统上执行的操作（包含在NormalATC路径中的信息）。关于第二个要求，必须将能够执行所选ATC的输入插入系统，以便能够转换到所需状态（包含在ExceptionalATC路径中的信息）。4.3.1活动a3当关注AirExtractorControl（正常和异常）组件行为时，只有一个IES状态：excManagement（如图4所示）。如4.3节所述，交互组件状态机上的路径覆盖生成架构级测试用例（ATC）。假设路径覆盖标准旨在产生的在测试执行期间，在四个ATC中建模的四个异常事件被强制在系统中发生。如果系统执行不符合体系结构规范的预期，则会发现体系结构错误5结论和今后的工作在这项工作中，我们提出了如何测试和容错可以联合使用，以提高和验证CBS。事实上，即使这两种技术被认为是软件可靠性工程中的两种主要方法，但到目前为止，它们很少一起使用。该方法从需求分析开始，区分主要需求和辅助需求，允许识别和指定容错SA，并最终允许生成测试规范。在未来的工作方面，我们计划更好地调查拟议的活动，并提高活动中的容错架构充分容错验证。由于软件体系结构规范代表CBS设计的第一步，因此需要此验证阶段来保证后续阶段的有效性。正如我们在本文中所介绍的，主要思想是将容错需求指定为系统应该满足的属性，并使用模型检查引擎来验证容错体系结构模型A. Bucchiarone等人理论计算机科学电子笔记168（2007）7789满足这些要求。为此，我们计划扩展CHARMY工具，用于指定和检查容错软件架构。在这种情况下，它是特别有趣的研究状态空间方面的影响时，考虑故障发生在任何可能的系统状态。引用[1] CHARMY项目。网站地图 http://www.di.univaq.it/charmy2004.[2] P. Ammann，S. Jajodia和P. Liu。一种容错的生存性方法。技术报告，安全信息系统中心，乔治梅森大学，1999年4月。[3] M. Autili，P. Inverardi，and P. Pelliccione.一种基于场景的时态属性表示法。第五届情景和状态机国际研讨会：模型、算法和工具（SCESMACM Press，May 2006.[4] A. Avizienis，J.C. 拉布里湾Randell和C.E. 国防军可靠安全计算的基本概念和分类IEEE跨部门安全Comput. ，1（1）：11[5] L. Bass，P. Clements，and R.卡兹曼软件架构实践，第6章。软件工程中的SEI系列。Addison-WesleyProfessional，第二版，2003年。[6] A.贝托利诺软件测试研究与实践。在ASM 2003，Invited Presentation，卷LNCS 2589，第1-21页，2003年。意大利陶尔米纳[7] R.布奇关于限制二阶算术中的一种判定方法。 In S.联合出版社，编辑，国际逻辑学、方法论和科学论文集，第1-11页，1960年。[8] P. H. da S.布里托角R.罗查湾C. Filho，E. Martins和C. M. F.鲁比拉一种在基于构件的软件开发中对异常进行建模和测试的方法。载于LADC，第61-79页[9] R. de Lemos和A.罗曼诺夫斯基软件中的异常处理。国际计算机系统科学与工程杂志，16（2）：167[10] M. C.长老关键信息系统中的容错。博士论文，工程和应用科学学院，弗吉尼亚大学，2001年。[11] F. C. Filho，P. H. S. Brito和C. M. F.鲁比拉一个分析软件体系结构中异常流的框架。在ICSE 2005年关于架构依赖系统的研讨会（WADS 05），2005年。[12] N.圭尔菲河Razavi，A. Romanovsky和S.范登伯格DRIP Catalyst：一种用于容错分布式软件族开发的MDE/MDA方法。OOPSLA和GPCE关于模型驱动软件开发，2004年。[13] A.哈特曼基于模型的测试生成工具。AGEDIS项目技术报告。[14] G. J. 霍尔茨曼SPIN Model EQUIPMENT：Primer and Reference Manual（）Addison-Wesley，2003年9月。[15] P. Inverardi，H. Muccini和P. Pelliccione。Charmy：一个可扩展的架构分析工具。在ESEC/FSE-13：Proceedings of the 10th European Software Engineering Conference，pages 111Press.[16] P. Inverardi ， H. Muccini 和 P. Pelliccione 。 DUALLY ： 放 入 Synergy UML 2.0 和 ADL 。 第 五 届IEEE/IFIP软件架构工作会议（WICSA 2005）。2005年11月6日至9日，宾夕法尼亚州匹兹堡[17] V. Issarny和J. Banquet。基于架构的异常处理。在2001年，美国华盛顿特区，第34届夏威夷系统科学国际会议论文集（2001年IEEE计算机协会。[18] C. Jard和T.杰隆 TGV：理论、原理和算法。 在2002年国际残疾人组织会议上[19] P. Lee和T.安德森容错：原理与实践，第二版。Prentice-Hall，1990年。[20] N. Medvidovic，D. S. Rosenblum，D. F. Redmiles和J.E.罗宾斯 软件体系结构建模统一建模语言UnifiedModeling Language ACM Transactions on Software Engineering and Methodology （ TOSEM ） ， 11（1），January 2002.90A. Bucchiarone等人理论计算机科学电子笔记168（2007）77[21] N. Medvidovic和R.N. Taylor. 软件体系结构描述语言的分类和比较框架IEEE软件工程学报，26（1），2000年1月。[22] H. Muccini，A.Bertolino和P.Inverardi. 使用软件架构进行代码测试。IEEE软件工程学报，30（3）：160[23] PSC项目。 PSC网站。 http：//www.di.univaq.it/psc2ba，2005年4月[24] C. M. F.鲁比拉河de Lemos，G. R. M. Ferreira和F. C.菲略可靠组件系统开发中的异常处理。软件。实习专家。，35（3）：195[25] S. Sinha和M.哈罗德分析和测试具有异常处理结构的程序。IEEE软件工程学报，26（9），2000年。