基于Petri网的自然语言需求描述测试场景生成方法的论证和应用示例

可在www.sciencedirect.com在线获取理论计算机科学电子笔记329（2016）123-148www.elsevier.com/locate/entcs基于Petri网的自然语言需求描述测试场景生成Edgar Sarmiento埃德加·萨米恩托1，2 胡里奥·C S. P. Leite3信息学系里约热内卢天主教大学巴西Eduardo Almeniah4里约热内卢联邦农村大学数学系巴西里约热内卢Guina Sotomayor AlzamoraInstitutodeMatema′ticayCienciasA fines国立工程大学秘鲁利马摘要从自然语言（NL）中的功能需求生成测试通常是耗时且容易出错的，特别是在复杂的项目中。在这种情况下，形式化的表示，如Petri网越来越多地被用作自动化测试场景生成的输入。 然而，形式表示并不是微不足道的，它需要对正式建模有很强的了解。 在本文中，我们提出了一种方法来生成测试场景，作为输入的限制形式的自然语言（RNL）的需求规格说明。这种方法自动将RNL需求指定为Scenarios转换为可执行的Petri-Net模型;这些Petri-Net用作测试场景生成的输入模型。我们的方法检查输入模型的质量，旨在减少测试场景生成过程中的时间和开销。 所提出的方法的可行性论证是基于一个例子，描述方法操作的用法保留字：场景，需求，Petri网，测试，测试场景。1感谢CAPES资助机构的财政支持2电子邮件地址：ecalisaya@inf.puc-rio.br3电子邮件地址：julio@inf.puc-rio.br4电子邮件地址：almentero@ufrrj.br5电子邮件：guinas@gmail.comhttp://dx.doi.org/10.1016/j.entcs.2016.12.0081571-0661/© 2016作者。出版社：Elsevier B.V.这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。124E. Sarmiento等人/理论计算机科学电子笔记329（2016）1231引言软件测试是最常用的验证技术之一，这种方法提高了最终产品的质量，特别是检查软件行为是否符合其要求。然而，测试生成和执行任务仍然是相当昂贵的，通常是手工完成的，那么测试过程的自动化是一个具有挑战性的课题。基于模型的测试（MBT）是这些任务自动化的替代方案，其中测试来自系统规范。因此，预期的系统行为是使用形式规范符号描述的[2]。MBT是指黑盒测试方法，其中测试场景和预言是从被测系统（SUT）的形式和功能模型自动生成的。MBT的一个重要好处是，从被测系统的模型自动生成测试场景，并通过执行被测系统并将其结果与预期结果进行比较来自动验证这些测试场景MBT的主要缺点是模型构建和选择合适的正式符号[24]，通常大多数提出的方法需要人工干预或创建额外的复杂行为模型。根据[25]，这严重阻碍了它们在实践中的适用性在现有的大多数生成基于模型的系统测试场景的方法中，测试人员通常将系统分解为不同的使用场景，然后为每个确定的场景创建形式化表示。测试场景是从这些中间形式表示中导出的根据[2]，这些规范的质量对于有效的测试活动至关重要;因此，希望通过一些（半）正式的注释来描述预期的系统行为。形式符号的例子是Petri网[17]或通信顺序进程（CSP）[19]。（半）形式化符号的使用促进了测试自动化的过程。然而，这种做法是昂贵的，并没有在工业实践中广泛使用。另一方面，为了便于客户和开发人员之间的沟通，基于自然语言的表示经常用于需求工程。在这种情况下，功能需求被表示为场景，并通过基于用户视角的特定事件流进行描述场景的使用有助于理解应用程序中的特定情况，优先考虑他们的行为[14]。一些用于编写场景的最突出的语言是用例描述的限制形式[5]，[9];场景表示[14]; UML动态行为图;和消息序列图[1]。虽然这些语言中的一些提供了一个可访问的可视化模型，他们缺乏正式的语义，以支持进一步的分析或测试生成。在这种情况下，情景规范通常是非正式或半正式的，并且由于自然语言的模糊性，它们不能直接用于MBT活动。为了从这些场景中执行自动化MBT，有必要：（i）检测和修复场景中的缺陷;（ii）将它们从非正式的形式化表示，如Petri网;（iii）从形式化表示导出测试E. Sarmiento等人/理论计算机科学电子笔记329（2016）123125表示。Petri-Nets [17]是基于严格数学理论的形式化模型，它们为并发系统的建模和仿真以及通过可达树分析属性提供了数学上的简化。将文本场景转换为Petri网模型以及从这些正式模型生成测试场景是具有挑战性的主题，因为这些过程中涉及的任务成本很高，特别是当我们考虑大型系统时。我们在这里提出了一种自动化的方法来生成测试场景从自然语言的需求规格说明;我们的方法使用RNL描述场景（符合元模型）作为输入，派生出一个等效的Petri网模型（符合一个受限制的Petri网元模型），并生成测试场景作为输出（事件转换序列和保护条件）。该方法由场景验证模块（缺陷检测）、模型转换方法（定义为映射规则）和遍历Petri网可达树生成测试场景的准则组成这些阶段正在C L[4]原型工具。本文的组织结构如下。第2节描述了该方法的概述。第3节介绍了用于编写场景的语言第4节描述了从场景到Petri网的转换第5节介绍了测试场景生成策略。最后，第六节介绍了与我们的建议相关的一些工作，结论，局限性和对未来工作的一些建议2策略概述出于实际原因，为了便于与利益相关者沟通，面向用户的方法广泛使用非正式或半正式表示。面向用户的方法在行业需求工程活动中占主导地位;并且，这种观点中的关键要素之一是场景的概念。在文献中，术语场景在不同的上下文中具有不同的含义，并且场景和用例之间没有明确的区别虽然有些作者认为每个场景对应于一个用例[8]，但其他人将场景定义为用例步骤的序列，这些步骤表示通过一个用例[5]。根据Glinz [8]，场景可以包括交互步骤的具体序列（实例场景）或可能的交互步骤的集合（类型场景）。用于详细描述场景的最常见组件是：标题/名称、目标、前置条件、后置条件、参与者、事件/主流程和事件/替代流程。所提出的方法侧重于场景规范，因为这些场景规范被用作设计、编码和测试等其他开发活动的输入。它们构成了软件开发过程的重要组成部分因此，我们需要确保应用程序中的不同情况被描述为清晰且定义明确的场景表示[14]。因此，在我们的方法中：首先，需求工程师开始使用场景语言描述系统的不同功能，服务或情况126E. Sarmiento等人/理论计算机科学电子笔记329（2016）123Fig. 1. 拟议办法概览。[22]在过去的作品[20]。第二，场景元素中不相关的信息被删除。第三，为了从场景表示执行自动化测试场景生成，通过将这些场景转换为地点/变迁Petri网，并将它们合成为一致的整个Petri网，得到初始系统设计第四，自动分析场景及其产生的Petri 网 ， 以 检 测 和 修 复 损 害 Unambiguity ， Completeness ， Consistency 和Correctness属性的缺陷。第五，分析结果被格式化并返回给需求工程师. 第六，如果发现缺陷，分析反馈用于改进场景描述，因为识别出的问题可以追溯到场景。第七，如果没有发现缺陷，则使用所得到的Petri网来导出测试场景。图1描述了我们方法的概述我们的方法的不同阶段正在C L [4]工具中实现第一至第六步已完全实施，并在[20]和[22]中详细说明。在我们的建议中，每个场景句子（命令式或声明式）都被翻译成一个Petri-Net节点（transition或place）。这些Petri网节点由弧连接，从而产生Petri网模型。每个翻译的场景都定义了系统正式规范的一部分。基于生成的Petri网模型，可以通过仿真来验证事件的可用的Petri-Net工具[16]使需求工程师能够使用等价的Petri-Net模型来模拟场景行为它们还允许通过将场景的句子重写为更具体的句子来详细描述场景的句子，以便于理解其行为。此外，这些工具还可以验证结构和行为特性（可达性、有界性和活性）;通过这些工具提供的反馈，需求工程师可以改进场景描述，然后重新开始流程。如果没有发现问题，这些场景和Petri网E. Sarmiento等人/理论计算机科学电子笔记329（2016）123127模型可以用于软件开发过程的下一个活动，如MBT。通过形式化地表示系统，Petri网模型可以用作基于模型的测试过程的输入，自动化一些重复和耗时的任务，如测试场景生成或测试执行。MBT的一个重要优点是从SUT的正式模型自动生成测试场景[18 ]第10段。从RNL场景规范自动转换正式的Petri-Net模型克服了MBT的主要缺点，MBT是正式模型建设在我们的建议中，测试场景生成过程可以使用从场景规范生成的Petri网模型自动执行;目标是将每个事件或转换序列转换为原子步骤，从而实现其实现。因此，这将允许自动执行测试场景。3编写RNL方案如前所述，用于编写场景的语言是RNL。使用RNL可以写祈使句和陈述句。祈使句描述参与者事件，陈述句描述参与者或资源状态。因此，软件需求规范可以被描述为清晰且定义明确的场景描述。RNL的使用限制了用于编写场景的词汇，并防止在场景规范中引入歧义句，从而有助于文档的质量。RNL还需要定义句子构造的语法规则。此外，它有助于文本场景到正式的可执行模型的自动转换。这项工作中使用的基于自然语言的场景是[14]的改编，并在[20]中提出。3.1场景场景规范捕获域中的系统行为或情况[14]，它有助于开发人员和其他利益相关者理解需求。以下场景定义可以实现进一步的转换：定义3.1场景是部分有序事件发生的集合，每个事件都由一组条件（前置条件和后置条件）保护或受约束条件限制[20]。事件是一个参与者操作或涉及用户、系统、环境或系统组件的交互。条件是一个执行器/资源/系统状态（例如，某些资源的可用性）。参与者可以是环境中的用户、设备、系统、系统组件或代理;他们在场景中或在系统中图2使用类图展示了本工作中使用的场景语言的抽象概念模型根据这一概念模型，128E. Sarmiento等人/理论计算机科学电子笔记329（2016）123图二. 情景概念模型[20]该语言由Scenario主实体和Context、Resource、Actor、Episode、Exception和Constraint实体组成场景在初始状态（上下文）中开始，具有所有必要的资源和参与者，并且必须满足通过执行其Epsilon而达到的目标。情节描述了情况的操作行为，其中包括主要的行动过程和可能的替代方案。异常可能出现在事件的执行过程中，并表明存在实现目标的障碍。对这种例外的处理不需要满足场景目标。一个场景、前置条件、后置条件、约束、情节或例外可以用另一个场景来表达。表1显示了基于[20]中提出的RNL场景语言编写场景的模板。它解释了每个场景元素的含义以及应该如何填充。Epsilon表示操作的主要流程，这是一系列步骤，其中一切都按预期工作。这些情况妨碍了方案的正确进程。它的治疗应该用一句话来描述。它也代表了替代/例外的非主流。约束是非功能性的方面，描述为陈述性的句子，限制目标实现的质量，需要的资源和情节的执行。它是资源、剧集或上下文子组件的属性情节句有单句、条件句、选择句和循环句。简单的情节是完成场景所必需的。条件性发作是指其发生取决于内部或外部条件的发作。可选事件是那些可能发生或可能不发生的事件，这取决于无法详细说明的条件。循环片段可以作为重复结构，其出现取决于内部或外部条件。内部条件可能是由于其他先决条件、行为者或资源限制以及以前的事件。外部条件可以由外部参与者或其他场景提供一系列的情节意味着一个优先顺序，但非连续的顺序E. Sarmiento等人/理论计算机科学电子笔记329（2016）123129表1用于编写场景的模板。元件描述标题<识别场景，并且必须是唯一的>目标<描述场景的目的>上下文<必须通过以下选项中的至少一个进行描述：><描述场景初始状态>地理位置<表示场景的物理集合>时间位置<是场景开发的时间规范>先决条件<场景的初始状态或其他场景的名称>后置条件<场景的最终状态或其他场景的名称>资源<列举方案为实现其目标而使用的相关物理要素或信息><必须出现在至少一集>行为者<直接涉及情况的人员、装置或组织结构的列举><必须出现在至少一集>集ID1句话<执行可以使用/修改资源并由参与者执行的动作><或其他方案的名称>先决条件（*）<我们希望在剧集播出前就已经满足了>后置条件（*）<我们希望在事件发生后实现>约束（*）<限制执行剧集的质量>例外ID1.1原因<由于输入数据无效或缺少必要资源或发生故障而导致的故障>溶液<用祈使句处理><或其他方案的名称>后置条件（*）<可以对资源/系统状态产生影响，或者简单地产生消息>（*）可选可以由符号“#”限定，允许两个或多个片段的分组。这是用来描述模糊的顺序，并发或平行的情节（#Episode Series> #）。上下文表2和表3给出了场景示例。这些例子将在后面解释。表2中描述的这些示例最初是作为用例描述在So m'e的“Online Broker System”案例研究中提出的[ 23 ]。3.2自然语言的限制形式（RNL）为了减少自然语言需求中的歧义并促进模型转换，在[20]中定义了一种用于根据其概念模型编写句子的场景语法（图2）。使用这种语法，可以写命令式（标题，情节句或例外解决方案）和声明式（条件或状态）句子。祈使句描述Actor事件;陈述句描述Actor或Resource状态（或Conditions）。情景语法中的句子基本上是按照“主语+动词+谓语“的格式来定义的130E. Sarmiento等人/理论计算机科学电子笔记329（2016）1231标题：提交订单目标：让客户为给定的订单找到最佳供应商。背景：先决条件：经纪人系统已在线，经纪人系统欢迎页面正在显示演员：客户，经纪人系统资源：登录页面，登录信息，订单EPISODES1. 客户加载登录页面2. 经纪人系统要求客户提供登录信息3. 客户输入其登录信息4. 代理系统检查提供的登录信息5. 经纪人系统显示订单页面6. 客户创建新订单7. 当客户有更多的商品要添加到订单中时，客户是否会添加一个商品8. 客户提交订单9. 经纪人系统将订单广播给供应商10. #供应商投标订单11. 国际供应商投标订单编号12. 过程投标例外1.1如果客户未注册，则注册客户2.1如果60秒后THEN经纪人系统显示登录超时页面4.1如果客户登录信息不准确，则经纪商系统显示警报消息表2经纪人系统中的“提交订单”场景描述主语、主要动词和由主要动词引导的宾语。因此，句子结构是以主要动词为中心的表4显示了使用部分Extended-BNF编写场景元素的语法根据这种语法，Scenario必须由以下属性描述：Title、Goal、Context、Resource、Actor、Epperity和Exception。在表4中，+表示组成，{x}表示x出现0次或多次，{x}N 意味着x，（）的1次或多次出现用于分组，|代表OR和[x]表示x是可选的。 以下词语仅包含ter-语法符号：短语、动词、谓语、名称、非动词、连接动词、字母和数字。下列单词和短语是终止符号：标题、目标、上下文、资源、演员、情节、例外、地理位置、时间位置、前提条件、后条件、约束、如果、那么、当、做、和、或、必须、不、根据"[Actor]“格式声明情节语句和异常解决方案|资源] +动作-动词+ [直接对象-谓词]"，其中“动作-动词”表示动作，“直接对象-谓词”指的是由行动在句子“The Customer submits the Order”中条件（事件条件或异常原因）可以被正式定义为根据格式“（Actor）”声明的逻辑句子。|资源）+连接-动词+谓词”。一个句子的主语（Actor或Resource）和一个谓语（主语补语），例如句子“Feederarea is available”中的单词“is”。连系动词后面不跟宾语。相反，它们后面是短语，E. Sarmiento等人/理论计算机科学电子笔记329（2016）123131表3“在线经纪人系统”的场景标题：本地供应商投标订单目标：提交投标上下文：为订单创建出价先决条件：订单已被广播后条件：本地供应商已收到代理人：本地供应商，经纪人系统资源：订单，投标集1. 本地供应商接收订单并进行检查2. 本地供应商确定订单的适用税费并创建投标3. 本地供应商提交订单投标4. 经纪人系统将出价发送给客户1.1如果本地供应商不能满足订单，则本地供应商将订单转移标题：国际供应商投标订单目标：处理投标上下文：处理订单的投标先决条件：订单已被广播后条件：国际供应商已收到订单。ACTOR：国际供应商，经纪人系统资源：订单，投标集1. 国际供应商收到订单并进行检查2. 国际供应商提交订单投标3. 经纪人系统将出价发送给客户1.1 如果订单包括限制出口的物品，则国际供应商将订单转交给国际1.2 如果国际供应商不能满足订单，则国际供应商将订单转移标题：过程投标目标：处理投标上下文：处理订单的投标先决条件：本地供应商有分销商或国际供应商有分销商参与者：客户，经纪人系统资源：订单，出价1. 客户审查投标2. 客户向系统发出继续投标的信号3. 办理缴费4. 系统向选定的投标人下订单关于受试者的信息（例如，名词短语、形容词短语、副词短语或介词短语）。连系动词包括有限数量动词的共轭形式。像条件一样，状态（前置条件和后置条件）可以被正式定义为根据"（Actor）“格式声明的句子。|资源）+状态-动词+谓词”。“状态动词”表示一种相对静态的状态。它们包括感知、认知、感觉、情感和存在状态的动词。在“The bubeher isempty”这句话中，“is”是状态动词，“empty”是谓语。状态动词一般不用于进行时态。[20]中包括了一些连接动词和状态动词的例子3.3基于情景的模块化使 用 Scenario 语 言 的 主 要 好 处 是 Scenario 支 持 使 用 Scenario 关 系 组 合 各 种Scenario。该特征提供132E. Sarmiento等人/理论计算机科学电子笔记329（2016）123表4[20]第二十类型描述<场景>标题：标题>+目标：目标>+CONTEXT：上下文>+资源：{资源>}N+1演员：{演员>}N+1Episodes：Episodes> +异常：{异常>}