CN114816969A - 测试用例的生成方法、装置、设备及存储介质 - Google Patents

Abstract

本申请涉及测试用例的生成方法、装置及存储介质，涉及软件测试领域，所述方法包括：在监测到剧本仓库中有新增的测试剧本时，将新增的测试剧本发送至第一客户端，所述测试剧本为在第二客户端生成并提交至所述剧本仓库中的剧本；响应于所述第一客户端发送的第一用例提交请求，在预设的待测试程序中执行第一测试用例，所述第一用例提交请求中包括所述第一测试用例，所述第一测试用例与所述测试剧本对应，所述第一测试用例用于对所述待测试程序的预设功能进行测试；在第一测试用例的执行结果为通过时，将第一测试用例确定为目标测试用例。本申请能生成用于对待测试程序的预设功能进行故障检测的目标测试用例，并能解决目标测试用例生成效率低的问题。

Description

测试用例的生成方法、装置、设备及存储介质

技术领域

本申请涉及软件测试领域，尤其涉及测试用例的生成方法、装置、设备及存储介质。

背景技术

测试用例是在项目进行过程中，为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实测试结果是否满足某个特定需求。

在现有的集成测试实践中，通常将测试剧本和测试用例托管至SVN(Subversion，版本控制系统)平台，具体的，在开发人员生成测试剧本后，将测试剧本托管至SVN平台，并通过人工分配给合作伙伴，合作伙伴根据测试剧本编写测试用例，并将编写后的测试用例托管至SVN平台，以分配给开发人员进行代码检查。但是，在实践中发现，上述方式会导致测试用例的生成效率低以及代码错误率高的问题，进而影响集成测试的效率，并易降低用户体验。

发明内容

本申请所要解决的技术问题在于，提供一种测试用例的生成方法、装置、设备及存储介质，能够解决现有测试实践过程中目标测试用例的生成效率低的问题。

为了解决上述技术问题，一方面，本申请提供了一种测试用例的生成方法，所述方法包括：在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端，所述测试剧本为在第二客户端生成并提交至所述剧本仓库中的剧本；响应于所述第一客户端发送的第一用例提交请求，在预设的待测试程序中执行第一测试用例，所述第一用例提交请求中包括所述第一测试用例，所述第一测试用例为在所述第一客户端生成的与所述测试剧本对应的用例，所述第一测试用例用于对所述待测试程序的预设功能进行测试；在所述第一测试用例的执行结果为通过时，将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

另一方面，本申请提供了一种测试用例的生成装置，所述装置包括：测试剧本发送模块，用于在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端，所述测试剧本为在第二客户端生成并提交至所述剧本仓库中的剧本；用例执行模块，用于响应于所述第一客户端发送的第一用例提交请求，在预设的待测试程序中执行第一测试用例，所述第一用例提交请求中包括所述第一测试用例，所述第一测试用例为在所述第一客户端生成的与所述测试剧本对应的用例，所述第一测试用例用于对所述待测试程序的预设功能进行测试；目标测试用例确定模块，用于在所述第一测试用例的执行结果为通过时，将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

另一方面，本申请提供了一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行如上述的方法。

另一方面，本申请提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如上述的方法。本申请实施例在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端，所述测试剧本为在第二客户端生成并提交至所述剧本仓库中的剧本；响应于所述第一客户端发送的第一用例提交请求，在预设的待测试程序中执行第一测试用例，所述第一用例提交请求中包括所述第一测试用例，所述第一测试用例为在所述第一客户端生成的与所述测试剧本对应的用例，所述第一测试用例用于对所述待测试程序的预设功能进行测试；在所述第一测试用例的执行结果为通过时，将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。如此，可以在第二客户端的用户(如开发人员)提交测试剧本至剧本仓库时，由剧本仓库自动将新增的测试剧本发送至第一客户端，以供第一客户端的用户(如合作伙伴)编写相应的测试用例，减少了第一客户端的用户和第二客户端的用户的沟通成本，提高了测试用例编写的及时性；并且，在第一客户端的用户编写完测试用例后，并不直接在平台托管测试用例，而是响应于第一客户端的用例提交请求，自动触发执行用例提交请求中的测试用例，并在测试用例的执行结果为通过时，将测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例，并可以在需要时将确认后的目标测试用例保存至用例仓库中，从而克服了现有技术中存在的测试用例在SVN平台的更新、第二客户端的用户手动触发执行用例等缺陷，提高了目标测试用例的生成效率。

附图说明

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

图1是本申请实施例提供的硬件环境示意图；

图2是本申请实施例提供的一种测试用例的生成方法的流程图；

图3是本申请实施例提供的一种测试用例的生成方法中在向第一客户端发送第一通知之前还可以包括的步骤的流程图；

图4是本申请实施例提供的一种测试用例的生成方法中还可以包括的对第一测试用例进行修改的流程图；

图5是本申请实施例提供的一种测试用例的生成方法中还可以包括的将所述目标测试用例存储至用例仓库的流程图；

图6是本申请实施例提供的一种测试用例的生成方法中的执行目标测试用例的流程图；

图7是本申请实施例提供的一种测试用例的生成方法的流程图；

图8是本申请实施例提供的一种测试用例的生成装置的结构示意图；

图9是本申请实施例提供的一种测试用例的生成设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述。显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请涉及以下关键术语，以下为各关键术语的含义。

DevOps：研发运营一体化技术，可自动化集成、部署、执行软件，提升软件交付效率。

Github：代码托管平台，提供hook能力，即在代码路径发生变化指定变化时，可终止该动作的执行，直至期待的事件发生。

集成测试：针对指定服务、接口进行的测试。

测试剧本：集成测试的剧本，是一种文本文件，记录某次测试的具体输入参数，以及期待的输出结果。

测试用例：测试剧本(文本文件)的代码化表达，是一种可执行的代码文件。

本申请实施例提供了一种测试用例的生成方法，可选地，在本申请实施例中，上述的测试用例的生成方法可以应用于如图1所示的第一终端101、服务器102和第二终端103所构成的硬件环境中。如图1所示，服务器102通过网络与第一终端101及第二终端103进行连接，上述网络包括但不限于：广域网、城域网或局域网，第一终端101和第二终端103并不限定于PC、手机、平板电脑等。本申请实施例的测试用例的生成方法可以由服务器102来执行，所述第一终端101中可以安装有用于供合作伙伴编写测试用例的第一客户端，所述第二终端103中可以安装有用于供开发人员编写测试剧本的第二客户端。

其中，服务器102可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、大数据和人工智能平台等基础云计算服务器。

在现有集成测试实践过程中，通常将测试剧本和测试用例托管至SVN(Subversion，版本控制系统)平台，例如，在开发人员编写好测试剧本后，将生成的测试剧本托管至SVN平台，合作伙伴(负责测试用例的编写)根据开发人员提供的剧本目录从SVN平台上获取测试剧本并根据测试剧本编写测试用例，在测试用例编写完成后，将编写的测试用例托管至SVN平台，由开发人员从SVN平台获取测试用例后，再由开发人员人工手动触发执行测试用例。

但是，本申请的发明人在研究过程中发现，合作伙伴根据开发人员提供的剧本目录在SVN平台查找测试剧本增加了合作伙伴和开发人员之间的沟通成本；并且，在现有实践测试过程中，不管测试用例编写如何，均需要将测试用例托管至SVN平台，由于编写的测试用例执行失败的可能性较高，意味着托管至SVN平台的测试用例可能为错误的用例，而在托管至SVN平台的测试用例为错误用例的情况下，还需要修改测试用例，并利用修改后的测试用例对SVN平台中错误的测试用例进行更新，继而再将更新后的测试用例发送给开发人员所在的终端，以供开发人员再次手动执行测试用例。在此过程中，受限于测试用例在SVN平台的更新、测试用例的发送过程(需要将测试用例从SVN平台发送至开发人员所在终端)以及开发人员手动触发执行测试用例等原因，导致现有技术中目标测试用例的生成效率较低。

基于此，本申请实施例提供了一种测试用例的生成方法，如图2所示，所述方法包括：

步骤S201：在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端，所述测试剧本为在第二客户端生成并提交至所述剧本仓库中的剧本；

在本申请实施例中，所述测试剧本为所述第二客户端的用户(如测试剧本开发人员)编写的、记录了对预设的待测试程序进行测试的具体输入参数以及期待的输出结果的文本文件。

在将新增的所述测试剧本发送至第一客户端后，所述第一客户端的用户(如编写测试用例的合作伙伴)对所述测试剧本进行代码化表达，生成与所述测试剧本对应的可执行的代码文件，即生成与所述测试剧本对应的第一测试用例。

其中，监测剧本仓库中是否有新增测试剧本的方式可以有多种，比如，可以通过Github提供的hook能力，实时监测测试剧本的代码路径，也即，所述在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端可以包括：

(1)监测所述剧本仓库中的各个代码路径下是否存在文件变更；

其中，文件变更可以包括文件的新增、文件的替换，在任一代码路径下新增文件或替换文件时，则判定监测到代码路径下存在文件变更。

(2)在监测到任一所述代码路径下存在文件变更时，将相应代码路径下的文件确定为新增的测试剧本，并将新增的所述测试剧本发送至所述第一客户端。

在监测到任一代码路径下存在文件变更时，说明第二客户端的用户想要针对新的测试剧本进行测试用例的编写，此时，将新增的所述测试剧本发送至第一客户端，以供第一客户端的用户进行测试用例的编写。

步骤S203：响应于所述第一客户端发送的第一用例提交请求，在预设的待测试程序中执行第一测试用例，所述第一用例提交请求中包括所述第一测试用例，所述第一测试用例为在所述第一客户端生成的与所述测试剧本对应的用例，所述第一测试用例用于对所述待测试程序的预设功能进行测试；

在本申请实施例中，预设的待测试程序是指经所述第二客户端的用户确认过的无异常的待测试程序，因此，若所述第一测试用例的结果为失败，则说明所述第一客户端的用户编写的第一测试用例出现了错误。

所述预设功能为所述待测试程序所具有的某一项或某几项功能，所述测试剧本为所述第二客户端的用户专门针对所述预设功能编写的剧本，所述第一测试用例为与所述测试剧本对应的功能化代码。

例如，在点击待测试程序中某一按钮后，预期结果应该为播放暂停，但是，在待测试程序中执行所述第一测试用例时，实际结果并没有暂停，即与预期结果不一致，所述第一测试用例的执行结果为失败，说明编写的第一测试用例出现了错误；相反，若实际结果为播放暂停，即与预期结果一致，所述第一测试用例的执行结果为通过，说明编写的第一测试用例没有出现错误。

步骤S205：在所述第一测试用例的执行结果为通过时，将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

在本申请实施例中，在所述第一测试用例的执行结果为通过时，说明所述第一客户端的用户编写的第一测试用例没有出现错误，因此将该第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

在获得所述目标测试用例后，可以将所述目标测试用例直接保存至用例仓库中，以供后续使用。当然，为了进一步保证目标测试用例的可靠性，还可以将所述目标测试用例发送至所述第二客户端，以供第二客户端的用户检查，并在检查无误后再将所述目标测试用例保存至用例仓库中。

在实际应用中，所述目标测试用例可以用于对更新后的待测试程序的预设功能进行测试，进而可以保证更新后的待测试程序可以正常运行。

例如，所述待测试程序包括三个功能模块A、B和C，利用本实施例的方案确定了用于测试待测试程序的功能模块A的目标测试用例a，在后续开发过程中，开发人员对功能模块B和/或C进行了代码更新，此时，可以利用目标测试用例a来测试功能模块B和/C的更新是否对功能模块A带来影响。

若目标测试用例a在更新后的待测试程序中的执行结果为失败，说明其余功能模块的更新对待测试程序中的功能模块A造成了影响，进而可以提醒开发人员对更新后的待测试程序进行检查及修改，保证更新后的待测试程序可以正常运行，也即，降低了更新后待测试程序的代码错误率。

在本申请实施例中，可以在第二客户端的用户(即开发人员)提交测试剧本至剧本仓库时，由剧本仓库自动将新增的测试剧本发送至第一客户端，以供第一客户端的用户(即合作伙伴)编写相应的测试用例，减少了第一客户端的用户和第二客户端的用户的沟通成本，提高了测试用例编写的及时性；并且，在第一客户端的用户编写完测试用例后，并不直接在平台托管测试用例，而是响应于第一客户端的用例提交请求，自动触发执行用例提交请求中的测试用例，并在测试用例的执行结果为通过时，将测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例，以便后续可以直接将确认的目标测试用例保存至用例仓库中，从而避免了错误测试用例在SVN平台的更新、第二客户端的用户手动触发执行用例等缺陷，提高了目标测试用例的生成效率。

在一些实施例中，在所述在待测试程序中执行所述第一测试用例的步骤之后，所述方法还可以包括：

在所述第一测试用例的执行结果为失败时，向所述第一客户端发送第一通知，所述第一通知用于提醒所述第一客户端的用户对所述第一测试用例进行修改。

在本申请实施例中，在所述第一测试用例的执行结果为失败时，说明所述第一客户端的用户编写的第一测试用例出现了错误，因此需要提醒第一客户端的用户对所述第一测试用例进行修改。

其中，所述第一通知可以包括失败的第一测试用例的名称、执行结果、可能的错误原因以及用于提醒第一客户端的用户对失败的第一测试用例进行修改的提示标识等。

在实际应用中，可以在所述第一客户端生成所述第一测试用例后，可以将所述第一测试用例保存在所述第一客户端所在的终端，从而当所述第一客户端接收到所述第一通知后，可以直接基于所述第一通知中的第一测试用例的名称对保存在终端本地的第一测试用例进行修改，避免了在第一测试用例的执行结果为失败时，需要将所述第一测试用例再返回到所述第一客户端，提高了对测试用例进行修改的效率。

在一些实施例中，虽然第二客户端的用户确认过待测试程序为无异常的待测试程序，但在实际测试过程中，并不能完全保证待测试程序完全无异常，而在待测试程序本身存在异常时，将会导致第一测试用例的执行结果不可靠，因此，如图3所示，在所述向所述第一客户端发送第一通知的步骤之前，所述方法还可以包括：

步骤S301：在所述第一测试用例的执行结果为失败时，向所述第二客户端发送第二通知，所述第二通知用于提醒所述第二客户端的用户对所述待测试程序进行检查，以确定所述待测试程序本身是否存在异常；

步骤S303：响应于所述第二客户端发送的第一通知发送指令，执行所述向所述第一客户端发送第一通知的步骤。

在本申请实施例中，所述第二通知可以包括失败的第一测试用例的名称、执行结果、可能的错误原因以及用于提醒第二客户端的用户对所述待测试程序进行检查的提示标识等。

当第二客户端的用户对待测试程序进行检查并发现待测试程序本身无异常时，通过所述第二客户端向执行测试用例生成方法的装置如服务器发送第一通知发送指令，以便服务器基于所述第一通知发送指令向所述第一客户端发送第一通知，进而提醒所述第一客户端的用户对所述第一测试用例进行修改。

在实际应用中，在第一测试用例的执行结果为失败时，通过对待测试程序进行复查，并在复查确认待测试程序没有问题时，才提醒第一客户端的用户对第一测试用例进行修改，从而避免第一客户端的用户在用例编写无误的情况下浪费精力去检查、修改用例，进而提高了生成最终的目标测试用例的效率。

在一些实施例中，如图4所示，所述方法还可以包括：

步骤S401：响应于所述第一客户端发送的第二用例提交请求，在所述待测试程序中执行第二测试用例，所述第二用例提交请求中包括所述第二测试用例，所述第二测试用例为在所述第一测试用例的基础上修改得到的用于对所述待测试程序的预设功能进行测试的用例；

步骤S403：在所述第二测试用例的执行结果为通过时，将所述第二测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

在本申请实施例中，在所述第一测试用例测试失败后，所述第一客户端的用户可以在接到第一通知后对所述第一测试用例进行修改，以得到第二测试用例；在得到所述第二测试用例后，所述第一客户端将所述第二测试用例发送至执行测试用例的生成方法的装置如服务器中，并由安装在所述服务器中的所述待测试程序中执行所述第二测试用例；以及在所述第二测试用例的执行结果为通过时，说明所述第一客户端的用户在所述第一测试用例的基础上修改得到的第二测试用例没有出现错误，因此将该第二测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

在一些实施例中，由于第一客户端的用户可能并没有基于测试剧本的内容进行测试用例的编辑，甚至在某些情况下，第一客户端的用户可能为了使得测试用例能够顺利通过而随意编写一些执行结果肯定为通过的用例，而这些随意编写的用例并不能用于后续对更新的待测试程序进行测试，因此，如图5所示，在所述将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例的步骤之后，所述方法还可以包括：

步骤S501：向所述第二客户端发送第三通知，所述第三通知包括所述目标测试用例，所述第三通知用于提醒所述第二客户端的用户对所述目标测试用例进行检查；

步骤S503：响应于所述第二客户端发送的用例入库请求，将所述目标测试用例存储至用例仓库。

在本申请实施例中，向所述第二客户端发送第三通知，所述第三通知中可以包括通过测试的目标测试用例，进而第二客户端的用户可以对通过测试的目标测试用例进行人工检查，通过简单的人工检查，即可以发现通过测试的目标测试用例是否为随意编写的测试用例。

例如，如果第一客户端的用户为了使得测试用例能够顺利通过，随意编写用例的输入1+1，期待的输出结果为2，实际运行后输出的结果肯定也为2，也即，虽然随意编写的该用例可以通过测试，但是显然这些随意编写的用例并不能用于后续对更新的待测试程序进行测试，而通过简单的人工检查，可以避免该问题。

如果经人工检查发现目标测试用例不是随意编写的测试用例，则第二客户端的用户可以通过所述第二客户端向执行测试用例的生成方法的装置如服务器发送用例入库请求，以供服务器基于所述用例入库请求将所述目标测试用例保存至用例仓库。

可选的，所述用例入库请求中可以包括所述目标测试用例，所述服务器在接收到所述用例入库请求时，将所述用例入库请求中的目标测试用例保存至用例仓库中。

可选的，所述用例入库请求也可以不包括所述目标测试用例，具体的，在将所述第一测试用例确定为所述目标测试用例后，可以将所述目标测试用例保存在服务器的缓存中，当在预设时间内能够接收到用例入库请求时，直接根据所述用例入库请求将缓存中的目标测试用例，可以理解的是，由于缓存的保存时间有限，如果超过预设时间还没有接收到用例入库请求，那么服务器将会从缓存中清除所述目标测试用例，因此，在服务器向所述第二客户端发送第三通知时，可以通过第三通知向第二客户端的用户提醒发送用户入库请求的时效，以使第二客户端的用户能够在预设时间内向服务器发送用例入库请求。

相反，如果经人工检查发现目标测试用例是随意编写的测试用例，则可以不用发送用例入库请求。

为了保证后续目标测试用例的生成，可以在目标测试用例检查有误时，由所述第二客户端向所述第一客户端发送对目标测试用例进行重新编写的通知，通知中可以包括需要重新编写的测试用例的名称或对应的测试剧本的名称，以便所述第一客户端的用户在看到该通知后，根据测试用例名称或测试剧本名称对需要重新编写的用例进行重新编写。

在实际应用中，通过第二客户端的用户简单的人工检查，可以避免通过测试的用例为第一客户端的用户随意编写的用例，进而保证后续对更新的待测试程序进行测试的可靠性。

在一些实施例中，如图6所示，所述方法还可以包括：

步骤S601：从所述用例仓库中拉取所述目标测试用例；

步骤S603：在更新后的待测试程序中执行所述目标测试用例，所述更新后的待测试程序为在所述待测试程序的基础上进行更新得到的程序；

步骤S605：向所述第二客户端发送所述目标测试用例的执行结果，所述目标测试用例的执行结果用于表征更新后的待测试程序的预设功能正常或更新后的待测试程序的预设功能异常。

在本申请实施例中，可以定时、周期性地或事件响应性地从所述用例仓库中拉取所述目标测试用例。

其中，定时是指在预设时间点从所述用例仓库中拉取所述目标测试用例，例如，预先设置好在第一天上午10点和下午3点从所述用例仓库中拉取所述目标测试用例，并在第二天上午11点和下午2点从所述用例仓库中拉取所述目标测试用例，以及在第三天上午12点和下午1点从所述用例仓库中拉取所述目标测试用例；周期性地是指每隔预设时间从所述用例仓库中拉取所述目标测试用例，例如，每隔12小时从所述用例仓库中拉取所述目标测试用例；事件响应地是指当监听到预设事件时，例如，监听到待测试程序更新的事件时，从所述用例仓库中拉取所述目标测试用例。

在程序开发过程中，当需要为待测试程序新增某一项功能或需要对某一项功能进行升级时，会对所述待测试程序进行更新，例如，可以在所述待测试程序中增加一段代码，或修改所述待测试程序中的某几行代码，而在待测试程序更新过程中，可能会对某些未更新的代码部分造成影响，通过在更新后的待测试程序中运行与未更新的代码部分对应的目标测试用例，可以判断更新后的待测试程序的预设功能是否正常，并可以在更新后的待测试程序的预设功能出现异常的情况下，提醒开发人员对更新后的待测试程序进行检查及修改，保证更新后的待测试程序可以正常运行。

以下将结合一个具体实施例进一步说明上述实施例所述的方法。

上述实施例中的测试用例的生成方法具体由第一客户端、第二客户端、第一服务器、第二服务器和第三服务器协调执行，其中，所述第一客户端可以为编写测试用例的合作伙伴所使用的客户端，所述第二客户端可以为测试剧本的开发人员所使用的客户端，所述第一服务器上可以安装有Github软件，所述第二服务器上可以安装有DevOps软件，所述第三服务器可以为公共构建机，如图7所示，所述测试用例的生成方法的具体流程可以如下：

步骤S701：第二客户端(测试剧本的开发人员所使用的客户端)向第一服务器发送测试剧本提交请求，所述测试剧本提交请求中包括待新增到剧本仓库中的测试剧本；

步骤S702：利用第一服务器上安装的Github软件监测剧本仓库中是否有新增的测试剧本，在监测到有新增剧本时，向第二服务器发送监测到新增测试剧本的通知；

步骤S703：DevOps软件在接收到新增测试剧本的通知时，从第一服务器上获取新增的测试剧本，并将新增的测试剧本发送至第一客户端(编写测试用例的合作伙伴所使用的客户端)；

步骤S704：第一客户端的用户根据接收的测试剧本开发测试用例；

步骤S705：第一客户端向第一服务器发送用例提交请求，用例提交请求中包括测试用例；

步骤S706：第一服务器上的Github软件在监测到第一客户端发送的用例提交请求后，向第二服务器转发该用例提交请求；

步骤S707：DevOps软件在接收到用例提交请求时，将用例提交请求中的测试用例发送至公共构建机；

步骤S708：公共构建机执行测试用例；

步骤S709：公共构建机将测试用例的执行结果发送至第二服务器；

步骤S710：如果执行结果为失败，则第二服务器将向第一客户端发送第一通知，以提醒所述第一客户端的用户对测试用例进行修改；

步骤S711：在执行结果为通过时，第二服务器向第二客户端发送第三通知，第三通知包括通过测试的目标测试用例；

步骤S712：第二客户端向第一服务器发送用例入库请求，所述第一服务器基于所述用例入库请求将目标测试用例存储至用例仓库；

步骤S713：第二服务器上的DevOps软件定时、周期性地或事件响应性地从第一服务器的用例仓库中拉取目标测试用例；

步骤S714：第二服务器向公共构建机发送目标测试用例；

步骤S715：在公共构建机中的更新后的待测试程序中执行目标测试用例；

步骤S716：公共构建机向第二服务器发送目标测试用例的执行结果；

步骤S717：DevOps软件向所述第二客户端发送目标测试用例的执行结果，目标测试用例的执行结果用于表征更新后的待测试程序的预设功能正常或更新后的待测试程序的预设功能异常。

未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的方法。

需要说明的是，上述Github软件和DevOps软件也可以安装在一台服务器上，所述公共构建机执行的功能也可以集成到同一台服务器上，并且，Github软件和DevOps软件也可以由其他可以实现相应功能的软件替代，本申请对此并不作限制。

本申请实施例还提供了一种测试用例的生成装置800，请参见图8，所述装置800包括：

测试剧本发送模块810，用于在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端，所述测试剧本为在第二客户端生成并提交至所述剧本仓库中的剧本；

用例执行模块820，用于响应于所述第一客户端发送的第一用例提交请求，在预设的待测试程序中执行第一测试用例，所述第一用例提交请求中包括所述第一测试用例，所述第一测试用例为在所述第一客户端生成的与所述测试剧本对应的用例，所述第一测试用例用于对所述待测试程序的预设功能进行测试；

目标测试用例确定模块830，用于在所述第一测试用例的执行结果为通过时，将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

在一些实施例中，所述装置还可以包括：

第一通知发送模块，用于在所述第一测试用例的执行结果为失败时，向所述第一客户端发送第一通知，所述第一通知用于提醒所述第一客户端的用户对所述第一测试用例进行修改。

在一些实施例中，所述装置还可以包括：

第二通知发送模块，用于在所述第一测试用例的执行结果为失败时，向所述第二客户端发送第二通知，所述第二通知用于提醒所述第二客户端的用户对所述待测试程序进行检查，以确定所述待测试程序本身是否存在异常；

所述第一通知发送模块还用于响应于所述第二客户端发送的第一通知发送指令，向所述第一客户端发送第一通知。

在一些实施例中，所述装置还可以包括：

第二测试用例执行模块，用于响应于所述第一客户端发送的第二用例提交请求，在所述待测试程序中执行第二测试用例，所述第二用例提交请求中包括所述第二测试用例，所述第二测试用例为在所述第一测试用例的基础上修改得到的用于对所述待测试程序的预设功能进行测试的用例；

所述目标测试用例确定模块还用于在所述第二测试用例的执行结果为通过时，将所述第二测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

在一些实施例中，所述装置还可以包括：

第三通知发送模块，用于向所述第二客户端发送第三通知，所述第三通知包括所述目标测试用例，所述第三通知用于提醒所述第二客户端的用户对所述目标测试用例进行检查；

用例存储模块，用于响应于所述第二客户端发送的用例入库请求，将所述目标测试用例存储至用例仓库。

在一些实施例中，所述装置还可以包括：

目标测试用例拉取模块，用于定时、周期性地或事件响应性地从所述用例仓库中拉取所述目标测试用例；

程序测试模块，用于在更新后的待测试程序中执行所述目标测试用例，所述更新后的待测试程序为在所述待测试程序的基础上进行更新得到的程序；

执行结果发送模块，用于向所述第二客户端发送所述目标测试用例的执行结果，所述目标测试用例的执行结果用于表征更新后的待测试程序的预设功能正常或更新后的待测试程序的预设功能异常。

在一些实施例中，所述测试剧本发送模块可以包括：

文件变更监测子模块，用于监测所述剧本仓库中的各个代码路径下是否存在文件变更；

测试剧本发送子模块，用于在监测到任一所述代码路径下存在文件变更时，将相应代码路径下的文件确定为新增的测试剧本，并将新增的所述测试剧本发送至所述第一客户端。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如本实施例上述任一方法。

本申请实施例还提供了一种电子设备，其结构图请参见图9，该电子设备900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)922(例如，一个或一个以上处理器)和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中，存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对设备中的一系列指令操作。更进一步地，中央处理器922可以设置为与存储介质930通信，在设备900上执行存储介质930中的一系列指令操作。电子设备900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，和/或，一个或一个以上操作系统941，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。本实施例上述的任一方法均可基于图9所示的电子设备进行实施。

本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤和顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或中断产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本实施例中所示出的结构，仅仅是与本申请方案相关的部分结构，并不构成对本申请方案所应用于其上的设备的限定，具体的设备可以包括比示出的更多或更少的部件，或者组合某些部件，或者具有不同的部件的布置。应当理解到，本实施例中所揭露的方法、装置等，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分仅仅为一种逻辑功能的划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元模块的间接耦合或通信连接。

基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例还提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实施方式中提供的一种对象流量的控制方法。

本领域技术人员还可以进一步意识到，结合本说明书所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但这种实现不应认为超出本申请的范围。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

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

在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端，所述测试剧本为在第二客户端生成并提交至所述剧本仓库中的剧本；

响应于所述第一客户端发送的第一用例提交请求，在预设的待测试程序中执行第一测试用例，所述第一用例提交请求中包括所述第一测试用例，所述第一测试用例为在所述第一客户端生成的与所述测试剧本对应的用例，所述第一测试用例用于对所述待测试程序的预设功能进行测试；

在所述第一测试用例的执行结果为通过时，将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

2.根据权利要求1所述的生成方法，其特征在于，在所述在待测试程序中执行所述第一测试用例的步骤之后，所述方法还包括：

在所述第一测试用例的执行结果为失败时，向所述第一客户端发送第一通知，所述第一通知用于提醒所述第一客户端的用户对所述第一测试用例进行修改。

3.根据权利要求2所述的生成方法，其特征在于，在所述向所述第一客户端发送第一通知的步骤之前，所述方法还包括：

在所述第一测试用例的执行结果为失败时，向所述第二客户端发送第二通知，所述第二通知用于提醒所述第二客户端的用户对所述待测试程序进行检查，以确定所述待测试程序本身是否存在异常；

响应于所述第二客户端发送的第一通知发送指令，执行所述向所述第一客户端发送第一通知的步骤。

4.根据权利要求2所述的生成方法，其特征在于，所述方法还包括：

响应于所述第一客户端发送的第二用例提交请求，在所述待测试程序中执行第二测试用例，所述第二用例提交请求中包括所述第二测试用例，所述第二测试用例为在所述第一测试用例的基础上修改得到的用于对所述待测试程序的预设功能进行测试的用例；

在所述第二测试用例的执行结果为通过时，将所述第二测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

5.根据权利要求1所述的生成方法，其特征在于，在所述将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例的步骤之后，所述方法还包括：

向所述第二客户端发送第三通知，所述第三通知包括所述目标测试用例，所述第三通知用于提醒所述第二客户端的用户对所述目标测试用例进行检查；

响应于所述第二客户端发送的用例入库请求，将所述目标测试用例存储至用例仓库。

6.根据权利要求5所述的生成方法，其特征在于，所述方法还包括：

从所述用例仓库中拉取所述目标测试用例；

在更新后的待测试程序中执行所述目标测试用例，所述更新后的待测试程序为在所述待测试程序的基础上进行更新得到的程序；

向所述第二客户端发送所述目标测试用例的执行结果，所述目标测试用例的执行结果用于表征更新后的待测试程序的预设功能正常或更新后的待测试程序的预设功能异常。

7.根据权利要求1所述的生成方法，其特征在于，所述在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端包括：

监测所述剧本仓库中的各个代码路径下是否存在文件变更；

在监测到任一所述代码路径下存在文件变更时，将相应代码路径下的文件确定为新增的测试剧本，并将新增的所述测试剧本发送至所述第一客户端。

8.一种测试用例的生成装置，其特征在于，所述装置包括：

测试剧本发送模块，用于在监测到剧本仓库中有新增的测试剧本时，将新增的所述测试剧本发送至第一客户端，所述测试剧本为在第二客户端生成并提交至所述剧本仓库中的剧本；

用例执行模块，用于响应于所述第一客户端发送的第一用例提交请求，在预设的待测试程序中执行第一测试用例，所述第一用例提交请求中包括所述第一测试用例，所述第一测试用例为在所述第一客户端生成的与所述测试剧本对应的用例，所述第一测试用例用于对所述待测试程序的预设功能进行测试；

目标测试用例确定模块，用于在所述第一测试用例的执行结果为通过时，将所述第一测试用例确定为用于测试所述待测试程序的预设功能的目标测试用例。

9.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至7任一项所述的测试用例的生成方法。

10.一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如权利要求1-7任一所述的测试用例的生成方法。

Images