CheckTable配置表检查工具
配置表是游戏开发中重要的内容文件，里面包含了大量策划配置的文字、数值、资源链接、甚至一些脚本逻辑等。填写量大，细节繁多，而且可能被策划随时随意地修改，很多测试团队，要么不测配置表，交由策划同学自己把握；即便测，也很难覆盖到所有配置表，或者是测试的不及时。
虽然配置表内容经常变，但配置表的结构和填写规则很少变，所以可以将填写的规则进行整理，然后编写相应的脚本逻辑进行检查。不但能提高检查效率，还能监控策划对配置表的临时修改，方便管理。
CheckTable工具的开发难度不大，只要懂点脚本语言基本都可以实现，快速应用于工作。以下就是从工具的流程架构，到检查规则，再到最后的应用效果进行介绍。
CheckTable流程架构
一般CheckTable工具有两种检查方案：
- 一种是定义统一的检查规则，然后这个检查规则去遍历所有的配置表。好处就是工具开发量小，检查速度快；缺点是不够灵活，很难有完全统一不变的规则。
- 另一种是针对每个配置表编写一个对应的检查脚本。好处就是检查规则可以十分细致，覆盖度高；缺点是开发量较大，有重复的工作量。
第一种方案，如果在开发前期，能制定好统一的配置表填写规范，会显得十分的简单快捷。但实际的项目开发中，即使有过经验，也很难在一开始就设计出完美的规则，最终还是会随着后期需要而不断修改规则。曾经有个项目使用的是这种方法，但随着项目开发时间越来越长，功能越来越多，统一的规则越来越难以维护，最后这个检查工具也就不了了之了。
而第二种方案，虽然看起来有点复杂，但懂得一点软件工程学的人都知道，重复的工作内容其实是可以抽象成方法的，然后只需要实现一遍，之后再通过不同的参数调用即可。所以实际工作中最终采用的还是第二种方案，只需要将重复的内容进行规整分类，抽象成方法，就可以得到如下基本架构：
在实际开发过程中，为方便策划配表，一般策划填写的配置表是用Excel工具打开的，而程序实际读取的配置表则是从Execl表中导出的json或其他类型的数据表，而CheckTable工具要读取解析并进行检查的表应该是导出后的表。
然后在这个基础上可以对CheckTable的功能进行扩展，比如定时自动运行，或是加入SVN（SVN是一种文件管理工具，主要用于团队多人协作。）监控，一有配置表修改就进行检查，如果发现报错还能将错误信息发送给对应的SVN提交人。扩展功能后的工具架构如下：
而工具实现后的流程如下图所示：
其中，运行全部用例检查的时间点“4点”和监控SVN的时间间隔“60秒”都是可以通过配置进行调整的。
CheckTable检查规则
配置表的检查规则大致可分为三类：
- 值检查：单张表行列填写的值的检查，例如某个行列的数据只能填写指定大小的值。
- 行列检查：单张表行列之间关系的检查，例如同列不同行的数字ID要具有唯一性。
- 表检查：多张表之间行列关系的检查，例如奖励表填写的奖励物品，要能够在道具表中找到相对应的物品ID。
当然，根据功能需要，很多配置表还有较为特殊的填写规则，例如A表里有两个字段a1和b2，若a1值为1，b2的值应为B表中id_i的值，若a1值为2，则b2应为C表中name_i的值。可根据自身项目及功能的需要自行进行检查规则的补充。
以往的工作中，较为常用的检查点如下
| 分类 | 测试需求 | 问题示例 |
|---|---|---|
| 值检查 | 字段值的类型填写是否正确 | 字段id_i第99行填写的“abc”不是int类型。 |
| 值检查 | 字段值的数值大小是否在指定范围内 | 字段price_i第100行填写的“21”大于指定的[1, 10]区间上限。 |
| 值检查 | 字段值的填写内容不在指定的数值集合中 | 字段type_i第111行填写的“9”不在指定的[1,2,3,4,5]集合范围内。 |
| 值检查 | 字段值填写的是个区间，区间的上限要大于等于下限 | 字段area_l第123行填写的[99, 10]区间上限小于下限 |
| 值检查 | 字段值填写的资源路径可以找到 | 字段resource_s第159行填写的“/NPC/model/boss.png”，找不到对应文件。 |
| 列检查 | 某一列的值具有唯一性 | id_i第2/99/200行出现相同的值“10086”。 |
| 行检查 | 某一行的值逐行递增 | |
| 表检查 | A表中的值要能够在B表中找到 | reward表的award字段的第299行填写的[1001,1002,1003]中1003无法在item表的id_i字段中找到。 |
CheckTable的使用价值
其实工具的开发并不复杂，实际工作中遇到最主要的困难就是推广工具的使用。如果仅仅只是通过简单口头表达，告诉大家这个工具好用，捧场者也许不少，但真正使用的人不会太多。这里想从以下几方面来分享下我对使用工具的一些看法：
从工具本身的角度出发，最直观的价值就是可以给我们带来工作效率上的提升。很多人觉得一个小小的工具似乎也带来不了多少效率的提升，甚至觉得开发个工具还没有我自己直接把事做了来得快。确实，就目前我们日常工作中，工具所能带来的效率提升并不明显，但这是有两方面原因导致的，一是测试本身在技术方面的发展远不如纯粹的开发，很多测试开发做出来的工具大多都只是停留在初级水平，所以直观上来说开发出来的工具确实不尽如人意。另外，因为游戏项目的开发模式，还要开发组工作模式的原因，使得游戏测试主要还是以手工测试为核心，很多自动化方案很难实施，长期这种工作模式，不断培养大家的人工执行能力，短期来看人工操作确实是超越机器的自动化手段的。但是我们如果耐心地去统计累计投入的人工成本，就会发现，一次次反复重复的人工检查，最终所耗费的时间其实是超过一次性的大投入的，所以这里才会有一个10远小于无数多个1的累加，一般编写一个配置表检查工具的用例差不多也就是十分钟时间。
效率不仅体现在节省时间方面，还有体现在响应速度上。策划改表提表是不会主动通知所有人的，我们日常中最经常看到的就是一个好好的功能突然出现问题了，查了半天发现是策划某个配表错误导致的。就算策划改完了表通知了测试，那我们要么中断当前的工作内容去检查一下他修改的内容，要么就暂时搁置，很容易就把事情给遗忘了。而配置表工具的意义就在于帮助我们减少分心的次数。
还有覆盖度，日常工作中，功能大多是均分给每个人的，大家可能都各自熟悉自己的测试内容，但是谁来保证所有人都会去检查配置表？谁又能保证检查的认真程度都是一样的。而工具的价值并不是说它能一下子把所有问题都解决掉，而在于它提供了可以持续积累的环境。即使再慢，但每次添加的测试用例都是实实在在可见的，可维护可持续运行的，只要不断深化使用，完全覆盖只是时间问题。这样也可以省去很多工作交接的麻烦。
如果从项目开发的角度来说，工具还可以帮助大家建立标准规范。标准规范的意义不是说要求所有事物都一样，而是让事物的特性能在一个可控范围内。说个具体的例子，美术资源。曾经我们用自研引擎做项目的时候，客户端表现还在改，美术就直接开始做场景角色等资源，做完之后，放在客户端里一跑，很卡。因为美术为了追求表现效果，随便一个角色就是5000面，场景数十万面。最后我们找了引擎程序和美术一起讨论了一下，写了一个客户端测试工具，这样美术同学可以直接查看做出来的资源对客户端性能影响的结果。最终协商出了表现效果最好的情况下所能接受的最大美术资源的规格，所有的美术资源都被约束到了角色2500面，场景3万面以内。所以工具的使用不仅仅可以帮助提高效率，它更可以为项目开发指出明确的目标方向，这比大家胡乱的尝试，不断的修改要有效的多了，可以极大地减少不必要的错误，而且还能降低风险。很多人都以为测试的主要职责就是发现和验证问题的存在，但其实测试更核心的价值体现是在于可以预防问题的产生，这也是测试在团队中完全可以承担项目管理这个角色的原因。
最后从我们测试团队自身的角度来说，开发工具可以锻炼大家的编程水平，增长能力，这个不用多说了。其实更重要的是开发和使用工具，对整个团队的提升也能有着明显的促进作用。比如做出来的工具需要有人用吧，用的过程就会伴随着问题的产生吧，然后使用者将问题反馈给开发者，开发者改善后，使用者就能更加积极地使用工具，这就像策划和开发之间提需求与做需求一样，如此交流互动最终就能推动我们在技术和工作能力方面的积累，而且交流的过程中，大家也会更加的熟络，促进团队氛围的活跃和成员的积极性。