CN113468069A - 应用测试方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请公开了一种应用测试方法、装置、计算机设备及存储介质，属于计算机技术领域。本申请通过响应于测试指令，自启动开发引擎，并自启动应用程序的主进程，由于主进程不具有环境依赖性，能够在开发引擎端完成针对待测功能的所有测试流程，而无需从开发引擎中耗费长时间以导出安装包，相当于在导出安装包之前进行预测试，率先测试主进程是否会产生异常，降低了应用测试的时间成本，提高了应用测试效率，提高了人机交互效率。

Description

应用测试方法、装置、计算机设备及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种应用测试方法、装置、计算机设备及存储介质。

背景技术

随着计算机技术的发展和终端功能的多样化，用户能够在终端上体验各式各样的游戏应用，游戏应用的开发离不开游戏引擎，例如，Unity(优美缔)是一种主流的游戏引擎。

在游戏应用的版本测试中，需要将游戏应用从Unity引擎中导出安装包(如安卓系统的安装包或者iOS即苹果系统的安装包)，并在终端上下载该安装包之后，再执行相关测试流程。其中，相关测试流程可划分为冒烟测试、兼容性测试、适配性测试等等，而冒烟测试是指针对游戏应用的业务逻辑(即主进程)执行的测试。

由于从Unity引擎中导出安装包通常需要2.5小时以上(通常为3小时)的耗时，但如果游戏应用的主进程异常，即冒烟测试失败，那么根本无法完成后续的各类测试，需要在修复相关BUG(问题)之后，重新从Unity引擎中导出安装包并再次测试，因此，应用测试的时间成本高、测试效率低。

发明内容

本申请实施例提供了一种应用测试方法、装置、计算机设备及存储介质，能够降低应用测试的时间成本、提高测试效率。该技术方案如下：

一方面，提供了一种应用测试方法，该方法包括：

响应于对应用程序的测试指令，基于所述应用程序的开发引擎，运行所述应用程序的主进程；

获取对所述主进程中待测功能的测试用例数据，所述测试用例数据用于模拟实现所述待测功能所需的至少一个触发事件；

基于所述测试用例数据，向所述主进程输入所述至少一个触发事件；

输出所述至少一个触发事件的事件执行结果。

一方面，提供了一种应用测试装置，该装置包括：

运行模块，用于响应于对应用程序的测试指令，基于所述应用程序的开发引擎，运行所述应用程序的主进程；

获取模块，用于获取对所述主进程中待测功能的测试用例数据，所述测试用例数据用于模拟实现所述待测功能所需的至少一个触发事件；

输入模块，用于基于所述测试用例数据，向所述主进程输入所述至少一个触发事件；

输出模块，用于输出所述至少一个触发事件的事件执行结果。

在一种可能实施方式中，所述输入模块包括：

注册单元，用于基于所述测试用例数据，注册所述至少一个触发事件；

输入单元，用于基于所述至少一个触发事件的触发次序，向所述主进程依次输入所述至少一个触发事件。

在一种可能实施方式中，所述输入单元包括：

输入子单元，用于对所述至少一个触发事件中的任一触发事件，若所述任一触发事件的事件执行结果为事件执行成功，向所述主进程输入所述触发次序中所述任一触发事件的下一个触发事件；

处理子单元，用于若所述任一触发事件的事件执行结果为事件执行失败，基于所述任一触发事件所对应的异常处理逻辑，对所述任一触发事件进行处理。

在一种可能实施方式中，所述处理子单元用于：

若所述异常处理逻辑为失败重试逻辑，重复向所述主进程输入所述任一触发事件，直到事件执行成功或者到达所述任一触发事件对应的重试次数；或者，

若所述异常处理逻辑为失败跳过逻辑，或者向所述主进程输入所述任一触发事件的次数到达所述重试次数，跳过所述任一触发事件，向所述主进程输入所述下一个触发事件。

在一种可能实施方式中，所述获取模块还用于：从所述测试用例数据中，获取所述任一触发事件对应的忽略错误参数；

所述装置还包括：确定模块，用于若所述忽略错误参数为真，确定所述异常处理逻辑为失败跳过逻辑；若所述忽略错误参数为假，确定所述异常处理逻辑为失败重试逻辑，从所述测试用例数据中读取所述任一触发事件对应的重试次数。

在一种可能实施方式中，所述输出模块还用于：

对所述至少一个触发事件中的任一触发事件，在向所述主进程输入所述任一触发事件之后，对所述主进程进行异常监控，输出异常监控结果。

在一种可能实施方式中，所述异常监控结果包括异常类型或者异常图像资料中至少一项，所述异常类型用于表征所述主进程所发生异常的种类，所述异常图像资料为所述主进程发生异常时的屏幕截图信息。

在一种可能实施方式中，所述异常类型包括目标异常或者超时异常中至少一项，所述目标异常是指需要被所述主进程抛出的异常，所述超时异常是指所述主进程发生阻塞的时长大于超时阈值。

在一种可能实施方式中，所述运行模块用于：

编译所述应用程序的运行代码；

在编译成功的情况下，启动所述开发引擎；

在启动成功的情况下，运行所述主进程。

在一种可能实施方式中，所述输出模块还用于：

对所述运行代码进行编译检查，输出所述编译日志的分析结果。

在一种可能实施方式中，所述输出模块还用于：

对所述开发引擎进行闪退监控，输出所述开发引擎的闪退监控结果。

在一种可能实施方式中，所述输出模块还用于：

基于所述至少一个触发事件的事件执行结果，输出所述待测功能的测试结果，所述测试结果包括测试通过或者测试未通过，所述测试通过是指所述至少一个触发事件的事件执行结果均为事件执行成功，所述测试未通过是指所述至少一个触发事件中任一触发事件的事件执行结果为事件执行失败。

一方面，提供了一种计算机设备，该计算机设备包括一个或多个处理器和一个或多个存储器，该一个或多个存储器中存储有至少一条计算机程序，该至少一条计算机程序由该一个或多个处理器加载并执行以实现如上述应用测试方法。

一方面，提供了一种存储介质，该存储介质中存储有至少一条计算机程序，该至少一条计算机程序由处理器加载并执行以实现如上述应用测试方法。

一方面，提供一种计算机程序产品或计算机程序，所述计算机程序产品或所述计算机程序包括一条或多条程序代码，所述一条或多条程序代码存储在计算机可读存储介质中。计算机设备的一个或多个处理器能够从计算机可读存储介质中读取所述一条或多条程序代码，所述一个或多个处理器执行所述一条或多条程序代码，使得计算机设备能够执行上述应用测试方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过响应于测试指令，自启动开发引擎，并自启动应用程序的主进程，由于主进程不具有环境依赖性，能够在开发引擎端完成针对待测功能的所有测试流程，而无需从开发引擎中耗费长时间以导出安装包，相当于在导出安装包之前进行预测试，率先测试主进程是否会产生异常，降低了应用测试的时间成本，提高了应用测试效率，提高了人机交互效率。

附图说明

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

图1是本申请实施例提供的一种应用测试方法的实施环境示意图；

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

图3是本申请实施例提供的一种显示测试结果消息的界面示意图；

图4是本申请实施例提供的一种应用测试方法的交互流程图；

图5是本申请实施例提供的一种游戏应用测试的原理性流程图；

图6是本申请实施例提供的一种应用测试方法的原理性流程图；

图7是本申请实施例提供的一种自动化冒烟测试的原理性流程图；

图8是本申请实施例提供的一种游戏应用内冒烟测试的原理性流程图；

图9是本申请实施例提供的一系列测试用例的原理性示意图；

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

图11是本申请实施例提供的一种终端的结构示意图；

图12是本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。

本申请中术语“至少一个”是指一个或多个，“多个”的含义是指两个或两个以上，例如，多个第一位置是指两个或两个以上的第一位置。

以下，对本申请涉及的术语进行解释。

游戏引擎：指一些已编写好的可编辑电脑游戏系统或者一些交互式实时图像应用程序的核心组件。这些系统为游戏设计者提供各种编写游戏所需的各种工具，其目的在于让游戏设计者能容易和快速地做出游戏程式而不用由零开始。大部分都支持多种操作平台，如Linux、Mac OS X、微软Windows。游戏引擎包含以下系统：渲染引擎(即“渲染器”，含二维图像引擎和三维图像引擎)、物理引擎、碰撞检测系统、音效、脚本引擎、电脑动画、人工智能、网络引擎以及场景管理。

Unity：是实时3D(三维)互动内容创作和运营平台。包括游戏开发、美术、建筑、汽车设计、影视在内的所有创作者，借助Unity将创意变成现实。Unity平台提供一整套完善的软件解决方案，可用于创作、运营和变现任何实时互动的2D和3D内容，支持平台包括手机、平板电脑、PC、游戏主机、增强现实和虚拟现实设备。在游戏开发领域中，Unity是针对游戏应用的一种主流开发引擎，主要用于制作游戏场景(即虚拟场景)、游戏物件(即虚拟对象)等，其中，游戏应用的开发引擎也可称为游戏开发引擎、游戏编辑器等。

虚拟场景：是应用程序在终端上运行时显示(或提供)的虚拟场景。该虚拟场景可以是对真实世界的仿真环境，也可以是半仿真半虚构的虚拟环境，还可以是纯虚构的虚拟环境。虚拟场景可以是二维虚拟场景、2.5维虚拟场景或者三维虚拟场景中的任意一种，本申请实施例对虚拟场景的维度不加以限定。例如，虚拟场景可以包括天空、陆地、海洋等，该陆地可以包括沙漠、城市等环境元素，用户可以控制虚拟对象在该虚拟场景中进行移动。可选地，该虚拟场景还可以用于至少两个虚拟对象之间的虚拟场景对战，在该虚拟场景中具有可供至少两个虚拟对象使用的虚拟资源。可选地，该虚拟场景中可以包括对称的两个区域，属于两个敌对阵营的虚拟对象分别占据其中一个区域，并以摧毁对方区域深处的目标建筑/据点/基地/水晶来作为胜利目标，其中，对称的区域比如左下角区域和右上角区域，又比如左侧中部区域和右侧中部区域等。

虚拟对象：是指在虚拟场景中的可活动对象。该可活动对象可以是虚拟人物、虚拟动物、虚拟精灵、动漫人物等，比如：在虚拟场景中显示的人物、动物、植物、油桶、墙壁、石块等。该虚拟对象可以是该虚拟场景中的一个虚拟的用于代表用户的虚拟形象。在虚拟场景中可以包括多个虚拟对象，每个虚拟对象在虚拟场景中具有自身的形状和体积，占据虚拟场景中的一部分空间。可选地，当虚拟场景为三维虚拟场景时，可选地，虚拟对象可以是一个三维立体模型，该三维立体模型可以是基于三维人体骨骼技术构建的三维角色，同一个虚拟对象可以通过穿戴不同的皮肤来展示出不同的外在形象。在一些实施例中，虚拟对象也可以采用2.5维或2维模型来实现，本申请实施例对此不加以限定。

可选地，该虚拟对象可以是通过客户端上的操作进行控制的玩家角色，还可以是设置在虚拟场景互动中的非玩家角色(Non-Player Character，NPC)。可选地，该虚拟对象可以是在虚拟场景中进行竞技的虚拟人物。可选地，该虚拟场景中参与互动的虚拟对象的数量可以是预先设置的，也可以是根据加入互动的客户端的数量动态确定的。

C#语言：C#语言是Unity引擎所使用的脚本语言，主要用于游戏逻辑或业务逻辑的实现。其中，C#语言是由C语言和C++语言衍生出来的一种面向对象编程语言，在继承C语言和C++语言强大功能的同时，去掉了一些它们的复杂特性(例如没有宏以及不允许多重继承)。

Exception(异常抛出)：一种异常处理机制，在Unity引擎中，特指Unity引擎使用的C#语言在遇到异常则会抛出异常的事件。

iOS(苹果操作系统)：一种苹果公司开发的移动操作系统。

群聊机器人：是在用户群组即群聊中添加的一个非真人用户，可通过制定的接口向用户群组中发送、接收消息。

测试用例(Test Case)：是指对一项特定的软件产品(如应用程序)进行测试任务的描述，体现测试方案、方法、技术和策略。简单地认为，测试用例是为某个特殊目标而编制的一组触发事件，这一组触发事件可视为该特殊目标的测试输入，用于核实应用程序是否能够实现某个特定待测功能。

冒烟测试：是指针对软件版本包进行详细测试之前的预测试，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷，并非对软件版本包的深入测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，如果冒烟测试的测试用例不能通过，则不必做进一步的测试(如兼容性测试、适配性测试等)。进行冒烟测试之前需要确定冒烟测试的测试用例集，对测试用例集要求覆盖软件的基本功能。这种版本包出包之后的验证方法通常称为软件版本包的门槛用例验证。

在游戏开发领域中，冒烟测试特指针对游戏应用的业务逻辑(即主进程)执行的测试，由于测试对象是软件版本包，意味着需要将游戏应用从Unity引擎中导出安装包(如安卓系统的安装包或者IOS即苹果系统的安装包)，并在终端上下载该安装包之后，才能够进行冒烟测试。但是，针对大型游戏项目而言，从Unity引擎中导出安装包通常需要2.5小时以上(通常为3小时)的耗时，如果没有做优化，甚至需要更长的耗时，在将安装包下载到终端上之后，如果发现连游戏应用最基本的冒烟测试都无法通过，那么无法完成进一步的各类测试。这种情况下，需要在开发人员修复相关BUG(问题)之后，重新从Unity引擎中导出安装包并再次测试，因此，应用测试的时间成本高、测试效率低。

由于冒烟测试具有只检测业务逻辑，并不检测环境依赖性的特点，本申请实施例提供一种基于应用程序的开发引擎，对应用程序进行自动化冒烟测试的方案，能够将冒烟测试从终端侧转移到开发端的开发引擎上，这样无需反复将安装包导出到终端才能完成冒烟测试，而是可以直接在开发端完成冒烟测试，换言之，无需出包即可在出包之前完成冒烟测试，使得一些基本的错误或者异常在终端上测试之前能够提前暴露，以降低应用测试的时间成本、提高测试效率。

进一步地，测试人员为了强调某些主进程产生的异常，可以通过开发引擎提供的Exception机制，在检测到针对某个UI控件的点击事件，或者执行某个特定逻辑的情况下，抛出异常并闪退，即在遇到指定异常(如阻塞问题、其他异常)时，应用程序主动退出流程以暴露该指定异常，从而实现对主进程的全面异常监控，使得这类指定异常能够在开发阶段就提前发现，便于异常排查和修复工作。

进一步地，测试人员可灵活可控针对不同的待测功能，编写不同的测试用例数据，可针对应用程序的任何UI控件进行基本功能的测试，具有测试稳定的效果，并能够兼容基于该开发引擎(如Unity引擎)的各类项目，且不局限于游戏应用，具有很强的通用性。

以下，对本申请涉及的系统架构进行说明。

图1是本申请实施例提供的一种应用测试方法的实施环境示意图。参见图1，在该实施环境中包括第一终端120、服务器140和第二终端160，第一终端120和第二终端160均为计算机设备的一种示例性说明。

第一终端120上可以安装和运行有测试应用，测试应用中提供远程测试功能，第一用户(如测试人员)可通过该远程测试功能，触发远端的第二终端160执行本申请实施例提供的应用测试方法。可选地，该测试应用为浏览器应用，那么第一用户可通过在该浏览器应用中访问目标平台(如企业内部搭建的运营系统等)，并在目标平台上登录第一用户账号，在该目标平台中提供多个应用程序的远程测试功能选项，第一用户点击某一应用程序的远程测试功能选项之后，触发目标平台的后台服务器140(例如，网站服务器)向第二终端160下发对该应用程序的测试指令。可选地，除了浏览器应用之外，该测试应用还可以是专用于提供远程测试功能的客户端等，还可以是集成有远程测试功能的开发应用等，本申请实施例对测试应用的类型不进行具体限定。

第一终端120和第二终端160均能够通过有线或无线通信方式与服务器140之间进行直接或间接地连接，本申请在此不做限制。

服务器140用于向第一终端120上的该测试应用提供后台服务，第一用户在第一终端120的测试应用中，点击针对任一应用程序的远程测试功能选项之后，第一终端120会向服务器140发送对该应用程序的测试指令，该测试指令用于触发对该应用程序进行自动化地冒烟测试，可选地，该测试指令至少携带该第一用户账号的账号标识(Identification，ID)以及该应用程序的应用标识，服务器140在接收到该测试指令之后，解析得到该账号标识和应用标识，在对该账号标识鉴权通过之后，查询与该应用标识对应的第二终端160，并向该第二终端160转发该测试指令，触发第二终端160执行本申请实施例提供的应用测试方法。

服务器140可以包括一台服务器、多台服务器、云计算平台或者虚拟化中心中的至少一种。可选地，服务器140可以承担主要计算工作，第一终端120和第二终端160可以承担次要计算工作；或者，服务器140承担次要计算工作，第一终端120和第二终端160承担主要计算工作；或者，第一终端120、第二终端160和服务器140之间采用分布式计算架构进行协同计算。

第二终端160上可以安装和运行有应用程序的开发引擎，第二用户可利用该开发引擎完成该应用程序的开发工作，例如，该应用程序为游戏应用，该开发引擎为Unity引擎。可选地，第二终端160在接收到服务器140发送的对该应用程序的测试指令之后，可自动触发本地机器上的一系列冒烟测试的相关逻辑，如：编译代码、检测是否存在编译错误、启动开发引擎等，在启动开发引擎之后，还可以自动打开该应用程序的主进程(即自动触发应用程序的内部逻辑)，并执行各项待测功能的测试用例，直到所有待测功能的测试用例都执行完毕，在上述全部测试过程的每个阶段，开发引擎都进行如下操作：监控编译错误、监控异常事件、监控进程阻塞问题，并记录到日志中，还可以在发生BUG时进行截图保存，最终第二终端160产生冒烟测试结果，并将冒烟测试结果通过服务器140返回至第一终端120，需要说明的是，如果冒烟测试结果为不通过，还可以在返回冒烟测试结果的同时，将发现的异常问题、日志、截图等资料一并返回，便于第一用户排查异常并修复异常。

如本申请所公开的应用测试方法，其中第一终端120和第二终端160还可组成为一区块链，第一终端120和第二终端160均为区块链上的节点，从而无需服务器140进行消息中转。

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

第一终端120或者第二终端160，均可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载终端、MP3(Moving Picture Experts Group AudioLayer III，动态影像专家压缩标准音频层面3)播放器、MP4(Moving Picture ExpertsGroup Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、电子书阅读器等，但并不局限于此。

本领域技术人员可以知晓，第一终端120或者第二终端160可以泛指多个终端中的一个，上述第一终端120或者第二终端160的数量可以更多或更少。比如上述第一终端120或者第二终端160可以仅为一个，或者上述第一终端120或者第二终端160为几十个或几百个，或者更多数量。本申请实施例对第一终端120或者第二终端160的数量和设备类型不加以限定。

图2是本申请实施例提供的一种应用测试方法的流程图。参见图2，该实施例应用于计算机设备，以该计算机设备为上述实施环境中的第二终端为例进行说明，该实施例包括以下步骤：

201、第二终端响应于对应用程序的测试指令，基于该应用程序的开发引擎，运行该应用程序的主进程。

第二终端上安装和运行有应用程序的开发引擎，第二用户可利用该开发引擎完成该应用程序的开发工作，并且，该开发引擎还能够启动该应用程序，即运行该应用程序的主进程，接着，可对该应用程序进行应用测试，由于上述应用测试是针对应用程序的主进程进行的，因此上述应用测试属于冒烟测试，即仅能够测试该应用程序的业务逻辑，而不能测试该应用程序的兼容性、适配性等其他方面。

示意性地，该应用程序为游戏应用，如多人在线战术竞技(Multiplayer OnlineBattle Arena，MOBA)游戏、第一人称射击(First-Person Shooting，FPS)游戏、第三人称射击游戏、虚拟现实应用程序、三维地图程序、军事仿真程序或者多人枪战类生存游戏等，在此情况下，该开发引擎为游戏引擎，如Unity引擎、Unreal(虚幻)引擎等，本申请实施例不对应用程序和开发引擎的类型进行具体限定。

在一些实施例中，第二终端可以获取第二用户触发的测试指令，即，该测试指令是由第二用户在本地触发生成的。示意性地，在该开发引擎中提供对该应用程序的目标测试选项(如预测试选项、冒烟测试选项等)，第二用户可通过对该预测试选项的触发操作，触发第二终端生成该测试指令。可选地，该触发操作包括但不限于：点击操作、长按操作、双击操作、按压操作、触摸操作、拖拽操作、滑动操作、语音指令、基于快捷键的触发操作、手势指令等，本申请实施例对触发操作的类型不进行具体限定。

在一些实施例中，第二终端可以接收服务器发送的第一终端触发的测试指令，即该测试指令是由第一用户在远端(即第一终端)触发生成的。示意性地，第一终端安装和运行有测试应用，该测试应用提供远程测试功能，即，第一终端可以通过该测试应用触发远端的第二终端对该应用程序进行应用测试。可选地，该测试应用包括但不限于：浏览器应用、专用于提供远程测试功能的客户端、集成有远程测试功能的开发应用等，本申请实施例对测试应用的类型不进行具体限定。

在一个示例性场景中，以该测试应用为浏览器应用为例说明，第一用户在第一终端上启动浏览器应用，并在该浏览器应用中访问目标平台(如企业内部搭建的运营网站)，第一用户在该目标平台上登录第一用户账号。可选地，目标平台可提供多个应用程序的远程测试功能选项，第一用户选定本次测试的应用程序之后，点击该应用程序的远程测试功能选项，触发第一终端向服务器发送对该应用程序的测试指令，该测试指令用于触发对该应用程序进行自动化地冒烟测试，该测试指令至少携带该第一用户账号的账号标识以及该应用程序的应用标识。服务器在接收到该测试指令之后，解析得到该账号标识和应用标识，在对该账号标识鉴权通过之后，查询与该应用标识对应的第二用户账号(即与该应用标识绑定的开发者账号)，从而确定该第二用户账号对应的第二终端，并向该第二终端转发该测试指令，第二终端接收该测试指令，执行上述步骤201。

在上述过程中，该测试指令可以由第二用户在本地触发，也可以由第一用户在远端触发，本申请实施例不对该测试指令的来源进行具体限定。第一终端在获取到该测试指令之后，可解析该测试指令，得到该应用程序的应用标识，这是由于同一开发引擎可以支持对多个应用程序的开发工作，因此可通过应用标识来指定本次测试的应用程序。

在一些实施例中，在获取到该应用程序的应用标识之后，第二终端可以基于该应用标识，查询该应用程序的运行代码，接着，编译该应用程序的运行代码，在编译成功的情况下，启动该应用程序的开发引擎，在启动成功的情况下，运行该应用程序的主进程。

在上述过程中，第二终端能够响应于该测试指令，实现对开发引擎和应用程序的自启动，无需第二用户手动启动开发引擎和应用程序，从而便于完成对该主进程的自动化冒烟测试，有利于节约人力成本。可选地，也可以在接收到测试指令之后，通过提示信息引导第二用户手动启动该开发引擎和应用程序，本申请实施例对该应用程序的启动方式是自动还是手动不进行具体限定。

在一些实施例中，由于代码故障或者程序异常可能发生在编译阶段，因此，第二终端可以对该运行代码进行编译检查，输出该编译日志的分析结果。在上述过程中，如果运行代码编译失败，是无法执行后续测试用例的，因此通过编译检查能够及时发现编译阶段的代码故障，并通过输出分析结果，及时提醒技术人员修复代码故障，完善了整体应用测试流程，使得故障排查覆盖到应用测试的编译阶段。

可选地，第二终端输出该分析结果，可以是在本地以可视化的方式显示该分析结果，从而由第二用户进行故障排查和修复工作，或者，第二终端还可以通过服务器向第一终端返回该分析结果，从而方便第一用户远程进行故障排查和修复工作，本申请实施例对向哪个设备输出该分析结果不进行具体限定。

在一些实施例中，由于代码故障或者程序异常可能发生在启动或运行阶段，因此，第二终端可以对该开发引擎进行闪退监控，输出该开发引擎的闪退监控结果。在上述过程中，如果在启动开发引擎时闪退，或者在启动该主进程时闪退，是无法执行后续测试用例的，因此通过闪退监控能够及时发现启动或运行阶段的代码故障、程序异常等，这一闪退监控过程可以贯穿对该应用程序的全部测试流程，使得故障排查全程覆盖到应用测试的启动或运行阶段，并通过输出闪退监控结果，及时提醒技术人员修复代码故障，完善了整体应用测试流程。

可选地，第二终端输出该闪退监控结果，可以是在本地以可视化的方式显示该闪退监控结果，从而由第二用户进行故障排查和修复工作，或者，第二终端还可以通过服务器向第一终端返回该闪退监控结果，从而方便第一用户远程进行故障排查和修复工作，本申请实施例对向哪个设备输出该闪退监控结果不进行具体限定。

202、第二终端获取对该主进程中待测功能的测试用例数据，该测试用例数据用于模拟实现该待测功能所需的至少一个触发事件。

其中，该测试用例数据用于模拟用户在该应用程序上实现该待测功能所需的至少一个触发事件，该至少一个触发事件可以是具有触发次序限制的，例如，待测功能为账号登录功能的情况下，该至少一个触发事件按照触发次数的排序包括：输入账号、输入密码、接入业务服务器(如游戏服务器，与上述步骤201中测试应用的后台服务器是不同的设备)、登录结果，可以看出这至少一个触发事件相当于是模拟用户在实际登录账号时需要执行的至少一个步骤。

可选地，由于针对该主进程可进行的待测功能的数量可以是一个或者多个，而每个待测功能可以对应于一个或多个测试用例数据，因此第二终端获取到的测试用例数据的数量也可以是一个或多个，例如，第二终端确定本次该主进程所对应的各个待测功能，并针对每个待测功能获取对应的各个测试用例数据，例如，该待测功能可以是：账号登录功能、虚拟场景显示功能、虚拟对象显示功能、UI控件交互功能等等，本申请实施例不对待测功能和测试用例数据的数量进行具体限定。

在一些实施例中，第二终端可以在运行该主进程之后，在该开发引擎中注册至少一个测试用例(由于本次测试为冒烟测试，因此也可以称为冒烟用例)，接着，第二用户可以在该开发引擎中编写每个测试用例各自的测试用例数据，使得第二终端获取到至少一个测试用例数据，以下实施例，仅以单个测试用例数据的处理过程为例进行说明。

可选地，每个测试用例数据中可以包括该至少一个触发事件的相关信息，该相关信息包括但不限于：每个触发事件的事件名称、事件类型、忽略错误参数、自定义事件信息、操作参数、重试次数等。

在一些实施例中，该测试用例数据可以是测试指令中携带的，也即，由第一用户在第一终端上编写本次所使用的测试用例数据，并将测试用例数据封装在该测试指令中，并通过测试应用的后台服务器将该测试指令转发至第二终端，第二终端解析该测试指令，即可获取到该测试用例数据。

在一些实施例中，该测试用例数据还可以是第二终端在云数据库中下载的，也即，第三用户在第三终端上针对该应用程序的测试用例数据编写完毕之后，上传到开发引擎接入的云数据库，从而由第二终端从该云数据库中，以该应用标识为索引，查询与该索引对应的索引内容即测试用例数据，并下载该测试用例数据至本地。

在上述过程中，测试用例数据可以是第二用户在本机输入的，也可以由第一终端封装在测试指令中并转发至本机，还可以从云数据库中下载至本机，本申请实施例不对测试用例数据的来源进行具体限定。

示意性地，测试用例的注册功能和测试用例数据的编写功能可接入到开发引擎的项目中，且无需入库到项目侧工程，支持直接调用开发引擎提供的接口或者项目自定义的接口，以使用该注册功能或编写功能。

在一些实施例中，可通过RegisterCases()模块来实现测试用例的注册功能，以下代码示出了对4个测试用例的注册过程：

在一些实施例中，可通过RegisterEvent()函数来实现每个测试用例对应的测试用例数据中，各个触发事件的相关信息的设计，并针对每个触发事件提供如下可供调整的参数：

1)stepName：事件名称，用于记录本测试用例中本触发事件所对应的测试步骤的名称；

2)type：事件类型，用于记录本测试用例中本触发事件的触发操作的类型，例如，包括但不限于：click点击类型、input输入类型、waitscene等待场景加载类型、selfdefine自定义操作类型、wait等待类型等；

3)ignoreError：忽略错误参数，用于表征在本触发事件执行失败时，是否跳过本触发事件，即在出错时是否跳过当前的测试步骤；

4)AutoSmokerEvent：自定义事件信息，若本测试用例需要自定义操作，可将函数传入此处；

5)param：操作参数，用于标识不同触发事件所对应不同步骤类型的操作的参数。

6)RetryCount：重试次数，用于表征在本触发事件执行失败时，需要重复执行本触发事件多少次，即在出错时需要重试的次数。

需要说明的是，针对每个触发事件，除了上述6种可供调整的参数之外，还可以配置有其他的参数，如触发事件阻塞时的超时阈值等，本申请实施例不对每个触发事件的可供调整的参数的数量及内容进行具体限定。

例如，以下代码示出了针对“账号登录”测试用例的测试用例数据的编写过程：

RegisterEvent(“WaitForSceneLoad”,StepEventType.waitscene,false,“Login”,null,60,90)；//等待场景加载

RegisterEvent(“Begin”,StepEventType.selfdefine)；//自定义的开局操作RegisterEvent(“username”,StepEventType.input,false,Login_input_Username+“,”+Username)；//输入用户名

RegisterEvent(“psw”,StepEventType.input,false,Login_input_Pwd+“,”+PSWD)；//输入用户密码

RegisterEvent(“select_server”,StepEventType.click,false,Login_btn_serverlist)；

//选择业务服务器

RegisterEvent(“server_url”,StepEventType.input,false,Login_btn_serverlist_in put+“,”+ServerUrl)；//输入业务服务器网址

RegisterEvent(“server_ok”,StepEventType.click,false,Login_serverlist_cancel_ok)；//点击OK选项

RegisterEvent(“devlogin”,StepEventType.click,false,DevLogin)；//登录

203、第二终端基于该测试用例数据，向该主进程输入该至少一个触发事件。

在一些实施例中，在进行冒烟测试的过程中，第二终端可以基于该测试用例数据，注册该至少一个触发事件；基于该至少一个触发事件的触发次序，向该主进程依次输入该至少一个触发事件。可选地，第二终端可以在注册本测试用例的时候，注册本测试用例的所有触发事件。可选地，各个触发事件的触发次序，可由该测试用例数据中各个触发事件在代码行中的顺序确定，换言之，第二终端按照触发次序从先到后的顺序，分别向该主进程中输入所有触发事件。

在上述过程中，通过注册所有触发事件，并依次向主进程输入触发事件，能够保证在无异常的情况下可以实现对应的待测功能，而在出现异常的情况下，可根据异常发生的节点来定位异常所在的代码行，方便了故障排查和异常修复。

在一些实施例中，对该至少一个触发事件中的任一触发事件，由于第二终端是按照触发次序逐个输入触发事件，因此，可以根据该任一触发事件的事件执行结果，来确定是否输入下一个触发事件。可选地，若该任一触发事件的事件执行结果为事件执行成功，向该主进程输入该触发次序中该任一触发事件的下一个触发事件；若该任一触发事件的事件执行结果为事件执行失败，基于该任一触发事件所对应的异常处理逻辑，对该任一触发事件进行处理。

在一些实施例中，由于主进程通常会实时监听事件，比如，通过回调函数监听，或者，通过钩子函数监听等，因此向主进程输入触发事件，是指调用该触发事件对应的回调函数，或者，调用该触发事件对应的钩子函数等，能够完成自动化地冒烟检测过程，当然，在另一些实施例中，还可以由第二用户人工输入触发事件，比如人工点击某一UI控件，提高测试的精细程度，本申请实施例不对触发事件的输入方式进行具体限定。

在上述过程中，通过针对事件执行结果的不同情况，决定是否对主进程输入下一个触发事件，能够完善对当前测试用例的测试过程，也即在事件执行失败的情况下，不一定要终止测试并退出流程，可以基于异常处理逻辑，灵活决定后续的处理操作，例如，跳过当前触发事件，或者，重试当前触发事件等等，从而避免了每出现一个异常就终止测试，简化了应用测试流程。

在一些实施例中，在该任一触发事件的事件执行结果为事件执行失败的情况下，第二终端可提供两种不同的异常处理逻辑：失败重试逻辑和失败跳过逻辑，失败重试逻辑是指重新向该主进程输入当前触发事件，失败跳过逻辑是指跳过当前触发事件并执行下一个触发事件。

在一些实施例中，若该异常处理逻辑为失败重试逻辑，第二终端可以重复向该主进程输入该任一触发事件，直到事件执行成功或者到达该任一触发事件对应的重试次数。其中，该重试次数可以是记载在测试用例数据中的参数，如果测试用例数据中该重试次数为空，可设置为默认值。

在上述过程中，由于触发事件执行失败的原因是多种多样的，并不一定是由于主进程的业务逻辑出错，比如在账号登录测试用例中有一步骤是连接业务服务器，如果本步骤执行失败，既有可能是主进程的业务逻辑出错，也有可能是网络波动导致无法连接业务服务器，而通过失败重试逻辑，能够排除掉上述网络波动等非业务逻辑本身导致的执行失败的情况，从而可以提高测试准确率，提高人机交互效率。需要说明的是，上述重复向主进程输入当前触发事件的步骤，最多可重复执行该重试次数，如果到达重试次数时仍然是指失败，可切换到下述失败跳过逻辑中，避免不停进行重试导致浪费过多时长。

在一些实施例中，若该异常处理逻辑为失败跳过逻辑，或者向该主进程输入该任一触发事件的次数到达该重试次数，第二终端可以跳过该任一触发事件，向该主进程输入该下一个触发事件。

在一些实施例中，第二终端跳过该任一触发事件并向该主进程触发该下一个触发事件时，如果该下一个触发事件依赖于该任一触发事件执行成功才能够进行，可以在记录该任一触发事件的异常监控结果之后，修改该任一触发事件的事件执行结果为事件执行成功，以顺利执行该下一个触发事件。例如，触发事件B的执行条件为触发事件A的返回值为True，但触发事件A的返回值为False，导致触发事件B无法执行，在失败跳过逻辑下，可以直接修改触发事件A的返回值为True。又例如，触发事件B为对UI控件的点击事件，但是只有在触发事件A执行成功的条件下才能在UI界面中显示该UI控件，导致触发事件B的执行间接依赖于触发事件A执行成功，此时可以直接跳过触发事件A，并调用触发事件B的回调函数，从而能够模拟检测到了对UI控件的点击事件。

在上述过程中，通过提供失败跳过逻辑，可以在当前触发事件执行失败，或者通过失败重试逻辑到达重试次数的情况下，支持跳过当前触发事件并执行下一触发事件的做法，能够避免主进程在当前触发事件这一步骤卡死，避免无法跳转至下一触发事件进行后续测试，从而可以提高测试效率，节约测试耗时，进一步提高人机交互效率。

在一些实施例中，第二终端可以通过如下方式来确定每个触发事件的异常处理逻辑：从该测试用例数据中，获取该任一触发事件对应的忽略错误参数ignoreError；若该忽略错误参数为真ignoreError＝True，确定该异常处理逻辑为失败跳过逻辑；若该忽略错误参数为假ignoreError＝False，确定该异常处理逻辑为失败重试逻辑，并从该测试用例数据中读取该任一触发事件对应的重试次数RetryCount。

在上述过程中，提供了基于测试用例数据确定异常处理逻辑的一种可能实施方式，能够快速确定每个触发事件的异常处理逻辑，可选地，如果测试用例数据中并未提供忽略错误参数ignoreError，还可以仅通过重试次数RetryCount来指示异常处理逻辑，例如，重试次数RetryCount可以是一个整型数据，即重试次数RetryCount为大于或等于0的整数，当重试次数等于0即RetryCount＝0时，确定异常处理逻辑为失败跳过逻辑，当重试次数大于0时，确定异常处理逻辑为失败重试逻辑，可选地，用户还可以为该重试次数设置默认值Default，如果默认值Default＝0，则当RetryCount＝Default时，默认异常处理逻辑为失败跳过逻辑，如果默认值Default>0，则当RetryCount＝Default时，默认异常处理逻辑为失败重试逻辑。

在一些实施例中，对该至少一个触发事件中的任一触发事件，第二终端还可以在向该主进程输入该任一触发事件之后，对该主进程进行异常监控，输出异常监控结果。

可选地，第二终端可以在本机上可视化的显示该异常监控结果，也可以通过测试应用的服务器向第一终端输出该异常监控结果，还可以将异常监控结果上传至异常排查平台(即另一分布式文件系统)或者上传到区块链系统上进行持久化存储，本申请实施例不对异常监控结果的输出对象进行具体限定。

在上述过程中，能够在基于测试用例数据对每个触发事件进行测试时，全程对主进程进行异常监控，从而即时记录下来各种各样可能发生的异常，便于技术人员排查故障并修复异常。

在一些实施例中，该异常监控结果可以包括异常类型或者异常图像资料中至少一项，其中，该异常类型用于表征该主进程所发生异常的种类，该异常图像资料为该主进程发生异常时的屏幕截图信息。

在上述过程中，通过在异常监控结果中记录异常类型和异常图像资料，能够无需技术人员人工识别异常类型，且方便了技术人员基于异常图像资料进行快速代码调试(DEBUG)，有利于提高测试效率。当然，还可以在异常监控结果中记录各个触发事件的事件执行结果以及主进程的执行日志，由技术人员根据执行日志来进行异常识别和异常修复，本申请实施例对异常监控结果的内容不进行具体限定。

在一些实施例中，该异常类型包括目标异常或者超时异常中至少一项，该目标异常是指需要被该主进程抛出的异常，该超时异常是指该主进程发生阻塞的时长大于超时阈值。

其中，由于在一些开发引擎中提供Exception异常抛出机制，能够用于强调某些特定类型的异常，技术人员可在开发引擎中设置目标异常的类型，使得主进程在遭遇预设的目标异常时，主动退出主进程，并引起技术人员的关注，通常适用于一些比较重大、会影响到整个业务逻辑的异常。

其中，该超时阈值可以是记录在测试用例数据中的，第二终端可以从该测试用例数据中读取该超时阈值，或者，该超时阈值还可以是开发引擎预设的默认值，该超时阈值可以是任一大于0的数值，例如为1秒，本申请实施例不对该超时阈值的设置方式和取值内容进行具体限定。

在上述过程中，由于在异常类型中可以记录目标异常，也可以记录超时异常，意味着开发引擎不仅支持基于Exception异常抛出机制主动退出主进程，而且还支持在遭遇主进程阻塞时，进入等待，直到达到超时阈值时才上报超时异常，从而能够丰富异常检测所能够识别的异常类型。

204、第二终端输出该至少一个触发事件的事件执行结果。

可选地，第二终端在本机输出该至少一个触发事件的事件执行结果，也可以通过测试应用的服务器向第一终端输出该至少一个触发事件的事件执行结果，还可以将该至少一个触发事件的事件执行结果上传至异常排查平台(即另一分布式文件系统)或者上传到区块链系统上进行持久化存储，本申请实施例不对该至少一个触发事件的事件执行结果的输出对象进行具体限定。

在一些实施例中，该至少一个触发事件的事件执行结果可以以测试报告单的形式对外输出，该测试报告单中除了包括每个触发事件的事件执行结果之外，还可以包括每个触发事件的执行日志、执行时间等详细信息，该测试报告单可以是文本格式、图片格式、聊天消息、电子邮件、短消息、网页链接、文本文件等各类形式进行可视化呈现，本申请实施例对此不进行具体限定。

在一些实施例中，由于该至少一个触发事件的事件执行结果是测试用例中各步骤较为细节的测试结果，为了方便用户直观地了解本次应用测试的最终结果，第二终端还可以基于该至少一个触发事件的事件执行结果，输出该待测功能的测试结果。其中，该测试结果包括测试通过或者测试未通过，该测试通过是指该至少一个触发事件的事件执行结果均为事件执行成功，该测试未通过是指该至少一个触发事件中任一触发事件的事件执行结果为事件执行失败。

可选地，当该至少一个触发事件的事件执行结果均为事件执行成功时，输出该测试结果为测试通过，当该至少一个触发事件中任一触发事件的事件执行结果为事件执行失败时，则输出该测试结果为测试未通过。

在一个示例性场景中，第二终端在将本测试用例的最后一个触发事件输入到主进程，并得到最后一个触发事件的事件执行结果之后，整理该至少一个触发事件的事件执行结果，生成测试报告单，并基于该至少一个触发事件的事件执行结果，确定该待测功能的测试结果，将该测试报告单和测试结果打包为测试结果消息，一方面，将该测试结果消息发送至测试应用的服务器，通过该测试应用的服务器向第一终端转发该测试结果消息，使得第一终端能够在测试应用中显示该测试结果，另一方面，还可以将该测试结果消息发送至社交应用的服务器，通过该社交应用的服务器向目标群组内各个群组成员所在的各个终端转发该测试结果消息，例如该第一用户和第二用户均位于目标群组中，此时第一终端和第二终端均能够在社交应用的目标群组中，以群组消息的方式接收并显示该测试结果和该测试报告单。

图3是本申请实施例提供的一种显示测试结果消息的界面示意图，如300所示，示出了在社交应用的目标群组中以群组消息的方式，分别显示测试结果301和测试报告单302，这里的测试结果301为“冒烟结果：成功”代表测试通过，这里的测试报告单302是以文本文件(.txt)格式输出的，在目标群组中的各个群组成员均能够在各自的终端上显示如300所示的群组消息。

需要说明的是，本申请实施例仅以本次冒烟测试针对单个待测功能为例说明，如果本次冒烟测试存在多个待测功能，那么可以基于多个待测功能的测试结果确定最终的冒烟结果，当该多个待测功能的测试结果均为测试通过时，输出该冒烟结果为冒烟成功，当该多个待测功能中任一待测功能的测试结果为测试未通过时，则输出该冒烟结果为冒烟失败。

以下，示出了在冒烟测试中包含多个待测功能的情况下，该多个待测功能各自对应的多个测试用例的测试结果：

“【海外版】冒烟结果：

Login|True

LobbyInit|True

GameFrotEnd|True

Loadout|True

Frontline|True

TDM|True

HardcortTDM|True

TDM_Night|True

DOM|True

BR|True

Snpier_Challenge|True

Warfare|True”

在上述过程中，通过在发现异常时自动提交BUG单(即测试报告单)，最终确认如何对异常进行调试，还可在修复完毕后进行再次测试，验证调试后的异常是否被修复完毕，直到异常被解决，从而能够形成异常的发现、上报、处理、回测、关闭的完整闭环。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过响应于测试指令，自启动开发引擎，并自启动应用程序的主进程，由于主进程不具有环境依赖性，能够在开发引擎端完成针对待测功能的所有测试流程，而无需从开发引擎中耗费长时间以导出安装包，相当于在导出安装包之前进行预测试，率先测试主进程是否会产生异常，降低了应用测试的时间成本，提高了应用测试效率，提高了人机交互效率。

在上述实施例中，介绍了第二终端如何响应于测试指令完成应用测试流程，可选地，第二终端可以响应于第二用户输入的测试指令以完成全部的测试流程，也可以响应于远端的第一终端发送的测试指令以执行测试流程，在本申请实施例中，将结合第一终端的触发过程以及第二终端的测试过程，对第一终端和第二终端之间如何进行交互的过程进行说明，下面进行详述。

图4是本申请实施例提供的一种应用测试方法的交互流程图，如图4所示，该实施例应用于第一终端和第二终端之间的交互过程，该实施例包括下述步骤：

401、第一终端向第二终端发送对应用程序的测试指令。

第一终端安装和运行有测试应用，该测试应用提供远程测试功能，即，第一终端可以通过该测试应用触发远端的第二终端对该应用程序进行应用测试。可选地，该测试应用包括但不限于：浏览器应用、专用于提供远程测试功能的客户端、集成有远程测试功能的开发应用等，本申请实施例对测试应用的类型不进行具体限定。

在一个示例性场景中，以该测试应用为浏览器应用为例说明，第一用户在第一终端上启动浏览器应用，并在该浏览器应用中访问目标平台(如企业内部搭建的运营网站)，第一用户在该目标平台上登录第一用户账号。可选地，目标平台可提供多个应用程序的远程测试功能选项，第一用户选定本次测试的应用程序之后，点击该应用程序的远程测试功能选项，触发第一终端向服务器发送对该应用程序的测试指令，该测试指令用于触发对该应用程序进行自动化地冒烟测试，该测试指令至少携带该第一用户账号的账号标识以及该应用程序的应用标识。服务器在接收到该测试指令之后，解析得到该账号标识和应用标识，在对该账号标识鉴权通过之后，查询与该应用标识对应的第二用户账号(即与该应用标识绑定的开发者账号)，从而确定该第二用户账号对应的第二终端，并向该第二终端转发该测试指令。

402、第二终端响应于该测试指令，编译该应用程序的运行代码。

第二终端接收该测试指令，可解析该测试指令，得到该应用程序的应用标识，这是由于同一开发引擎可以支持对多个应用程序的开发工作，因此可通过应用标识来指定本次测试的应用程序。在一些实施例中，在获取到该应用程序的应用标识之后，第二终端可以基于该应用标识，查询该应用程序的运行代码，接着，编译该应用程序的运行代码。

在一些实施例中，由于代码故障或者程序异常可能发生在编译阶段，因此，第二终端可以对该运行代码进行编译检查，输出该编译日志的分析结果。在上述过程中，如果运行代码编译失败，是无法执行后续测试用例的，因此通过编译检查能够及时发现编译阶段的代码故障，并通过输出分析结果，及时提醒技术人员修复代码故障，完善了整体应用测试流程，使得故障排查覆盖到应用测试的编译阶段。

可选地，第二终端输出该分析结果，可以是在本地以可视化的方式显示该分析结果，从而由第二用户进行故障排查和修复工作，或者，第二终端还可以通过服务器向第一终端返回该分析结果，从而方便第一用户远程进行故障排查和修复工作，本申请实施例对向哪个设备输出该分析结果不进行具体限定。

403、第二终端在编译成功的情况下，启动该应用程序的开发引擎。

在一些实施例中，在编译失败的情况下，第二终端输出编译日志的分析结果，并由技术人员排查异常并修复异常之后，重新执行编译步骤，直到编译成功之后，第二终端可自启动该开发引擎。

在一些实施例中，由于代码故障或者程序异常可能发生在启动或运行阶段，因此，第二终端可以对该开发引擎进行闪退监控，输出该开发引擎的闪退监控结果。在上述过程中，如果在启动开发引擎时闪退，或者在启动该主进程时闪退，是无法执行后续测试用例的，因此通过闪退监控能够及时发现启动或运行阶段的代码故障、程序异常等，这一闪退监控过程可以贯穿对该应用程序的全部测试流程，使得故障排查全程覆盖到应用测试的启动或运行阶段，并通过输出闪退监控结果，及时提醒技术人员修复代码故障，完善了整体应用测试流程。

可选地，第二终端输出该闪退监控结果，可以是在本地以可视化的方式显示该闪退监控结果，从而由第二用户进行故障排查和修复工作，或者，第二终端还可以通过服务器向第一终端返回该闪退监控结果，从而方便第一用户远程进行故障排查和修复工作，本申请实施例对向哪个设备输出该闪退监控结果不进行具体限定。

404、第二终端在启动成功的情况下，运行该应用程序的主进程。

在一些实施例中，如果在启动开发引擎时发生崩溃或者闪退，由于在实时进行闪退监控，可对外输出闪退监控结果，并由技术人员排查异常并修复异常之后，重新执行启动开发引擎的步骤，直到启动成功之后，第二终端在该开发引擎内自启动该应用程序的主进程。

在上述步骤402-404中，提供了第二终端响应于对应用程序的测试指令，基于该应用程序的开发引擎，运行该应用程序的主进程的一种可能实施方式，即，无需第二用户手动启动开发引擎和应用程序，实现对开发引擎和应用程序的自启动，从而便于完成对该主进程的自动化冒烟测试，有利于节约人力成本。可选地，也可以在接收到测试指令之后，通过提示信息引导第二用户手动启动该开发引擎和应用程序，本申请实施例对该应用程序的启动方式是自动还是手动不进行具体限定。

405、第二终端获取对该主进程中待测功能的测试用例数据，该测试用例数据用于模拟实现该待测功能所需的至少一个触发事件。

上述步骤405与上述步骤202类似，这里不做赘述。

406、第二终端基于该测试用例数据，注册该至少一个触发事件。

可选地，第二终端可以在注册本测试用例的时候，注册本测试用例的所有触发事件，并在注册完毕之后，执行下述步骤406。

407、第二终端基于该至少一个触发事件的触发次序，向该主进程依次输入该至少一个触发事件。

可选地，各个触发事件的触发次序，可由该测试用例数据中各个触发事件在代码行中的顺序确定，换言之，第二终端按照触发次序从先到后的顺序，分别向该主进程中输入所有触发事件。

在上述步骤406-407中，示出了基于该测试用例数据，向该主进程输入该至少一个触发事件的一种可能实施方式，通过注册所有触发事件，并依次向主进程输入触发事件，能够保证在无异常的情况下可以实现对应的待测功能，而在出现异常的情况下，可根据异常发生的节点来定位异常所在的代码行，方便了故障排查和异常修复。

在一些实施例中，对该至少一个触发事件中的任一触发事件，由于第二终端是按照触发次序逐个输入触发事件，因此，可以根据该任一触发事件的事件执行结果，来确定是否输入下一个触发事件。可选地，若该任一触发事件的事件执行结果为事件执行成功，向该主进程输入该触发次序中该任一触发事件的下一个触发事件；若该任一触发事件的事件执行结果为事件执行失败，基于该任一触发事件所对应的异常处理逻辑，对该任一触发事件进行处理。

在一些实施例中，由于主进程通常会实时监听事件，比如，通过回调函数监听，或者，通过钩子函数监听等，因此向主进程输入触发事件，是指调用该触发事件对应的回调函数，或者，调用该触发事件对应的钩子函数等，能够完成自动化地冒烟检测过程，当然，在另一些实施例中，还可以由第二用户人工输入触发事件，比如人工点击某一UI控件，提高测试的精细程度，本申请实施例不对触发事件的输入方式进行具体限定。

在上述过程中，通过针对事件执行结果的不同情况，决定是否对主进程输入下一个触发事件，能够完善对当前测试用例的测试过程，也即在事件执行失败的情况下，不一定要终止测试并退出流程，可以基于异常处理逻辑，灵活决定后续的处理操作，例如，跳过当前触发事件，或者，重试当前触发事件等等，从而避免了每出现一个异常就终止测试，简化了应用测试流程。

在一些实施例中，在该任一触发事件的事件执行结果为事件执行失败的情况下，第二终端可提供两种不同的异常处理逻辑：失败重试逻辑和失败跳过逻辑，失败重试逻辑是指重新向该主进程输入当前触发事件，失败跳过逻辑是指跳过当前触发事件并执行下一个触发事件。

在一些实施例中，若该异常处理逻辑为失败重试逻辑，第二终端可以重复向该主进程输入该任一触发事件，直到事件执行成功或者到达该任一触发事件对应的重试次数。其中，该重试次数可以是记载在测试用例数据中的参数，如果测试用例数据中该重试次数为空，可设置为默认值。

在上述过程中，由于触发事件执行失败的原因是多种多样的，并不一定是由于主进程的业务逻辑出错，比如在账号登录测试用例中有一步骤是连接业务服务器，如果本步骤执行失败，既有可能是主进程的业务逻辑出错，也有可能是网络波动导致无法连接业务服务器，而通过失败重试逻辑，能够排除掉上述网络波动等非业务逻辑本身导致的执行失败的情况，从而可以提高测试准确率，提高人机交互效率。需要说明的是，上述重复向主进程输入当前触发事件的步骤，最多可重复执行该重试次数，如果到达重试次数时仍然是指失败，可切换到下述失败跳过逻辑中，避免不停进行重试导致浪费过多时长。

在一些实施例中，若该异常处理逻辑为失败跳过逻辑，或者向该主进程输入该任一触发事件的次数到达该重试次数，第二终端可以跳过该任一触发事件，向该主进程输入该下一个触发事件。

在一些实施例中，第二终端跳过该任一触发事件并向该主进程触发该下一个触发事件时，如果该下一个触发事件依赖于该任一触发事件执行成功才能够进行，可以在记录该任一触发事件的异常监控结果之后，修改该任一触发事件的事件执行结果为事件执行成功，以顺利执行该下一个触发事件。例如，触发事件B的执行条件为触发事件A的返回值为True，但触发事件A的返回值为False，导致触发事件B无法执行，在失败跳过逻辑下，可以直接修改触发事件A的返回值为True。又例如，触发事件B为对UI控件的点击事件，但是只有在触发事件A执行成功的条件下才能在UI界面中显示该UI控件，导致触发事件B的执行间接依赖于触发事件A执行成功，此时可以直接跳过触发事件A，并调用触发事件B的回调函数，从而能够模拟检测到了对UI控件的点击事件。

在上述过程中，通过提供失败跳过逻辑，可以在当前触发事件执行失败，或者通过失败重试逻辑到达重试次数的情况下，支持跳过当前触发事件并执行下一触发事件的做法，能够避免主进程在当前触发事件这一步骤卡死，避免无法跳转至下一触发事件进行后续测试，从而可以提高测试效率，节约测试耗时，进一步提高人机交互效率。

在一些实施例中，第二终端可以通过如下方式来确定每个触发事件的异常处理逻辑：从该测试用例数据中，获取该任一触发事件对应的忽略错误参数ignoreError；若该忽略错误参数为真ignoreError＝True，确定该异常处理逻辑为失败跳过逻辑；若该忽略错误参数为假ignoreError＝False，确定该异常处理逻辑为失败重试逻辑，并从该测试用例数据中读取该任一触发事件对应的重试次数RetryCount。

在上述过程中，提供了基于测试用例数据确定异常处理逻辑的一种可能实施方式，能够快速确定每个触发事件的异常处理逻辑，可选地，如果测试用例数据中并未提供忽略错误参数ignoreError，还可以仅通过重试次数RetryCount来指示异常处理逻辑，例如，重试次数为空RetryCount＝NULL，或者重试次数小于或等于0即RetryCount≤0时，确定异常处理逻辑为失败跳过逻辑，反之，重试次数大于0时，确定异常处理逻辑为失败重试逻辑，可选地，用户还可以为该重试次数设置默认值Default，如果默认值Default≤0，则当RetryCount＝Default时，默认异常处理逻辑为失败跳过逻辑，如果默认值Default>0，则当RetryCount＝Default时，默认异常处理逻辑为失败重试逻辑。

在一些实施例中，对该至少一个触发事件中的任一触发事件，第二终端还可以在向该主进程输入该任一触发事件之后，对该主进程进行异常监控，输出异常监控结果。

可选地，第二终端可以在本机上可视化的显示该异常监控结果，也可以通过测试应用的服务器向第一终端输出该异常监控结果，还可以将异常监控结果上传至异常排查平台(即另一分布式文件系统)或者上传到区块链系统上进行持久化存储，本申请实施例不对异常监控结果的输出对象进行具体限定。

在上述过程中，能够在基于测试用例数据对每个触发事件进行测试时，全程对主进程进行异常监控，从而即时记录下来各种各样可能发生的异常，便于技术人员排查故障并修复异常。

在一些实施例中，该异常监控结果可以包括异常类型或者异常图像资料中至少一项，其中，该异常类型用于表征该主进程所发生异常的种类，该异常图像资料为该主进程发生异常时的屏幕截图信息。

在上述过程中，通过在异常监控结果中记录异常类型和异常图像资料，能够无需技术人员人工识别异常类型，且方便了技术人员基于异常图像资料进行快速代码调试(DEBUG)，有利于提高测试效率。当然，还可以在异常监控结果中记录各个触发事件的事件执行结果以及主进程的执行日志，由技术人员根据执行日志来进行异常识别和异常修复，本申请实施例对异常监控结果的内容不进行具体限定。

在一些实施例中，该异常类型包括目标异常或者超时异常中至少一项，该目标异常是指需要被该主进程抛出的异常，该超时异常是指该主进程发生阻塞的时长大于超时阈值。

其中，由于在一些开发引擎中提供Exception异常抛出机制，能够用于强调某些特定类型的异常，技术人员可在开发引擎中设置目标异常的类型，使得主进程在遭遇预设的目标异常时，主动退出主进程，并引起技术人员的关注，通常适用于一些比较重大、会影响到整个业务逻辑的异常。

其中，该超时阈值可以是记录在测试用例数据中的，第二终端可以从该测试用例数据中读取该超时阈值，或者，该超时阈值还可以是开发引擎预设的默认值，该超时阈值可以是任一大于0的数值，例如为1秒，本申请实施例不对该超时阈值的设置方式和取值内容进行具体限定。

在上述过程中，由于在异常类型中可以记录目标异常，也可以记录超时异常，意味着开发引擎不仅支持基于Exception异常抛出机制主动退出主进程，而且还支持在遭遇主进程阻塞时，进入等待，直到达到超时阈值时才上报超时异常，从而能够丰富异常检测所能够识别的异常类型。

408、第二终端基于该至少一个触发事件的事件执行结果，确定该待测功能的测试结果。

其中，该测试结果包括测试通过或者测试未通过，该测试通过是指该至少一个触发事件的事件执行结果均为事件执行成功，该测试未通过是指该至少一个触发事件中任一触发事件的事件执行结果为事件执行失败。

可选地，当该至少一个触发事件的事件执行结果均为事件执行成功时，输出该测试结果为测试通过，当该至少一个触发事件中任一触发事件的事件执行结果为事件执行失败时，则输出该测试结果为测试未通过。

在上述过程中，由于该至少一个触发事件的事件执行结果是测试用例中各步骤较为细节的测试结果，第二终端通过获取该待测功能的测试结果，能够方便用户直观地了解本次应用测试的最终结果。

409、第二终端输出该至少一个触发事件的事件执行结果和该待测功能的测试结果。

可选地，第二终端在本机输出该至少一个触发事件的事件执行结果，也可以通过测试应用的服务器向第一终端输出该至少一个触发事件的事件执行结果，还可以将该至少一个触发事件的事件执行结果上传至异常排查平台(即另一分布式文件系统)或者上传到区块链系统上进行持久化存储，本申请实施例不对该至少一个触发事件的事件执行结果的输出对象进行具体限定。

在一些实施例中，该至少一个触发事件的事件执行结果可以以测试报告单的形式对外输出，该测试报告单中除了包括每个触发事件的事件执行结果之外，还可以包括每个触发事件的执行日志、执行时间等详细信息，该测试报告单可以是文本格式、图片格式、聊天消息、电子邮件、短消息、网页链接、文本文件等各类形式进行可视化呈现，本申请实施例对此不进行具体限定。

可选地，第二终端在本机输出该待测功能的测试结果，也可以通过测试应用的服务器向第一终端输出该待测功能的测试结果，还可以将该待测功能的测试结果上传至异常排查平台(即另一分布式文件系统)或者上传到区块链系统上进行持久化存储，本申请实施例不对该待测功能的测试结果的输出对象进行具体限定。

在一些实施例中，该待测功能的测试结果可以文本格式、图片格式、聊天消息、电子邮件、短消息、网页链接、文本文件等各类形式进行可视化呈现，本申请实施例对此不进行具体限定。

在一个示例性场景中，第二终端在将本测试用例的最后一个触发事件输入到主进程，并得到最后一个触发事件的事件执行结果之后，整理该至少一个触发事件的事件执行结果，生成测试报告单，并基于该至少一个触发事件的事件执行结果，确定该待测功能的测试结果，将该测试报告单和测试结果打包为测试结果消息，一方面，将该测试结果消息发送至测试应用的服务器，通过该测试应用的服务器向第一终端转发该测试结果消息，使得第一终端能够在测试应用中显示该测试结果，另一方面，还可以将该测试结果消息发送至社交应用的服务器，通过该社交应用的服务器向目标群组内各个群组成员所在的各个终端转发该测试结果消息，例如该第一用户和第二用户均位于目标群组中，此时第一终端和第二终端均能够在社交应用的目标群组中，以群组消息的方式接收并显示该测试结果和该测试报告单。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本申请实施例提供的方法，通过响应于测试指令，自启动开发引擎，并自启动应用程序的主进程，由于主进程不具有环境依赖性，能够在开发引擎端完成针对待测功能的所有测试流程，而无需从开发引擎中耗费长时间以导出安装包，相当于在导出安装包之前进行预测试，率先测试主进程是否会产生异常，降低了应用测试的时间成本，提高了应用测试效率，提高了人机交互效率。

在上述实施例中，示出了第一终端如何通过测试应用的远程测试功能，触发远端的第二终端完成自动化冒烟测试，而在本申请实施例中，将以测试应用为浏览器应用、本次测试的应用程序为游戏应用、该开发引擎为游戏引擎为例，对游戏引擎冒烟自动化测试的完整流程进行说明。

图5是本申请实施例提供的一种游戏应用测试的原理性流程图，如图5所示，以游戏引擎为Unity为例，第一终端能够通过Web(网页)端远程触发第二终端启动Unity引擎，并在Unity引擎内自运行冒烟测试，且还支持Unity引擎进行全程监控、记录结果并反馈结果。

在触发阶段501中，第一终端基于浏览器应用触发测试流程开启，比如，第一用户在第一终端的浏览器应用中访问目标平台(如企业内部搭建的运营系统等)，并在目标平台上登录第一用户账号，点击游戏应用的远程测试功能选项，第一终端通过目标平台所对应的网站服务器，向第二终端发送对游戏应用的测试指令。

在初始化阶段502中，第二终端响应于测试指令，编译C#代码，自启动Unity引擎，自运行游戏应用，注册冒烟用例(即测试用例)。

在局外UI事件处理阶段503中，以单个UI事件(即触发事件)处理为例，第二终端查询指定UI控件，判断UI控件是否激活，检测点击操作或输入操作或自定义回调事件，执行回调事件，并返回事件执行结果。

在局内游戏逻辑测试阶段504中，第二终端可针对游戏应用的业务逻辑执行各种类型的检测，例如，场景状态检测、角色状态检测、局内UI状态检测、局内用例执行、返回执行结果。

在反馈结果阶段505中，第二终端可以采用各种形式来输出各个事件的事件执行结果、各个测试用例的测试结果以及冒烟测试的冒烟结果。比如，通过群聊机器人以群聊消息的方式进行通知，或者，以电子邮件的方式进行通知，或者，生成测试报告单即自动提BUG单并反馈至第一终端的浏览器应用等等。

在监控阶段506中，监控阶段506是贯穿从触发阶段501到反馈结果阶段505的全部周期的，包括：编译检查、Unity引擎闪退监控、异常监控、进程阻塞监控、问题截图、用例执行结果监控等监控方式。可选地，在编译检查时，可使用Python分析编译日志以得到分析结果。可选地，Unity引擎闪退监控是指实时监控Unity进程是否存在。可选地，在问题截图时，可以在识别到异常的情况下，调用函数Application.CaptureScreenshot(path)进行屏幕截图。可选地，在异常监控时，可以执行Application.logMessageReceivedThreaded+＝LogCallback，以执行回调事件并输出事件的执行日志。可选地，在进程阻塞监控时，是指对每个测试用例的每个步骤(即每个触发事件)均进行超时检测。可选地，用例执行结果监控时，是由测试用例中所有步骤的执行结果(即事件执行结果)决定该测试用例的测试结果。

以下，将分别针对第一终端和第二终端，单独介绍第一终端所执行的操作，以及第二终端所执行的操作。

图6是本申请实施例提供的一种应用测试方法的原理性流程图，如图6所示，在步骤601中，第一终端基于浏览器应用触发测试流程开启，比如，第一用户在第一终端的浏览器应用中访问目标平台(如企业内部搭建的运营系统等)，并在目标平台上登录第一用户账号，点击游戏应用的远程测试功能选项，第一终端通过目标平台所对应的网站服务器，向第二终端发送对游戏应用的测试指令。在步骤602中，第二终端进行如初始化阶段502所执行的操作，即完成测试环境的前置处理。在步骤603中，第二终端开启自动化冒烟测试流程，自动化冒烟测试流程的详细过程可参考图7，这里不做赘述。在步骤604中，第二终端归档上述自动化冒烟测试流程的所有执行日志。在步骤605中，第二终端对上述步骤604中的归档日志进行结果分析。在步骤606中，第二终端向第一终端进行结果推送。

在本申请实施例中，可以发现第一终端仅参与了触发步骤601和结果推送步骤606，而不参与任何自动化冒烟测试的具体流程，换言之，针对第一终端的浏览器应用而言，只承担拉起冒烟测试以及接收结果推送的作用。针对第二终端而言，需要完成步骤602-605中的环境前置处理、开启自动化冒烟测试、归档日志以及结果分析这几项操作，下面将对自动化冒烟测试603进行详述。

图7是本申请实施例提供的一种自动化冒烟测试的原理性流程图，如图7所示，整个自动化冒烟测试流程是由第二终端执行的。在步骤701中，第二终端Unity编译代码。在步骤702中，第二终端判断是否编译错误，如果编译错误，结束自动化，如果编译成功，执行步骤703。在步骤703中，第二终端带窗口启动Unity引擎。在步骤704中，第二终端自动加载项目工程。在步骤705中，第二终端自动运行游戏应用。在步骤706中，第二终端开始游戏应用内冒烟测试。在步骤707中，第二终端产出测试结果，并结束自动化。

示意性地，在上述步骤701中，第二终端可以通过如下代码完成主动编译：

cd/d％UnityEditor_PATH％

call Unity.exe-batchmode-projectPath％UnityProject_PATH％-logFile

％UnityLog_PATH％-quit

上述主动编译代码能够使用Unity无窗口编译代码和资源。

示意性地，在上述步骤703中，第二终端启动Unity引擎时，可以直接由浏览器应用的主进程启动窗口化的Unity引擎，也即实现不同应用之间的相互调用。

示意性地，在上述步骤705中，第二终端可以通过如下代码自动运行游戏应用：

上述自启动Unity引擎和自运行游戏应用的代码，能够实现无人工干预Unity引擎的运行，并由于可进行编译检查和闪退监控，针对编译资源完成后没有回调事件通知、脚本编译错误导致自动化测试流程直接中断等问题，均通过输出编译日志的分析结果以及闪退监控结果，得到了良好的改善。

示意性地，在上述步骤706中，第二终端可以通过如下代码，针对游戏应用开启自动化测试：

上述代码示出了一种如何开启自动化冒烟测试的方式，但是针对自动化冒烟测试这一过程，在上述各个实施例中，均是以单个待测功能的单个测试用例为例进行说明的，在本申请实施例中，将以针对多个待测功能的多个测试用例的测试流程进行介绍。

图8是本申请实施例提供的一种游戏应用内冒烟测试的原理性流程图，如800所示，在测试过程中，每个待测功能对应于一个测试用例，每个测试用例可视为是整体冒烟测试过程的一个模块或步骤。在测试过程中，可包括多个模块即多个测试用例。在初始化完成后，运行模块一即测试用例一，以测试用例一为例进行说明：注册测试用例一所包含的所有事件(即触发事件，在本申请实施例中简称为事件)；依次取出事件，即依次向游戏应用主进程输入事件；对每个事件，基于Exception异常抛出机制进行监控，如遇到目标异常则主动退出主进程，并记录目标异常至异常监控结果中；如主进程遇到阻塞，进行超时检测，即判断阻塞的时长是否大于超时阈值，如果阻塞的时长大于超时阈值，记录超时异常至异常监控结果中，如果阻塞的时长小于或等于超时阈值，获取事件执行结果；如果事件执行结果为事件执行成功，继续取出下一个事件；如果事件执行结果为事件执行失败，视异常处理机制进行对应处理，例如，基于失败重试机制，再次执行当前事件，又例如，基于失败跳过机制，跳过当前事件并取出下一个事件；重复执行上述过程，直到测试用例一中的全部事件均执行完成，归档超时、异常、步骤记录，形成异常监控结果，退出流程。

如上述图8可以看出，各个测试用例和游戏应用的主进程(代表了游戏应用的核心逻辑模块)是互相解耦的，用户只需要关心自身各个测试用例的编写即可，在编写各个测试用例时，还提供可以对外提供一些通用接口，用户可以选择合适的接口来编写测试用例，如果通用接口无法满足编写需求，用户也可以自定义相关操作并添加到测试用例中，在一定程度上保证了用户的自主性。

示意性地，图9是本申请实施例提供的一系列测试用例的原理性示意图，如900所示，在冒烟测试中涉及多个测试用例：登录、用例1、用例2、用例3……等的情况下，用户可以在Unity引擎上自由的编辑每个测试用例各自的可调整的参数，最终形成每个测试用例的测试用例数据。例如，登录用例包括如下步骤(一个步骤可视为一个触发事件)：输入账号、输入密码、连接业务服务器、登录，例如，用例2可以包括：步骤1、步骤2、步骤3、步骤4……结束，本申请实施例对每个测试用例的内容不进行具体限定。

上述多个测试用例中每个测试用例都包含了多个步骤，所有的测试用例的所有步骤可以组成一个类似于哈希桶的结构，冒烟测试系统可针对哈希桶进行逐一运行检查工作，一旦发现异常则中断并记录到异常监控结果中，等待最终一起上报，然后执行下一个测试用例。

本申请实施例提供的方法，以Unity引擎为例，详细介绍了针对Unity引擎内的游戏应用进行自动化冒烟测试的过程，针对稍微大型的游戏项目来说，在传统出包后测试的方案下，通常从编译到出包(即导出安装包)需要花费2.5小时以上，再加上冒烟测试时长，会花费更长的时间，而应用本申请实施例提供的自动化冒烟测试方案，相较于传统出包后测试的方案，能够节约冒烟测试的人力成本至少0.5人日/天，并且还能够提前发现异常导致的崩溃(即闪退)问题，缩短问题的发现时长至少0.5天，也即降低了定位异常的难度，提高了测试效率。

图10是本申请实施例提供的一种应用测试装置的结构示意图，如图10所示，该装置包括：

运行模块1001，用于响应于对应用程序的测试指令，基于该应用程序的开发引擎，运行该应用程序的主进程；

获取模块1002，用于获取对该主进程中待测功能的测试用例数据，该测试用例数据用于模拟实现该待测功能所需的至少一个触发事件；

输入模块1003，用于基于该测试用例数据，向该主进程输入该至少一个触发事件；

输出模块1004，用于输出该至少一个触发事件的事件执行结果。

本申请实施例提供的装置，通过响应于测试指令，自启动开发引擎，并自启动应用程序的主进程，由于主进程不具有环境依赖性，能够在开发引擎端完成针对待测功能的所有测试流程，而无需从开发引擎中耗费长时间以导出安装包，相当于在导出安装包之前进行预测试，率先测试主进程是否会产生异常，降低了应用测试的时间成本，提高了应用测试效率，提高了人机交互效率。

在一种可能实施方式中，基于图10的装置组成，该输入模块1003包括：

注册单元，用于基于该测试用例数据，注册该至少一个触发事件；

输入单元，用于基于该至少一个触发事件的触发次序，向该主进程依次输入该至少一个触发事件。

在一种可能实施方式中，基于图10的装置组成，该输入单元包括：

输入子单元，用于对该至少一个触发事件中的任一触发事件，若该任一触发事件的事件执行结果为事件执行成功，向该主进程输入该触发次序中该任一触发事件的下一个触发事件；

处理子单元，用于若该任一触发事件的事件执行结果为事件执行失败，基于该任一触发事件所对应的异常处理逻辑，对该任一触发事件进行处理。

在一种可能实施方式中，该处理子单元用于：

若该异常处理逻辑为失败重试逻辑，重复向该主进程输入该任一触发事件，直到事件执行成功或者到达该任一触发事件对应的重试次数；或者，

若该异常处理逻辑为失败跳过逻辑，或者向该主进程输入该任一触发事件的次数到达该重试次数，跳过该任一触发事件，向该主进程输入该下一个触发事件。

在一种可能实施方式中，该获取模块1002还用于：从该测试用例数据中，获取该任一触发事件对应的忽略错误参数；

基于图10的装置组成，该装置还包括：确定模块，用于若该忽略错误参数为真，确定该异常处理逻辑为失败跳过逻辑；若该忽略错误参数为假，确定该异常处理逻辑为失败重试逻辑，从该测试用例数据中读取该任一触发事件对应的重试次数。

在一种可能实施方式中，该输出模块1004还用于：

对该至少一个触发事件中的任一触发事件，在向该主进程输入该任一触发事件之后，对该主进程进行异常监控，输出异常监控结果。

在一种可能实施方式中，该异常监控结果包括异常类型或者异常图像资料中至少一项，该异常类型用于表征该主进程所发生异常的种类，该异常图像资料为该主进程发生异常时的屏幕截图信息。

在一种可能实施方式中，该异常类型包括目标异常或者超时异常中至少一项，该目标异常是指需要被该主进程抛出的异常，该超时异常是指该主进程发生阻塞的时长大于超时阈值。

在一种可能实施方式中，该运行模块1001用于：

编译该应用程序的运行代码；

在编译成功的情况下，启动该开发引擎；

在启动成功的情况下，运行该主进程。

在一种可能实施方式中，该输出模块1004还用于：

对该运行代码进行编译检查，输出该编译日志的分析结果。

在一种可能实施方式中，该输出模块1004还用于：

对该开发引擎进行闪退监控，输出该开发引擎的闪退监控结果。

在一种可能实施方式中，该输出模块1004还用于：

基于该至少一个触发事件的事件执行结果，输出该待测功能的测试结果，该测试结果包括测试通过或者测试未通过，该测试通过是指该至少一个触发事件的事件执行结果均为事件执行成功，该测试未通过是指该至少一个触发事件中任一触发事件的事件执行结果为事件执行失败。

上述所有可选技术方案，能够采用任意结合形成本公开的可选实施例，在此不再一一赘述。

需要说明的是：上述实施例提供的应用测试装置在测试应用程序时，仅以上述各功能模块的划分进行举例说明，实际应用中，能够根据需要而将上述功能分配由不同的功能模块完成，即将计算机设备(如第二终端)的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的应用测试装置与应用测试方法实施例属于同一构思，其具体实现过程详见应用测试方法实施例，这里不再赘述。

图11是本申请实施例提供的一种终端的结构示意图，如图11所示，该终端为计算机设备的一种示例性说明，上述各个实施例中涉及的第一终端或者第二终端，均可以具有如图11所示终端1100的逻辑结构。可选地，该终端1100的设备类型包括：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端1100还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端1100包括有：处理器1101和存储器1102。

可选地，处理器1101包括一个或多个处理核心，比如4核心处理器、8核心处理器等。可选地，处理器1101采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable LogicArray，可编程逻辑阵列)中的至少一种硬件形式来实现。在一些实施例中，处理器1101包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central Processing Unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1101集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1101还包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

在一些实施例中，存储器1102包括一个或多个计算机可读存储介质，可选地，该计算机可读存储介质是非暂态的。可选地，存储器1102还包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1102中的非暂态的计算机可读存储介质用于存储至少一个程序代码，该至少一个程序代码用于被处理器1101所执行以实现本申请中各个实施例提供的应用测试方法。

在一些实施例中，终端1100还可选包括有：外围设备接口1103和至少一个外围设备。处理器1101、存储器1102和外围设备接口1103之间能够通过总线或信号线相连。各个外围设备能够通过总线、信号线或电路板与外围设备接口1103相连。具体地，外围设备包括：射频电路1104、显示屏1105、摄像头组件1106、音频电路1107、定位组件1108和电源1109中的至少一种。

外围设备接口1103可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器1101和存储器1102。在一些实施例中，处理器1101、存储器1102和外围设备接口1103被集成在同一芯片或电路板上；在一些其他实施例中，处理器1101、存储器1102和外围设备接口1103中的任意一个或两个在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路1104用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路1104通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1104将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1104包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。可选地，射频电路1104通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路1104还包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏1105用于显示UI(User Interface，用户界面)。可选地，该UI包括图形、文本、图标、视频及其它们的任意组合。当显示屏1105是触摸显示屏时，显示屏1105还具有采集在显示屏1105的表面或表面上方的触摸信号的能力。该触摸信号能够作为控制信号输入至处理器1101进行处理。可选地，显示屏1105还用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1105为一个，设置终端1100的前面板；在另一些实施例中，显示屏1105为至少两个，分别设置在终端1100的不同表面或呈折叠设计；在再一些实施例中，显示屏1105是柔性显示屏，设置在终端1100的弯曲表面上或折叠面上。甚至，可选地，显示屏1105设置成非矩形的不规则图形，也即异形屏。可选地，显示屏1105采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode，有机发光二极管)等材质制备。

摄像头组件1106用于采集图像或视频。可选地，摄像头组件1106包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1106还包括闪光灯。可选地，闪光灯是单色温闪光灯，或者是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，用于不同色温下的光线补偿。

在一些实施例中，音频电路1107包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1101进行处理，或者输入至射频电路1104以实现语音通信。出于立体声采集或降噪的目的，麦克风为多个，分别设置在终端1100的不同部位。可选地，麦克风是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1101或射频电路1104的电信号转换为声波。可选地，扬声器是传统的薄膜扬声器，或者是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅能够将电信号转换为人类可听见的声波，也能够将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1107还包括耳机插孔。

定位组件1108用于定位终端1100的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。可选地，定位组件1108是基于美国的GPS(GlobalPositioning System，全球定位系统)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源1109用于为终端1100中的各个组件进行供电。可选地，电源1109是交流电、直流电、一次性电池或可充电电池。当电源1109包括可充电电池时，该可充电电池支持有线充电或无线充电。该可充电电池还用于支持快充技术。

在一些实施例中，终端1100还包括有一个或多个传感器1110。该一个或多个传感器1110包括但不限于：加速度传感器1111、陀螺仪传感器1112、压力传感器1113、指纹传感器1114、光学传感器1115以及接近传感器1116。

在一些实施例中，加速度传感器1111检测以终端1100建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1111用于检测重力加速度在三个坐标轴上的分量。可选地，处理器1101根据加速度传感器1111采集的重力加速度信号，控制显示屏1105以横向视图或纵向视图进行用户界面的显示。加速度传感器1111还用于游戏或者用户的运动数据的采集。

在一些实施例中，陀螺仪传感器1112检测终端1100的机体方向及转动角度，陀螺仪传感器1112与加速度传感器1111协同采集用户对终端1100的3D动作。处理器1101根据陀螺仪传感器1112采集的数据，实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

可选地，压力传感器1113设置在终端1100的侧边框和/或显示屏1105的下层。当压力传感器1113设置在终端1100的侧边框时，能够检测用户对终端1100的握持信号，由处理器1101根据压力传感器1113采集的握持信号进行左右手识别或快捷操作。当压力传感器1113设置在显示屏1105的下层时，由处理器1101根据用户对显示屏1105的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器1114用于采集用户的指纹，由处理器1101根据指纹传感器1114采集到的指纹识别用户的身份，或者，由指纹传感器1114根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1101授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。可选地，指纹传感器1114被设置终端1100的正面、背面或侧面。当终端1100上设置有物理按键或厂商Logo时，指纹传感器1114能够与物理按键或厂商Logo集成在一起。

光学传感器1115用于采集环境光强度。在一个实施例中，处理器1101根据光学传感器1115采集的环境光强度，控制显示屏1105的显示亮度。具体地，当环境光强度较高时，调高显示屏1105的显示亮度；当环境光强度较低时，调低显示屏1105的显示亮度。在另一个实施例中，处理器1101还根据光学传感器1115采集的环境光强度，动态调整摄像头组件1106的拍摄参数。

接近传感器1116，也称距离传感器，通常设置在终端1100的前面板。接近传感器1116用于采集用户与终端1100的正面之间的距离。在一个实施例中，当接近传感器1116检测到用户与终端1100的正面之间的距离逐渐变小时，由处理器1101控制显示屏1105从亮屏状态切换为息屏状态；当接近传感器1116检测到用户与终端1100的正面之间的距离逐渐变大时，由处理器1101控制显示屏1105从息屏状态切换为亮屏状态。

本领域技术人员能够理解，图11中示出的结构并不构成对终端1100的限定，能够包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

图12是本申请实施例提供的一种计算机设备的结构示意图，该计算机设备1200可因配置或性能不同而产生比较大的差异，该计算机设备1200包括一个或一个以上处理器(Central Processing Units，CPU)1201和一个或一个以上的存储器1202，其中，该存储器1202中存储有至少一条计算机程序，该至少一条计算机程序由该一个或一个以上处理器1201加载并执行以实现上述各个实施例提供的应用测试方法。可选地，该计算机设备1200还具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算机设备1200还包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括至少一条计算机程序的存储器，上述至少一条计算机程序可由终端中的处理器执行以完成上述各个实施例中的应用测试方法。例如，该计算机可读存储介质包括ROM(Read-Only Memory，只读存储器)、RAM(Random-Access Memory，随机存取存储器)、CD-ROM(Compact Disc Read-OnlyMemory，只读光盘)、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品或计算机程序，包括一条或多条程序代码，该一条或多条程序代码存储在计算机可读存储介质中。计算机设备的一个或多个处理器能够从计算机可读存储介质中读取该一条或多条程序代码，该一个或多个处理器执行该一条或多条程序代码，使得计算机设备能够执行以完成上述实施例中的应用测试方法。

本领域普通技术人员能够理解实现上述实施例的全部或部分步骤能够通过硬件来完成，也能够通过程序来指令相关的硬件完成，可选地，该程序存储于一种计算机可读存储介质中，可选地，上述提到的存储介质是只读存储器、磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (15)

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

响应于对应用程序的测试指令，基于所述应用程序的开发引擎，运行所述应用程序的主进程；

获取对所述主进程中待测功能的测试用例数据，所述测试用例数据用于模拟实现所述待测功能所需的至少一个触发事件；

基于所述测试用例数据，向所述主进程输入所述至少一个触发事件；

输出所述至少一个触发事件的事件执行结果。

2.根据权利要求1所述的方法，其特征在于，所述基于所述测试用例数据，向所述主进程输入所述至少一个触发事件包括：

基于所述测试用例数据，注册所述至少一个触发事件；

基于所述至少一个触发事件的触发次序，向所述主进程依次输入所述至少一个触发事件。

3.根据权利要求2所述的方法，其特征在于，所述基于所述至少一个触发事件的触发次序，向所述主进程依次输入所述至少一个触发事件包括：

对所述至少一个触发事件中的任一触发事件，若所述任一触发事件的事件执行结果为事件执行成功，向所述主进程输入所述触发次序中所述任一触发事件的下一个触发事件；

若所述任一触发事件的事件执行结果为事件执行失败，基于所述任一触发事件所对应的异常处理逻辑，对所述任一触发事件进行处理。

4.根据权利要求3所述的方法，其特征在于，所述基于所述任一触发事件所对应的异常处理逻辑，对所述任一触发事件进行处理包括：

若所述异常处理逻辑为失败重试逻辑，重复向所述主进程输入所述任一触发事件，直到事件执行成功或者到达所述任一触发事件对应的重试次数；或者，

若所述异常处理逻辑为失败跳过逻辑，或者向所述主进程输入所述任一触发事件的次数到达所述重试次数，跳过所述任一触发事件，向所述主进程输入所述下一个触发事件。

5.根据权利要求3所述的方法，其特征在于，所述基于所述任一触发事件所对应的异常处理逻辑，对所述任一触发事件进行处理之前，所述方法还包括：

从所述测试用例数据中，获取所述任一触发事件对应的忽略错误参数；

若所述忽略错误参数为真，确定所述异常处理逻辑为失败跳过逻辑；

若所述忽略错误参数为假，确定所述异常处理逻辑为失败重试逻辑，从所述测试用例数据中读取所述任一触发事件对应的重试次数。

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

对所述至少一个触发事件中的任一触发事件，在向所述主进程输入所述任一触发事件之后，对所述主进程进行异常监控，输出异常监控结果。

7.根据权利要求6所述的方法，其特征在于，所述异常监控结果包括异常类型或者异常图像资料中至少一项，所述异常类型用于表征所述主进程所发生异常的种类，所述异常图像资料为所述主进程发生异常时的屏幕截图信息。

8.根据权利要求7所述的方法，其特征在于，所述异常类型包括目标异常或者超时异常中至少一项，所述目标异常是指需要被所述主进程抛出的异常，所述超时异常是指所述主进程发生阻塞的时长大于超时阈值。

9.根据权利要求1所述的方法，其特征在于，所述基于所述应用程序的开发引擎，运行所述应用程序的主进程包括：

编译所述应用程序的运行代码；

在编译成功的情况下，启动所述开发引擎；

在启动成功的情况下，运行所述主进程。

10.根据权利要求9所述的方法，其特征在于，所述编译所述应用程序的运行代码之后，所述方法还包括：

对所述运行代码进行编译检查，输出所述编译日志的分析结果。

11.根据权利要求9所述的方法，其特征在于，所述启动所述开发引擎之后，所述方法还包括：

对所述开发引擎进行闪退监控，输出所述开发引擎的闪退监控结果。

12.根据权利要求1所述的方法，其特征在于，所述方法还包括：

基于所述至少一个触发事件的事件执行结果，输出所述待测功能的测试结果，所述测试结果包括测试通过或者测试未通过，所述测试通过是指所述至少一个触发事件的事件执行结果均为事件执行成功，所述测试未通过是指所述至少一个触发事件中任一触发事件的事件执行结果为事件执行失败。

13.一种应用测试装置，其特征在于，所述装置包括：

运行模块，用于响应于对应用程序的测试指令，基于所述应用程序的开发引擎，运行所述应用程序的主进程；

获取模块，用于获取对所述主进程中待测功能的测试用例数据，所述测试用例数据用于模拟实现所述待测功能所需的至少一个触发事件；

输入模块，用于基于所述测试用例数据，向所述主进程输入所述至少一个触发事件；

输出模块，用于输出所述至少一个触发事件的事件执行结果。

14.一种计算机设备，其特征在于，所述计算机设备包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条计算机程序，所述至少一条计算机程序由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求12任一项所述的应用测试方法。

15.一种存储介质，其特征在于，所述存储介质中存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现如权利要求1至权利要求12任一项所述的应用测试方法。

Images