正如Jackie在《进销存系统中的报表测试》中所言，在报表中，我们很难直观地通过某个数据项，看到它的算法和数据源。在报表测试用例设计中，第一步就是分析报表的数据源和算法。
不同业务报表之间的区别是很大的，特别是在不同行业之间。在分析报表前，首先，我们要提高对业务的熟悉程度。对于某些系统，如计费系统等统计精度较高的系统，我们甚至需要达到精通的程度。那么，是不是报表的分析就全无规律可循呢？不是的。下面将介绍我在分析报表时惯常使用的几个切入点，希望对大家有一定的启发。
1． 源数据的来源
源数据，即保存在报表数据库中的数据。源数据的来源，大致可分两大类：
A． 由业务系统生成
报表数据库中的数据是由前台业务系统插入的。报表系统和业务系统是关联着的，甚至它们根本就在使用同一个数据库。如此一来，前台的操作即直接反应在报表的统计值上。在这种情况下，我们测试用例的设计，重点放在影响报表统计值的前台业务场景的设计上。
例如，某点播系统中的点播率报表，其报表统计值有效点播次数的源数据，就是点播业务所关联的点播数据库表。在测试用例设计中，我们重点考察不同场景的点播对报表统计值的影响。而场景的设计除了考虑前台业务规则外，更重要的是考虑报表的统计规则。如例子中，有效点播次数的统计规则是，视频购买后1分钟内的重复点播不计入有效点播次数中。这样一来，场景的设计就不能只是点播一次和点播多次这么简单。
B． 来源于第三方数据库
有些报表系统与业务系统是分隔的，各自独立的。这样的设计，更多地出现在大型系统中。如此设计，既可以确保业务系统和报表系统各自的性能，又可以提高报表系统的扩展能力，即使用一个报表系统对不同业务系统的数据进行整合和分析。当然这个设计也有不足之处，即报表的实时性。
在这种情况下，测试用例设计的重点应该放在报表数据库源数据的设计上，重点考察第三方数据到报表数据库传递的正确性，源数据的完整性，以及不同业务源数据的相互影响。
2． 报表的算法
算法，是指源数据演变成统计值的过程。报表的算法应详细清晰地记录在Functional Specification中。根据算法的复杂程度，我将报表划分为三大类：
A． 罗列式
罗列式报表是将源数据根据规则进行罗列，不涉及任何计算，如话费清单、销售清单等。对于此类报表，测试的重点在于：
· 罗列项的完整性，即FS中所规定的源数据的属性项是否列举完整；
· 列举数据的正确性和完整性；
· 数据属性变动对报表的影响，如，修改客户地址后，报表是否能正确地显示客户的最新地址；
B． 统计式。
统计式报表是指，统计值是由单个源数据简单的加或平均得来的报表。此类报表，我们可以采用增量的方法来测试。
例如，前面所举的有效点播次数统计值。应用增量测试方法，就是在执行不同的场景后，检查报表的统计值是否在原来的基础上有对应的增减。
使用增量的方法来测试报表，既可以避免复杂的数据设计，又可以提高测试效率。但是增量测试方法的使用范围比较狭窄，对所测试的统计值要求不能太复杂。
C． 算法式
算法式报表是指，统计值是由一个或多个源数据根据一定的公式得来的报表。此类报表中的统计值，涉及到多表数据，多业务流程，是报表测试的难点。
在设计此类报表的测试用例时，建议理清以下两点：
· 统计值所关联的源数据；
· 源数据关联的业务规则；特别注意，源数据受多个业务规则共同影响的情况。
在报表分析过程中，大家除了可以参考我上面的几个切入点外，还可以使用小组brainstorm的方式，来列出尽可能多的测试要点。然后再将要点梳理，这样，报表测试用例的基本框架也就形成了。框架形成后，接下来我们就需要基于框架对测试用例进行细化和补充。
