ALM工具选择的多准则决策方法及其在软件开发中的应用

可在www.sciencedirect.com在线获取理论计算机科学电子笔记302（2014）95-109www.elsevier.com/locate/entcs软件开发过程的半自动工具推荐系统MarinaPilar、JocelynSimmonds和 Hern'anAstudilloDepartamentodeInforma′ticaUniversidadT′ecnicaFedericoSantaMar′ıa智利圣地亚哥电子邮件：{mpilar，jsimmond，hernan} @ inf.utfsm.cl摘要应用程序生命周期管理（ALM）工具是简化软件开发过程的关键。然而，中小型开发公司（SMB）无法在时间和人员上进行对每个项目进行密集的工具评估，而不是采用固定的工具集，从而失去了灵活性。 为了简化工具选择过程，本文提出将工具选择形式化为一组多准则决策（MCDM）问题，每个ALM域一个。我们的域参数推荐器将域、过程定义和一组工具评估标准作为输入，并生成工具.该方法已经使用测试域进行了原型化，并使用真实的过程和项目进行了评估;我们的方法生成的建议与三位测试专家的建议非常相似。在进一步评估之前，这些结果表明，我们的方法可以生成项目特定的工具建议，其结果与专家的结果相当，但成本仅为专家的一小部分保留字：软件开发过程;分类法;测试工具;多准则决策1引言越来越多的信息技术工具支持政府和保健等领域的广泛活动，给这些组织带来了新的问题：他们现在必须评估和比较一套不断增长的工具----商业的、学术的和开源的----以确定哪一种更适合他们的需要[ 7 ]。这一问题在软件开发公司中更为关键，它们在评估工具时必须考虑更多的标准，如其当前的技术生态系统、工具集成能力、易用性、用户培训等;但最重要的是，工具必须满足项目和/或组织的需要。这使得工具选择成为一项复杂而昂贵的任务，中小型企业（SMB）只能分配有限的资源。因此，这些公司在选择工具之前没有进行太多的研究[21，26]，最终，这些工具要么无法满足项目和/或开发团队的需求http://dx.doi.org/10.1016/j.entcs.2014.01.0221571-0661 © 2014 Elsevier B. V.在CC BY-NC-ND许可下开放访问。96M. Pilar等人理论计算机科学电子笔记302（2014）95发现它们太难或太麻烦而无法使用。其他人使用非特定的工具，如MS O工具，例如，使用电子表格进行错误跟踪，但这种方法通常不能很好地扩展改进此过程的一种方法是创建和维护一个工具目录，供团队在决定评估哪些工具以供将来使用时使用。然而，由于在决定评估哪些工具时必须考虑许多不同的标准，并且不清楚（先验）这些标准是否相互作用/干扰，因此这种方法不能完全解决问题。因此，我们建议使用多标准决策（MCDM）技术[5]来半自动化工具推荐过程。我们的框架需要作为输入的团队的开发过程和他们的偏好水平的各种工具选择标准，并使用MCDM产生一个排名列表的工具，支持输入过程的任务。这些工具是从一个可扩展的工具目录中选择的，该目录构建在一组工具和任务分类之上，每个ALM域都有一对这种方法的优点是，任何已经正式化其软件开发过程的公司都可以很容易地通过大量工具快速过滤（使用一组简化的标准）。此外，如果一家公司发展或定制了他们的开发过程[9]，很容易检查是否为新过程推荐了相同的工具。这种方法的另一个优点是可以增量地构建工具和任务分类在这篇文章中，我们描述了我们的框架，适用于测试领域。我们已经验证了我们的原型，通过使用它来为一个真实的、以前记录的过程和项目推荐工具;我们使用我们的原型获得的推荐本文的主要贡献在于：（1）提出了一个考虑项目背景和开发过程的领域参数化、半自动化的工具推荐框架：（2）开发了一个测试工具目录及其相应的分类法;（3）将工具推荐问题转化为MCDM问题，通过设定准则偏好水平来控制工具推荐过程。本文的其余部分组织如下。我们在第2节和第3节中概述了MCDM和我们的方法。测试领域分类在第4节中描述，我们的专家研究在第5节中介绍。在将我们的工作与第6节中的相关方法进行比较之后，我们在第7节中总结了文章并对未来工作提出了建议2多准则决策决策已经成为一门数学科学，决策过程中涉及的各个方面已经形式化[5]。决策过程中的关键方面是问题定义，确定最低要求，指定目标，定义选择标准（有形或无形），以及确定可能的替代方案。这个过程需要大量的时间，我们希望减少用户所需的输入量为M. Pilar等人理论计算机科学电子笔记302（2014）9597ΣΣ我我我由于这些原因，我们决定使用多标准决策技术，以便根据选择标准对工具进行排名。具体来说，我们使用层次分析法（AHP）[23]和多属性效用理论（MAUT）[29]。2.1层次分析法AHP是一种决策技术，它使用成对比较以及专家的判断来得出选择标准之间的优先级。这些比较是使用绝对判断的尺度来进行的，该尺度表示一个元素相对于给定属性在多大程度上支配另一个元素。通过创建标准比较矩阵，该技术生成一组权重，其表示标准之间的偏好等级。之后，必须为每个标准制作一个比较矩阵[23]。由于该技术高度依赖于单个用户的输入，并且所使用的矩阵的数量和大小取决于备选方案和标准的数量而2.2多属性效用理论MAUT尝试为每个动作分配一个效用值。该效用是一个实数，表示所考虑的操作的优先性。通常，效用是每个标准分配给所考虑的行为的边际效用之和[5]。该效用是使用效用函数获得的，该效用函数将具有不同单位的价值转换为唯一的维度尺度。我们使用这种技术来补充层次分析法1，其中的主要内容是：• 备选方案集合A ={a1，a2，.， a n}• 选择标准集合C ={c1，c2，...，c m}• 权重集合W ={w1，w2，...，w m}，其中mi=1wi= 1MXj=wi Aij（1）i=1Aij =（x−x−i）x+−x−（二）每一种选择都是使用Eq.1，并被分配一个分数，该分数将用于生成替代排名。 在该等式中，X j表示备选方案j的效用，w i表示准则i的权重，A ij表示准则i相对于备选方案j的效用值。 根据等式（1）中所示的公式计算ij。2，其中rex−i在评估准则j时，最佳值与备选项i相关联，并且x+是最佳值。98M. Pilar等人理论计算机科学电子笔记302（2014）952.3例如Fig. 1. MENTOR架构，应用于测试领域我们现在使用一个例子来展示如何将AHP和MAUT结合起来对备选方案进行排名。在这个例子中，我们决定是否购买丰田普锐斯，奥迪A3或现代口音（替代品），考虑成本和舒适度（选择标准）。 舒适度是一个无形的标准，所以我们使用从1到首先，运用层次分析法，得到了与费用和舒适度相关的权重。表1示出了该示例的成本和舒适度的值，以及使用AHP计算的权重。表1根据AHP的普锐斯A3口音重量成本100020006000.6舒适3510.4如表1所示，成本的最差值为2000，最好值为600，而舒适度的最差值为1，最好值为5。我们现在可以应用MAUT，使用Eq。2得到普锐斯的成本值，即（1000−2000）/（600− 2000）=0。71.其余数值见表2。最后一行显示了使用Eq. 1：根据这些值，丰田普锐斯是最能满足用户表2使用MAUT实用普锐斯A3口音重量成本0.71010.6舒适0.5100.4评分0.6260.40.63我们的方法知识库为信息的收集、组织、共享、搜索和使用提供了一种手段[10]。通过创建过程和工具知识库（每个ALM域一个），我们可以降低工具推荐过程的复杂性，因为我们可以明确地对过程任务和工具能力之间的关系进行建模，并通过这些关系确定工具对特定开发过程的支持程度然后我们可以半自动化推荐M. Pilar等人理论计算机科学电子笔记302（2014）9599通过使用MCDM技术进行过程：开发团队针对各种选择标准指定他们的优先级;这些优先级用于对最适合项目需求的工具进行排名。因此，我们的工具推荐器是基于分类的。图1显示了MENTOR的体系结构，我们的多目标决策引擎。MENTOR将SPEM2.0 [16]中规定的软件开发过程作为输入。SPEM 2.0是建模过程的OMG标准，我们选择它作为输入格式，因为智利的各种中小型软件开发公司已经在SPEM 2.0中正式化了他们的过程[28]。项目背景数据，也是推荐过程的输入，直接输入我们的工具。项目上下文数据包括关于正在开发的项目的类型和规模、预算、可用技术等的信息，并且是在推荐生成过程中必须考虑的约束的来源。给定先前定义的软件开发过程，过程提取器组件首先从过程规范中提取特定于ALM领域的活动、任务、角色和工作产品，并将其存储在数据库中以供进一步使用。由于不同的组织为不同的流程组件提供不同的名称[2]，因此我们还包含了一个同义词库组件，用于规范术语。ALM领域活动、任务和概念之间的等价关系必须由领域专家维护为了提出工具建议，我们需要知道哪些工具支持不同的ALM域任务和活动。为此，我们创建了一个工具目录（每个ALM域一个），它收集有关可用工具的信息。该目录基于两种分类法：特定于领域的分类法，描述了ALM领域;以及工具分类法，描述了与该ALM领域的工具推荐过程相关的工具这种关注点的分离使我们的方法具有可扩展性，因为我们可以通过添加更多特定于领域的分类法（和同义词），为其他领域（如需求分析）推荐工具。此时，我们可以使用工具目录来确定哪些工具可以用于执行输入软件开发过程的活动和任务。这不是一个简单的任务，如果手动完成，团队必须单独安装和评估每个可用的工具。相反，我们依靠选择标准来自动化这一步骤：团队表明他们对有限的一组选择标准的偏好，我们使用第2.3节中描述的过程来对工具进行排名。我们决定使用AHP和MAUT的组合，以减少开发团队必须输入的信息量。使用AHP为每个工具评估标准分配权重相对容易，因为用户只需填写标准比较矩阵的上三角形，与SMART或MACBETH [5]方法相比，需要更少的用户输入，这些方法需要所有成对比较的值然而，AHP也试图管理不一致的选择标准偏好100M. Pilar等人理论计算机科学电子笔记302（2014）95图二. 测试分类法程度.例如，用户可以回答标准A比标准B更重要，并且标准B比标准C更重要，但是标准C也比标准A更重要。为了补救这一点，AHP需要额外的信息后的权重生成过程，以确保用户输入的出于这个原因，我们也使用MAUT技术家族，它依赖于效用函数。在我们的原型中，我们使用了该方法提供的一个示例函数，因为我们的目标用户并不知道所有正在考虑的工具，而在PROMETHEE [5]中，偏好函数必须由用户定义，用户为所考虑的每个标准设置独立阈值和严格的偏好4测试领域软件测试是一个复杂的过程。测试活动的范围很广，执行哪些活动（以及如何执行）取决于所使用的测试方法和技术，以及正在开发的软件类型。这些因素使得自动化工具选择成为一项困难的任务;然而，其他工具特定的因素，如支持哪些测试活动、可用性以及与其他工具的兼容性，使得工具选择过程在实践中更加困难。在本节中，我们将描述用于定义测试工具目录的分类法4.1测试分类法本文提出的测试分类法是基于Barbosa等人提出的本体论。在[1]中。巴博萨的本体论和我们的分类法M. Pilar等人理论计算机科学电子笔记302（2014）95101图三. 工具分类测试领域;然而，考虑到不同的目标。Barbosa的本体提供了对测试工具开发的支持，其中公共词汇表可以通过提供公共词汇表来提高工具的互操作性。另一方面，我们的分类法作为可用工具的知识库，并对特定于工具的概念（如运行时环境和其他技术约束）进行建模（受[3，8，13，30]中的工作启发）。图2显示了我们的测试分类法的关键概念和关系，以UML类图的形式呈现。我们现在描述这些概念：• TestingActivity ： 一 个 TestingProcess 由 多 个 TestingActivity 组 成 ， 每 个TestingActivity定义了一组需要执行的操作。TestingActivity是这个分类法的核心概念，它的五个子类代表了整个测试生命周期的主要阶段[3，8]。· TestPlanning：将测试管理活动分组，如测试计划的开发计划子活动被建模为PlanningSubActivity类的实例，根据预定义的因素（如可用资源、质量和目标）对子活动进行分组。· TestCaseDesign：对测试用例设计活动进行分组。子活动被进一步组织成DesignSubActivities，它将子活动分为测试套件生成和设计技术。测试设计技术进一步分为测试策略，例如，白色vs.黑盒测试· TestExecution：对处理测试套件执行的活动进行分组。ExecutionSubActivity包括oracle设计、工件检查、扩展设计和测试套件执行（手动、记录重放、基于脚本）。· TestResultEvaluation ： 对 验 证 测 试 套 件 执 行 结 果 的 活 动 进 行 分 组ValidationSubActivity包括子活动，如确定测试套件覆盖率、比较测试套件和计算度量。· ReportGeneration：将在任何步骤生成测试报告的活动分组，102M. Pilar等人理论计算机科学电子笔记302（2014）95测试过程以及最终报告生成（包括测试和验证结果）。• TestingProcess：先前定义的软件开发过程的测试部分。过程可以分解为活动、角色、任务和工作产品[16]。• TestEnvironment ： 测 试 工 具 在 不 同 的 运 行 时 环 境 配 置 下 运 行 测 试TestEnvironment包括有关已安装的软件和硬件、环境变量、已安装的代码库和所需支持任务的信息。• TestingTool：对帮助管理和支持测试过程及其活动产生的工件的工具进行建模。工具描述包括基本信息，如：技术要求和限制、工具规范以及支持哪些测试活动• 测试活动：测试活动产生和使用测试工件，如源代码、分析和设计图、计划等。工件可以按类型和格式分类，以及它们是由工具创建还是使用• TestApproach：可以使用各种方法来执行活动。TestMethods可以分为两个子类：technique（基于错误的、基于错误的、组合的、功能的等）。方法（基于规范和基于方案）。• 测试级别：测试活动可以在不同的级别执行：单元测试，集成测试，系统测试和验收测试。4.2工具分类工具分类是使用迭代过程开发的：[6，12，18，25]中定义的工具选择标准和模板作为起点，我们添加了建模工具特征，人力资源和现有工具度量的概念。图3显示了我们的Tools分类法的关键概念和关系，以UML类图的形式呈现。我们现在描述这些概念：• 工具：是这个分类法的核心概念，它的属性为基本的工具特征建模，如描述、版本、作者等。工具产生和使用工件，并支持不同的活动，这些活动可以以不同的方式执行（参见KindofExecution）。• 这些可以按类型和格式分类，以及它们是否由工具创建或使用。测试领域的典型例子包括源代码、分析和设计图、测试计划等。• ToolMetric：根据使用的度量工具对用户定义的工具选择度量进行分组，例如，工具是否支持测试环境中的过程或面向对象代码。• TeamMember：对单个团队成员的工具使用能力以及他们选择相关选择标准和工具度量的能力进行建模团队成员M. Pilar等人理论计算机科学电子笔记302（2014）95103见图4。词库在任何开发过程中都被分配了角色，根据他们的能力，工具用户可以分为技术、半技术或非技术用户。• KindofExecution：活动可以以多种方式执行，例如，人工地或自动地。• 工具类型：测试工具可以根据工具类型进行分类，例如，桌面、开源、嵌入式、系统、特定语言、库、API等。• 选择标准：人们可以定义工具选择标准，如成本、风险、技术、复杂性、学习曲线等。可以定义更专业的标准，例如，考虑工具的类型（参见工具类型）。• ToolCharacteristic：将测试环境必须支持的特定工具特性分组，例如，脚本创建、信息共享、脚本执行、数据测试、生命周期集成等。• 环境：工具在不同的运行时环境配置下执行。环境包括有关已安装的软件和硬件、环境变量、已安装的代码库和所需支持任务的信息。4.3词库图4显示了SPEM过程资产和我们的测试分类法之间术语的主要等价性这个模型是由领域专家创建的，他指出了哪些元素表示两个领域中的相同概念5评价我们联系了三位智利测试专家，以验证我们的原型。这些专家都在中小型企业从事软件开发，特别是软件质量保证。在本节中，我们首先描述了向我们的三位专家介绍的案例研究，然后讨论了这项研究的结果104M. Pilar等人理论计算机科学电子笔记302（2014）95表3项目1：工具建议秩Expert 1专家2Expert 3导师1狼蛛TestLinkTestLinkTestLink2TestLinkXstudioSquish CentralXstudio3XstudioSilk C T.M.理性军需官理性军需官4E. 测试仪理性Q M.E. 测试仪5Silk C T.M.Squish CentralSilk C T.M.6理性军需官硒-IDE5.1案例研究：销售点系统[20]中提出的流程已被智利SMB用于开发销售点（POS）系统，并包括使用此流程开发的一些项目的描述。由于原始的演示格式相当扩展，我们为专家准备了一份摘要，突出了SMB的主要特征，其开发过程，包括该SMB开发的项目的类型和规模、员工的大致数量以及正在使用的硬件的特征等信息。向专家们提出了两个项目，他们必须为这两个项目推荐测试工具：项目1：SMB的任务是使用PHP和JavaScript创建一个新的库存SMB正在规划其测试过程，并决定如何管理测试用例和需求之间的关系。SMB还需要在bug跟踪方面的帮助，因为目前bug还没有正式分配给团队成员，所以没有人负责修复这些bug。此外，没有记录哪些测试用例已经执行，哪些失败等。项目2：SMB的任务是为现有的Web产品目录添加一些新功能（如处理信用卡支付），该产品目录也是用PHP和JavaScript开发的。在本例中，新特性已经添加，开发团队目前正在测试GUI。然而，新功能是直接添加到实时系统中的，因此开发团队希望尽可能自动化测试过程，以便尽快完成测试过程。这些信息通过电子邮件发送给专家我们还向他们发送了我们测试工具目录中可用的测试工具的完整列表。然后，专家们有一周的时间来为这些项目提出他们的测试工具建议5.2结果表3和表4列出了我们的专家以及MENTOR提出的建议。在这两种情况下，MENTOR仅限于生成前5名的工具建议，因为在实践中，我们不希望用户评估更多的工具。就项目1而言，三位专家中有两位建议采用与项目1相同的工具，M. Pilar等人理论计算机科学电子笔记302（2014）95105表4项目2：工具建议秩Expert 1专家2Expert 3导师1硒-IDE硒-IDE硒-IDE硒-IDE2特斯特曼合理F.T.Apache JMeterApache JMeter3XstudioApache JMeterSquish GUI T.Silk C T.M.4Squish GUI T.TestLink合理F.T.Xstudio5JUnit南瓜TA6Silk C T.M.7Squish GUI T.第一名（Testlink）。Expert 1选择Tarantula作为最适合该项目的工具，并将Testlink列为第二位。但是请注意，这位专家没有仔细阅读讲义：由于SMB可用的硬件有限，Tarantula无法在这种情况下使用。此外，Xstudio在大多数排名中都排在第二或第三位关于项目2，我们看到有一项关于以下方面的协议： 最适合的工具（Selenium-IDE）。此外，Apache JMeter在大多数排名中排名第二或第三。当我们分析进一步的建议时，排名之间的一致性更小;我们认为这是因为专家试图使他们的建议尽可能完整，并包括可以用来执行讲义中描述的任务的工具，而MENTOR只包括被描述为能够执行任务的工具。在实践中，我们希望开发团队在分析其他工具之前，将重点放在对前两三个工具的评估上（我们的结果更精确）。我们现在正在与非专家用户进行研究，以进一步验证我们的方法。6相关工作近年来，人们对知识领域的定义越来越感兴趣，将其作为共享信息和标准化领域的一种方式。这些领域可以用来避免概念定义上的分歧，这有助于工具集成以及新工具的创建，因此对本体定义的兴趣重新燃起[1]。本体定义了特定领域的通用词汇表，提供了领域概念及其之间关系的正式规范[15]。文献中定义了几个软件工程专用本体Falbo等人[4]提出了一种软件过程本体，它支持软件过程的获取和组织，以及过程知识的共享和重用。Barbosa等人[1]提出了一个基于ISO/IEC 12207标准的测试本体，用于帮助定义支持工具，以及增强这些类型工具之间的互操作性。作为本体建模工具，106M. Pilar等人理论计算机科学电子笔记302（2014）95虽然它以简单的方式支持，但在其当前状态下，它不能用于自动化测试工具选择过程。在软件测试领域，Nakagawa等人[14]通过提出软件测试工具的参考体系结构来关注工具标准化。Zhu等人[8，31]已经实现了一个原型多代理系统，专注于测试基于Web的应用程序。这个系统并不试图自动化测试过程，也不推荐测试工具;然而，我们已经使用他们的测试概念分类法作为我们的测试分类法的基础检查表是一种流行的工具选择机制，例如，IEEE 1175标准定义了一个可用于评估支持工具的检查表模板。Poston等人[18]扩展了该模板，不仅考虑了团队需求，还考虑了有关正在考虑的工具（如果可用）的任何其他信息，如质量和生产力指标。可以定义其他标准，如可用平台和通信接口等。改进工具选择过程的另一种方法是使用工具分类。例如，Mustafa等人[12]提出了一种基于测试工具支持的测试方法的测试工具分类法，以及根据预期用途进行的分类。其他工作侧重于为具体情况界定标准。例如，Tilley等人[25]定义了基于项目特定需求（如成本，硬件平台，与其他工具的集成等）选择软件可视化工具的标准。其他测试工具选择方法可以是网站搜索[24]，可以列出一些测试工具，但并不总是涵盖SMB的需求。在其他领域，Patel等人[17]提出了一种方法，描述了选择知识管理工具时应考虑的问题和因素。 而Vafaie等人[27]展示了一种商业现货（COTS）和政府现货（GOTS）选择方法，其中供应商对工具特性进行了调查。 另一方面，Maxville等人[11]提出了一个从存储库中选择COTS的过程，使用了目标/问题/度量（GQM），层次分析法（AHP）和加权评分法（WSM）等评估技术。Rivas等人。[21，22]提出了一个选择模型，旨在支持软件开发SMB基于ISO/IEC 14102和目标/问题/度量（GQM）方法选择项目管理工具。Tran等人[26]提出了其他中小企业的工具选择过程，包括三个阶段：研究，供应商沟通和工具安装。这些建议需要大量的手工工作来实现。总之，在定义工具选择标准方面有很多工作;然而，开发团队有责任确定每个工具满足这些标准的程度。因此，工具选择过程目前是手动过程。M. Pilar等人理论计算机科学电子笔记302（2014）951077结论和今后的工作在这篇文章中，我们提出了MENTOR，一个基于域的工具推荐系统，它使用一个工具目录，半自动化的工具推荐过程。它将正式指定的ALM域、过程定义、开发团队的工具选择标准偏好级别作为输入为了验证我们的方法，我们为Testing域创建了工具和任务分类，并使用这些分类创建了测试工具目录。我们请三位专家为一个真实的、以前记录的过程和项目推荐测试工具。我们的原型能够生成类似于专家所做的建议，并且如果我们手动研究工具目录中的每个可用工具，则需要更少的由于使用这个框架，我们希望看到软件质量的提高，因为过程的测试活动将得到更好的我们还期望测试团队将有更多的时间来进行实际测试，因为他们将不再手动评估可用的支持工具。测试团队甚至可能意识到他们从未考虑使用工具的活动的工具支持的存在。作为未来的工作，我们将用额外的分类法扩展这个建议，这样MENTOR就可以为额外的ALM域提供工具建议。我们还评估了其他MCDM技术的使用，如模糊[19]，以改进推荐过程，以及改进选择标准评估方法。最后，我们正在用更多的工具填充目录，这些工具将在线提供确认这 项工 作的 部 分资 金来 自 以下 研究 补 助金 ：项 目 ADAPTE（ FONDEF D 09i1171 ） ， 补 助 金 UTFSM-DGIP 24.12.50 ， 24.11.15 和 基 础 项 目 CCTVal （ FB0821）。引用[1] E. Barbosa ， E. Nakagawa 和 J. Maldonado 。 软 件 测 试 本 体 论 的 建 立 。 在 Proceedings of the 18 thInternational Conference on Software Engineering and Knowledge Engineering（SEKE[2] R. De Almeida Falbo 和 G. 贝 托 罗 为 软 件 组 织 建 立 通 用 词 汇 表 理 解 软 件 过 程 。 EDOCInternationalWorkshop on Vocabularies，Ontologies and Rules for The Enterprise，VORTE，2005.[3] N. Eickelmann和D.理查森软件测试环境体系结构的评价。在Proceedings of the 18 th InternationalConference on Software Engineering（ICSE[4] R.法尔博角 Menezes和A. 罗卡 本体论的系统构建方法。 第六届伊比利亚美洲人工智能会议论文集[5] J. Figueira，S. Greco和M.厄高特多准则决策分析：最新技术调查，第78卷。Springer Verlag，2005.108M. Pilar等人理论计算机科学电子笔记302（2014）95[6] R.作者声明：R. 佩蒂亚湖 Roberts Gold和W. 木材. 软件工程工具的分类和评估指南。技术报告CMU/SEI-87-TR-010，软件工程研究所，卡内基梅隆大学，1987年8月[7] W. Guo，X. Fu和J. Feng.数据驱动的软件测试工具集成系统。 计算智能和软件工程国际会议论文集（CiSE'10），第1-4页，2010年12月[8] Q. Huo，H. zhu和S.格林伍德一个用于测试基于Web的应用程序的多Agent软件环境。在Proceedings ofthe 27th Annual International Conference on Computer Software and Applications（COMPSAC[9] J. A. H urtadoAleg r'ıa，M. C. 巴斯塔里卡湾F. O choa和J. 西蒙兹 MDEsof tw是小公司的流程线。Journalof Systems and Software，86（5）：1153[10] A.梅奇湾Motik，N. Silva和R.沃尔兹MAFRA -一个分布式本体的映射框架。第13届知识工程与知识管理国际会议论文集。Ontologies and the Semantic Web（EKAW'02），第235-250页，2002年。[11] 诉Maxville，J.Armarego和C.Lam. 将可重用框架应用于软件选择。软件，IET，3（5）：369[12] K.穆斯塔法河Al-Qutaish和M. Muhairat基于软件测试方法的软件测试工具分类。在Proceedings of theInternational Conference on Computer and Electrical Engineering（ICCEE[13] G. 迈尔斯软件测试的艺术。约翰·威利父子公司2004年。[14] E.Nakagawa ， A.SimChao， F.Ferrari 和 J.Maldonado. 为 软 件 测 试 工 具 提 供 参 考 体 系 结 构 。 在Proceedings of the 19 th International Conference on Software Engineering and KnowledgeEngineering（SEKE[15] N. Noy和D.麦吉尼斯本体开发101：创建第一个本体的指南。技术报告，斯坦福知识系统实验室和斯坦福医学信息学，2001年。[16] OMG. 软件过程工程元模型SPEM 2.0 OMG Beta规范。技术报告ptc/07-11-01，OMG，2007年。[17] N.帕特尔和V. Hlupic。知识管理工具选择的方法论。第24届信息技术接口国际会议论文集（ITI'02），第369-374页，2002年6月[18] R. Poston和M.塞克斯顿评估和选择测试工具。IEEE软件，9：33[19] Y.伦角，澳-地Quan，T. Xing和X。尘软件配置管理工具选择的模糊决策分析。2010年第三届信息科学与工程国际研讨会论文集（ISISE'10），第295-297页，2010年[20] M. A. Ribo'. MetologiadeDesarrollodeSof twareparaPyMEsdeRetail. 智利大学硕士论文，2009年。[21] L.里瓦斯湾佩雷斯湖Mendoza和A.格里曼中小企业软件工程工具的选择模型。第三届软件工程进展国际会议论文集（ICSEA[22] L.里瓦斯湾佩雷斯湖Mendoza和A.格里曼中小企业软件项目管理工具选择模型在Proceedings of the 2ndInternational Conference on Software Technology and Engineering（ICSTE[23] T.萨蒂用层次分析法进行决策。International Journal of Services Sciences，1：83[24] 技术评估中心。软件测试工具评估中心。http：//test-tools. technologyevaluation.com/，2013年7月访问。[25] S. Tilley和S.煌在 工业环 境中为 程序 理解选 择软件 可视化 工具。 第 10届国 际程序 理解研 讨会 论文集（IWPC'02），第285-288页，2002年[26] X.特兰，T. Huynh，S. Shoval和T. 费里斯 国防工程中小企业工具选择过程及其管理。在IEEE系统工程系统国际会议论文集（SoSEM. Pilar等人理论计算机科学电子笔记302（2014）95109[27] H. Vafaie ， N. Brown 和 L. 张 选 择 情 报 分 析 工 具 的 方 法 论 。 第 18 届 IEEE 人 工 智 能 工 具 国 际 会 议（ICTAI'06），第55-62页，2006年11月[28] G. 我们走吧。Astudillo ，M. Visco nti和C. 我来了。 Tutel k'anSPIFrame workforSmallSettings：AMethodology Transfer Vehicle.在第17届欧洲系统会议论文集，软件服务过程改进创新会议（EuroSPI[29] M.王世文J. Lin和Y.- C.低区 MAUT和PROMETHEE之间的比较。 出发工业工程和工程管理国际会议（IEEM'10），第753-757页，2010年12月。[30] M.杨和M。佩泽软件测试与分析：过程、原理与技术。John Wiley Sons，2005年。[31] H. Zhu和Q.霍在基于Web应用的软件增长环境中用UML开发软件测试本体。In H.Yang，编辑，软件演化与UML和XML，第263-295页Idea Group，2005年。