一种测试用例的生成方法及装置与流程

本发明实施例涉及信号处理领域，尤其涉及一种测试用例的生成方法及装置。

背景技术：

随着软件功能的不断增强，版本更替越来越快，自动化测试作为软件测试的一个重要一环的地位也随之水涨船高，逐渐形成一股在测试行业中的风潮，越来越多的软件企业在他们的测试计划中加入了自动化测试的时间表，而对于测试人员，是否具备一种或者多种自动化测试能力也逐渐的成为晋升和评判的重要评判依据。

自动化工具的开发如图1所示，有如下的流程：在文档接收阶段进行需求接收的工作，并进行设计，产生设计文档。在代码编译和控制阶段进行自动化工具的开发工作，产生自动化脚本及用户指导手册，在代码走查阶段进行自动化工具的测试，输出测试结果，最后在代码提交阶段，将修改后的bug代码合并，形成最终的自动化工具，完成需求。

目前自动化工具的设计和使用过程中，是需要测试人员同时具备编码能力的，但在我国，自动化测试还处于一个蹒跚学步的时期，测试人员的技术水平，尤其是对语言的掌握普遍偏低，选择测试工作的从业者往往是因为不懂代码，无法承担开发工作才退而求其次，因此传统的自动化测试存在开发人员不懂业务，使用人员不懂代码的尴尬问题，测试用例稍有变动就需要开发人员修改代码，加大了开发人员的工作量，使得自动化测试实际用起来并不高效。

技术实现要素：

本发明实施例提供一种测试用例的生成方法及装置，以解决在进行测试时，测试用例需要重新编写代码，导致测试低效的问题。

第一方面，本发明实施例提供了一种测试用例的生成方法，该方法包括：

获取用户根据测试计划制定的测试用例所需的RA(Reusable Action，可重用行为)列表；

接收用户指定的所述RA列表中的RA对应的代码的路径；

根据所述路径，获取所述RA列表中的RA对应的代码；

根据所述RA列表，将所述RA对应的代码拼装为所述测试用例。

进一步的，在将所述RA对应的代码拼装为所述测试用例之后，还包括：

接收用户创建的由至少一个所述测试用例组成的测试用例集。

进一步的，在接收用户创建的由至少一个所述测试用例组成的测试用例集之后，还包括：

接收用户设定的至少一个所述测试用例集的执行时间；

按照所述执行时间，执行所述至少一个所述测试用例集。

进一步的，在执行所述至少一个所述测试用例集之后，还包括：

在接收到用户的查看测试结果的指令时，显示执行所述测试用例集得到的测试结果。

进一步的，该方法还包括：

记录在所述测试用例集的执行过程中的日志文件。

第二方面，本发明实施例还提供了一种测试用例的生成装置，该装置包括：

RA列表获取模块，用于获取用户根据测试计划制定的测试用例所需的RA列表；

路径接收模块，用于接收用户指定的所述RA列表中的RA对应的代码的路径；

代码获取模块，用于根据所述路径，获取所述RA列表中的RA对应的代码；

测试用例拼装模块，用于根据所述RA列表，将所述RA对应的代码拼装为所述测试用例。

进一步的，该装置还包括：

测试用例集接收模块，用于在将所述RA对应的代码拼装为所述测试用例之后，接收用户创建的由至少一个所述测试用例组成的测试用例集。

进一步的，该装置还包括：

执行时间接收模块，用于在接收用户创建的由至少一个所述测试用例组成的测试用例集之后，接收用户设定的至少一个所述测试用例集的执行时间；

测试用例集执行模块，用于按照所述执行时间，执行所述至少一个所述测试用例集。

进一步的，该装置还包括：

测试结果显示模块，用于在执行所述至少一个所述测试用例集之后，在接收到用户的查看测试结果的指令时，显示执行所述测试用例集得到的测试结果。

进一步的，该装置还包括：

日志文件记录模块，用于记录在所述测试用例集的执行过程中的日志文件。

本发明实施例通过获取用户根据测试计划制定的测试用例所需的可重用行为RA列表，根据用户指定的所述RA列表中的RA对应的代码的路径，获取所述RA列表中的RA对应的代码，根据所述RA列表，将所述RA对应的代码拼装为所述测试用例，实现了根据RA对应的代码进行测试用例的灵活拼装，完成自动化测试，简化测试流程，提高测试效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图做一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术中自动化工具的开发流程图；

图2是本发明实施例一提供的一种测试用例的生成方法的流程示意图；

图3是本发明实施例一提供的一种测试流程图；

图4是本发明实施例二提供的一种测试用例的生成方法的流程示意图；

图5是本发明实施例提供的一种测试的架构图；

图6是本发明实施例提供的一种自动化测试的流程图；

图7是本发明实施例三提供的一种测试用例的生成装置的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，以下将参照本发明实施例中的附图，通过实施方式清楚、完整地描述本发明的技术方案，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

图2是本发明实施例一提供的一种测试用例的生成方法的流程图。本实施例的技术方案可以适用于根据测试计划生成测试用例进行自动化测试的情况。该方法可以由本发明实施例提供的一种测试用例的生成装置来执行，该装置可以采用软件和/或硬件的方式实现。该方法具体包括如下操作：

S110、获取用户根据测试计划制定的测试用例所需的RA列表。

其中，RA是可重用行为，在执行测试任务时，可以实现某一功能，并且可以重复执行的步骤。RA列表是筛选得到的测试用例中适合进行自动化测试的用例中按功能划分的不同RA按照顺序排列的列表。

测试人员即所述用户在接到一个测试任务时，制定测试计划，根据测试计划制定测试用例，测试用例对应有需要的RA列表。测试用例的生成装置获取该RA列表，以便对RA列表中的RA进行相应操作。

图3示出了一种测试流程图，如图所示，根据测试计划制定的测试用例可以是测试人员从手工测试用例中筛选出适合进行自动化测试的用例，根据筛选出的自动化测试用例的步骤编写出RA列表，用来标注自动化测试用例需要哪些RA和所需RA的排列顺序，为后续的拼装做准备。根据RA列表编写RA设计文档，该文档为对RA进行编码时的需求文档，规定了RA的行为和输入输出参数，RA设计文档在进行评审合格后提交。一般该阶段过程在第一轮手工测试前完成，之后测试人员进入第一轮手工测试阶段，自动化流转到第二阶段，即开发阶段。

在将手工测试用例中的每一步分解成为可重用的RA时，需要记录每个RA的行为描述，行为描述即具体步骤。示例性的，若RA是实现登录网站的功能，那么该RA的行为就是打开浏览器，登录某个网页，然后输入用户名密码等，每一步要分开写，对应脚本里的每一个动作，这样开发人员通过该文档就能了解都有哪些行为需要实现。

可以采用任何脚本工具进行编码得到RA对应的代码，优选采用QTP(Quick Test Professional，自动化测试工具)编码。

标准的QTP脚本是在test文件中进行编程的，好处是可以在编写完成后直接运行脚本进行调试，直接而简便，但是软件规模大，模块多，会需要几百个RA进行覆盖。如果几百个RA都各自编写自己的执行逻辑，存放于各自的test文件中，那么一旦版本变更，有相关的模块功能发生了变化，那么就需要分别到对应的test文件下去修改代码，但是RA的数量如此巨大的前提下，很容易在修改的过程中遗漏脚本或者产生错误，这样就大大降低了自动化工作的灵活性。因此，将每个RA分为参数设定和逻辑处理两个部分，采用QTP的库文件的功能，参数设定部分放在test文件中，而逻辑处理功能根据模块的划分统一放在和逻辑处理功能相关的模块下，如搜索相关的RA逻辑都被写入search这个库文件中，这样当对应模块的功能版本发生更替的时候，仅需要修改这一个文件就可以起到变更脚本的目的，有效提升效率。

S120、接收用户指定的所述RA列表中的RA对应的代码的路径。

在进行自动化测试时,用户可以指定RA列表中的每个RA对应的代码所在的存储路径。接收用户指定的RA列表中的RA对应的代码的路径，以方便调用RA对应的代码。RA对应的代码的存放路径，同时也是RA设计文档的存放路径。示例性的，所述路径可以是：

C:\Transfer_automation\qtp\reusable\Transfer\common\login

其中“common”表示RA设计文档所属的分类，“login”代表行为的名称。

S130、根据所述路径，获取所述RA列表中的RA对应的代码。

根据接收到的用户指定的RA列表中的RA对应的代码的路径，则可以获取到RA列表中的RA对应的代码。

如图3所示，开发人员接到测试人员提交的RA设计文档，并开始根据文档进行QTP代码的编码工作，在完成后进行对应的评审工作，校验代码中的参数及行为是否完全按照设计文档进行编码，单元测试结果是否通过，之后将代码入库并提交回测试人员手中，该阶段与第一轮手工测试同时进行，在第一轮测试结束前提交到测试人员手中，此时自动化流转到第三阶段，即测试阶段。

经过QTP编码之后的RA需要对应该RA的自身功能进行概述。示例性的，若RA是访问91助手网站，对某一版本的软件进行版本获取，对应这个RA是登录网站的RA，那么在概述时，直接写这个RA是登录91助手网站功能即可。

RA对应有前置条件，所述前置条件包括硬件条件和步骤条件，其中硬件条件表示该操作需要某些设备的调通或者硬件支持，比如需要万兆网卡，步骤条件包括搜索网站使用前可能需要先登录等。执行完RA之后，用后置条件列出后置状态。

RA对应的输入和输出参数中，每个参数必须要有“必选”或者“可选”的标记，“必选”表示该参数的值不能为空；“可选”表示该参数可以为空，或者有默认值。每个参数后面还需要描述该参数功能，默认值，取值范围等也是必填的。示例性的：超时(可选,创建链接超时时长，默认为“3”)；用户名(必选,登录用户名，默认为空)。

S140、根据所述RA列表，将所述RA对应的代码拼装为所述测试用例。

根据所述RA列表中的RA顺序将所述RA对应的代码拼装为所述测试用例。其中，RA对应的代码可以在已有的RA代码中根据每个RA的逻辑功能进行搜索得到。如果RA列表中所有RA对应的代码均在已有的RA代码中存在，就不再需要开发人员进行编码，而可以直接使用已有代码，可以大大简化测试流程，提高测试效率；只有在RA列表中的RA对应的代码在已有代码中不存在时，才返回给开发人员进行该RA的编码。

如图3所示，测试人员在网管软件开发人员修改第一轮测试提交的bug的时间内进行对RA的拼装工作，由此可以保证测试和开发的并行处理，彼此不会相互干扰。按照RA列表的顺序将对应的RA拼装成对应的用例并进行评审，评审内容为是否按照要求拼装用例。在完成评审后提交用例并进行用例的自动化执行，每个用例至少连续执行三次并没有任何问题为执行通过标准，对QTP代码本身或者EMS(Electro Magnetic Susceptibility，电磁抗干扰能力)的问题进行bug的提交，最终产生测试报告，QTP开发人员对问题进行对应代码的修改和验证工作。

本实施例的技术方案，通过获取用户根据测试计划制定的测试用例所需的可重用行为RA列表，根据用户指定的所述RA列表中的RA对应的代码的路径，获取所述RA列表中的RA对应的代码，根据所述RA列表，将所述RA对应的代码拼装为所述测试用例，实现了根据RA对应的代码进行测试用例的灵活拼装，完成自动化测试，简化测试流程，提高测试效率。在测试用例发生变化的时候，如果这个用例不需要新的RA支持(没有新的操作方法)，测试人员就可以不需要开发人员，自己重新拼装RA，完成自动化测试用例的修改，大大提高了效率。

在本实施例的一个优选实施方式中，在将所述RA的代码拼装为所述测试用例之后，还包括：

接收用户创建的由至少一个所述测试用例组成的测试用例集。

每个测试任务可以对应至少一个测试用例，所有的测试用例组成测试用例集，测试工具接收用户创建的由至少一个测试用例组成的测试用例集，由此可以实现，对应相同的测试任务，由测试用例集进行测试，保证了测试的充分性。

实施例二

图4是本发明实施例二提供的一种测试用例的生成方法的流程图。本发明实施例在上述实施例的基础上，在接收用户创建的由至少一个所述测试用例组成的测试用例集之后，进一步增加了接收用户设定的至少一个所述测试用例集的执行时间；按照所述执行时间，执行所述至少一个所述测试用例集的操作。

相应的，本实施例的方法包括：

S210、获取用户根据测试计划制定的测试用例所需的RA列表。

S220、接收用户指定的所述RA列表中的RA对应的代码的路径。

S230、根据所述路径，获取所述RA列表中的RA对应的代码。

S240、根据所述RA列表，将所述RA对应的代码拼装为所述测试用例。

S250、接收用户设定的至少一个所述测试用例集的执行时间。

S260、按照所述执行时间，执行所述至少一个所述测试用例集。

所述执行时间即测试时间。所述执行至少一个测试用例集即应用测试用例集对待测软件进行测试。针对不同的测试任务，设定不同的测试用例集，可以为每个测试用例集设定进行测试的时间，测试工具接收用户设定的至少一个所述测试用例集的执行时间。由此可以保证，用户根据需要自主设定对应不同的测试任务的测试用例集进行测试的时间，提升了用户体验，保证了测试任务的有序进行。

在执行所述至少一个测试用例集的过程中需要进行错误处理，即应对出现的错误定位错误的消息并且给出处理错误的行为。示例性的：如果登录失败，则显示的错误信息为：“该用户登录失败”，对应的后续行为为：“FAIL”数加1。

本发明实施例通过接收用户设定的至少一个所述测试用例集的执行时间，按照所述执行时间，执行所述至少一个所述测试用例集，实现了按照测试用例集的执行时间有序进行自动测试，保证了测试的效率。

在本实施例的一个优选实施方式中，在执行所述至少一个所述测试用例集之后，还包括：

在接收到用户的查看测试结果的指令时，显示执行所述测试用例集得到的测试结果。

测试结果可以以HTTP文件的形式存储在某一预设的文件夹下。测试结果可以用饼状图、柱状图或折线图等形式显示。

在本实施例的一个优选实施方式中，本方法还包括：记录在所述测试用例集的执行过程中的日志文件。

所述日志文件可以包括组成测试用例的RA对应的代码存在的bug。如果RA对应的代码存在bug，则需要返回给开发人员进行修改。

图5中示出了一种测试的架构图。其中，TLI(Transport Layer Interface,传输层接口)控制台和CLI(Command Line Interface，命令行接口)控制台支持测试对象为输入的字符串的形式，EMS GUI(Graphical User Interface，图形用户界面)支持测试对象为GUI的形式，由此可以保证测试对象的全面。从图中可以看出，层3部分就是测试人员进行RA拼装的界面，优选TK操作界面，T是一个利用TCL脚本语言来编写GUI的工具箱。所述TK操作界面的功能包括测试用例管理，测试用例拼装，测试用例安排，查看测试结果和记录log。其中，测试用例拼装用于将测试用例所需的RA进行拼装，测试用例管理用于控制测试用例的执行与不执行，测试用例安排用于设定测试用例的执行时间。整个界面可以用任意支持GUI的脚本语言完成，这里选用的是TCL(Tool Command Language，脚本语言)，用户通过使用该功能，可以不接触QTP和TCL的代码就能完成用例管理，拼装等工作，每个用户可以创建独立的测试用例集，加载不同的测试用例，还可以按照自己需要的顺序来拼装和调试他们，最后可以通过直观的测试报告来监控执行结果。

层2完成的是拼装工具的后台部分，实现测试用例管理，测试用例拼装，测试用例安排，查看测试结果和记录log的功能，并且向RA进行参数传递的工作。TCL自身的函数库包含了TCL脚本管理器所需的所有函数库和数据文件，TCL通过他们对QTP进行操作和通信，传递参数和逻辑处理。完成从TK层下发的命令，这层的代码是TCL脚本管理工具的核心部分。

层1是RA的实体部分，这部分选用的是QTP进行编写，QTP通过执行这些RA直接对下面的管理对象进行操作，每个RA实际就是测试用例中的一个或者一组动作，这些动作连接在一起才组成了测试用例，可以看出，QTP的主要工作就是构建出这些测试用例的零件，用来完成自动化测试。

图6示出了一种自动化测试的流程图。当开始一个测试任务时，首先进入需求阶段，测试人员需要检测是否有新增用例，当有新增用例时，编写用例，并筛选用例，编写用例对应的RA列表，提交并评审RA列表是否通过，当通过时，编写RA设计文档，提交并评审RA设计文档是否通过，当通过时，RA设计文档利用CC文档管理器入库。然后进入编码阶段，开发人员对RA设计文档进行QTP编码，评审代码是否通过，当通过时，利用CC文档管理器将代码入库。最后进入测试阶段，测试人员输入RA拼装命令将RA拼装为对应的自动化测试用例，评审通过时，运行该自动化测试用例，并验证RA代码是否有bug,当有bug时，返回开发人员进行代码修改，修改之后的代码需要经过测试并通过，然后利用CC文档管理器将修改后的代码入库；当无bug时，完成测试，并发布测试报告。

实施例三

图7是本发明实施例三提供的一种测试用例的生成装置的结构框图。该装置用于执行上述任意实施例所提供的一种测试用例的生成方法。该装置包括：

RA列表获取模块310，用于获取用户根据测试计划制定的测试用例所需的RA列表；

路径接收模块320，用于接收用户指定的所述RA列表中的RA对应的代码的路径；

代码获取模块330，用于根据所述路径，获取所述RA列表中的RA对应的代码；

测试用例拼装模块340，用于根据所述RA列表，将所述RA对应的代码拼装为所述测试用例。

进一步的，该装置还包括：

测试用例集接收模块，用于在将所述RA对应的代码拼装为所述测试用例之后，接收用户创建的由至少一个所述测试用例组成的测试用例集。

进一步的，该装置还包括：

执行时间接收模块，用于在接收用户创建的由至少一个所述测试用例组成的测试用例集之后，接收用户设定的至少一个所述测试用例集的执行时间；

测试用例集执行模块，用于按照所述执行时间，执行所述至少一个所述测试用例集。

进一步的，该装置还包括：

测试结果显示模块，用于在执行所述至少一个所述测试用例集之后，在接收到用户的查看测试结果的指令时，显示执行所述测试用例集得到的测试结果。

进一步的，该装置还包括：

日志文件记录模块，用于记录在所述测试用例集的执行过程中的日志文件。

本发明实施例三提供的测试用例的生成装置，实现了根据RA对应的代码进行测试用例的灵活拼装，完成自动化测试，简化测试流程，提高测试效率。

本发明实施例所提供的测试用例的生成装置可执行本发明任意实施例所提供的测试用例的生成方法，具备执行方法相应的功能模块和有益效果。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。