一种测试用例自动生成的方法和装置

摘要

本发明公开了一种测试用例自动生成的方法和装置，能够降低人员投入成本，提高自动化用例生成效率。其技术方案为：装置包括用例管理系统以及多个运行于本地测试环境的测试管理代理组件和本地用例集组件，用例管理系统和每一个测试管理代理组件进行数据通讯，包括上传和下载的操作，其中用例管理系统配置为供用户查看、管理测试用例、测试结果；测试管理代理组件配置为对微服务应用的日志进行抓取并解析生成测试用例，执行生成的测试用例并生成测试结果报告，将测试结果报告上传到用例管理系统。

说明书

技术领域

本发明涉及一种软件测试技术，具体涉及自动生成测试用例的方法和装置。

背景技术

软件的接口自动化测试中，自动化用例通常根据提前设计的测试用例，通过编写代码或者脚本来实现，一般包括对目标接口的调用、一组测试输入、测试夹具和预期结果。

自动化用例代码或者脚本的编写以及后期维护成本占据了整个自动化测试活动中的大部分人力资源和时间成本投入。在软件产品迭代加速、发布间隔降低的情况下，只能依靠增加人工投入来实现自动化测试，或者只选择部分功能实施自动化测试，导致产品成本上升或者质量劣化。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种测试用例自动生成的方法和装置，能够降低人员投入成本，提高自动化用例生成效率。

本发明的技术方案为：本发明揭示了一种测试用例自动生成的装置，包括用例管理系统以及多个运行于本地测试环境的测试管理代理组件和本地用例集组件，用例管理系统和每一个测试管理代理组件进行数据通讯，包括上传和下载的操作，其中：

用例管理系统，配置为供用户查看、管理测试用例、测试结果；

测试管理代理组件，配置为对微服务应用的日志进行抓取并解析生成测试用例，执行生成的测试用例并生成测试结果报告，将测试结果报告上传到用例管理系统。

根据本发明的测试用例自动生成的装置的一实施例，用例管理系统还配置为供用户编辑和管理用例自动生成的策略。

根据本发明的测试用例自动生成的装置的一实施例，测试管理代理组件对测试用例的解析策略是根据约定模式进行，包括被调用接口名称或者URL、入参及入参类型、接口返回结果。

根据本发明的测试用例自动生成的装置的一实施例，测试管理组件进一步包括日志解析单元、用例上传下载单元、用例执行单元、用例执行报告单元，其中：

日志解析单元，配置为根据测试用例的解析策略，按照约定模式对系统生成的日志进行解析，自动生成测试用例；

用例上传下载单元，配置为从用例管理系统下载测试用例的解析策略，供日志解析单元进行解析，并将解析结果上传至用例管理模块；

用例执行单元，配置为执行日志解析单元生成的测试用例，并生成测试结果报告；

用例执行和报告单元，配置为对给定的测试用例进行测试，并生成测试结果报告。

本发明还揭示了一种测试用例自动生成的方法，其特征在于，方法在如上所述的装置上实施，方法包括：

步骤1：测试环境的配置在经过用户修改之后启动测试模式；

步骤2：手动测试用例在被用户执行后，自动生成录制的日志；

步骤3：上传自动生成的日志经用户；

步骤4：解析自动生成的日志，生成测试用例并上传到用例管理系统；

步骤5：生成的测试用例的用例集被其他用户下载到对应的本地测试环境中；

步骤6：在本地测试环境中被用户执行下载的测试用例，并将测试结果上传到用例管理系统。

根据本发明的测试用例自动生成的方法的一实施例，在步骤2中，日志是在服务间调用的过程中，通过对各个目标微服务产生调用而在后台产生的日志文件，其中将对服务间接口调用的数据记录在日志中。

根据本发明的测试用例自动生成的方法的一实施例，在步骤4中，测试用例的生成过程中，通过模式匹配获取接口调用的关键信息，包括应用的被调用接口名称、入参及入参类型、接口返回结果，以此关键信息来作为测试用例的基础数据，自动生成测试用例并保存为指定格式的文件。

根据本发明的测试用例自动生成的方法的一实施例，在步骤6中，扫描本地测试环境中的指定目录，通过测试夹具根据发现的测试用例的文件列表进行测试用例的执行并生成测试结果报告。

本发明对比现有技术有如下的有益效果：本发明的方法和装置是通过解析应用日志的方式来实现接口自动化用例自动生成，降低人员投入成本，提高自动化用例生成效率。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的测试用例自动生成的装置的一实施例的原理图。

图2示出了本发明的测试用例自动生成的方法的一实施例的流程图。

图3示出了图1的装置实施例中的测试管理代理组件的细化原理图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图1示出了本发明的测试用例自动生成的装置的一实施例的原理。请参见图1，本实施例的装置包括用例管理系统以及多个位于本地测试环境中的测试管理代理组件和本地用例集组件。

用例管理系统和每一个测试管理代理组件进行数据通讯，包括上传和下载的操作。

用例管理系统配置为供用户通过UI查看、管理测试用例、测试结果。同时，用例管理系统支持用户编辑和管理用例自动生成的策略。

测试管理代理组件运行在本地测试环境中，是作为本地测试环境与用例管理系统之间的桥梁。测试管理代理组件配置为：对于微服务应用的日志进行抓取并解析生成测试用例文件，其中测试用例的解析策略是根据事先约定的模式进行，包括被调用接口名称或者URL、入参及入参类型、接口返回结果等。测试管理代理组件还用于上述生成的测试用例的执行，生成测试结果报告，并将测试结果报告上传到用例管理系统中。

测试管理代理组件包括如图3所示的以下单元：日志解析单元、用例上传下载单元、自动测试用例执行单元、给定测试用例执行单元。

日志解析单元配置为根据测试用例的解析策略，按照约定模式对系统生成的日志进行解析，并自动生成测试用例。

具体而言，日志解析单元配置为进行以下的处理。

首先，解决定位一次接口调用过程的日志。由于服务属于多线程工作，会导致不同的请求记录在混杂的日志文件中。可以在应用中以traceID的方式,以traceID唯一标识一次接口调用的日志内容。通过筛选traceID，可以获取某个接口调用的完整内容，并且确定接口调用的先后顺序。

在获取某次接口调用的完整记录后，通过模式匹配来获取接口调用的关键信息，包括应用的被调用接口名称、入参及入参类型、接口返回结果，以此来作为测试用例的基础数据，并保存为指定格式的文件作为测试用例。

在日志中，需要按照约定，应用容器在获取到接口调用内容后，将打印出“调用接口为:”+URL的日志，由此可以解析出被调用的接口。此外，还需要打印出“参数为：”+参数列表的日志，以及“参数类型”+参数类型列表，由此两项可以确定接口的入参的名称、类型和具体值。

在接口调用的最后，还需要打印出“接口调用成功，返回值为”+返回值列表，由此可以确定接口调用结果作为测试用例的预期结果。对于用户个人隐私信息、账号密码等数据则需要额外进行替换处理。

如果该服务存在对其它微服务的服务间调用的，也按照上述方案，抓取对其它微服务请求以及返回结果，作为自动化测试时的mock服务响应内容。

由于应用框架统一了服务调用的入口，接口开发人员无需为每个接口编写上述日志，由框架在接口调用时自行处理生成上述日志。

业务人员或者测试人员通过操作业务系统完成某项业务操作，对系统返回的结果予以确认是否符合预期。如果不符合，则报告系统缺陷。期间，通过服务间的调用，会对各个目标微服务产生调用，并在其后台产生日志。在日志生成的过程中，对于需要进行测试的后台微服务，在启动时开启约定的测试开关，已进入测试模式，对服务间接口调用数据进行记录，记录信息存储在日志中。

对日志的解析是通过traceID这一参数(该参数能够唯一区别并筛选出一次接口调用的日志内容)来实现。通过模式匹配获取接口调用的关键信息，包括应用的被调用接口名称、入参及入参类型、接口返回结果等，以此来作为测试用例的基础数据，并保存为指定格式的文件(例如为csv文件)作为测试用例。对于用户个人隐私信息、账号密码等数据则需要额外进行替换处理。

日志解析单元根据被测微服务的接口调用方式，通过测试夹具解析扫描指定目录下的csv文件，根据扫描结果生成运行时的测试用例并执行和断言。

用例上传下载单元配置为从用例管理系统下载测试用例的解析策略，供日志解析单元进行解析，并将解析结果上传至用例管理模块。

自动测试用例执行单元配置为执行日志解析单元自动生成的测试用例，并生成测试结果报告。自动测试用例执行单元扫描指定目录，通过测试夹具根据发现的csv测试文件列表进行用例的执行并生成测试报告。

给定测试用例执行单元配置为对给定测试用例实施测试并生成测试结果报告。

图2示出了本发明的测试用例自动生成的方法的一实施例的流程。请参见图2，本实施例的测试用例自动生成的方法是在如图1所示的装置上实施的，其实施步骤详述如下。

步骤1：测试环境的配置在经过用户修改之后，启动测试模式。

步骤2：手动测试用例在被用户执行后，自动生成录制的日志。

用户通过操作业务系统完成某项业务操作，对系统返回的结果予以确认是否符合预期。如果不符合，则报告系统缺陷。期间，通过服务间的调用，会对各个目标微服务产生调用，并在其后台产生日志。在日志生成的过程中，对于需要进行测试的后台微服务，在启动时开启约定的测试开关，以进入测试模式，对服务间接口调用数据进行记录，记录信息存储在日志中。

步骤3：自动生成的日志经用户上传到系统中。

步骤4：系统解析自动生成的日志，生成测试用例并上传到用例管理系统。

这一步骤的具体处理过程如下。

首先，解决定位一次接口调用过程的日志。由于服务属于多线程工作，会导致不同的请求记录在混杂的日志文件中。可以在应用中以traceID的方式,以traceID唯一标识一次接口调用的日志内容。通过筛选traceID，可以获取某个接口调用的完整内容，并且确定接口调用的先后顺序。

在获取某次接口调用的完整记录后，通过模式匹配来获取接口调用的关键信息，包括应用的被调用接口名称、入参及入参类型、接口返回结果，以此来作为测试用例的基础数据，并保存为指定格式的文件作为测试用例。

在日志中，需要按照约定，应用容器在获取到接口调用内容后，将打印出“调用接口为:”+URL的日志，由此可以解析出被调用的接口。此外，还需要打印出“参数为：”+参数列表的日志，以及“参数类型”+参数类型列表，由此两项可以确定接口的入参的名称、类型和具体值。

在接口调用的最后，还需要打印出“接口调用成功，返回值为”+返回值列表，由此可以确定接口调用结果作为测试用例的预期结果。对于用户个人隐私信息、账号密码等数据则需要额外进行替换处理。

如果该服务存在对其它微服务的服务间调用的，也按照上述方案，抓取对其它微服务请求以及返回结果，作为自动化测试时的mock服务响应内容。

由于应用框架统一了服务调用的入口，接口开发人员无需为每个接口编写上述日志，由框架在接口调用时自行处理生成上述日志。

对日志的解析是通过traceID这一参数(该参数能够唯一区别并筛选出一次接口调用的日志内容)来实现。通过模式匹配获取接口调用的关键信息，包括应用的被调用接口名称、入参及入参类型、接口返回结果等，以此来作为测试用例的基础数据，并保存为指定格式的文件(例如为csv文件)作为测试用例。对于用户个人隐私信息、账号密码等数据则需要额外进行替换处理。

根据被测微服务的接口调用方式，通过测试夹具解析扫描指定目录下的csv文件，根据扫描结果生成运行时的测试用例并执行和断言。

步骤5：生成的测试用例的用例集被其他用户下载到对应的本地测试环境中。

步骤6：在本地测试环境中被用户执行下载的测试用例，并将测试结果上传到用例管理系统。

扫描本地测试环境中的指定目录，通过测试夹具根据发现的csv测试文件列表进行用例的执行并生成测试结果报告。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。