CN115510454A - 游戏测试方法、装置、电子设备及存储介质 - Google Patents

游戏测试方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN115510454A
CN115510454A CN202211249277.9A CN202211249277A CN115510454A CN 115510454 A CN115510454 A CN 115510454A CN 202211249277 A CN202211249277 A CN 202211249277A CN 115510454 A CN115510454 A CN 115510454A
Authority
CN
China
Prior art keywords
game
target
test case
version
test
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211249277.9A
Other languages
English (en)
Inventor
陈春龙
黄婉娟
刘显楠
徐星
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Netease Hangzhou Network Co Ltd
Original Assignee
Netease Hangzhou Network Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Netease Hangzhou Network Co Ltd filed Critical Netease Hangzhou Network Co Ltd
Priority to CN202211249277.9A priority Critical patent/CN115510454A/zh
Publication of CN115510454A publication Critical patent/CN115510454A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577Assessing vulnerabilities and evaluating computer system security
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/79Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/5546Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033Test or assess software

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请提供一种游戏测试方法、装置、电子设备和计算机可读存储介质,该方法先从游戏服务端获取各游戏的参考版本的真实玩家控制数据,然后处理真实玩家控制数据得到各游戏的测试用例集,每一测试用例集包括至少一个测试用例,再基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果,在监测结果表征目标版本存在漏洞时,修复漏洞,并在修复后继续基于目标测试用例集对目标版本进行循环测试,直至监测结果表征目标版本无漏洞。本申请的测试用例来自于游戏服务端的真实玩家控制数据,则真实性、复杂性和覆盖率均得到提升,且与游戏客户端的图像质量和交互方式均无关,因此更易满足测试需求。

Description

游戏测试方法、装置、电子设备及存储介质
技术领域
本申请涉及测试技术领域,尤其涉及一种游戏测试方法、装置、电子设备及存储介质。
背景技术
在游戏产品的新版本或新功能上线之前需要经过内部测试,在测试中发现漏洞并进行修复,以达到新版本或新功能的上线标准。在内部测试阶段,主要工作包括测试用例设计、测试用例执行以及漏洞识别三个环节。
当前在测试用例设计环节,主要有人工编写测试用例、随机生成测试用例和同一测试用例反复测试三种方式,然而,方式一的人力成本较高,且无法保证较高的覆盖率,方式二的随机性较大,会存在较大的测试盲点,方式三只能覆盖玩家操作可预测的场景,对于不可预测的玩家操作场景以随机聚集的爆发点场景则难以覆盖。即,在当前的测试用例设计环节中,测试用例的复杂度和覆盖率均无法满足测试需求。
当前在测试用例执行环节是通过自动化执行工具来进行,自动化执行工具主要基于图像识别和交互控件识别两种方式来直接对游戏客户端进行测试用例录制,但前者受限于图像质量和客户端分辨率等因素,准确率不高,后者受版本更新频率影响,需要录制用例的人员较为频繁地进行维护和迭代,因此效率较低。即,在当前的测试用例执行环节,测试用例的获取质量和获取效率也均无法满足测试需求。
因此,当前的游戏测试阶段存在测试需求难以满足的技术问题,需要改正。
发明内容
本申请实施例提供一种游戏测试方法、装置、电子设备及存储介质,用以缓解现有游戏测试过程中测试需求难以满足的技术问题。
为解决上述技术问题,本申请实施例提供以下技术方案:
本申请提供一种游戏测试方法,包括:
从游戏服务端获取各游戏的参考版本的真实玩家控制数据;
处理所述真实玩家控制数据,得到各游戏的测试用例集,每一所述测试用例集包括至少一个测试用例;
基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果;
在监测结果表征所述目标版本存在漏洞时,修复所述漏洞,并在修复后继续基于所述目标测试用例集对所述目标版本进行循环测试,直至监测结果表征所述目标版本无漏洞。
同时,本申请实施例还提供了一种游戏测试装置,包括:
获取模块,用于从游戏服务端获取各游戏的参考版本的真实玩家控制数据;
处理模块,用于处理所述真实玩家控制数据,得到各游戏的测试用例集,每一所述测试用例集包括至少一个测试用例;
测试模块,用于基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果;
修复模块,用于在监测结果表征所述目标版本存在漏洞时,修复所述漏洞,并在修复后继续基于所述目标测试用例集对所述目标版本进行循环测试,直至监测结果表征所述目标版本无漏洞。
本申请还提供一种电子设备,包括存储器和处理器;所述存储器存储有应用程序,所述处理器用于运行所述存储器内的应用程序,以执行上述任一项所述的游戏测试方法中的操作。
本申请实施例提供一种计算机可读存储介质,计算机可读存储介质存储有多条指令,指令适于处理器进行加载,以执行上述游戏测试方法中的步骤。
本申请提供一种游戏测试方法、装置、电子设备和计算机可读存储介质,在该方法中先从游戏服务端获取各游戏的参考版本的真实玩家控制数据,然后处理所述真实玩家控制数据,得到各游戏的测试用例集,每一所述测试用例集包括至少一个测试用例,再基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果,在监测结果表征所述目标版本存在漏洞时,修复所述漏洞,并在修复后继续基于所述目标测试用例集对所述目标版本进行循环测试,直至监测结果表征所述目标版本无漏洞。本申请中的测试用例均来自于真实玩家控制数据,则真实性、复杂性和覆盖率均得到了极大提升,且真实玩家控制数据是从游戏服务端中得到,与游戏客户端的图像质量和交互方式均无关,则测试用例的获取质量和获取效率也得到了较大提升,因此本申请的游戏测试方法更易满足测试需求。
附图说明
下面结合附图,通过对本申请的具体实施方式详细描述,将使本申请的技术方案及其它有益效果显而易见。
图1为本申请实施例提供的游戏测试方法的应用场景示意图。
图2为图1中测试服务器的测试架构图。
图3为本申请实施例提供的游戏测试方法的流程示意图。
图4为本申请实施例中游戏客户端和游戏服务端通信的基本框架。
图5为本申请实施例中自动录制过程的示意图。
图6为本申请实施例中放映机和纠错机的工作过程示意图。
图7为本申请实施例中目标游戏的目标版本在windows运行平台时的监测界面示意图。
图8为本申请实施例中目标游戏的目标版本在Android运行平台时的监测界面示意图。
图9为图7中某次循环测试对应的预警信息的展示界面示意图。
图10为本申请实施例测试用例管理界面的示意图。
图11为本申请实施例提供的游戏测试装置的结构示意图。
图12为本申请实施例提供的电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请实施例提供一种游戏测试方法、装置、电子设备和计算机可读存储介质,其中,该游戏测试装置可以集成在电子设备中,该电子设备可以是服务器,也可以是终端等设备。
请参阅图1,图1为本申请实施例所提供的游戏测试方法应用的场景示意图,该场景可以包括终端以及服务器,终端之间、服务器之间、以及终端与服务器之间通过各种网关组成的互联网等方式连接通信,其中,该应用场景中包括第一游戏客户端11、游戏服务器12、测试服务器13和第二游戏客户端14;第一游戏客户端11包括各游戏的已上线的参考版本,其运行在真实玩家的游戏设备中,第二游戏客户端14包括目标游戏的待测试的目标版本,其运行在游戏开发人员的设备中,游戏服务器12和测试服务器13均包括本地服务器和/或远程服务器等,游戏服务器12与第一游戏客户端11进行交互,用于缓存两者之间的交互数据,测试服务器13用于与游戏服务器12进行交互得到测试用例,并通过测试用例对第二游戏客户端14进行测试。
第一游戏客户端11、游戏服务器12、测试服务器13和第二游戏客户端14位于无线网络或有线网络中,以实现四者之间的数据交互,其中:
第一游戏客户端11可以对应多款游戏,真实玩家在玩各款游戏时,游戏服务端与第一游戏客户端11之间进行通信和数据交互,游戏服务器12位于游戏服务端,且真实玩家执行各种操作时产生的真实玩家控制数据均在游戏服务器12中有缓存。测试服务器13从游戏服务端的游戏服务器12中获取各游戏的参考版本的真实玩家控制数据,并处理得到各游戏的测试用例集,每一测试用例集包括至少一个测试用例。然后,基于这些测试用例集中的目标测试用例对第二游戏客户端14对应的目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果。在监测结果表征目标版本存在漏洞时,通知对应的游戏开发人员及时修复漏洞,并在修复后继续基于目标测试用例集对目标版本进行循环测试,直至监测结果表征目标版本无漏洞,最终完成对目标游戏的目标版本的测试,得到无漏洞的目标版本并进行上线发布。
如图2所示,为图1中测试服务器13的测试架构图,该架构主要包括摄像机、放映机和纠错机。摄像机从游戏服务器12中对n个游戏的参考版本中的玩家行为实时录制,录制得到的真实玩家控制数据在处理后得到各游戏的测试用例,同一游戏的所有测试用例形成测试用例集,n个测试用例集均存储在玩家真实行为数据库中。放映机可以从玩家真实行为数据库中随时提取所需的测试用例,当目标版本的游戏引擎、游戏脚本、游戏资源以及运行平台中的任意一者发生更新时,需要对目标游戏的目标版本进行测试时,此时放映机会在目标版本中自动播放这些测试用例,还原出真实用户具体操作对应的控制逻辑,纠错机对目标版本在这些控制逻辑下的运行情况进行监测,判断是否出现了脚本错、性能差、资源错或者闪退等问题。如果监测到有这些情况,则通知对应的游戏设计人员对目标版本的漏洞进行修复,然后放映机会继续提取所需的测试用例,并继续自动播放这些测试用例对修复后的目标版本进行测试,且继续进行监测,循环执行测试-监测-修复-测试的过程,直至满足预设的测试结束条件时,如果没有监测到目标版本中有漏洞,表示目标版本符合上线标准,可以将其进行发布。
需要说明的是,图1所示的系统场景示意图仅仅是一个示例,本申请实施例描述的服务器以及场景是为了更加清楚地说明本申请实施例的技术方案,并不构成对于本申请实施例提供的技术方案的限定,本领域普通技术人员可知,随着系统的演变和新业务场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。以下分别进行详细说明。需说明的是,以下实施例的描述顺序不作为对实施例优选顺序的限定。
在本申请实施例中,游戏测试是指测试人员在游戏产品的新版本或新功能上线之前,通过测试用例对游戏产品进行测试,在测试中发现漏洞并进行修复,以使得游戏产品能达到新版本或新功能的上线标准。游戏测试包括内部测试和外部测试,本申请的测试方法主要针对内部测试,在内部测试阶段,没有真实玩家参与,仅由内部测试人员使用测试用例来对游戏产品进行测试。
在本申请实施例中,测试用例是指对特定游戏的特定测试任务的描述文件,其内容可以包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,用于测试该游戏是否满足某个特定的功能需求。游戏的某个版本在上线前,需要通过大量各类场景下的测试用例对其进行全方位测试,以检查该游戏的各项功能是否均达到策划需求。
在本申请实施例中,游戏的参考版本是指游戏已经上线发布的版本,其可以被真实玩家从运行平台中获取,并在各真实玩家的设备中运行。真实玩家在玩游戏的过程中对游戏的各类控制数据缓存在游戏服务端。
在本申请实施例中,游戏的目标版本是指游戏未上线发布且当前需要进行测试的版本,其相对于参考版本在某些方面进行了更新,构成了与参考版本的区别,目标版本运行在游戏设计人员的设备中。对于某个具有参考版本的特定游戏,当该游戏的游戏引擎、游戏资源、游戏脚本或者运行平台中的任意一者发生了更新,则更新后的版本均作为该游戏的目标版本。
在本申请实施例中,游戏引擎是指已编写好的可编辑游戏系统,这些系统为游戏设计人员提供编写游戏所需的各种工具,使得游戏设计人员能容易和快速地做出游戏而不用由零开始。
在本申请实施例中,游戏脚本是指依据一定的格式编写的可执行文件,游戏脚本里记录了游戏的控制语句,游戏引擎将这些控制语句进行解析并执行相应的逻辑,从而转换成为生动的游戏画面。
在本申请实施例中,游戏资源是指游戏的图片、文字、音乐、动画以及其他类型的数据资源。
在本申请实施例中,运行平台是指游戏的运行载体,游戏的各版本在上线后均发布在特定的运行平台中,其可以包括街机平台、主机平台、电脑平台、便携平台等,一个运行平台可运行多个游戏。
在本申请实施例中,请参阅图3,图3是本申请实施例提供的游戏测试方法的流程示意图,具体包括:
S1:从游戏服务端获取各游戏的参考版本的真实玩家控制数据。
对于某个游戏的参考版本,其以游戏客户端的形式运行于真实玩家的游戏设备中,在玩家对游戏的参考版本进行操作时,游戏客户端与游戏服务端之间需要进行数据通信,则真实玩家控制数据会缓存在游戏服务端。具体地,如图4所示,为游戏客户端和游戏服务端通信的基本框架,游戏服务端可以与多个游戏的游戏客户端进行数据通信,多个游戏可以是相同的游戏,也可以是不同的游戏,但游戏客户端均为参考版本对应的客户端。游戏服务端包括多个实体和GATE模块,实体是指游戏中的控制对象,游戏服务端与各实体之间的数据通信均会先经过GATE,GATE具有一定的缓存空间,各游戏客户端与游戏服务端之间的交互数据缓存在该空间内,以起到一定的缓冲作用,避免数据爆炸。
真实玩家在游戏客户端中对游戏画面的各类交互控件执行触发操作后,均会调用该触发操作对应的底层接口来得到底层控制数据,底层控制数据经过GATE对游戏服务端的相应的实体进行控制,从而产生新的游戏画面并展示在游戏客户端中,在此交互过程中均会产生对应的真实玩家控制数据,如控制游戏角色战斗的底层数据,控制游戏画面景别切换的底层数据等,因此,真实玩家控制数据为游戏的底层数据,也即对游戏对象进行控制的底层逻辑,其与游戏客户端中交互控件的设计方式以及玩家的操作方式无关,交互控件的数量、位置、触发方式等因素的不同均不会影响真实玩家控制数据的内容。
例如,在游戏中对于需要从多个技能选项中选择某个技能这一场景,需要先控制游戏展示多个技能选项来供玩家选择,在游戏的第一个参考版本中,交互控件的设计方式为通过下拉菜单来展示多个技能选项,而在第二个参考版本中,交互控件的设计方式为通过多选框来展示多个技能选项,则在两个版本中交互方式不同,玩家所需执行的操作也不同的,但游戏客户端与游戏服务端进行数据通信后,在游戏服务端的GATE中均得到的是“在游戏界面展示多个技能选项给玩家选择”这一过程的底层控制数据。再例如,在第一个参考版本中实现退出游戏这一功能的交互控件在游戏画面中的左下角位置,在第二个参考版本中该交互控件在游戏画面中的右上角位置,则玩家在两个版本中退出游戏时需要点击的位置不同,需要执行的具体操作不同,但在GATE中均得到的是“退出游戏”这一过程的底层控制数据。
在一种实施例中,S1具体包括:获取各游戏的预设录制参数,预设录制参数包括预设周期、预设时长和预设场景;基于预设周期分别对各游戏的参考版本在预设场景下的交互数据进行录制,得到各游戏的预设时长的真实玩家控制数据。
对于每个游戏的参考版本,其与游戏服务端通信时产生的交互数据均会缓存在网关服务器中,本申请实施例中获取真实玩家控制数据的过程实质上是指对交互数据进行录制的过程,该过程由游戏引擎的底层录制技术来实现。由于每个游戏均具有一定规模的真实玩家,大量的真实玩家会持续产生交互数据,且交互数据覆盖游戏中的各类场景,为实现测试的精准化,可以先根据测试需求,为每个游戏预设录制周期、录制时长和录制场景,后续录制时仅从交互数据中获取需要参与测试的这部分数据。
对于每一游戏,预设录制参数均包括预设周期、预设时长和预设场景,预设周期用于限定每间隔多长时间进行一次录制,预设时长用于限定每份真实玩家控制数据的录制时长,预设场景用于限定每份真实玩家控制数据对应游戏中的哪个或哪些场景。例如,假设某个游戏具有副本A场景、副本B场景和副本C场景,预设录制参数中预设周期为1小时,预设周期为10分钟,预设场景为副本C场景,则对于该游戏在游戏服务端缓存的交互数据,每隔1小时进行一次录制,每次录制的真实玩家控制数据时长为10分钟,且每次只录制副本C场景下的真实玩家控制数据,在录制时的通用处理函数为:save_record(watch_time=600),600的单位为秒。
如图5所示,项目A至D的线上运营分别对应4款不同的游戏,对每款游戏均按照预设录制参数,以一定的录制周期对各特定场景的进行特定时长的定时录制,可以得到每个游戏的参考版本的真实玩家控制数据,且该数据在不断地更新,具有高时效性和高复杂度。
在当前已有的录制技术中,录制主要针对游戏客户端进行,包括基于图像识别的方案和基于交互控件识别的POCO方案。首先,基于图像识别的录制方案受制于运行平台的分辨率以及游戏画面的图像质量,精确度不高,且在游戏画面进行了更新后识别到的用户操作也会发生变化;基于交互控件识别的POCO方案则需要依靠识别出来的UI树进行控制,其识别的正确度与不同游戏引擎的开发程度有关,因此精确度也不高,且在游戏的整个生命周期内UI控件的更新频率是较高的,UI控件每更新一次,录制的内容均会发生变化,因此在游戏产品更新后,很大可能需要重新录制数据或者更新数据的情况,大量浪费人力成本,无法在质量和效率上有较大提高。
例如,对于上述实施例中提到的退出游戏这一功能对应的交互控件,在两个版本中一个位于左下角,一个位于右上角,则基于图像识别的方案对第一个版本录制得到的数据中,退出游戏的操作为点击左下角,如果将录制的数据在第二个版本中进行播放,则退出游戏时也会模拟点击左下角的操作,而第二个版本中退出游戏的交互控件并不在左下角,则无法完成退出游戏这一操作,也即该录制数据不能用于对第二个版本的测试。或者,两个版本中退出游戏这一功能对应的交互控件位置一致,但该控件本身较小,基于图像识别的方案对第一个版本录制得到的数据中,退出游戏的操作为点击左下角的A处,但由于第一个版本的画面质量不高,识别的点击位置出现了一定偏差,录制数据中点击位置识别成了该交互控件没有覆盖的B处,如果将录制的数据在第二个版本中进行播放,则退出游戏时会模拟点击B处的操作,也无法完成退出游戏这一操作,该录制数据同样不能用于对第二个版本的测试。再例如,对于上述实施例中提到的展示多个技能选项这一场景,在两个版本中一个方案为下拉菜单,一个方案为复选框,两个版本的UI控件并不相同,则基于POCO方案对第一个版本的录制数据,同样无法在第二个版本中实现展示技能选项这一功能,因此也无法用于对第二个版本的测试。
其次,由于录制是针对游戏客户端进行,难免会对玩家的游戏体验造成影响,且录制得到的数据量较大,对存储资源和处理资源的要求也较高。最后,针对游戏客户端的录制方式使得每个游戏的录制标准均不相同,则同一游戏的录制数据后续只能用于本游戏的其他版本的测试,适用面较窄。
而在本申请的录制过程中,首先,由于录制是针对游戏服务端的交互数据来进行的,游戏客户端的图像质量、设备分辨率、交互控件设计方式等均不会对录制结果造成影响,则在游戏产品更新后,只要玩家操作对应的底层控制逻辑不变,就不需要重新录制,从而保证了录制的质量和效率。其次,本申请的录制过程属于后台处理,整个录制过程不会影响玩家的游戏体验,对服务器的CPU消耗低,且相对于直接从游戏客户端录制,本实施例中从游戏服务端录制的真实玩家控制数据的数据量较小,录制的每份真实玩家控制数据通常不会超过1MB大小,对存储空间的要求和后续处理资源的要求均不会太高。最后,由于本申请的录制过程针对的是游戏服务端,则对于不同的游戏可以设置相同的录制标准,在录制后不同游戏可以得到统一标准的真实玩家控制数据,该数据具有通用性,则后续可以适用于跨游戏的测试场景,适用面得到了拓宽。
S2:处理真实玩家控制数据,得到各游戏的测试用例集,每一测试用例集包括至少一个测试用例。
对于录制的每份真实玩家控制数据,对其进行处理后可以得到一个测试用例,同一游戏当前已经得到的所有测试用例形成该游戏的测试用例集,多个不同游戏的测试用例集形成用例库。如图5所示,项目A至D的线上运营分别对应4款不同的游戏,每个游戏的测试用例集均存放在各自对应的项目用例库中,所有的项目用例库形成完整的用例库,后续当需要新增或删除某个游戏的测试任务时,可以在完整用例库中对该游戏对应的项目用例库进行相应地增加和删除。
在一种实施例中,还可以设置定期去除低时效性数据的机制,即对所有游戏均设定一时效周期,例如5天,当设置了该机制时,在第i个时效周期内,每间隔1小时对同一游戏的特定场景录制一份时长为10分钟的真实玩家控制数据,则5天共可以得到Q份数据,并处理得到Q个测试用例,在第i+1个时效周期内,每得到一个新的测试用例,则去除当前测试用例集中已存在时间最久的一个测试用例,以使得测试用例集中所有测试用例的总数量始终不超过Q个,且Q个测试用例均具有高时效性。
在一种实施例中,S2具体包括:处理每一预设周期内的真实玩家控制数据,得到目标格式的各测试用例,并生成各测试用例的播放接口;分别组合同一游戏的各测试用例,得到各游戏的测试用例集。对同一游戏,将其每一预设周期内录制的真实玩家控制数据处理为二进制的文件格式,形成一个测试用例,且为每个测试用例生成UUID(UniversallyUnique Identifier,通用唯一标识符),然后存储在指定数据库中,属于该游戏的所有测试用例形成该游戏的测试用例集。对于录制的每个测试用例,在后续步骤中需要进行播放,则还需要为每个测试用例生成对应的播放接口,播放接口的要求包括:replay_port(gameID,data,start,end),其中replay_port是播放测试用例的接口,gameID是该游戏的ID,data是该测试用例的录制数据,start是开始时间,end是结束时间。
S3:基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果。
目标游戏为当前需要进行测试的游戏,目标游戏的目标版本为相对于参考版本进行了更新的版本,其同样以游戏客户端的形式运行于测试人员的设备中。对于目标游戏的目标版本,先从用例库中确定当前需要参与测试的目标测试用例集,然后使用目标测试用例集中的各目标测试用例对目标版本进行循环测试,循环测试是指从目标测试用例集中得到一定数量的目标测试用例,然后使用这些目标测试用例进行反复测试,每个目标测试用例均可以反复播放一定的次数。假设目标测试用例中包含K个目标测试用例,在循环测试时,可以遍历K个目标测试用例依次对目标版本进行一次测试,共执行N次遍历测试;也可以每次只使用一个目标测试用例对目标版本进行N次测试,N次测试完成后再更换下一个目标测试用例进行N次测试,本申请对循环测试的具体过程不做限定,每次参数测试的目标测试用例的数量、参与测试的顺序、循环测试的次数以及循环测试的方式等均可根据测试需求来提前设定。
在循环测试时,对每个目标测试用例的测试过程进行监测,可以得到监测结果,监测结果可以包括两种,一种是目标游戏的目标版本可以正常运行,没有出现任何异常,一种则是出现了异常,在异常时根据具体情况的不同会显示不同的信息。
在一种实施例中,S3具体包括:监测目标游戏的游戏引擎、游戏脚本、游戏资源以及运行平台中的任意一者是否更新;若是,根据更新状态从各游戏的测试用例集中确定目标测试用例集,并基于目标测试用例集对目标游戏的目标版本进行循环测试。
如图5和图6所示,本申请实施例中对目标游戏的目标版本的测试为自动测试,服务器自动监测目标游戏的更新情况,如果监测到目标游戏进行了更新,则将更新后的版本作为目标版本,自动使用目标测试用例集来进行测试。
目标游戏的更新状态主要包括四种情况,即游戏引擎更新、游戏脚本更新、游戏资源更新以及运行平台更新,其中游戏引擎、游戏脚本和游戏资源的更新是指这三者在原有版本上进行了内容的增加、减少或者调整,运行平台更新则是指目标版本所在的运行平台与参考版本的运行平台为不同类型的平台,也即目标版本上线了新的平台,如参考版本的运行平台为便携平台,目标版本的运行平台为主机平台,则将其视为运行平台更新。在监测到目标游戏出现上述任意一种情况的更新时,都表示目标游戏的当前版本相对于参考版本具有一定的差异性,因此需要对其进行测试。此时,根据更新状态从多个游戏对应的多个测试用例集中确定出需要参与本次测试的目标测试用例集,放映机实时获取目标测试用例集中的目标测试用例,并将目标游戏的目标版本对应的目标游戏包推送到放映机中,然后自动播放这些目标测试用例对目标版本进行测试。
在一种实施例中,根据更新状态从各游戏的测试用例集中确定目标测试用例集的步骤包括:在更新状态表征目标游戏的游戏引擎更新时,将游戏引擎中所有游戏的测试用例集均确定为目标测试用例集;在更新状态表征目标游戏的游戏脚本、游戏资源或运行平台更新时,将目标游戏的测试用例集确定为目标测试用例集。
当目标游戏的游戏引擎更新时,由于同一游戏引擎一般用于多款游戏产品,针对此种更新情况,可以将用例库中该游戏引擎中所有游戏的测试用例集均确定为目标测试用例集,并且将目标测试用例集中与游戏引擎相关的测试用例均确定为目标测试用例,对目标游戏包进行测试,以提高对游戏引擎的测试覆盖率。当目标游戏的游戏脚本或游戏资源更新时,由于游戏脚本和游戏资源均与一款具体游戏绑定,均具有唯一性,针对这两种更新情况,只需要将目标游戏的测试用例集确定为目标测试用例集并对目标游戏包进行测试。当目标游戏的运行平台更新,也即目标游戏需要在新运行平台上架时,虽然运行平台发生了变化,但也仅与目标游戏相关,针对此种更新情况,也只需要将目标游戏的测试用例集确定为目标测试用例集并对目标游戏包进行测试。
在一种实施例中,基于目标测试用例集对目标游戏的目标版本进行循环测试的步骤,包括:获取目标测试用例集中各目标测试用例的目标播放接口;调用各目标播放接口在目标游戏的目标版本中循环播放各目标测试用例。在上述实施例中,对于每个测试用例,均生成了对应的播放接口,则在确定了目标测试用例集中,直接调用各目标测试用例的目标播放接口在目标游戏的目标版本中循环播放各目标测试用例,还原出真实用户的各类控制行为。
在一种实施例中,S3具体包括:获取目标游戏的目标版本运行过程中的每一目标帧图像,并获取目标游戏的参考版本运行过程中的每一参考帧图像;对比每一目标帧图像与对应的参考帧图像的相似度;在相似度低于第一阈值时,得到渲染错误的监测结果。
当目标游戏的游戏版本存在漏洞时,使用测试用例对其进行测试会出现各类异常,为尽可能全面地监测出存在的问题,需要设计不同的监测机制。
在本申请实施例中,监测机制为渲染画面错误甄别机制。具体地,对于目标游戏,当真实玩家对参考版本进行了某一控制时,在参考版本中产生了对应的游戏视频,游戏视频中的每一帧图像均作为参考帧图像,当采用该控制对应的测试用例对来目标版本进行测试时,播放该测试用例相当于玩家在目标版本中执行了相同的控制,则在目标版本中同样会产生对应的游戏视频,游戏视频中的每一帧图像均作为目标帧图像。当目标版本中没有漏洞时,相同的控制在参考版本中和在目标版本中产生的游戏视频理论上是相同的,设两个版本中游戏视频均有P帧图像,则参考版本的第j参考帧图像与目标版本的第j目标帧图像对应。在运行过程中实时对目标版本的每一目标帧图像进行截图,并对比每一目标帧图像与对应的参考帧图像的相似度,如果某两个对应帧的相似度低于第一阈值,如低于95%,则表示目标版本中该帧图像出现了画面渲染错误,此时需要给出渲染错误的监测结果。
在一种实施例中,S3具体包括:获取目标游戏的目标版本运行过程中的当前性能数据,并获取目标游戏的参考版本运行过程中的历史性能数据;对比当前性能数据和历史性能数据的差异度;在差异度超过第二阈值时,得到性能异常的监测结果。
在本申请实施例中,监测机制为性能监测机制。具体地,对于目标游戏,当真实玩家对参考版本进行了某一控制时,对参考版本在对应运行平台运行时的各性能指标进行监测,得到历史性能数据,各性能指标主要包括帧率、内存、耗电量、CPU占用率、GPU占用率、网络流量等,当采用该控制对应的测试用例对来目标版本进行测试时,对目标版本在对应运行平台运行时的各性能指标也进行监测,得到当前性能数据。当目标版本中没有漏洞时,相同的控制在参考版本中和在目标版本中产生的性能数据理论上是相同的,将当前性能数据和历史性能数据进行对比,得到两者的差异度,如果差异度超过第二阈值,如3%,即表示目标版本中的性能存在异常,此时需要给出性能异常的监测结果。
除了上述两种监测机制外,本申请还包括另外两种监测机制,一种为crash类别监控机制,另一种为脚本错类别监控机制。前者是指目标版本在运行时游戏应用程序运行中断,发生crash(闪退或者崩溃),此时需要给出程序crash的监测结果,后者是指目标版本在运行时出现相关脚本错,此时需要给出脚本错的监测结果。
在当前的游戏测试方法中,仅设计了crash类别监控机制和脚本错类别监控机制,监测覆盖率并不高。本申请在上述两种监测机制外,还对渲染画面和性能进行了监测,则监控机制更加完善,覆盖率更高,目标版本在上线后的质量更加有保证。
S4:在监测结果表征目标版本存在漏洞时,修复漏洞,并在修复后继续基于目标测试用例集对目标版本进行循环测试,直至监测结果表征目标版本无漏洞。
如图6所示,在放映机播放测试用例进行测试的过程中,纠错机实时监测测试过程,以对目标版本的漏洞进行识别。当出现渲染错误、性能异常、程序crash和脚本错中任意一种监测结果时,表征目标游戏的目标版本存在漏洞,需要对其进行修复更新。此时,可以根据监测结果的具体内容去分类定位问题,并通过通信平台进行针对性的消息推送,提醒对应的游戏开发人员进行漏洞的修复。在修复之后将目标版本的目标游戏包再推送给放映机,然后放映机继续基于目标测试用例集对该目标版本进行循环测试。例如,修复前在测试用例t的测试过程中监测到漏洞,在修复后可以优先基于测试用例t对修复后的目标版本进行测试,以判断当前漏洞是否已经修复成功,再按照原有的测试顺序,依次用目标测试用例集中的其他测试用例来进行测试,直至所有的测试用例均已经循环测试过预定的次数,且监测结果均表征没有漏洞。此时,测试通过,可以将目标游戏的目标版本进行上线发布。由于目标测试用例集中的测试用例是在不断更新的,则参与测试的目标测试用例具有较高的测试覆盖率,测试效果和修复效果也较佳。
对于上述实施例中的四种监控机制,可以定位不同级别的漏洞,具体地,对程序crash的监测结果定位为P1级别漏洞,对脚本错的监测结果定位为P2或P3级别漏洞,对渲染错误的监测结果定位为P2或P3级别漏洞,对性能异常的监测结果定位为P1级别漏洞。P3至P1级别依次上升,修复优先级也依次上升。
监测结果和对应的漏洞分级情况可以通过对应的监测界面来进行展示,如图7和图8所示,分别为目标游戏的目标版本在windows运行平台和Android运行平台中进行测试时的监测界面,在两个测试场景下均有多个测试用例参与了测试,图7和图8中的纵坐标均表示参与测试的同一游戏的不同目标版本,横坐标表示每个目标版本的测试过程中各级别漏洞与总漏洞的数量占比,为便于区分,用△表示P1级别漏洞,用○表示P2级别漏洞,用□表示P3级别漏洞,每条曲线用于表示本级别漏洞的数量占比在不同目标版本下的变化趋势。当需要知道某个目标版本的测试的漏洞监测结果时,可以对曲线上的对应点执行触发操作,则可以在当前界面中展示各级别漏洞的占比,例如图7中的0.049、0以及0.951分别表示某个目标版本在测试时P1级别的漏洞占比为4.9%,P2级别的漏洞占比为0.0%,P3级别的漏洞占比为95.1%,图8中的0.011、0以及0.989分别表示某个目标版本在测试时P1级别的漏洞占比为1.1%,P2级别的漏洞占比为0.0%,P3级别的漏洞占比为98.9%。
在每完成一个目标版本的循环测试后,还可以根据监测结果生成并展示该目标版本对应的预警信息。如图9所示,为图7中某次循环测试对应的预警信息,图9中可以展示本次循环测试的测试用例总数82,运行平台windows,三种级别的漏洞(BUG)分布情况,并将P1等级漏洞对应的测试用例作为高风险项进行预警,为漏洞的修复提供参考,从而提高游戏开发人员修复漏洞的效率。
在上述实施例中,对目标游戏的目标版本进行测试时采用自动测试的方式,但本申请不以此为限,还可以采用手动方式选择某些测试用例进行单独测试。如图10所示,可以在测试用例的相关管理界面上展示已经得到的测试用例的相关信息,如每个测试用例的UUID、操作系统、场景名、场景编号、更新时间、执行成功次数、执行失败次数,并提供生成指令的操作按钮。具体地,测试用例的UUID格式可以是629dcc8817d88b42817140133VqXFTMm01,操作系统可以是Windows、Andorid、iOS等,场景名和场景编号可以自动生成。当需要用某个测试用例进行单独测试时,可以点击该测试用例对应的“生成指令”按钮,则可以生成执行该测试用例的相关指令对待测的目标版本进行测试,并对执行测试后的执行结果进行统计。执行成功是指播放该测试用例的整个过程中游戏没有监测到漏洞,没有报错,执行失败则是播放该测试用例的整个过程中游戏监测到漏洞进行了报错,可以分别统计两种情况下的次数得到执行成功次数和执行失败次数,以供测试人员进行参考和决策。
综合上述实施例的内容,本申请的游戏测试方法相对于现有的游戏测试方法,主要优势体现在以下几个方面。
当前在测试用例设计环节,主要包括以下三种方式:方式1、人工设计大量测试用例进行产品功能的全方面覆盖测试,这部分测试用例设计是特定的;方式2、通过MonkeyTest方法自动进行随机测试,这部分测试用例是随机的;方式3、暴力压测方法,创建足够多的实例,且相同用例在多实例中同时反复测试。然而,方式1中设计测试用例非常依靠人员的数量和经验能力,导致人力成本高,但覆盖率往往不能达到零缺陷要求,在游戏产品上线之后可能出现大量的低级漏洞;方式2中的方法只能实现在用户交互层进行随机的点击,无法完全模拟玩家的真实操作,存在较大的随机性和遗漏;方式3中的方法虽然可以在一定程度上考验服务器的负载能力,但也只能覆盖玩家操作可预测的场景,对于不可预测的玩家操作场景以随机聚集的爆发点场景则难以覆盖,使得服务器仍然存在某一时刻的瞬时压力峰值超出上限而奔溃的风险。
而在本申请中,由于测试用例是从游戏的真实运行过程中录制得到,不需要再人工进行编写和设计,因此极大地降低了人力成本,且提升了效率。此外,由于测试用例均来自于真实玩家控制数据,则真实性、复杂性和覆盖率均得到了极大提升,对于不可预测的玩家操作场景也可以覆盖,则测试效果更佳,游戏产品的质量更加有保障。
当前在测试用例执行环节,主要通过自动化工具针对游戏客户端执行,包括基于图像识别的方案和基于交互控件识别的POCO方案,此过程较为依赖测试人员的能力和经验以及工具的稳定和效率,且录制过程游戏客户端的游戏画面质量、游戏设备分辨率、游戏版本更新频率、游戏交互控件更换频率等因素对录制结果的影响较大,使得录制精确度和稳定性均不高。
而在本申请中,可以直接自动从游戏服务端进行录制,再自动到目标版本中进行播放,则不需要使用专用工具,受人员和工具的影响较小,且不受游戏客户端中各交互因素的影响,因此录制精确度和稳定性都较高。
当前在漏洞识别环节,仅设置了脚本错误监测机制和程序crash监测机制,监测机制不够完善,使得识别效果不佳。
而在本申请中,除了上述两种监测机制外,还对渲染画面和性能进行了监测,则监控机制更加完善,覆盖率更高,目标版本在上线后的质量更加有保证。
综上,本申请的游戏测试方法相对于现有的游戏测试方法,更易满足测试需求。
相应地,如图11所示,本申请还提供一种游戏测试装置,具体包括:
获取模块101,用于从游戏服务端获取各游戏的参考版本的真实玩家控制数据;
处理模块102,用于处理所述真实玩家控制数据,得到各游戏的测试用例集,每一所述测试用例集包括至少一个测试用例;
测试模块103,用于基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果;
修复模块104,用于在监测结果表征所述目标版本存在漏洞时,修复所述漏洞,并在修复后继续基于所述目标测试用例集对所述目标版本进行循环测试,直至监测结果表征所述目标版本无漏洞。
在一种实施例中,各游戏的参考版本与所述游戏服务端的交互数据缓存于所述游戏服务端,获取模块101包括:
获取各游戏的预设录制参数,所述预设录制参数包括预设周期、预设时长和预设场景;
基于所述预设周期分别对各游戏的参考版本在所述预设场景下的交互数据进行录制,得到各游戏的预设时长的真实玩家控制数据。
在一种实施例中,处理模块102包括:
处理每一所述预设周期内的所述真实玩家控制数据,得到目标格式的各测试用例,并生成各测试用例的播放接口;
分别组合同一游戏的各测试用例,得到各游戏的测试用例集。
在一种实施例中,测试模块103包括:
监测所述目标游戏的游戏引擎、游戏脚本、游戏资源以及运行平台中的任意一者是否更新;
若是,根据更新状态从各游戏的测试用例集中确定目标测试用例集,并基于所述目标测试用例集对所述目标游戏的目标版本进行循环测试。
在一种实施例中,
在更新状态表征所述目标游戏的游戏引擎更新时,将所述游戏引擎中所有游戏的测试用例集均确定为目标测试用例集;
在更新状态表征所述目标游戏的游戏脚本、游戏资源或运行平台更新时,将所述目标游戏的测试用例集确定为目标测试用例集。
在一种实施例中,
获取所述目标测试用例集中各目标测试用例的目标播放接口;
调用各目标播放接口在所述目标游戏的目标版本中循环播放各目标测试用例。
在一种实施例中,测试模块103包括:
获取所述目标游戏的目标版本运行过程中的每一目标帧图像,并获取所述目标游戏的参考版本运行过程中的每一参考帧图像;
对比每一所述目标帧图像与对应的所述参考帧图像的相似度;
在所述相似度低于第一阈值时,得到渲染错误的监测结果。
在一种实施例中,测试模块103包括:
获取所述目标游戏的目标版本运行过程中的当前性能数据,并获取所述目标游戏的参考版本运行过程中的历史性能数据;
对比所述当前性能数据和所述历史性能数据的差异度;
在所述差异度超过第二阈值时,得到性能异常的监测结果。
本申请的游戏测试装置中,由于测试用例均来自于真实玩家控制数据,则真实性、复杂性和覆盖率均得到了极大提升,且真实玩家控制数据是从游戏服务端中得到,与游戏客户端的图像质量和交互方式均无关,则测试用例的获取质量和获取效率也得到了较大提升,因此本申请的游戏测试装置更易满足测试需求。
相应的,本申请实施例还提供一种电子设备,如图12所示,该电子设备可以包括射频(RF,Radio Frequency)电路121、包括有一个或一个以上计算机可读存储介质的存储器122、输入单元123、显示单元124、传感器125、音频电路126、WiFi模块127、包括有一个或者一个以上处理核心的处理器128、以及电源129等部件。本领域技术人员可以理解,图12中示出的电子设备结构并不构成对电子设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。其中:
射频电路121可用于收发信息或通话过程中,信号的接收和发送,特别地,将基站的下行信息接收后,交由一个或者一个以上处理器128处理;另外,将涉及上行的数据发送给基站。存储器122可用于存储软件程序以及模块,处理器128通过运行存储在存储器122的软件程序以及模块,从而执行各种功能应用以及数据处理。输入单元123可用于接收输入的数字或字符信息,以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。
显示单元124可用于显示由用户输入的信息或提供给用户的信息以及服务器的各种图形用户接口,这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。
电子设备还可包括至少一种传感器125,比如光传感器、运动传感器以及其他传感器。音频电路126包括扬声器,扬声器可提供用户与电子设备之间的音频接口。
WiFi属于短距离无线传输技术,电子设备通过WiFi模块127可以帮助用户收发电子邮件、浏览网页和访问流式媒体等,它为用户提供了无线的宽带互联网访问。虽然图12示出了WiFi模块127,但是可以理解的是,其并不属于电子设备的必须构成,完全可以根据需要在不改变申请的本质的范围内而省略。
处理器128是电子设备的控制中心,利用各种接口和线路连接整个手机的各个部分,通过运行或执行存储在存储器122内的软件程序和/或模块,以及调用存储在存储器122内的数据,执行电子设备的各种功能和处理数据,从而对手机进行整体监控。
电子设备还包括给各个部件供电的电源129(比如电池),优选的,电源可以通过电源管理系统与处理器128逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
尽管未示出,电子设备还可以包括摄像头、蓝牙模块等,在此不再赘述。具体在本实施例中,服务器中的处理器128会按照如下的指令,将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器122中,并由处理器128来运行存储在存储器122中的应用程序,从而实现以下功能:
从游戏服务端获取各游戏的参考版本的真实玩家控制数据;
处理所述真实玩家控制数据,得到各游戏的测试用例集,每一所述测试用例集包括至少一个测试用例;
基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果;
在监测结果表征所述目标版本存在漏洞时,修复所述漏洞,并在修复后继续基于所述目标测试用例集对所述目标版本进行循环测试,直至监测结果表征所述目标版本无漏洞。
在一种实施例中,各游戏的参考版本与所述游戏服务端的交互数据缓存于所述游戏服务端,实现功能:
获取各游戏的预设录制参数,所述预设录制参数包括预设周期、预设时长和预设场景;
基于所述预设周期分别对各游戏的参考版本在所述预设场景下的交互数据进行录制,得到各游戏的预设时长的真实玩家控制数据。
在一种实施例中,实现功能:
处理每一所述预设周期内的所述真实玩家控制数据,得到目标格式的各测试用例,并生成各测试用例的播放接口;
分别组合同一游戏的各测试用例,得到各游戏的测试用例集。
在一种实施例中,实现功能:
监测所述目标游戏的游戏引擎、游戏脚本、游戏资源以及运行平台中的任意一者是否更新;
若是,根据更新状态从各游戏的测试用例集中确定目标测试用例集,并基于所述目标测试用例集对所述目标游戏的目标版本进行循环测试。
在一种实施例中,实现功能:
在更新状态表征所述目标游戏的游戏引擎更新时,将所述游戏引擎中所有游戏的测试用例集均确定为目标测试用例集;
在更新状态表征所述目标游戏的游戏脚本、游戏资源或运行平台更新时,将所述目标游戏的测试用例集确定为目标测试用例集。
在一种实施例中,实现功能:
获取所述目标测试用例集中各目标测试用例的目标播放接口;
调用各目标播放接口在所述目标游戏的目标版本中循环播放各目标测试用例。
在一种实施例中,实现功能:
获取所述目标游戏的目标版本运行过程中的每一目标帧图像,并获取所述目标游戏的参考版本运行过程中的每一参考帧图像;
对比每一所述目标帧图像与对应的所述参考帧图像的相似度;
在所述相似度低于第一阈值时,得到渲染错误的监测结果。
在一种实施例中,实现功能:
获取所述目标游戏的目标版本运行过程中的当前性能数据,并获取所述目标游戏的参考版本运行过程中的历史性能数据;
对比所述当前性能数据和所述历史性能数据的差异度;
在所述差异度超过第二阈值时,得到性能异常的监测结果。
本申请的电子设备实现的功能中,由于测试用例均来自于真实玩家控制数据,则真实性、复杂性和覆盖率均得到了极大提升,且真实玩家控制数据是从游戏服务端中得到,与游戏客户端的图像质量和交互方式均无关,则测试用例的获取质量和获取效率也得到了较大提升,因此更易满足测试需求。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见上文的详细描述,此处不再赘述。
本领域普通技术人员可以理解,上述实施例的各种方法中的全部或部分步骤可以通过指令来完成,或通过指令控制相关的硬件来完成,该指令可以存储于一计算机可读存储介质中,并由处理器进行加载和执行。
为此,本申请实施例提供一种计算机可读存储介质,其中存储有多条指令,该指令能够被处理器进行加载,以实现以下功能:
从游戏服务端获取各游戏的参考版本的真实玩家控制数据;
处理所述真实玩家控制数据,得到各游戏的测试用例集,每一所述测试用例集包括至少一个测试用例;
基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果;
在监测结果表征所述目标版本存在漏洞时,修复所述漏洞,并在修复后继续基于所述目标测试用例集对所述目标版本进行循环测试,直至监测结果表征所述目标版本无漏洞。
在一种实施例中,各游戏的参考版本与所述游戏服务端的交互数据缓存于所述游戏服务端,实现功能:
获取各游戏的预设录制参数,所述预设录制参数包括预设周期、预设时长和预设场景;
基于所述预设周期分别对各游戏的参考版本在所述预设场景下的交互数据进行录制,得到各游戏的预设时长的真实玩家控制数据。
在一种实施例中,实现功能:
处理每一所述预设周期内的所述真实玩家控制数据,得到目标格式的各测试用例,并生成各测试用例的播放接口;
分别组合同一游戏的各测试用例,得到各游戏的测试用例集。
在一种实施例中,实现功能:
监测所述目标游戏的游戏引擎、游戏脚本、游戏资源以及运行平台中的任意一者是否更新;
若是,根据更新状态从各游戏的测试用例集中确定目标测试用例集,并基于所述目标测试用例集对所述目标游戏的目标版本进行循环测试。
在一种实施例中,实现功能:
在更新状态表征所述目标游戏的游戏引擎更新时,将所述游戏引擎中所有游戏的测试用例集均确定为目标测试用例集;
在更新状态表征所述目标游戏的游戏脚本、游戏资源或运行平台更新时,将所述目标游戏的测试用例集确定为目标测试用例集。
在一种实施例中,实现功能:
获取所述目标测试用例集中各目标测试用例的目标播放接口;
调用各目标播放接口在所述目标游戏的目标版本中循环播放各目标测试用例。
在一种实施例中,实现功能:
获取所述目标游戏的目标版本运行过程中的每一目标帧图像,并获取所述目标游戏的参考版本运行过程中的每一参考帧图像;
对比每一所述目标帧图像与对应的所述参考帧图像的相似度;
在所述相似度低于第一阈值时,得到渲染错误的监测结果。
在一种实施例中,实现功能:
获取所述目标游戏的目标版本运行过程中的当前性能数据,并获取所述目标游戏的参考版本运行过程中的历史性能数据;
对比所述当前性能数据和所述历史性能数据的差异度;
在所述差异度超过第二阈值时,得到性能异常的监测结果。
本申请的计算机可读存储介质实现的功能中,由于测试用例均来自于真实玩家控制数据,则真实性、复杂性和覆盖率均得到了极大提升,且真实玩家控制数据是从游戏服务端中得到,与游戏客户端的图像质量和交互方式均无关,则测试用例的获取质量和获取效率也得到了较大提升,因此更易满足测试需求。
以上对本申请实施例所提供的一种游戏测试方法、装置、电子设备和计算机可读存储介质进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的技术方案及其核心思想;本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例的技术方案的范围。

Claims (11)

1.一种游戏测试方法,其特征在于,包括:
从游戏服务端获取各游戏的参考版本的真实玩家控制数据;
处理所述真实玩家控制数据,得到各游戏的测试用例集,每一所述测试用例集包括至少一个测试用例;
基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果;
在监测结果表征所述目标版本存在漏洞时,修复所述漏洞,并在修复后继续基于所述目标测试用例集对所述目标版本进行循环测试,直至监测结果表征所述目标版本无漏洞。
2.如权利要求1所述的游戏测试方法,其特征在于,各游戏的参考版本与所述游戏服务端的交互数据缓存于所述游戏服务端,从游戏服务端获取各游戏的参考版本的真实玩家控制数据的步骤,包括:
获取各游戏的预设录制参数,所述预设录制参数包括预设周期、预设时长和预设场景;
基于所述预设周期分别对各游戏的参考版本在所述预设场景下的交互数据进行录制,得到各游戏的预设时长的真实玩家控制数据。
3.如权利要求2所述的游戏测试方法,其特征在于,处理所述真实玩家控制数据,得到各游戏的测试用例集的步骤,包括:
处理每一所述预设周期内的所述真实玩家控制数据,得到目标格式的各测试用例,并生成各测试用例的播放接口;
分别组合同一游戏的各测试用例,得到各游戏的测试用例集。
4.如权利要求3所述的游戏测试方法,其特征在于,基于目标测试用例集对目标游戏的目标版本进行循环测试的步骤,包括:
监测所述目标游戏的游戏引擎、游戏脚本、游戏资源以及运行平台中的任意一者是否更新;
若是,根据更新状态从各游戏的测试用例集中确定目标测试用例集,并基于所述目标测试用例集对所述目标游戏的目标版本进行循环测试。
5.如权利要求4所述的游戏测试方法,其特征在于,根据更新状态从各游戏的测试用例集中确定目标测试用例集的步骤,包括:
在更新状态表征所述目标游戏的游戏引擎更新时,将所述游戏引擎中所有游戏的测试用例集均确定为目标测试用例集;
在更新状态表征所述目标游戏的游戏脚本、游戏资源或运行平台更新时,将所述目标游戏的测试用例集确定为目标测试用例集。
6.如权利要求4所述的游戏测试方法,其特征在于,基于所述目标测试用例集对所述目标游戏的目标版本进行循环测试的步骤,包括:
获取所述目标测试用例集中各目标测试用例的目标播放接口;
调用各目标播放接口在所述目标游戏的目标版本中循环播放各目标测试用例。
7.如权利要求1所述的游戏测试方法,其特征在于,对测试过程进行监测,得到监测结果的步骤,包括:
获取所述目标游戏的目标版本运行过程中的每一目标帧图像,并获取所述目标游戏的参考版本运行过程中的每一参考帧图像;
对比每一所述目标帧图像与对应的所述参考帧图像的相似度;
在所述相似度低于第一阈值时,得到渲染错误的监测结果。
8.如权利要求1所述的游戏测试方法,其特征在于,对测试过程进行监测,得到监测结果的步骤,包括:
获取所述目标游戏的目标版本运行过程中的当前性能数据,并获取所述目标游戏的参考版本运行过程中的历史性能数据;
对比所述当前性能数据和所述历史性能数据的差异度;
在所述差异度超过第二阈值时,得到性能异常的监测结果。
9.一种游戏测试装置,其特征在于,包括:
获取模块,用于从游戏服务端获取各游戏的参考版本的真实玩家控制数据;
处理模块,用于处理所述真实玩家控制数据,得到各游戏的测试用例集,每一所述测试用例集包括至少一个测试用例;
测试模块,用于基于目标测试用例集对目标游戏的目标版本进行循环测试,并对测试过程进行监测,得到监测结果;
修复模块,用于在监测结果表征所述目标版本存在漏洞时,修复所述漏洞,并在修复后继续基于所述目标测试用例集对所述目标版本进行循环测试,直至监测结果表征所述目标版本无漏洞。
10.一种电子设备,其特征在于,包括存储器和处理器;所述存储器存储有应用程序,所述处理器用于运行所述存储器内的应用程序,以执行权利要求1至8任一项所述的游戏测试方法中的步骤。
11.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行以实现权利要求1至8任一项所述的游戏测试方法中的步骤。
CN202211249277.9A 2022-10-12 2022-10-12 游戏测试方法、装置、电子设备及存储介质 Pending CN115510454A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211249277.9A CN115510454A (zh) 2022-10-12 2022-10-12 游戏测试方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211249277.9A CN115510454A (zh) 2022-10-12 2022-10-12 游戏测试方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN115510454A true CN115510454A (zh) 2022-12-23

Family

ID=84509974

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211249277.9A Pending CN115510454A (zh) 2022-10-12 2022-10-12 游戏测试方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN115510454A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116225969A (zh) * 2023-05-08 2023-06-06 欢喜时代(深圳)科技有限公司 一种游戏运行系统的稳定性测试方法及系统
CN117234935A (zh) * 2023-09-28 2023-12-15 重庆赛力斯新能源汽车设计院有限公司 基于虚幻引擎的测试方法、装置、电子设备及存储介质
CN117874772A (zh) * 2024-03-11 2024-04-12 广州锦高信息科技有限公司 应用软件漏洞扫描方法及系统

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116225969A (zh) * 2023-05-08 2023-06-06 欢喜时代(深圳)科技有限公司 一种游戏运行系统的稳定性测试方法及系统
CN116225969B (zh) * 2023-05-08 2023-06-30 欢喜时代(深圳)科技有限公司 一种游戏运行系统的稳定性测试方法及系统
CN117234935A (zh) * 2023-09-28 2023-12-15 重庆赛力斯新能源汽车设计院有限公司 基于虚幻引擎的测试方法、装置、电子设备及存储介质
CN117234935B (zh) * 2023-09-28 2024-05-14 重庆赛力斯新能源汽车设计院有限公司 基于虚幻引擎的测试方法、装置、电子设备及存储介质
CN117874772A (zh) * 2024-03-11 2024-04-12 广州锦高信息科技有限公司 应用软件漏洞扫描方法及系统
CN117874772B (zh) * 2024-03-11 2024-06-11 广州锦高信息科技有限公司 应用软件漏洞扫描方法及系统

Similar Documents

Publication Publication Date Title
CN115510454A (zh) 游戏测试方法、装置、电子设备及存储介质
US11455231B2 (en) Testing as a service for cloud gaming
US9164870B2 (en) Integrated fuzzing
US20180276111A1 (en) Mock services for software infrastructures
CN107948640B (zh) 视频播放测试方法、装置、电子设备和存储介质
CN104765678A (zh) 对移动终端设备上的应用进行测试的方法及装置
US9292423B1 (en) Monitoring applications for compatibility issues
CN110013672B (zh) 用于机器运行的游戏的自动化测试的方法、设备、装置以及计算机可读存储介质
CN112187585A (zh) 网络协议测试方法及装置
US11743155B2 (en) Systems and methods of monitoring and controlling remote assets
CN110177300B (zh) 程序运行状态的监控方法、装置、电子设备和存储介质
CN111522749B (zh) 页面测试方法、装置、可读存储介质及电子设备
CN109985387B (zh) 自动化测试方法和装置
CN115588458A (zh) 存储设备测试方法、系统、设备和可读存储介质
US9990274B2 (en) Testing integrated business systems
CN111679924B (zh) 构件化软件系统可靠性仿真方法、装置及电子设备
CN113230661A (zh) 数据同步方法、装置、计算机可读介质及电子设备
CN112199229A (zh) 数据处理方法、装置、设备和存储介质
CN109815050A (zh) 一种应用故障信息的修复方法、系统及设备
CN106776325A (zh) 一种虚拟用户操作的系统稳定性测试方法和系统、终端
CN110647458A (zh) 基于分布式测试平台的测试方法、装置及电子设备
CN114448832B (zh) 一种用于证券线上交易平台的压力测试系统
US20240123355A1 (en) Tracking in-game events and generating event reports across multiple gaming applications
CN118278166A (zh) 变更信息的测试方法、装置、存储介质以及终端
CN117033174A (zh) 软件测试方法、装置、存储介质及电子设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination