配置表是策划填写的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这边可以及时知道.