配置表是策划填写的excel格式的表格,主要存放游戏中的各种设定数据(任务、怪物、奖励、物品、宝宝、装备...）等等所有和游戏相关的数据。
从设计先进度的角度来讲，把尽可能多的参数让策划填，对于游戏开发是很有好处的，这样能使程序更专注于程序设计方面，而不用在逻辑实现上浪费时间。
在实际工作中，策划填配置表却带来了一系列的问题：填错导致系统报错、无法正常进入游戏、游戏中无法正常体验等等问题。
究其原因，无非是以下几点：
1.策划填错配置表，手误..
2.A、B同时修改配置表中某一行，A提交之后，B强行提交（删除原配置表，commit，然后提交）导致和A修改内容关联的所有游戏逻辑出现问题
3.和2类似，新人把老版本配置表强行覆盖掉新版本，导致大量数据缺失
4.策划擅自更改表结构没有及时通知程序和测试
5.程序擅自改进读表程序没有及时通知测试和策划
6.原表结构设计不合理，扩展性差，不能满足最新需要
... （一时间就想到这么多，其实还有更多）
配置表出问题后的表现：
1.读入配置表报错，服务器无法启动
2.编译新版本后无法进入游戏
3.游戏某玩法无法正常体验，不断报错
……
（欢迎大家补充）
配置表出问题后果非常严重，必须立即解决，而实际导致bug的原因却很简单，以至于每次出现这种问题，都给人一种无力感。
面对这种情况，我整理了一些思路，未必是最好的办法，先记在这里，慢慢探讨
1.表的制定。配置表的制订需要策划和程序共同协商完成，并且要有非常详尽的说明文档，每一项的类型、内容、对应功能、异常等等都需要详细列出。所有填表的策划都应该熟悉并完全掌握该文档。
2.自查。 策划可以利用excel自身的机制对所填内容做一个检查；qa可以制作专门的配置表检查工具；程序可以在读表代码部分做一些规则判断，有问题的地方则抛出异常。三方面共同努力，尽量降低出错的情况
3.熟悉读表代码。QA需要熟悉读表代码，明白数据的读入读出，数据流向，对测试中报出的异常，能够快速定位。
4.svn diff邮件。邮件监控所有配置表的修改，小规模的改动用检查工具，大规模的改动需要QA仔细研究表结构和对应的读表接口。
关于配置表检查工具:
一般来说,越简单的程序越不容易出错,如果不考虑各种条件,有什么就读什么,在读表这一步很少会出错,但万一表填错了,会在游戏中体现出来. 程序可能会在读表代码中做一些常规检查,比如数据类型等,但不会针对其逻辑性做检查,因为表太多了,而读表程序又必须是通用的.所以,逻辑性检查应该是qa主要关注的地方.
qa自己编写的配置表检查工具,应该复用程序的读表代码,数据的读入使用程序提供的接口. 这样的好处是万一程序修改了读表程序导致出现问题,qa这边可以及时知道.
就执行方式而言,
