（7） 寻求开发人员的协助
在报表测试中很常见的一个问题，是需求文档中可能没有定义报表的各个数据项的算法，这时候你需要找开发人员帮忙，向他们了解准确的算法和相应的公式。
（8） 多个报表相互对照
这是一项“高级”的报表测试技能，需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外，还能够进行横向的联系，知道不同报表之间存在的关系。例如，一个简单的例子，库存报表中，你可以看到商品的出入库情况，而在销售报表中，你可以看到商品的销售金额和销售成本金额，在应收应付报表中，你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间，是否存在一些关联呢？是否会存在一些可以相互验证的地方呢？
（9） 着重对那些算法复杂、与业务功能关联较多的报表的测试
如果只是简单的把某个日期范围内的所有入库情况统计出来，可能不会出错；但是如果还要考虑按照供应商或商品汇总，同时要选取特定的类型或状态的单据，再进行一些响应的计算，恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样，越是复杂的业务，越有可能出错。
（10） 留意四舍五入对报表数据的影响
从这一条开始，后面的内容可以说也是一些在实际测试时要注意的事项。
这也是一个常见的问题。在一般的进销存系统中，都会存在这种情况，无论小数点后保留几位，总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致，因为拆零引起的，例如10/30*30≠10；或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。
（11） 留意进/存/销时使用不同单位对报表数据的影响
例如采购时是5箱，每箱有100盒，而销售单位是盒，入库之后，可能会要求按照销售单位来统计，这时要注意开发人员是否会选择了错误的单位，把500盒弄成5盒。
（12） 留意业务单据中存在多个日期字段时对报表数据的影响
一般来说，一张单据上都会有多个日期字段，比如采购单就有采购日期、单据日期、审核日期，而入库单也会有单据日期、入库日期，诸如此类。那么在测试时，一定要留意，开发人员是否按照要求选择了正确的日期，包括日期选取的一致性——是否存在这边取采购日期，那边取审核日期的情况。
（13） 留意是否存在遗漏的单据类型
例如像出入库的报表，入库方向的，除了最主要的采购入库外，可能还会包括退货入库、盘盈入库、报溢入库；出库方向的，除了最常见的销售出库，还会包括盘亏出库、报损出库。那么在具体测试时，一定要准备充分这些相应类型的单据，并且要留意开发人员是否遗漏了相应的单据类型。
（14） 留意不同状态的单据对报表数据的影响
例如采购单，当采购单发出后，供应商会开始送货，可能第一批之送来了一半的商品，那么这时采购单的收货状态是“未完成” ；当供应商把商品送齐了以后，采购数量＝收货数量，则采购单的收货状态变为“已完成”。那这时留意，开发人员在采购报表中，是包含所需要的状态的单据，还是只包含了一部分？
（15） 留意那些被当做默认规则的因素
有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面，这些规则不会体现在界面，也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以，一定要同开发人员反复确认，保证自己已经了解了同报表各数据项计算有关的各个因素。
（16） 保证测试人员可以通过UI 找到自己所需的所有原始数据
在进行系统测试时，无论是报表，还是一般的业务功能测试，都不要去直接通过SQL语句查询数据库中的内容，而是通过UI来输入，再通过UI体现处理的结果进行验证——因为这是系统测试，不是集成测试，将来用户是决不会去直接查数据库的。因此，如果需要对报表的结果进行验证，应该通过其他的功能模块，去查询业务单据，或者其他报表，根据UI体现的结果，来进行确认。
（17） 检查大数据量对报表的影响
报表测试也会涉及到性能测试，主要是在大数据量查询统计的测试。大数据量一是说原始数据多，二是被操作、计算的数据多，三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表，10万条数据和100万条数据时的响应时间将表现出巨大的差别。
（18） 不要遗漏权限控制和访问安全性的测试
这里说的权限控制不是谁可以访问某个模块，谁不可以访问某个模块，而且数据的计算也没有直接的关系，而是侧重于报表设计的测试。我们都知道不同的报表是设计给不同的人看的，例如出入库报表是给仓库管理人员看的，里面不会包含商品的价格，而只会包含数量；而财务报表中，只会包含采购、销售的金额，而不会包含数量，这样才能保证可以相互对照，不会出现营私舞弊的行为。那么在测试时，应当考虑报表是否泄漏了不该泄漏的信息。当然，这里对业务的熟悉程度就是更高的要求了。
又如，不同的业务员只能看到同自己有关的业务，但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域，他们之间的销售情况是互相保密的。
还有一种情况，系统的用户可能会为他的供应商提供一个专门的程序或者Web页面，供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况，一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况，如果某个商品由多个供应商同时提供，那么其中一个供应商应该只能看到他提供的那部分，而看不到其他供应商提供的同一商品的情况。当然，这种功能一般都是通过外网（internet）来访问的，所以也还要考虑相应的访问安全性测试，以免泄漏重要的商业信息。
