在报表测试用例设计中，测试数据是关键。正如Jackie在《进销存系统中的报表测试》中所言，如果希望更有效、更高质量地完成报表测试，就要重视并增加对于数据准备的关注。其实，测试数据也是为测试场景服务的，一个或者一组的测试数据往往是为了验证在某个测试场景下报表是否能正确的展现统计值。归根结底，测试场景的设计才是关键的关键。在之前的报表分析后，测试用例的基本框架已经完成。接下来我们需要在这个框架上，细化和补充场景设计，然后通过场景，设计出对应的测试数据。
对于测试数据的设计，我将其粗略地分为3大类：
1． 有效数据
有效数据，顾名思义，是指既符合前台业务规则，又符合统计规则的数据。它们会被统计进报表中，对报表的统计值会产生正面的影响。
2． 无效数据
无效数据，属于统计规则以外的数据。此类数据，符合前台业务规则，但不符合报表统计规则，即对报表的统计值不会产生任何影响。
3． 异常数据
异常数据，主要目的是用于检验报表系统对数据的容错能力。此类数据不符合前台业务规则，对报表的统计值会产生负面影响。最常见的场景是，统计值的分母为零。
这类数据的设计，更多地应用于报表系统与业务系统分离的情况中。当报表系统与业务系统互相统一时，异常数据会受到前台业务规则的限制，即异常数据连出现的可能也没有；在报表系统和业务系统分离的情况下，异常数据就很有可能由于数据传输的不同步，造成短时间的出现，此时报表系统对于错误的处理机制就显得非常重要了。
除了针对以上3类数据的设计以外，我们在设计报表测试数据时，还需要注意以下几点：
1． 保证场景间测试数据的独立性
这是为了保证数据可控而要注意的。如果同一条或者同一组测试数据被使用到多个报表统计值的检查中时，一旦出现测试结果与预期结果不一致，就会提高查错的难度。况且保证数据的独立，可以更好地阐述defect，保留defect现场，等待开发人员来解决。
2． 数据的多样性
多样性是指为场景而准备的多组测试数据。因为凭借不同数据才能更接近真实，更容易发现问题。此前我就碰到过类似的情况：在测试一份报表中，我发现同一个统计值，一月份的是正确的，三月份的却是错误的。正常情况下，使用同样的程序计算只有两种结果，要不两者都对，要不两者都错。怎么会出现一对一错呢？后来开发人员经过检查，发现还是计算程序中存在的问题。而出现一对一错是因为一月份与三月份的数据使用了不同组的测试数据，而正好一月份的数据，在错误的计算程序中也能计算出正确的值。由此说明，报表的测试是需要多组测试数据支持的，否则defect就会从我们眼皮底下溜走了。
3． 不要忘了空报表
所谓的空报表，就是指在报表查询条件下，没有相符的源数据，从而造成报表中的统计值为空。这样的测试，是为了确保报表的正确性，检查报表统计是否有张冠李戴的现象。
4． 注意数值的设计
这里所说的数值，是指统计值。例如，统计值是百分比时，我们需要覆盖最大值(100.00%)、最小值(0.00%)、中间值(如38.01%)、小数位检查(99.99%)。除了这些，我们还需要考虑负数、百分比超过100%、小数位的四舍五入等情况。
5． 不同报表间的对照
同一组数据在不同报表中的表现应该是一致的。例如，在销售总额报表中，营业点A的一月份总计是1万元；然而在营业点A的销售清单却只能查看到9000元的销售数据。那么，这意味着肯定是其中一份报表出现问题了。
6． 注意历史数据的设计
在基于OLAP技术设计的报表系统中，历史维度也属于测试的一个重点。历史维度的测试，涉及到历史数据的设计。例如，销售员A在2011年1月份，服务于营业点A，那么他的销售业绩就应该计算到营业点A中；然而到了2月份销售员A调到了营业点B，那么他2月份以后的销售业绩就应该计算到营业点B中。报表是否能正确地将销售员A在不同时间的销售业绩计算到对应的营业点中，就需要我们设计一批针对销售员A的销售源数据来检查。
7． 测试数据的备份
与一般的系统测试相同，报表的测试也需要经历多个版本。此外，报表测试数据的量很大，起码是业务测试数据的 3 倍以上。因此，数据的备份就非常必要了。我使用过数据库备份文件、 SQL 语句、 CSV 或 excel 格式 3 种方式来备份数据。通过比较，我推荐大家采用 CSV 或者 excel 格式来保存数据。因为在不同版本的测试中，我们很难避免数据库结构或者数据表字段的变化。如果采用数据库备份文件，一旦数据库发生了一点变化，就导致这个备份无法使用； SQL 语句可以避免这样的问题，但保存在 SQL 语句中的测试数据不直观，且不方便修改。因此， CSV 或 excel 格式使用起来更简单，而且很多数据库都提供批量导入 CSV 或者 excel 文件的功能。