CN115587036A - 一种测试***和测试用例的生成方法 - Google Patents

Abstract

本公开提供了一种测试***和测试用例的生成方法，所述***包括：基本元素层，用于响应第一用户的第一操作请求，根据所述第一操作请求中的基本测试需求，构建至少一个基本元素单元，所述基本元素单元为测试的最小操作单元；功能逻辑层，用于响应第二用户的第二操作请求，根据所述第二操作请求中的功能测试模块构建策略，从所述基本元素层中调取与所述功能测试模块构建策略对应的所有所述基本元素单元构建至少一个功能测试模块；业务逻辑层，用于响应第三用户的第三操作请求，根据所述第三操作请求中的测试用例构建策略，从所述功能逻辑层中调取与所述测试用例构建策略对应的所有所述功能测试模块生成测试用例。

Description

一种测试***和测试用例的生成方法

技术领域

本公开涉及软件测试技术领域，尤其涉及一种测试***和测试用例的生成方法。

背景技术

UI(User Interface，用户界面)自动化测试是一种测试人员作为待测试应用程序的使用者，通过模拟使用者的操作过程，针对测试人员看到的界面、按钮等UI组件进行相应的测试操作并对测试结果的正确性进行验证。

目前，市面上常见的UI自动化测试工具主要包括Espresso、UI Automator以及Appium三种。其中，Espresso是Google开源的一款Android自动化测试框架具有运作速度快，API小等优势，但仅能通过Java语言来写代码；UI Automator所运行的JUnit测试用例是有特殊权限的，这意味着测试用例可以跨越不同的进程，但UI Automator只能工作在API16或更高级别的Android设备上。Appium作为一款“移动”的自动化测试工具，不仅支持iOS和Android***的原生和混生的移动应用程序，并且可以使用任意一种编程语言，例如Java、Objective-C、JavaScript、PHP、Ruby等来编写Appium的测试脚本。

在使用现有的自动化测试框架生成自动化测试用例过程中，需要测试人员从头到尾编写整个自动化测试的测试用例，对于使用不同编程语言或者不同编程能力的测试人员来说，这样的测试框架的设计并不合理，对于测试人员的能力要求较高，不仅需要测试人员编写大量的测试脚本，而且为后续测试脚本的维护带来诸多困难。

发明内容

本公开提供了一种测试***和测试用例的生成方法，以至少解决现有技术中存在的以上技术问题。

根据本公开的第一方面，提供了一种测试***，其特征在于，所述***包括：基本元素层，用于响应第一用户的第一操作请求，根据所述第一操作请求中的基本测试需求，构建至少一个基本元素单元，所述基本元素单元为测试的最小操作单元；功能逻辑层，用于响应第二用户的第二操作请求，根据所述第二操作请求中的功能测试模块构建策略，从所述基本元素层中调取与所述功能测试模块构建策略对应的所有所述基本元素单元构建至少一个功能测试模块；业务逻辑层，用于响应第三用户的第三操作请求，根据所述第三操作请求中的测试用例构建策略，从所述功能逻辑层中调取与所述测试用例构建策略对应的所有所述功能测试模块生成测试用例。

在一可实施方式中，所述基本元素层还用于：根据所述基本测试需求获取至少一个基本测试脚本，并为每个基本测试脚本生成对应的基本关键词；根据所述基本测试脚本和对应的基本关键词，构建所述基本元素单元。

在一可实施方式中，所述功能测试模块构建策略包括功能测试需求和流程结构语句，所述流程结构语句包括以下至少之一：顺序语句、选择语句和循环语句，相应的，所述功能逻辑层还用于：从所述基本元素层中调取所述功能测试需求对应的所有所述基本元素单元，获取相应的基本测试脚本；将获取的所有基本测试脚本通过所述流程结构语句进行组合得到至少一个功能测试脚本，并为每个所述功能测试脚本生成对应的功能关键词；根据所述功能测试脚本和对应的功能关键词，构建所述功能测试模块。

在一可实施方式中，所述测试用例构建策略包括业务测试需求和业务逻辑，所述业务逻辑为在执行测试用例时，所述功能测试模块运行的先后顺序，相应的，所述业务逻辑层还用于：从所述功能逻辑层中调取所述业务测试需求对应的所有所述功能测试模块，按照所述业务逻辑将调取的所有功能测试模块的功能测试脚本进行排列组合，得到所述测试用例。

在一可实施方式中，所述功能测试需求为文本信息，将所述文本信息通过语义识别获得文本关键词，相应的，所述功能逻辑层还用于：从所述基本元素层查找与所述文本关键词匹配的所述基本关键词，并调取所有对应的所述基本元素单元。

在一可实施方式中，所述业务测试需求为文本信息，将所述文本信息通过语义识别获得文本关键词，相应的，所述业务逻辑层还用于：从所述功能逻辑层查找与所述文本关键词匹配的所述功能关键词，并调取所有对应的所述功能测试模块。

在一可实施方式中，所述基本元素层，还用于在用户界面显示所述基本关键词，以使所述第二用户根据所述基本关键词输入所述功能测试模块构建策略。

在一可实施方式中，所述功能逻辑层，还用于在用户界面显示所述功能关键词，以使所述第三用户根据所述功能关键词输入所述测试用例构建策略。

根据本公开的第二方面，提供了一种测试用例的生成方法，其特征在于，所述方法包括：响应于第一用户的第一操作请求，根据所述第一操作请求中的基本测试需求，构建至少一个基本元素单元，所述基本元素单元为测试的最小操作单元；响应于第二用户的第二操作请求，根据所述第二操作请求中的功能测试模块构建策略，调取与所述功能测试模块构建策略对应的所有所述基本元素单元构建至少一个功能测试模块；响应于第三用户的第三操作请求，根据所述第三操作请求中的测试用例构建策略，调取与所述测试用例构建策略对应的所有所述功能测试模块生成测试用例。

在一可实施方式中，所述根据所述操作请求中的基本测试需求，构建至少一个基本元素单元，包括：根据所述基本测试需求获取至少一个基本测试脚本，并为每个基本测试脚本生成对应的基本关键词；根据所述基本测试脚本和对应的基本关键词，构建所述基本元素单元。

在一可实施方式中，所述功能测试模块构建策略包括功能测试需求和流程结构语句，所述流程结构语句包括以下至少之一：顺序语句、选择语句和循环语句，相应的，所述调取所述功能测试模块构建策略对应的所有所述基本元素单元构建至少一个功能测试模块，包括：调取所述功能测试需求对应的所有所述基本元素单元，获取相应的基本测试脚本；将获取的所有基本测试脚本通过所述流程结构语句进行组合得到至少一个功能测试脚本，并为每个所述功能测试脚本生成对应的功能关键词；根据所述功能测试脚本和对应的功能关键词，构建所述功能测试模块。

在一可实施方式中，所述测试用例构建策略包括业务测试需求和业务逻辑，所述业务逻辑为在执行测试用例时，所述功能测试模块运行的先后顺序，相应的，所述调取所述测试用例构建策略对应的所有所述功能测试模块生成测试用例，包括：调取所述业务测试需求对应的所有所述功能测试模块，按照所述业务逻辑将调取的所有功能测试模块的功能测试脚本进行排列组合，得到所述测试用例。

在上述方案中，根据功能测试模块构建策略，功能逻辑层从基本元素层调取构建好的基本元素单元组合生成功能测试模块，然后业务逻辑层将这些功能测试模块组合即可生成符合测试用例生成策略的测试用例，相较于需要从头到尾编写整个测试用例的传统自动化测试框架，通过本公开的测试***能够大大提高测试用例的编写效率。并且，在后期测试的维护过程中，能够针对性地对生成测试用例的功能测试模块和基本元素单元进行维护调整，从而避免调整大量的测试脚本，提高了维护的效率降低了维护成本。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

在附图中，相同或对应的标号表示相同或对应的部分。

图1示出了本公开一实施例的测试***示意图；

图2示出了本公开另一实施例的测试***示意图；

图3示出了本公开一实施例测试用例的生成方法的实现流程示意图；

图4示出了本公开一实施例构建基本元素单元的实现流程示意图；

图5示出了本公开一实施例构建功能测试模块的实现流程示意图。

具体实施方式

为使本公开的目的、特征、优点能够更加的明显和易懂，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而非全部实施例。基于本公开中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

本公开提供了一种测试***，如图1所示，该***包括：基本元素层101、功能逻辑层102以及业务逻辑层103。

基本元素层101，用于响应第一用户的第一操作请求，根据第一操作请求中的基本测试需求，构建至少一个基本元素单元，基本元素单元为测试的最小操作单元。

基本元素层101位于整个测试***的第一层，用于构建和存储基本元素单元。在当前的基本元素层中若没有符合基本测试需求的基本元素单元，就需要根据基本测试需求构建相应的基本元素单元，以供后续的调用，并且对基本元素单元的数量不做限制。

在本公开中，基本元素单元是指在软件的自动化测试中最小且独立的测试操作单元。软件的自动化测试还可以是接口的自动化测试，不局限于用户界面的自动化测试，软件即为测试对象。

功能逻辑层102，用于响应第二用户的第二操作请求，根据第二操作请求中的功能测试模块构建策略，从基本元素层101中调取与功能测试模块构建策略对应的所有基本元素单元构建至少一个功能测试模块。

功能逻辑层102位于整个测试***的第二层，其作用是基于第二操作请求中的功能测试模块构建策略，调取基本元素层101中的基本元素单元形成功能测试模块。

业务逻辑层103，用于响应第三用户的第三操作请求，根据第三操作请求中的测试用例构建策略，从功能逻辑层102中调取与测试用例构建策略对应的所有功能测试模块生成测试用例。

业务逻辑层103位于整个测试***的第三层，该层用于调取功能逻辑层中的功能测试模块形成完整的测试用例。

本公开的测试***除了上述的三层，还包括执行单元104，如图2所示，执行单元104用于执行业务逻辑层103形成测试用例，完成软件的自动化测试。

本公开提供了一种测试***，根据功能测试模块构建策略，功能逻辑层从在基本元素层调取构建好的基本元素单元组合生成功能测试模块，然后业务逻辑层将这些构建的功能测试模块组合即可生成符合测试用例构建策略的测试用例，相较于需要从头到尾编写整个测试用例的传统自动化测试框架，通过本公开的测试***能够大大提高测试用例的编写效率。并且，在后期测试的维护过程中，能够针对性地对生成测试用例的功能测试模块和基本元素单元进行维护调整，从而避免调整大量的测试脚本，提高了维护的效率降低了维护成本。

在一个示例中，在构建基本元素单元时，基本元素层还用于：根据基本测试需求获取至少一个基本测试脚本，并为每个基本测试脚本生成对应的基本关键词；根据基本测试脚本和对应的基本关键词，构建基本元素单元。

一个基本元素单元包括两个部分，一是基本测试脚本，一是与基本测试脚本映射的基本关键词。基本元素层中每个基本元素单元都是独立的，之间并不存在任何逻辑关系。本公开中构建基本元素单元包括以下两种方式：

第一种构建方法是基于现有的基本测试脚本构建基本元素单元。现有的基本测试脚本包括两种类型，一种是适用于任一测试对象，即符合基本测试需求的最基础的基本测试脚本，根据该基本测试脚本生成对应的基本关键词构建的基本元素单元，例如：启动APP、重置APP、安装APP、卸载APP、关闭APP、关闭所有APP、后台运行APP、打开APP以及退出APP等，这一类基本测试脚本适用于所有的软件自动化测试。采用这种类型的基本测试脚本构建的基本元素单元适用于所有的测试对象，并且是通用且不可或缺的。因此，此类型的基本元素单元也通常是固定存储在基本元素层中，可以直接调用无需反复构建。另一种则是根据基本测试需求，从基本测试脚本库中调取相应的基本测试脚本，根据该基本测试脚本生成对应的基本关键词构建基本元素单元。在基本测试脚本库中包括各种类型测试操作的基本测试脚本，例如等待APP线程加载完成、输入文本、清除输入框的内容、点击坐标、点击坐标处的元素、检测元素属性是否正确、检测文本是否存在等等。对于一个测试对象来说，基本测试脚本库中的基本测试脚本并不是全部都用到，但由于基本测试脚本库包含了适用于绝大部分测试对象的基本测试操作，因此，可以从基本测试脚本库中调取大量符合基本测试需求的基本测试脚本构建基本元素单元，以满足绝大部分基本测试需求所需要的基本测试操作。优选的，基本测试脚本库可以是Robot framework库。Robot framework库是使用Python语言实现的，也可以在其他的语言环境中运行，在Python的语言环境下运行是最优的选择。

第二种构建方法则是当上述构建方法无法得到符合基本测试需求的基本元素单元时，便可以根据基本测试需求采用任一编程语言编写新的基本测试脚本，同样地，生成基本测试脚本对应的基本关键词构建新的基本元素单元，将新构建的基本元素单元加入基本元素层中，以供后续功能逻辑层的调取。在本公开中，在通过第二种构建方法构建基本元素单元时，生成基本测试脚本可以采用Java、Objective-C、JavaScript、PHP、Ruby、Python等任意一种编程语言。

如此，本公开通过上述两种方法构建的基本元素单元，能够针对性的满足每个测试对象在测试过程中所需要的全部基本测试操作。

在一个示例中，上述功能测试模块构建策略包括功能测试需求和流程结构语句。流程结构语句包括：顺序语句、选择语句和循环语句。相应的，在构建功能测试模块时，功能逻辑层还用于：从基本元素层中调取功能测试需求对应的所有基本元素单元，获取相应的基本测试脚本；将获取的所有基本测试脚本采用至少一个流程结构语句进行组合，得到至少一个功能测试脚本，并为每个功能测试脚本生成对应的功能关键词；根据功能测试脚本和对应的功能关键词，构建功能测试模块。

需要注意的是，在功能测试脚本的形成过程中的语言环境需要与调取的基本测试脚本对应的语言环境要保持一致。例如，从基本元素层中调取的基本元素单元，其对应的基本测试脚本是基于Java生成的，因此在利用流程结构语句生成功能测试脚本时，也必须在Java的语言环境中进行。

在一个示例中，功能测试需求为文本信息，将文本信息通过语义识别获得文本关键词，相应的，功能逻辑层还用于：从基本元素层查找与文本关键词匹配的基本关键词，并调取所有对应的基本元素单元。

通常的，构建功能测试需求可以以文本信息形式体现，因此可以对该文本信息进行语义识别并拆分成多个文本关键词，通过将这些文本关键词与基本元素层中的基本关键词进行匹配，获取相应的基本元素单元。

在一个示例中，基本元素层，还用于在用户界面显示基本关键词，以使第二用户根据基本关键词输入功能测试模块构建策略。

基于基本关键词和基本测试脚本的映射关系构建的基本元素单元，可以通过基本关键词显示在用户界面中，相当于将基本测试脚本通过其对应的基本关键词进行简化显示。如此，基本关键词不仅简化了冗长的基本测试脚本，还能简单描述该基本测试脚本对应的测试操作。

由于基本测试脚本可以通过基本关键词简化显示，可以使得第二用户根据代替基本测试脚本显示的基本关键词输入流程结构语句，生成功能测试模块构建策略。因此，在构建功能测试模块的过程中，可以将代替基本测试脚本显示的基本关键词通过流程结构语句构建功能测试脚本，如此，便可节省用户的工作量和维护成本。

举例说明，例如功能测试模块“设置-点击退出登录”可以实现从软件的“设置”页面“退出登录”的功能，该功能测试需求的文本可以是：“等待页面出现，点击退出，退出登录”，相应的，功能测试模块的形成过程如下：首先，在基本元素层中包括“等待页面出现元素”、“点击元素”、“退出登录”等基本元素单元。然后，根据功能测试需求语义识别得到的文本关键词：“等待页面出现”，“点击”以及“退出登录”，功能逻辑层从基本元素层中匹配和调取如下三种基本元素单元：“等待页面出现元素”、“点击元素”、“退出登录”，需要注意的是“等待页面出现元素”和“点击元素”中的“元素”是指用户界面的组件。接着通过顺序语句这一流程结构语句将这三种基本元素单元的基本测试脚本串联起来，利用基本关键词代替显示基本测试脚本，进而形成了相应的功能测试脚本，再对该功能测试脚本设置对应的功能关键词“设置-点击退出登录”，功能关键词和映射的功能测试脚本形成了“设置-点击退出登录”功能测试模块。

在一个示例中，上述测试用例构建策略包括业务测试需求和业务逻辑，业务逻辑为在执行测试用例时，功能测试模块运行的先后顺序，相应的，业务逻辑层还用于：从功能逻辑层中调取业务测试需求对应的所有功能测试模块，按照业务逻辑将调取的所有功能测试模块的功能测试脚本进行排列组合，得到测试用例。

测试用例是模拟用户在测试对象上的实际操作，从而形成具备业务逻辑的功能测试模块的集合。业务逻辑层从功能逻辑层中调取所有符合业务测试需求的功能测试模块，然后获取相应的功能测试脚本，基于测试用例构建策略中的业务逻辑将功能测试脚本进行组合得到测试用例的业务测试脚本，业务测试脚本也可以设置相应的业务关键词，在一个测试用例中包含业务测试脚本和相应的业务关键词。对于常用的测试用例可以保存在业务逻辑层中以便重复利用。

在一个示例中，功能测试需求为文本信息，将文本信息通过语义识别获得文本关键词，相应的，功能逻辑层还用于：从基本元素层查找与文本关键词匹配的功能关键词，并调取对应的功能测试模块。

业务逻辑层基于这些文本关键词在功能逻辑层中查找匹配的功能关键词调取相应的功能测试模块，形成测试用例。

例如，生成一个购物APP的“购物车-购买支付”的测试用例，目的是在通过购物APP的“购物车”页面中实现“购买支付”的功能，该业务测试需求输入的文本信息可以是：“启动APP，等待APP购物页面，点击购物车选择购物车商品，点击提交订单，点击确认付款，输入付款密码完成支付”。该测试用例的生成过程如下：首先，在功能逻辑层中，包括：“启动APP”、“等待页面出现”、“点击购物车”、“点击选择购物车商品”、“点击提交订单”、“点击确认付款”、“输入付款密码”等功能测试模块；对业务测试需求的文本信息经过语义识别后得到“启动APP”、“等待页面出现”、“点击购物车”、“点击选择购物车商品”、“点击提交订单”、“点击确认付款”、“输入付款密码”等文本关键词，根据这些文本关键词，在功能逻辑层中匹配功能关键词调取相应的功能测试模块。最后基于业务逻辑，对上述功能测试模块进行排列组合生成“购物车-购买支付”的测试用例。

在一个示例中，功能逻辑层，还用于在用户界面显示功能关键词，以使第三用户根据功能关键词输入测试用例构建策略。

基于功能关键词和功能测试脚本的映射关系构建的功能测试模块，可以通过功能关键词显示在功能逻辑层的用户界面中，相当于将功能测试脚本通过其对应的功能关键词进行简化显示。如此，可使第三用户根据功能关键词输入业务逻辑生成测试用例构建策略，在生成测试用例的过程中，同样可以节省用户的工作量和维护成本。

需要注意的是，业务逻辑层在构建生成测试用例的过程中，如果发现没有符合业务测试需求的功能测试模块，需要向功能逻辑层发送测试用例构建策略，功能逻辑层根据用例构建策略调取基本元素单元构建新的功能测试模块。如果功能测试模块仍无法实现该用例构建策略，则继续向基本元素层发送功能测试模块构建策略，由基本元素层构建新的基本元素单元，以供功能逻辑层调取相应的基本元素单元形成新的功能测试模块。

本公开还提供了一种测试用例的生成方法，如图3所示，具体实现过程如下：

步骤201：响应于第一用户的第一操作请求，根据第一操作请求中的基本测试需求，构建至少一个基本元素单元，基本元素单元为测试的最小操作单元。

在本公开中，基本元素单元是指在软件的自动化测试中最小且独立的测试操作单元。在当前没有符合基本测试需求的基本元素单元时，就需要根据基本测试需求构建相应的基本元素单元，以供后续的调用，并且对基本元素单元的数量不做限制。而软件的自动化测试还可以是接口的自动化测试，不局限于用户界面的自动化测试，软件即为测试对象。

步骤202：响应于第二用户的第二操作请求，根据第二操作请求中的功能测试模块构建策略，调取与功能测试模块构建策略对应的所有基本元素单元构建至少一个功能测试模块。

步骤203：响应于第三用户的第三操作请求，根据第三操作请求中的测试用例构建策略，调取与测试用例构建策略对应的所有功能测试模块生成测试用例。

在生成上述测试用例后，还需执行该测试用例完成测试对象的自动化测试，得到测试结果。

本公开提供了一种测试用例的生成方法，根据功能测试模块构建策略，调取构建好的基本元素单元组合生成功能测试模块，然后将这些构建的功能测试模块组合即可生成符合测试用例构建策略的测试用例，如此，相较于需要从头到尾编写自动化测试的测试用例，通过本公开的方法能够大大提高测试用例的编写效率。并且，在后期测试的维护过程中，能够针对性地对生成测试用例的功能测试模块和基本元素单元进行维护调整，从而避免调整大量的测试脚本，提高了维护的效率降低了维护成本。

在一个示例中，上述步骤201，根据操作请求中的基本测试需求，构建至少一个基本元素单元的实现过程，如图4所示，包括：

步骤301：根据基本测试需求获取至少一个基本测试脚本，并为每个基本测试脚本生成对应的基本关键词。

在本示例中，获取基本测试脚本的方法有两种。

第一种是现有基本测试脚本的获取方法，现有的基本测试脚本分为两种，一种为适用于任一测试对象，即符合基本测试需求的最基础的基本测试脚本；另一种则是根据基本测试需求，从基本测试脚本库中调取相应的基本测试脚本，优选的，基本测试脚本库可以是Robot framework库。

第二种是根据基本测试需求，采用任一编程语言编写新的基本测试脚本，生成基本测试脚本所采用的编程语言不限，可以是Java、Objective-C、JavaScript、PHP、Ruby、Python等等任一种。第二种获取方法是在第一种获取方法无法得到符合基本测试需求的基本测试脚本时使用。

步骤302：根据基本测试脚本和对应的基本关键词，构建基本元素单元。

一个基本元素单元包括两个部分，一是基本测试脚本，一是与基本测试脚本映射的基本关键词。根据基本测试脚本和对应的基本关键词构建基本元素单元，

在本公开中，基本测试脚本可以通过其对应的基本关键词进行简化代替。如此，通过基本关键词不仅简化了冗长的基本测试脚本，还能简单描述该基本测试脚本对应的测试操作，方便后续的调取操作。

在一个示例中，上述步骤202，功能测试模块构建策略包括功能测试需求和流程结构语句，流程结构语句包括以下至少之一：顺序语句、选择语句和循环语句，相应的，调取功能测试模块构建策略对应的所有基本元素单元构建至少一个功能测试模块的实现过程，如图5所示，包括：

步骤401：调取功能测试需求对应的所有基本元素单元，获取相应的基本测试脚本。

通常的，构建功能测试模块的功能测试需求可以以文本形式体现，因此可以对该功能测试需求进行语义识别并拆分成多个文本关键词，通过将这些文本关键词与基本关键词进行匹配得到对应的基本元素单元，获取基本测试脚本。

步骤402：将获取的所有基本测试脚本通过流程结构语句进行组合得到至少一个功能测试脚本，并为每个功能测试脚本生成对应的功能关键词。

在构建功能测试模块的过程中，将获取的基本测试脚本通过三种流程结构语句搭建代码逻辑关系，形成与功能测试需求相符的功能测试脚本。由于基本测试脚本可以通过基本关键词简化显示，因此可以将代替基本测试脚本显示的基本关键词通过流程结构语句构建功能测试脚本，如此，便可节省测试人员编写功能测试脚本的工作量和维护成本。

需要注意的是，在功能测试脚本的形成过程中的语言环境需要与调取的基本测试脚本对应的语言环境要保持一致。例如，调取的基本元素单元，其对应的基本测试脚本是基于Java生成的，因此在利用流程结构语句生成功能测试脚本时，也必须在Java的语言环境中进行。

步骤403：根据功能测试脚本和对应的功能关键词，构建功能测试模块。

同样的，将功能测试脚本通过其对应的功能关键词进行简化代替，同时方便后续功能测试模块的调取。

在一个示例中，上述功能测试需求为文本信息，将文本信息通过语义识别获得文本关键词，相应的，调取基本元素单元的过程包括：查找与文本关键词匹配的基本关键词，并调取对应的基本元素单元。

在一个示例中，上述步骤203，测试用例构建策略包括业务测试需求和业务逻辑，业务逻辑为在执行测试用例时，功能测试模块运行的先后顺序，相应的，调取测试用例构建策略对应的所有功能测试模块生成测试用例，包括：调取业务测试需求对应的所有功能测试模块，按照业务逻辑将调取的所有功能测试模块的功能测试脚本进行排列组合，得到测试用例。

测试用例是模拟用户在测试对象中的实际操作，从而形成具备业务逻辑的功能测试模块的集合。调取所有符合业务测试需求的功能测试模块，然后获取相应的功能测试脚本，基于业务测试需求中的业务逻辑将功能测试脚本进行组合得到测试用例的业务测试脚本，业务测试脚本也可以设置相应的业务关键词，在一个测试用例中包含业务测试脚本和相应的业务关键词。

在一个示例中，上述业务测试需求为文本信息，相应的，调取所有功能测试模块包括：将文本信息通过语义识别获得文本关键词，查找与文本关键词匹配的功能关键词，并调取所有对应的功能测试模块。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本公开的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种测试***，其特征在于，所述***包括：

基本元素层，用于响应第一用户的第一操作请求，根据所述第一操作请求中的基本测试需求，构建至少一个基本元素单元，所述基本元素单元为测试的最小操作单元；

功能逻辑层，用于响应第二用户的第二操作请求，根据所述第二操作请求中的功能测试模块构建策略，从所述基本元素层中调取与所述功能测试模块构建策略对应的所有所述基本元素单元构建至少一个功能测试模块；

业务逻辑层，用于响应第三用户的第三操作请求，根据所述第三操作请求中的测试用例构建策略，从所述功能逻辑层中调取与所述测试用例构建策略对应的所有所述功能测试模块生成测试用例。

2.根据权利要求1所述的***，其特征在于，所述基本元素层还用于：

根据所述基本测试需求获取至少一个基本测试脚本，并为每个基本测试脚本生成对应的基本关键词；

根据所述基本测试脚本和对应的基本关键词，构建所述基本元素单元。

3.根据权利要求2所述的***，其特征在于，所述功能测试模块构建策略包括功能测试需求和流程结构语句，所述流程结构语句包括以下至少之一：顺序语句、选择语句和循环语句，相应的，所述功能逻辑层还用于：

从所述基本元素层中调取所述功能测试需求对应的所有所述基本元素单元，获取相应的基本测试脚本；

将获取的所有基本测试脚本通过所述流程结构语句进行组合得到至少一个功能测试脚本，并为每个所述功能测试脚本生成对应的功能关键词；

根据所述功能测试脚本和对应的功能关键词，构建所述功能测试模块。

4.根据权利要求3所述的***，其特征在于，所述测试用例构建策略包括业务测试需求和业务逻辑，所述业务逻辑为在执行测试用例时，所述功能测试模块运行的先后顺序，相应的，所述业务逻辑层还用于：

从所述功能逻辑层中调取所述业务测试需求对应的所有所述功能测试模块，按照所述业务逻辑将调取的所有功能测试模块的功能测试脚本进行排列组合，得到所述测试用例。

5.根据权利要求3所述的***，其特征在于，所述功能测试需求为文本信息，将所述文本信息通过语义识别获得文本关键词，相应的，所述功能逻辑层还用于：从所述基本元素层查找与所述文本关键词匹配的所述基本关键词，并调取所有对应的所述基本元素单元。

6.根据权利要求4所述的***，其特征在于，所述业务测试需求为文本信息，将所述文本信息通过语义识别获得文本关键词，相应的，所述业务逻辑层还用于：从所述功能逻辑层查找与所述文本关键词匹配的所述功能关键词，并调取对应的所述功能测试模块。

7.根据权利要求2所述***，其特征在于，

所述基本元素层，还用于在用户界面显示所述基本关键词，以使所述第二用户根据所述基本关键词输入所述功能测试模块构建策略。

8.根据权利要求3所述***，其特征在于，

所述功能逻辑层，还用于在用户界面显示所述功能关键词，以使所述第三用户根据所述功能关键词输入所述测试用例构建策略。

9.一种测试用例的生成方法，其特征在于，所述方法包括：

响应于第一用户的第一操作请求，根据所述第一操作请求中的基本测试需求，构建至少一个基本元素单元，所述基本元素单元为测试的最小操作单元；

响应于第二用户的第二操作请求，根据所述第二操作请求中的功能测试模块构建策略，调取与所述功能测试模块构建策略对应的所有所述基本元素单元构建至少一个功能测试模块；

响应于第三用户的第三操作请求，根据所述第三操作请求中的测试用例构建策略，调取与所述测试用例构建策略对应的所有所述功能测试模块生成测试用例。

10.根据权利要求9所述的方法，其特征在于，所述根据所述操作请求中的基本测试需求，构建至少一个基本元素单元，包括：

根据所述基本测试需求获取至少一个基本测试脚本，并为每个基本测试脚本生成对应的基本关键词；

根据所述基本测试脚本和对应的基本关键词，构建所述基本元素单元。

11.根据权利要求10所述的方法，其特征在于，所述功能测试模块构建策略包括功能测试需求和流程结构语句，所述流程结构语句包括以下至少之一：顺序语句、选择语句和循环语句，相应的，所述调取所述功能测试模块构建策略对应的所有所述基本元素单元构建至少一个功能测试模块，包括：

调取所述功能测试需求对应的所有所述基本元素单元，获取相应的基本测试脚本；

将获取的所有基本测试脚本通过所述流程结构语句进行组合得到至少一个功能测试脚本，并为每个所述功能测试脚本生成对应的功能关键词；

根据所述功能测试脚本和对应的功能关键词，构建所述功能测试模块。

12.根据权利要求11所述的方法，其特征在于，所述测试用例构建策略包括业务测试需求和业务逻辑，所述业务逻辑为在执行测试用例时，所述功能测试模块运行的先后顺序，相应的，所述调取所述测试用例构建策略对应的所有所述功能测试模块生成测试用例，包括：

调取所述业务测试需求对应的所有所述功能测试模块，按照所述业务逻辑将调取的所有功能测试模块的功能测试脚本进行排列组合，得到所述测试用例。

Images