基于cucumber测试案例的解析方法、装置、设备及存储介质

技术领域

本发明涉及自动化测试技术领域，特别是涉及一种基于cucumber测试案例的解析方法、装置、设备及存储介质。

背景技术

为了更好地开发符合用户要求的产品，在软件开发过程中往往需要对需求进行反复澄清，确保研发和产品之间达成共识；除此之外，在开发完成软件之后需要根据需求场景进行多次验证，以确保软件质量达标。

为了更好的实现以上产品研发过程，目前，业内有如下解决方案：BDD(Behaviour-Driven Development，行为驱动开发模式)以业务为主导，更进一步站在客户角度去对软件使用场景进行开发及测试。基于BDD模式，Cucumber已是比较成熟且流行的自动化测试工具，Cucumber支持负责对接客户规划产品的人员使用中文进行业务场景定义，然后根据定义的场景自动翻译成Java、Ruby等语言的测试代码并进行软件测试，最后生成测试报告以验证该软件结果是否符合客户预期。但，其在定义场景时，仅限于固定标签解析，灵活性不够；而且在解析多测试案例的时候无法实现多案例互相关联解析。

发明内容

本发明提供一种基于cucumber测试案例的解析方法、装置、设备及存储介质，能够实现多案例相互关联解析，提高了解析效率。

为解决上述技术问题，本发明采用的一个技术方案是：提供一种基于cucumber测试案例的解析方法，包括：

获取用户基于业务场景定义的案例文本以及所述用户输入的第一案例名称，根据所述第一案例名称从所述案例文本中确定当前用于cucumber测试的第一测试案例；

对所述第一测试案例进行特征提取，根据特征提取结果获取待解析标签；

从所述待解析标签中提取标签信息，根据所述标签信息获取案例依赖关系，根据所述案例依赖关系获取与所述第一测试案例相互依赖关联的第二测试案例；

对所述待解析标签进行解析，将解析结果自动注册到所述第一测试案例的注册表中，对所述第二测试案例进行解析，将解析结果自动注册到所述第二测试案例的注册表中。

根据本发明的一个实施例，所述对所述第一测试案例进行特征提取，根据特征提取结果获取待解析标签，包括：

对所述第一测试案例进行场景特征提取，根据场景特征提取结果获取基于每个业务场景描述的第一标签；

对每个所述第一标签进行标签特征提取，根据标签特征提取结果获得与所述第一标签对应的业务场景描述的第二标签，所述待解析标签包括所述第一标签和所述第二标签。

根据本发明的一个实施例，所述对所述待解析标签进行解析，将解析结果自动注册到所述第一测试案例的注册表中，包括：

按照所述第一标签的获取先后顺序对所述第一标签进行排序，依序将所述第一标签与所述预设标签库进行比对，从所述预设标签库中获得与所述第一标签对应的第一测试代码并将所述第一测试代码注册到所述第一测试案例的注册表中；

按照所述第二标签的获取先后顺序对所述第二标签进行排序，依序将所述第二标签与所述预设标签库进行比对，从所述预设标签库中获得与所述第二标签对应的第二测试代码并将所述第二测试代码注册到所述第一测试案例的注册表中。

根据本发明的一个实施例，所述从所述待解析标签中提取的标签信息，根据所述标签信息获取案例依赖关系，根据所述案例依赖关系获取与所述第一测试案例相互依赖关联的第二测试案例，包括：

从所述待解析标签中提取所述标签信息，根据所述标签信息从所述待解析标签中确定标签内容为案例的标签作为目标标签；

根据所述目标标签确定案例依赖关系并获取所述目标标签的标签内容，从所述标签内容中确定与所述第一测试案例相互依赖关联的第二测试案例的第二案例名称；

根据所述第二案例名称从所述案例文本中提取所述第二测试案例。

根据本发明的一个实施例，所述从所述待解析标签中提取所述标签信息，根据所述标签信息从所述待解析标签中确定目标标签，包括：

从所述待解析标签中提取标签名，根据所述标签名识别每个所述待解析标签的类别；

若所述待解析标签为自定义标签，则获取所述自定义标签的标签内容，根据所述标签内容识别所述自定义标签的类别；

若所述自定义标签为案例标签，则确定所述自定义标签为目标标签。

根据本发明的一个实施例，所述对所述待解析标签进行解析，将解析结果自动注册到所述第一测试案例的注册表中的步骤之后，包括：

将解析后的标签与解析结果进行关联以形成映射关系；

对解析后的标签进行分类；

根据分类结果将解析后的标签以及对应的映射关系存储于对应的预设标签库中。

根据本发明的一个实施例，所述获取用户基于业务场景定义的案例文本以及用户输入的第一案例名称，根据所述第一案例名称从所述案例文本中确定当前用于cucumber测试的第一测试案例，包括：

获取用户基于业务场景定义的案例文本以及用户输入的第一案例名称；

根据所述案例文本的存储格式确定待解析案例文本；

根据所述第一案例名称从所述待解析案例文本中提取当前用于cucumber测试的第一测试案例。

为解决上述技术问题，本发明采用的另一个技术方案是：提供一种基于cucumber测试案例的解析装置，包括：

第一获取模块，用于获取用户基于业务场景定义的案例文本以及用户输入的第一案例名称，根据所述第一案例名称从所述案例文本中确定当前用于cucumber测试的第一测试案例；

第二获取模块，用于对所述第一测试案例进行特征提取，根据特征提取结果获取待解析标签；

第一解析模块，用于从所述待解析标签中提取标签信息，根据所述标签信息获取案例依赖关系，根据所述案例依赖关系获取与所述第一测试案例相互依赖关联的第二测试案例；

第二解析模块，用于对所述待解析标签进行解析，将解析结果自动注册到所述第一测试案例的注册表中，对所述第二测试案例进行解析，将解析结果自动注册到所述第二测试案例的注册表中。

为解决上述技术问题，本发明采用的再一个技术方案是：提供一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现所述的基于cucumber测试案例的解析方法。

为解决上述技术问题，本发明采用的再一个技术方案是：提供一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述基于cucumber测试案例的解析方法。

本发明的有益效果是：通过标签信息获取案例依赖关系，根据案例依赖关系获取相互依赖关联测试案例并对依赖关联测试案例进行解析，实现多案例互相关联解析，提高了解析效率，解决了在解析多案例时候无法实现多案例相互关联解析，导致解析效率低的问题。

附图说明

图1是本发明第一实施例的基于cucumber测试案例的解析方法的流程示意图；

图2是本发明实施例的基于cucumber测试案例的解析方法中步骤S102的流程示意图；

图3是本发明实施例的基于cucumber测试案例的解析方法中步骤S103的流程示意图；

图4是本发明实施例的基于cucumber测试案例的解析方法中步骤S301的流程示意图；

图5是本发明实施例的基于cucumber测试案例的解析方法中步骤S104的流程示意图；

图6是本发明第二实施例的基于cucumber测试案例的解析方法的流程示意图；

图7是本发明实施例的基于cucumber测试案例的解析装置的结构示意图；

图8是本发明实施例的计算机设备的结构示意图；

图9是本发明实施例的计算机存储介质的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明中的术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括至少一个该特征。本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。本发明实施例中所有方向性指示(诸如上、下、左、右、前、后……)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

图1是本发明第一实施例的基于cucumber测试案例的解析方法的流程示意图。需注意的是，若有实质上相同的结果，本发明的方法并不以图1所示的流程顺序为限。如图1所示，该方法包括步骤：

步骤S101：获取用户基于业务场景定义的案例文本以及用户输入的第一案例名称，根据第一案例名称从案例文本中确定当前用于cucumber测试的第一测试案例。

在步骤S101中，软件研发过程一般包括需求分析、系统设置、编码以及测试等阶段，测试是软件质量把控的关键环节。本实施例的案例文本用于对软件的使用场景进行开发和自动化测试，所有的案例文本存储于一个目录列表中，针对每一个软件可采用多个案例文本进行自动化测试以获得软件的所有适用场景，本实施例将用于同一个软件测试的案例文本称为待解析案例文本，需依次利用待解析案例文本对软件进行测试。

进一步地，在步骤S101中，获取用户基于业务场景定义的案例文本以及用户输入的第一案例名称；根据案例文本的存储格式确定待解析案例文本；根据第一案例名称从待解析案例文本中提取当前用于cucumber测试的第一测试案例。例如，待解析案例文本的存储格式的后缀为“.Feature”，因此，在对所有案例文本进行扫描时，将定位存储格式的后缀为“.Feature”的案例文本，获取到待解析案例文本后，根据用户输入的第一案例名称从待解析案例文本中选择与第一案例名称匹配的待解析案例文本作为当前需要解析的第一测试案例。

步骤S102：对第一测试案例进行特征提取，根据特征提取结果获取待解析标签。

在步骤S102中，基于NLP技术对第一测试案例进行特征提取，具体地，NLP技术可以为词嵌入模型、TextRank算法、TF-IDF算法等，本实施例的第一测试案例中可以存在多个业务场景，每一个业务场景对应一个标签，而对于每个业务场景的描述中，还可以包含多个标签，即每个标签下还可以包含多个子标签。本实施例的标签特征例如：“假如”、“而且”、“当”、“那么”，当第一测试案例的文本中出现上述标签特征，则提取对应的标签，即待解析标签。

进一步地，请参见图2，步骤S102还包括以下步骤：

步骤S201：对第一测试案例进行场景特征提取，根据场景特征提取结果获取基于每个业务场景描述的第一标签；

步骤S202：对每个第一标签进行标签特征提取，根据标签特征提取结果获得与第一标签对应的业务场景描述的第二标签，待解析标签包括第一标签和第二标签。

本实施例中，第一测试案例中可以存在多个业务场景，每一个业务场景对应一个第一标签，第一标签包括标签名和标签内容，例如，标签名为“场景”，标签内容为业务场景的场景描述。每个业务场景的场景描述中还可以存在多个第二标签；本实施例的第二标签包括标签名和标签内容。

例如：以第一测试案例中包括一个业务场景为例进行说明，第一测试案例的文本内容如下：

【第一案例名称:测试案例

这个案例仅仅供演示示例使用

场景:购买基金产品相关案例

假如查询该机构下存在的两个业务员

而且_{第二案例名称}

当业务员使用银行帐号去申请经办购买零售基金产品金额为20000

那么经办成功，订单入库】

上述第一测试案例中第一标签为“场景”，第二标签为“假如”、“而且_”、“当”、“那么”。场景标签的标签名为“场景”，标签内容为“购买基金产品相关案例”，假如标签的标签名为“假如”，标签内容为“查询该机构下存在的两个业务员”。

步骤S103：从待解析标签中提取标签信息，根据标签信息获取案例依赖关系，根据案例依赖关系获取与第一测试案例相互依赖关联的第二测试案例。

在步骤S103中，从待解析标签中解析案例依赖关系，本实施例的待解析标签包括第一标签和第二标签，但仅第二标签支持多案例关联。

本实施例的第二标签支持自定义标签，因此，第二标签包括固定标签和自定义标签，固定标签例如cucumber自带的Given(如果)，When(当)等标签，为了跟cucumber默认的固定标签区分开，自定义标签加了下划线后缀。如cucumber默认的固定标签例“而且”，而自定义标签为“而且_”。例如，上述第一测试案例中第二标签的“假如”、“当”、“那么”为固定标签，“而且_”为自定义标签。

进一步地，自定义标签包括函数标签以及案例标签，为了将函数标签和案例标签进行区分，案例标签带有固定标识，例如案例标签带有“@Casebel”的标识。案例标签可以实现多案例依赖关联。

例如：案例标签的文本内容如下：

又如，以第一测试案例存在依赖关联的第二测试案例为例进行说明，第一测试案例的文本内容如下：

【第一案例名称:测试案例

这个案例仅仅供演示示例使用

场景:购买基金产品相关案例

假如查询该机构下存在的两个业务员

而且_{第二案例名称}

当业务员使用银行帐号去申请经办购买零售基金产品金额为20000那么经办成功，订单入库】

上述第一测试案例中使用了cucumber默认的固定标签“假如”、“当”、“那么”，在此基础上为了实现依赖即多案例关联，还使用了自定义标签“而且_”，通过“而且_”标签可以在第一测试案例中依赖第二测试案例，在其他实施例中，还可以通过“而且_”实现在第一测试案例中依赖多个第二测试案例，达到跨案例解析的目的。

本实施例中，因为自定义标签可能存在案例依赖关联，因此需要对第二标签的类别进行识别，判断第二标签是否为自定义标签，若第二标签为自定义标签则识别第二标签是函数标签还是案例标签，若自定义标签为案例标签则存在案例依赖关联。

进一步地，请参见图3，步骤S103还包括以下步骤：

步骤S301：从待解析标签中提取标签信息，根据标签信息从待解析标签中确定标签内容为案例的标签作为目标标签；

本实施例通过案例标签实现案例依赖关联，因此，将案例标签确定为目标标签。

进一步地，请参见图4，步骤S301还包括以下步骤：

步骤S401：从待解析标签中提取标签名，根据标签名识别每个待解析标签的类别；

本实施例的待解析标签的类别包括固定标签和自定义标签，若待解析标签为固定标签，则按照步骤S104对待解析标签进行解析，若待解析标签为自定义标签，则执行步骤S402。

步骤S402：若待解析标签为自定义标签，则获取自定义标签的标签内容，根据标签内容识别自定义标签的类别；

本实施例的自定义标签的类别包括函数标签和案例标签，其中，若自定义标签为函数标签，表明第一测试案例不存在依赖关联的其他案例，则按照固定标签的解析步骤对自定义标签进行解析；若自定义标签为案例标签，表明第一测试案例存在依赖关联的其他案例，执行步骤S403。

步骤S403：若自定义标签为案例标签，则确定自定义标签为目标标签。

本实施例将自定义标签为案例标签作为目标标签，对目标标签的案例依赖关系进行解析。

步骤S302：根据目标标签确定案例依赖关系并获取目标标签的标签内容，从标签内容中确定与第一测试案例相互依赖关联的第二测试案例的第二案例名称；

步骤S303：根据第二案例名称从案例文本中提取第二测试案例。

本实施例根据第二案例名称在案例文本中索引与第二案例名称对应的第二测试案例。

步骤S104：对待解析标签进行解析，将解析结果自动注册到第一测试案例的注册表中，对第二测试案例进行解析，将解析结果自动注册到第二测试案例的注册表中。

在步骤S104中，对待解析标签进行解析即将待解析标签转换为相应的测试代码。具体地，将待解析标签与预设标签库进行对比，预设标签库存储有用于解析标签的测试代码，通过对比从预设标签库中获取与待解析标签对应的测试代码，进一步地，获取待解析标签的标签名和标签内容，通过对比，从预设标签库获取与标签名和标签内容分别对应的测试代码。本实施例的每个测试案例对应一个注册表，注册内容包括标签序号、标签名以及标签内容，测试代码包括Java、Ruby等语言。本实施例的第二测试案例的解析方法与第一测试案例的解析方法相同。

进一步地，本实施例按照标签获取先后顺序对待解析标签进行排序，依次将第一标签、第二标签与预设标签库进行比对，根据比对结果将第一标签和第二标签解析成对应的测试代码并将测试代码自动注册到第一测试案例的注册表中。

进一步地，请参见图5，步骤S104中对待解析标签进行解析，将解析结果自动注册到第一测试案例的注册表中还包括以下步骤：

步骤S501：按照第一标签的获取先后顺序对第一标签进行排序，依序将第一标签与预设标签库进行比对，从预设标签库中获得与第一标签对应的第一测试代码并将第一测试代码注册到第一测试案例的注册表中；

步骤S502：按照第二标签的获取先后顺序对第二标签进行排序，依序将第二标签与预设标签库进行比对，从预设标签库中获得与第二标签对应的第二测试代码并将第二测试代码注册到第一测试案例的注册表中。

本发明第一实施例的基于cucumber测试案例的解析方法通过标签信息获取案例依赖关系，根据案例依赖关系获取相互依赖关联测试案例并对依赖关联测试案例进行解析，实现多案例互相关联解析，提高了解析效率，解决了在解析多案例时候无法实现多案例相互关联解析，导致解析效率低的问题。

图6是本发明第二实施例的基于cucumber测试案例的解析方法的流程示意图。需注意的是，若有实质上相同的结果，本发明的方法并不以图6所示的流程顺序为限。如图6所示，该方法包括步骤：

步骤S601：获取用户基于业务场景定义的案例文本以及用户输入的第一案例名称，根据第一案例名称从案例文本中确定当前用于cucumber测试的第一测试案例。

在本实施例中，图6中的步骤S601和图1中的步骤S101类似，为简约起见，在此不再赘述。

步骤S602：对第一测试案例进行特征提取，根据特征提取结果获取待解析标签。

在本实施例中，图6中的步骤S602和图1中的步骤S102类似，为简约起见，在此不再赘述。

步骤S603：从待解析标签中提取标签信息，根据标签信息获取案例依赖关系，根据案例依赖关系获取与第一测试案例相互依赖关联的第二测试案例。

在本实施例中，图6中的步骤S603和图1中的步骤S103类似，为简约起见，在此不再赘述。

步骤S604：对待解析标签进行解析，将解析结果自动注册到第一测试案例的注册表中，对第二测试案例进行解析，将解析结果自动注册到第二测试案例的注册表中。

在本实施例中，图6中的步骤S604和图1中的步骤S104类似，为简约起见，在此不再赘述。

步骤S605：将解析后的标签与解析结果进行关联以形成映射关系。

本实施例的映射关系为解析后的标签与对应的测试代码的对应关系，将解析后的标签与解析结果进行关联，在后续使用中，若获取到相同的标签，则可以通过映射关系直接获取到对应的解析结果，无需再次对相同的标签进行解析，从而提高解析效率。

步骤S606：对解析后的标签进行分类。

本实施例解析后的标签的类别包括：案例标签、函数标签以及其它标签。

步骤S607：根据分类结果将解析后的标签以及对应的映射关系存储于对应的预设标签库中。

本实施例的预设标签库包括案例标签库、函数标签库以及其他标签库，当解析后的标签为函数标签或其他标签时，根据分类结果将映射关系存储于对应的预设标签库中，当解析后的标签为案例标签时，说明该标签存在案例依赖关系，根据分类结果将映射关系和案例依赖关系存储于案例标签库中，在后续获取到相同的标签时，则可以通过映射关系直接获取到对应的解析结果，同时通过案例依赖关系获取到相互依赖关联的测试案例。例如，第一标签不属于案例标签，也不属于函数标签，则将第一标签以及对应的映射关系存储于其他标签库中。本实施例中，如相同的标签在多个案例出现，在存储时，在预设标签库存均保存其中一个标签，即同一个预设标签库中不存在相同的标签。本实施例将解析的标签以及对应的映射关系存储于预设标签库中，对新的案例文本进行解析时，若存在与预设标签库相同的标签，通过映射关系进行索引直接调用对应的测试代码，能够提高标签的复用率，进一步提高案例解析效率。

本发明第二实施例的基于cucumber测试案例的解析方法在第一实施例的基础上，通过将解析后的标签与解析结果进行关联以形成映射关系，并对标签进行分类根据分类结果存储标签实现依赖管理，在后续解析测试案例时，若获取到相同的标签，则可以通过映射关系直接获取到对应的解析结果，同时通过案例依赖关系获取到相互依赖关联的测试案例，从而提高标签的复用率以及案例解析效率。

图7是本发明实施例的基于cucumber测试案例的解析装置的结构示意图。如图7所示，该装置70包括第一获取模块71、第二获取模块72、第一解析模块73以及第二解析模块74。

第一获取模块71用于获取用户基于业务场景定义的案例文本以及用户输入的第一案例名称，根据第一案例名称从案例文本中确定当前用于cucumber测试的第一测试案例；

第二获取模块72用于对第一测试案例进行特征提取，根据特征提取结果获取待解析标签；

第一解析模块73用于从待解析标签中提取标签信息，根据标签信息获取案例依赖关系，根据案例依赖关系获取与第一测试案例相互依赖关联的第二测试案例；

第二解析模块74用于对待解析标签进行解析，将解析结果自动注册到第一测试案例的注册表中，对第二测试案例进行解析，将解析结果自动注册到第二测试案例的注册表中。

请参阅图8，图8为本发明实施例的计算机设备的结构示意图。如图8所示，该计算机设备80包括处理器81及和处理器81耦接的存储器82。

存储器82存储有用于实现上述任一实施例所述的基于cucumber测试案例的解析方法的程序指令。

处理器81用于执行存储器82存储的程序指令以解析测试案例。

其中，处理器81还可以称为CPU(Central Processing Unit，中央处理单元)。处理器81可能是一种集成电路芯片，具有信号的处理能力。处理器81还可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

参阅图9，图9为本发明实施例的计算机存储介质的结构示意图。本发明实施例的计算机存储介质存储有能够实现上述所有方法的程序文件91，其中，该程序文件91可以以软件产品的形式存储在上述计算机存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施方式所述方法的全部或部分步骤。而前述的计算机存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质，或者是计算机、服务器、手机、平板等终端设备。

在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。