近期在testerhome的游戏测试节点里，看到一个很有趣的帖子：针对游戏策划的配置表测试，是否有开源的框架可以用？除了问题本身之外，帖子的楼主也附了一张整个配置表测试工具的设计图，由SVN变更监控、发起检查最后到消息通知，组成了一个持续集成的配置表测试专项工程。为此，针对这个场景，笔者也希望输出一些自己对于配置表检查测试技术的一些思考。
本篇文章讲述两块内容，第一块讲下测试框架的开源，第二块讲下专项技术的设计。首先，看一下配置表测试框架开源这块的问题。
开源的技术产品有很多种，可以是日常的玩具，可以是为了解决特定问题的工具，也可以是提升影响力的筹码。如果单纯只是针对配置表测试框架而言，不考虑业务方面的需要，这类框架如果开源出来，形态则相对类似日常玩具或者工具的类型，但能不能直接用上，就值得商榷了。不同的工作室，用的策划配置表可能文件格式不同，表格排版不同，数据结构不同，因此不一定说一个项目的配置表检查工具，就一定可以通用到另外一个项目里。而且，如果开源的框架需要为我所用，那么必须保证框架本身是具备较高防御性的，不能说实际用的时候要排查一堆框架本身的bug。从这一点考虑，大多数业务测试团队内部开发出来的检查工具，很大概率只是跑通了基础流程，而并非一个很具备防御性的技术产品。因此如果把这类框架拿出来开源，那使用起来也会相当麻烦。
因此第一个问题，是否要使用开源的测试框架，笔者的建议是如果需要快速交付是可以考虑，github跟gitee上肯定有类似的repo，但如果要打持久战，开源的肯定不如自家的好。
第二个问题是配置表测试专项技术的设计。为什么把话题扯得这么大？是因为如果做配置表检查，不结合游戏业务来做是无意义的，尤其是我们需要做到持续交付、持续反馈，提升整个项目团队的交付质量，不只是要考虑检查本身，对哪些配置表做检查，检查什么，用什么方式展现出来，这些都是整个专项所需要考虑的。我们所要解决的最终问题，是提升配置表的质量，所用到的手段，是配置表检查框架，还有一套CI测试流水线。
首先再回到配置表检查框架。表格类型的数据，我们可以简单划分为key-value两个部分，其中key可能包含id类型的主键。而针对value，除了基础的数值、字符串类型之外，在转表过程中，也有可能被转化成json类型的数据。因此我们在写检查逻辑时，不仅要考虑到简单的kv映射，还要考虑到异构化的数据值，内部应该如何解析。如果从通用化的层面考虑，用mongodb或者es存储表格数据是不错的形式，这样我们只需要组合一些特定的检索规则查询”错账”数据即可达到数据检查的目的。当然，如果在内存里面做数据查询也可以，但需要你的主机具有足够的内存空间。
然后来到检查什么数据。通常不论是用SVN还是用Git来存储配置数据，我们都可以实时监听repo的变化，来决定需要检查哪些表格的数据。从持续集成的角度来说，流程搭建起来并不难，但难点在于性能跟效率方面的优化。
如果一个游戏项目涉及到多渠道多国家发布，那么必须要处理多版本共存的问题，也就是说在同一个时间窗口，可能要检查不同分支不同提交的表格数据。要做到这一点，就必须有一套检查任务调度+数据归档的机制，不论什么分支有变化，都可以最终收敛到一次检查任务，保证每一次检查过程都是相互独立的。同时，工具开发者也需要根据自己主机资源的多少，决定一个时间窗口里，有多少任务可以并行。考虑了这些点，就能解决多版本共存的问题。
然后是检查任务本身。对于业务，最理想的情况是能够每一次提交配置时候都做一次检查，但如果提交的内容和配置本身无关，或者不在业务希望检查的配置里，那么就会产生一次无效检查。因此为了提升效率，就需要做预检查，看提交的内容和自己标记的需要检查的内容是否相关，如果相关才做检查。除此之外，还有一点是变更的配置文件可能只有很小一部分，那么如果在技术设计方面是全量下载数据的话，可能下载本身会比做规则检查费时很多。因此在数据更新方面，如果能做到调度不同分支的repo，能够做到按需更新数据，那整个检查过程的效率就会非常快。
总体来说，配置表测试专项技术，做小了可以做成日常测试的工具，做大了也可以成为一个庞大的工程。具体做多少，做成怎样的形式，最终还是需要衡量业务具体需求如何，以及交付时间是否紧张。