[发明专利]游戏测试方法及装置

说明书

本发明公开了一种游戏测试方法及装置。其中，该方法包括：获取修改文件列表，其中，修改文件列表中包括多个修改文件；获取文件关系引用树，其中，文件关系引用树中包括各个文件之间的引用关系；依据文件关系引用树，查询修改文件列表中每个修改文件对应的目标关联文件，其中，目标关联文件是关联游戏玩法的文件；对目标关联文件关联的游戏玩法进行回归测试，得到测试结果。本发明解决了相关技术中在游戏测试时，需要手动对修改进行归类，人工成本较大，且测试不全面的技术问题。

技术领域

本发明涉及游戏测试领域，具体而言，涉及一种游戏测试方法及装置。

背景技术

相关技术中，在发生代码更改时，往往需要对更改的代码进行验证，通过验证结果，确认代码中的更改会按预期运行，不会破坏整个版本的稳定性。当前在进行代码更改时，往往是以代码版本的更替进行代码更改，从而实现游戏的优化，常用的方式包括传统冒烟测试、遍历冒烟测试、需求关联冒烟测试，下面对每一种测试进行说明。

第一种，传统冒烟测试，关注本次修改代码所对应的功能，从而进行回归测试，图1(a)是现有技术中一种冒烟测试的示意图，如图1(a)所示，本次修改是由需求A(demandA)迭代引起的，即当前版本RevisionA(对应于版本号176780)经过需求demandA的修改，版本变成了RevisionA+1(对应于版本号176781)的过程，但是这种传统冒烟测试，测试不全面，只测试了表面修改，与该修改相关的功能没有覆盖到，且每次修改都需要手动归类，根据归类后的功能进行回归，人工成本较大，不及时的更新类型，会导致后续提交的累积，从而失去冒烟测试的意义。

而对于第二种，遍历冒烟测试，无需关注本次提交的内容，也不需要关注每个需求之间的依赖关系，只需要把目前有的所有测试用例执行一遍来发现错误，即遍历冒烟测试是从开始到代码结尾都执行一遍，该种方式虽然能全部测试完成，但是在大型项目中，无法在短时间完成多个功能的遍历，造成测试阻塞，同时每次冒烟测试中存在大量冗余，增加了测试成本。

对于第三种，需求关联冒烟测试，根据需求关联关系，确定测试用例内容，图1(b)是现有技术中另一种冒烟测试的示意图，如图1(b)中所示，本次修改了需求A(demandA),并且与需求A关联的需求有需求B，那么本次修改将会影响需求A和需求B，对应的测试用例是test-taskA和test-taskB，该种方式存在如下缺陷：需要对每次修改进行手动归类，在根据归类后的功能进行回归，人工成本较大，而且规定需求关系是人为规定的，可能存在遗漏和误差，导致回归测试不全。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种游戏测试方法及装置，以至少解决相关技术中在游戏测试时，需要手动对修改进行归类，人工成本较大，且测试不全面的技术问题。

根据本发明实施例的一个方面，提供了一种游戏测试方法，包括：获取修改文件列表，其中，所述修改文件列表中包括多个修改文件；获取文件关系引用树，其中，所述文件关系引用树中包括各个文件之间的引用关系；依据所述文件关系引用树，查询所述修改文件列表中每个修改文件对应的目标关联文件，其中，所述目标关联文件是关联游戏玩法的文件；对所述目标关联文件关联的游戏玩法进行回归测试，得到测试结果。

可选地，在获取文件关系引用树之前，所述方法还包括：每隔预设时间段，获取一次游戏中的各个文件和每个文件之间的第一映射关系，其中，所述映射关系指示了文件之间的调用关系；依据文件之间的第一映射关系，建立所述文件关系引用树。

可选地，获取修改文件列表还包括：在游戏版本库中增加一个文件的情况下，确定该增加的文件为一个修改文件，将所述增加的文件补入所述修改文件列表中，并查询该增加的文件所引用的文件；在游戏版本库中删除一个文件的情况下，确定该删除的文件为一个修改文件，将所述删除的文件补入所述修改文件列表中，并将所述文件关系引用树中所有关于该删除文件的内容删除。