CN110389889A - 用于测试用例的可视化的方法、设备和计算机可读存储介质 - Google Patents

Abstract

本公开的实施例提供了用于测试用例的可视化的方法、设备和计算机可读存储介质。在一个实施例中，获得测试数据文件，其中记录用于手动测试用例的第一测试数据和第一组元数据，以及用于自动化测试用例的第二测试数据和第二组元数据。基于第一组元数据和第二组元数据，引起手动测试用例和自动化测试用例的可视化呈现。以此方式，显著提高了测试用例的评审、维护、更新和管理等过程的效率。

Description

用于测试用例的可视化的方法、设备和计算机可读存储介质

技术领域

本公开的实施例总体上涉及计算机技术，更具体地，涉及用于测试用例的可视化的方法、设备和计算机可读存储介质。

背景技术

在软件开发过程中，为了保证软件的正确性、完整性、安全性等质量指标，通常需要进行软件测试。一种常规的软件测试方式是针对不同的测试需求，设计专门的测试用例来验证软件相应功能和性能。目前，测试用例的设计已经成为软件测试的核心，而“如何创建和维护测试用例”成为整个软件开发过程中的关键。

设计测试用例的一种传统方式是测试人员分别设计或创建手动测试用例和自动化测试用例。手动测试用例可以采用Excel电子表格的形式，或者可以利用其他用例库来创建。用例库例如包括诸如RQM(Rational Quality Manager)的需求分析模型，诸如TestLink的用例管理系统，诸如质量中心(QC)的测试管理工具，等等。

测试人员可以将部分手动测试用例转化为自动化测试用例。例如，测试人员可以将用于自动化测试用例的测试数据编写为源代码的一部分。自动化测试数据通常被组织为特定的数据格式，诸如可标记扩展语言(XML)、另一个多栏布局(YAML)、JSON(Java ScriptObject Notation)、逗号分隔值(CSV)等等，或者由其他数据库来实现。

这种测试用例的设计和开发，通常需要测试人员花费很多时间和精力。例如，测试人员首先要开发手动测试用例，然后再将手动测试用例转化为自动化测试用例。这种转化不仅耗时费力，有时候还很难实现，因为手动测试用例通常是从终端用户视角创建的。

另外，手动测试用例和自动化测试用例需要分别进行评审以及分别进行后续的功能更新和维护。这非常繁琐并且效率很低。而且，手动测试用例和自动化测试用例的修改和更新很难同步。

发明内容

总体上，本公开的实施例提出了用于测试用例的可视化的方法、设备和计算机可读存储介质。

在第一方面，本公开的实施例提供了一种测试用例的可视化的方法。在方法中，获得测试数据文件。测试数据文件中记录用于手动测试用例的第一测试数据和第一组元数据，以及用于自动化测试用例的第二测试数据和第二组元数据。基于第一组元数据和第二组元数据，引起手动测试用例和自动化测试用例的可视化呈现。

在第二方面，本公开的实施例提供了一种用于测试用例的可视化的设备。该设备包括处理器以及存储有计算机可执行指令的存储器。计算机可执行指令在被处理器执行时使得设备执行动作，动作包括：获得测试数据文件，测试数据文件中记录用于手动测试用例的第一测试数据和第一组元数据，以及用于自动化测试用例的第二测试数据和第二组元数据；以及基于第一组元数据和第二组元数据，引起手动测试用例和自动化测试用例的可视化呈现。

在第三方面，本公开的实施例提供了一种计算机可读存储介质，其上存储有计算机可执行指令。该计算机可执行指令在处理器中被执行时，使得处理器执行根据第一方面的方法。

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

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：

图1示出了测试用例的传统设计和审核过程；

图2示出了根据本公开的某些实施例的测试用例的可视化过程；

图3示出了思维导图的示例结构；

图4示出了根据本公开的某些其他实施例的测试用例的可视化过程；

图5示出了根据本公开的某些实施例的思维导图形式的测试用例；

图6示出了根据本公开的某些实施例的方法的流程图；以及

图7示出了适合实现本公开的实施例的设备的框图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

在此使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”。其他术语的相关定义将在下文描述中给出。

图1示出了测试用例的传统设计和审核方式的示例过程100。如图1所示，首先由测试人员105设计手动测试用例(框110)。手动测试用例可以采用Excel电子表格或其他用例库来创建。然后，由测试人员105设计自动化测试用例(框115)。自动化测试用例可以是由至少一部分手动测试用例转化来的。备选地，自动化测试用例可以是测试人员105根据测试需求而专门创建的。

用于自动化测试用例的测试数据通常是源代码的一部分，其可以被组织为诸如XML、YAML、JSON、CSV等等特定的数据格式。下面是YAML格式的测试数据的一个示例。

自动化测试通常是数据驱动的。这使得可以采用单一的自动化测试用例来执行多组测试数据。下面是自动化测试过程中所使用的一段示例代码：

可以利用多个测试数据迭代地执行上述代码，从而迭代地执行同一测试过程。

如上所述，这种单独设计手动和自动测试用例的方式，通常需要测试人员花费很多时间和精力。另外，在创建手动测试用例和自动化测试用例时，测试人员可能需要针对服务层或应用编程接口(API)调用创建API自动化，因此无法全面了解这两个创建阶段。

在测试用例创建完成后，如图1所示，由包括测试人员、评审人员和管理人员的工程团队120分别对手动测试用例和自动化测试用例进行评审、维护、更新和管理等等。如上所述，这个过程非常繁琐并且效率很低。另外，对于传统的Excel电子表格形式的或者使用其他用例库创建的手动测试用例，由于可读性较差，其评审以及后续维护、更新和管理等都不容易实施。

本公开的实施例提供了一种测试用例可视化的方式。在该方式中，用于手动测试用例和自动化测试用例的测试数据和元数据被记录在测试数据文件中。利用这种测试数据文件，实现了测试用例的可视化呈现。以此方式，显著提高了测试用例的评审、维护、更新和管理等过程的效率。

测试用例的可视化，使得查看界面更加友好，更易于评审、维护、更新和管理。而且，只需要创建、维护、更新和管理测试数据文件，大大减轻了工程团队的工作负担量。因此，包括设计、创建和审查等的整个测试用例生命周期的效率被大大提高。

图2示出了根据本公开的某些实施例的测试用例的示例可视化过程200。在此示例中，过程200由转换器205实施。转换器205可以由硬件、软件或者其组合实现。作为示例，转换器205可以由存储器中存储的、由处理器可执行的计算机程序代码来实现。

转换器205获得测试数据文件210-1、210-2……210-N，统称为测试数据文件210。测试数据文件210中记录用于手动测试用例的测试数据(称为“第一测试数据”)和一组元数据(称为“第一组元数据”)，以及用于自动化测试用例的测试数据(称为“第二测试数据”)和一组元数据(称为“第二组元数据”)。

第一组元数据和第二组元数据可以包括与相应的测试用例有关的任意适当信息。例如，这些信息可以包括但不限于，诸如用例名称、用例标识符(ID)和用例作者的用例标识，例如表示用例是手动还是自动化的用例类型，例如指示用例属于测试过程的哪一级的用例层级，以及用例功能描述，等等。

测试数据文件210可以记录任意适当数目和类型的测试用例的相关测试数据和元数据。在某些实施例中，一个测试数据文件210中可以记录手动和自动化测试用例两者的测试数据和元数据。

在某些其他实施例中，一个测试数据文件210可以仅记录一种类型的测试用例的测试数据和元数据。例如，测试数据文件210可以包括一个或多个手动测试数据文件以及一个或多个自动测试数据文件。手动测试数据文件中记录手动测试用例的第一数据和第一元数据。自动化测试数据文件中记录自动化测试用例的第二数据和第二元数据。

手动测试数据文件可以例如由图1中的测试人员105手动设计或创建。而自动化测试数据文件可以例如由测试人员105基于手动测试数据文件中的至少一部分测试数据设计或创建，或者基于功能或测试要求变化或更新而设计或创建。

手动测试数据文件和自动化测试数据文件都可以采用任意适当格式。在某些实施例中，为了进一步提高测试用例自动化效率，手动和自动化测试数据文件可以具有相同的文件格式。例如，二者可以都为YAML文件。

转换器205在获取测试数据文件210之后，基于其中记录的用于手动测试用例的第一组元数据和用于自动化测试用例的第二组元数据，实现手动测试用例和自动化测试用例的可视化呈现215。可视化呈现215可以任意适当形式实现。在某些实施例中，可以基于第一组元数据和第二组元数据，确定手动测试用例和自动化测试用例在测试过程中的层级，继而以可视化的方式呈现手动测试用例和自动化测试用例的层级。

可以采用任意适当形式的组织结构来可视化地呈现测试用例。在图2所示的示例中，以树形结构，可视化地呈现了手动测试用例和自动化测试用例在测试过程中所处的层级。所示出的树形结构具有三层。根节点220表示测试过程的第一级，第一级子节点225-1、225-2和225-3(统称为“第一级子节点225”)表示测试过程的第二级。叶子节点230-1、230-2……230-7(统称为“叶子节点230”)表示具体的测试用例，包括手动测试用例和自动化测试用例中的至少一种测试用例。

在某些实施例中，可以思维导图的形式来可视化地呈现测试用例。思维导图是一种高效的笔记记录形式，通常具有中心向四周辐射的组织结构。图3示出了思维导图的示例结构300。如图3所示，在结构300中，从位于中心的主题305，向四周辐射出四个构思310-1到310-4，再从四个构思310-1到310-4辐射出八个子构思315-1到315-8。

利用这种思维导图，单调的Excel形式的手动测试用例可以被转化为高度组织化且可视性较高的图表。这样，使用思维导图来演示测试用例，有助于包括测试人员、评审人员或者管理人员的工程团队快速从可视化结构中获取测试点，并且有利于工程团队进行分析和回顾。

图4示出了根据本公开的某些其他实施例的测试用例的示例可视化过程400。在过程400中，首先由测试人员105将手动测试用例和自动化测试用例的测试数据和元数据都放入测试数据文件210(框405)。在此示例中，测试数据文件210包括手动测试数据文件和自动化测试数据文件，分别用于记录手动测试用例和自动化测试用例的测试数据和元数据。手动测试数据文件和自动化测试数据文件都是YAML或XML文件。

转换器205将测试数据文件210转换为以可视化方式呈现的手动测试用例和自动化测试用例。在此示例中，转换器205借助于可视化转换工具(例如，思维导图工具)，将YAML或XML文件格式的测试数据文件转换为例如思维导图的形式的手动和自动化测试用例。另外，如图4所示，转换器205还可以借助思维导图工具，将思维导图形式的测试用例反向转换为测试数据文件，从而实现测试驱动开发(TDD)。

这种思维导图形式的测试用例，可以展示所测试的全部功能模块或功能点的概况，便于工程团队120查看。在需要修改或更新测试用例时，测试人员105只需修改或更新测试数据文件210。继而，转换器205可以利用可视化转换工具将更新后的测试数据文件再次转换为思维导图形式的测试用例。

下面讨论一个具体的应用场景。在此示例中，测试数据文件210包括YAML文件格式的手动测试数据文件和自动化测试文件。手动测试数据文件的代码如下：

上述代码中的“fci_change_job_status”和“fci_cleanup”表示测试的功能。元数据“id”表示用例标识符，“author”表示用例的作者，“description”表示用例的功能描述。元数据“level”表示用例类型，其中“skip”表明用例是手动的。

自动化测试数据文件的代码如下：

在上述代码中，“fci_documents”表示测试的功能。元数据“id”表示用例标识符，“author”表示用例的作者，“description”表示用例的功能描述。元数据“level”表示用例类型，其中“smoke”表明用例是自动化的。

所生成的思维导图形式的测试用例如图5所示。在图5中，“test_avamar_fci_api”表示测试模块，从测试模块分出第一级测试子模块“fci documents”、“fci change jobstatus”和“fci cleanup”，再从第一级测试子模块分出下一级测试子模块，以此类推。数字“2”表示某一类别(例如，具有某种重要程度)的自动化测试用例。还可以用数字“1”和“3”表示其他类别(例如，具有其他重要程度)的自动化测试用例。数字“4”表示手动测试用例。数字后面是用例的功能描述。

这种可视化地呈现测试用例的方式大大简化了包括测试人员、审核人员和管理人员的工程团队的工作负荷，明显提高了工程团队的满意度。例如，测试人员只需要管理和维护测试数据文件，而不再需要单独创建、维护和更新手动测试用例和自动化测试用例。这样，每个迭代周期的开发和维护工作量大大降低。而且，测试人员不再需要面对手动测试用例到自动化测试用例的转化有时候很难实施的问题。

对于审核人员而言，可视化的测试用例更易于查看和审核，使得审核时间被大大缩减。而且，审核人员更易于对可视化的测试用例提出修改建议。对于管理人员而言，测试数据文件更容易被集中管理。管理人员还很容易获得有关自动化覆盖率、每个模块的案例覆盖率等等的统计信息。

图6示出了根据本公开的某些实施例的示例方法600的流程图。方法600可以在如图2所示的转换器205处实施。

如图所示，在框605，获得测试数据文件210。测试数据文件中记录用于手动测试用例的第一测试数据和第一组元数据，以及用于自动化测试用例的第二测试数据和第二组元数据。在框610，基于第一组元数据和第二组元数据，引起手动测试用例和自动化测试用例的可视化呈现。

在某些实施例中，测试数据文件可以包括手动测试数据文件和自动化测试数据文件。手动测试数据文件中记录第一测试数据和第一组元数据。自动化测试数据文件中记录第二测试数据和第二组元数据。

在某些实施例中，手动测试数据文件和自动化测试数据文件具有相同的格式。

在某些实施例中，可以基于第一组元数据和第二组元数据，确定手动测试用例和自动化测试用例在测试过程中的层级。继而，按照所确定的层级，引起手动测试用例和自动化测试用例的可视化呈现。

在某些实施例中，第一组元数据和第二组元数据中的至少一组元数据包括以下中的至少一项：用例标识、用例类型、用例层级和用例功能描述。

在某些实施例中，可视化呈现是思维导图形式的呈现。

在某些实施例中，还可以确定可视化地呈现的手动测试用例和自动化测试用例中的至少一项的改变，并且基于所确定的改变更新测试数据文件。

应理解，上文结合图2到图5描述的转换器205所执行的操作和相关的特征同样适用于方法600，并且具有同样的效果，具体细节不再赘述。

图7示出了一个可以用来实施本公开的实施例的设备700的示意性框图。如图7所示，设备700包括控制器或处理器，或者称中央处理单元(CPU)701，其可以根据存储在只读存储器(ROM)702和/或随机访问存储器(RAM)703的程序而执行各种适当的动作和处理。ROM702和/或RAM 703可存储设备700操作所需的各种程序和数据。CPU 701、ROM 702和RAM 703通过总线704彼此相连。特别地，设备700还包括一个或多个专用处理单元(未示出)，这些专用处理单元也可以连接至总线704。

输入/输出(I/O)接口705也连接至总线704。设备700中的多个部件连接至I/O接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。特别地，在本公开的实施例中，通信单元709支持与客户端或者其他设备的通信。

在某些实施例中，CPU 701可被配置为执行上文所描述的各个过程和处理，例如方法600。例如，在一些实施例中，方法600可被实现为计算机软件程序，其被有形地包含于计算机可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序被加载到RAM703并由CPU 701执行时，可以执行上文描述的方法600的一个或多个步骤。备选地，在其他实施例中，CPU 701也可以以其他任何适当的方式被配置以实现上述过程/方法。

特别地，根据本公开的实施例，上文参考图2至图6描述的过程可以被实现为计算机程序产品，其可以被有形地存储在非瞬态计算机可读存储介质上，并且包括计算机可执行指令，该指令在被执行时使得设备实现根据本公开的各个方面。

计算机可读存储介质可以是可以存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以包括但不限于电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的、非穷举的例子包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，编程语言包括面向对象的编程语言—诸如Java、Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这里参照根据本公开实施例的设备、方法和计算机程序产品的框图和/或流程图描述了本公开的各个方面。应当理解，框图和/或流程图的每个方框以及框图和/或流程图中各方框的组合，都可以由计算机可读程序指令实现。

已经出于示例的目的描述了本公开的各个实施例，但是本公开并不意图限于所公开的这些实施例。在不脱离本公开实质的前提下，所有修改和变型均落入由权利要求所限定的本公开的保护范围之内。

Claims (15)

1.一种测试用例的可视化的方法，包括：

获得测试数据文件，所述测试数据文件中记录用于手动测试用例的第一测试数据和第一组元数据，以及用于自动化测试用例的第二测试数据和第二组元数据；以及

基于所述第一组元数据和所述第二组元数据，引起所述手动测试用例和所述自动化测试用例的可视化呈现。

2.根据权利要求1所述的方法，其中所述测试数据文件包括手动测试数据文件和自动化测试数据文件，所述手动测试数据文件中记录所述第一测试数据和所述第一组元数据，并且所述自动化测试数据文件中记录所述第二测试数据和所述第二组元数据。

3.根据权利要求2所述的方法，其中所述手动测试数据文件和所述自动化测试数据文件具有相同的格式。

4.根据权利要求1所述的方法，其中引起所述可视化呈现包括：

基于所述第一组元数据和所述第二组元数据，确定所述手动测试用例和所述自动化测试用例在测试过程中的层级；以及

按照所确定的层级，引起所述手动测试用例和所述自动化测试用例的所述可视化呈现。

5.根据权利要求1所述的方法，其中所述第一组元数据和所述第二组元数据中的至少一组元数据包括以下中的至少一项：用例标识、用例类型、用例层级和用例功能描述。

6.根据权利要求1所述的方法，其中所述可视化呈现是思维导图形式的呈现。

7.根据权利要求1所述的方法，还包括：

确定可视化地呈现的所述手动测试用例和所述自动化测试用例中的至少一项的改变；以及

基于所确定的改变，更新所述测试数据文件。

8.一种用于测试用例的可视化的设备，包括：

处理器，以及

存储有计算机可执行指令的存储器，所述计算机可执行指令在被所述处理器执行时使得所述设备执行动作，所述动作包括：

获得测试数据文件，所述测试数据文件中记录用于手动测试用例的第一测试数据和第一组元数据，以及用于自动化测试用例的第二测试数据和第二组元数据；以及

基于所述第一组元数据和所述第二组元数据，引起所述手动测试用例和所述自动化测试用例的可视化呈现。

9.根据权利要求8所述的设备，其中所述测试数据文件包括手动测试数据文件和自动化测试数据文件，所述手动测试数据文件中记录所述第一测试数据和所述第一组元数据，并且所述自动化测试数据文件中记录所述第二测试数据和所述第二组元数据。

10.根据权利要求9所述的设备，其中所述手动测试数据文件和所述自动化测试数据文件具有相同的格式。

11.根据权利要求8所述的设备，其中引起所述可视化呈现包括：

基于所述第一组元数据和所述第二组元数据，确定所述手动测试用例和所述自动化测试用例在测试过程中的层级；以及

按照所确定的层级，引起所述手动测试用例和所述自动化测试用例的所述可视化呈现。

12.根据权利要求8所述的设备，其中所述第一组元数据和所述第二组元数据中的至少一组元数据包括以下中的至少一项：用例标识、用例类型、用例层级和用例功能描述。

13.根据权利要求8所述的设备，其中所述可视化呈现是思维导图形式的呈现。

14.根据权利要求8所述的设备，其中所述动作还包括：

确定可视化地呈现的所述手动测试用例和所述自动化测试用例中的至少一项的改变；以及

基于所确定的改变，更新所述测试数据文件。

15.一种计算机可读存储介质，其上存储有计算机可执行指令，所述计算机可执行指令在被处理器执行时使得所述处理器执行根据权利要求1至7中任一项所述的方法。