正如陈雷在《MIS系统中的报表测试》中所言，在报表中，我们很难直观地通过某个数据项，看到它的算法和数据源。在报表测试用例设计中，第一步就是分析报表的数据源和算法。

　　不同业务报表之间的区别是很大的，特别是在不同行业之间。在分析报表前，首先，我们要提高对业务的熟悉程度。对于某些系统，如计费系统等统计精度较高的系统，我们甚至需要达到精通的程度。那么，是不是报表的分析就全无规律可循呢？不是的。下面将介绍我在分析报表时惯常使用的几个切入点，希望对大家有一定的启发。

　　1、源数据的来源

　　源数据，即保存在报表数据库中的数据。源数据的来源，大致可分两大类：

　　A、由业务系统生成

　　报表数据库中的数据是由前台业务系统插入的。报表系统和业务系统是关联着的，甚至它们根本就在使用同一个数据库。如此一来，前台的操作即直接反应在报表的统计值上。在这种情况下，我们测试用例的设计，重点放在影响报表统计值的前台业务场景的设计上。

　　例如，某点播系统中的点播率报表，其报表统计值有效点播次数的源数据，就是点播业务所关联的点播数据库表。在测试用例设计中，我们重点考察不同场景的点播对报表统计值的影响。而场景的设计除了考虑前台业务规则外，更重要的是考虑报表的统计规则。如例子中，有效点播次数的统计规则是，视频购买后1分钟内的重复点播不计入有效点播次数中。这样一来，场景的设计就不能只是点播一次和点播多次这么简单。

　　B、来源于第三方数据库

　　有些报表系统与业务系统是分隔的，各自独立的。这样的设计，更多地出现在大型系统中。如此设计，既可以确保业务系统和报表系统各自的性能，又可以提高报表系统的扩展能力，即使用一个报表系统对不同业务系统的数据进行整合和分析。当然这个设计也有不足之处，即报表的实时性。

　　在这种情况下，测试用例设计的重点应该放在报表数据库源数据的设计上，重点考察第三方数据到报表数据库传递的正确性，源数据的完整性，以及不同业务源数据的相互影响。

　　2、报表的算法

　　算法，是指源数据演变成统计值的过程。报表的算法应详细清晰地记录在Functional Specification中。根据算法的复杂程度，我将报表划分为三大类：