说明：报表功能的基本要求，就是通过查询、统计、分析，为用户提供准确的数据，帮助用户做出决策

报表业务：主要是两个方面：数据项的算法和数据来源，也就是说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就无法验证报表中的数据是否准确，也无法通过报表去检查业务系统的正确与否。

业务规则：主要是被测软件对操作的规定及限制

尽可能覆盖到报表所提供的各查询统计方法的数据，至少保证每一种查询统计方法都应该有对应的数据，得到的结果不是0，否则等于没有覆盖到这个查询统计算法。

这里涉及到的方面比较多，都是跟数据来源有关，现举例说明：

a.同样的业务数据来源于多个数据表，则需要准备多个数据表中的数据

b.与状态相关的数据，有些状态需要纳入统计，有些不需要，但这些数据都需要准备

c.数据来源与显示数据不同时，比如在数据库中存储的是1，显示时则需要显示为“是”

除数为0，以及与0相加，与0相乘，与0相减，是否可以得到正确的结果

按上述的方法基本上可以准备比较完整的数据了，但数据也不是越多越好，为了提高测试效率，需要对数据进行优化，尽量保证用最少的数据覆盖所有可能的情况。

即使个人精心准备了报表数据，如果多人同时测试，或者本人在测试业务时，录入了其他数据，都会对报表的数据产生影响；所以需要在开始测试时，团队内对数据的准备达成一致，使数据中的某一项具有特征性，例如分别使用不同的供应商，或者使用不同的商品。在准备报表数据的过程中，还需要多与开发人员进行沟通，一来可以了解开发人员采用的算法是否与需求符合；二来可以更加明确数据的来源。在进行业务功能的测试时，可以通过业务测试的过程，把报表测试所需要的数据输入到系统中。

如果想减少回归测试的工作量，那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础数据与单据已经输入完成，但是还都没有开始审核，那么可以备份一下，下次再测的时候可以直接在数据库中恢复这部分原始数据

业务功能测试是报表测试的基础。如果业务功能本身存在缺陷，导致的数据不准，那么进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务的功能测试通过之后，才开始考虑对报表进行测试。

报表的使用者一般是企业的中层或高层领导，他们对于报表的要求可能会是多方面的，例如在进销存系统中，可能需要按不同商品进行分类统计，也可能是按供应商分类统计，这些都是由用户在实际工作中的需要来决定的，所以假如一个报表提供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用到的查询统计方法。

这需要非常了解各报表之间存在的联系。例如：库存报表中，可以看到商品的出入库情况，而在销售报表中，可以看到商品的销售金额和销售成本金额，对业务熟悉到一定程度就会知道实际上这两种报表之间就存在着某种联系。

1)        着重对那些算法复杂、与业务功能关联较多的报表的测试。

2)        留意数据的显示：小数位,千位符,四舍五入等是否与报表设置一致；单位转换是否正确；组合显示的数据是否合理 ；数据的排序。等等

3)        保证测试人员可以通过软件功能界面找到自己所需的所有原始数据，而不是通过SQL语句来查找，因为实际用户在使用软件时，是不会到数据库中查找数据的。

4)        对有些报表需要考虑权限控制和访问安全性的测试。

5)        大数据量的测试。

a)        原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。

b)        数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。

c)         数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。

d)        数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

e)        由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了if else,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。

f)         当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。