【测试人生】浅谈游戏策划配置表检查的技术设计

近期在testerhome的游戏测试节点里,看到一个很有趣的帖子:针对游戏策划的配置表测试,是否有开源的框架可以用?除了问题本身之外,帖子的楼主也附了一张整个配置表测试工具的设计图,由SVN变更监控、发起检查最后到消息通知,组成了一个持续集成的配置表测试专项工程。为此,针对这个场景,笔者也希望输出一些自己对于配置表检查测试技术的一些思考。

本篇文章讲述两块内容,第一块讲下测试框架的开源,第二块讲下专项技术的设计。首先,看一下配置表测试框架开源这块的问题。

开源的技术产品有很多种,可以是日常的玩具,可以是为了解决特定问题的工具,也可以是提升影响力的筹码。如果单纯只是针对配置表测试框架而言,不考虑业务方面的需要,这类框架如果开源出来,形态则相对类似日常玩具或者工具的类型,但能不能直接用上,就值得商榷了。不同的工作室,用的策划配置表可能文件格式不同,表格排版不同,数据结构不同,因此不一定说一个项目的配置表检查工具,就一定可以通用到另外一个项目里。而且,如果开源的框架需要为我所用,那么必须保证框架本身是具备较高防御性的,不能说实际用的时候要排查一堆框架本身的bug。从这一点考虑,大多数业务测试团队内部开发出来的检查工具,很大概率只是跑通了基础流程,而并非一个很具备防御性的技术产品。因此如果把这类框架拿出来开源,那使用起来也会相当麻烦。

因此第一个问题,是否要使用开源的测试框架,笔者的建议是如果需要快速交付是可以考虑,github跟gitee上肯定有类似的repo,但如果要打持久战,开源的肯定不如自家的好。

第二个问题是配置表测试专项技术的设计。为什么把话题扯得这么大?是因为如果做配置表检查,不结合游戏业务来做是无意义的,尤其是我们需要做到持续交付、持续反馈,提升整个项目团队的交付质量,不只是要考虑检查本身,对哪些配置表做检查,检查什么,用什么方式展现出来,这些都是整个专项所需要考虑的。我们所要解决的最终问题,是提升配置表的质量,所用到的手段,是配置表检查框架,还有一套CI测试流水线。

首先再回到配置表检查框架。表格类型的数据,我们可以简单划分为key-value两个部分,其中key可能包含id类型的主键。而针对value,除了基础的数值、字符串类型之外,在转表过程中,也有可能被转化成json类型的数据。因此我们在写检查逻辑时,不仅要考虑到简单的kv映射,还要考虑到异构化的数据值,内部应该如何解析。如果从通用化的层面考虑,用mongodb或者es存储表格数据是不错的形式,这样我们只需要组合一些特定的检索规则查询"错账"数据即可达到数据检查的目的。当然,如果在内存里面做数据查询也可以,但需要你的主机具有足够的内存空间。

然后来到检查什么数据。通常不论是用SVN还是用Git来存储配置数据,我们都可以实时监听repo的变化,来决定需要检查哪些表格的数据。从持续集成的角度来说,流程搭建起来并不难,但难点在于性能跟效率方面的优化。

如果一个游戏项目涉及到多渠道多国家发布,那么必须要处理多版本共存的问题,也就是说在同一个时间窗口,可能要检查不同分支不同提交的表格数据。要做到这一点,就必须有一套检查任务调度+数据归档的机制,不论什么分支有变化,都可以最终收敛到一次检查任务,保证每一次检查过程都是相互独立的。同时,工具开发者也需要根据自己主机资源的多少,决定一个时间窗口里,有多少任务可以并行。考虑了这些点,就能解决多版本共存的问题。

然后是检查任务本身。对于业务,最理想的情况是能够每一次提交配置时候都做一次检查,但如果提交的内容和配置本身无关,或者不在业务希望检查的配置里,那么就会产生一次无效检查。因此为了提升效率,就需要做预检查,看提交的内容和自己标记的需要检查的内容是否相关,如果相关才做检查。除此之外,还有一点是变更的配置文件可能只有很小一部分,那么如果在技术设计方面是全量下载数据的话,可能下载本身会比做规则检查费时很多。因此在数据更新方面,如果能做到调度不同分支的repo,能够做到按需更新数据,那整个检查过程的效率就会非常快。

总体来说,配置表测试专项技术,做小了可以做成日常测试的工具,做大了也可以成为一个庞大的工程。具体做多少,做成怎样的形式,最终还是需要衡量业务具体需求如何,以及交付时间是否紧张。

你可能感兴趣的:(测试人生,游戏策划,游戏测试,测试开发,专项测试,持续集成)