（4）  特征性数据的准备

　　这又是一个同数据准备有关的问题，也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试，虽然大家各自使用的数据都是经过精心设计的，但是在实际进行报表测试时，还是很难保证其他人的数据不会对自己的测试结果产生影响，最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的，是可控的，但是现在掺杂了别人的数据，就需要花时间去区分这种“假”的错误和真的错误。

　　有一个经验是可以借鉴的，就是在初期，团队内对数据的准备达成一直，使数据中的某一项具有特征性，例如分别使用不同的供应商，或者使用不同的商品。最后测试报表时，通过限定选取的数据来源，来保证相互之间尽可能的没有影响。

　　（5）  做好数据环境的备份和维护

　　虽然数据是经过精心准备的，但是难免在操作过程中因为误操作导致环境的变化，例如不小心把一张单据变成了另外一种状态，或者某个类型的单据多做了一张。对于这种情况，一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表来保存我们事先准备的数据，可以一个文件保存一个类型的单据，例如采购单、入库单、出库单等等，文件中的每张表用来保存不同状态的单据，例如已经审核过的入库单，没有审核过的入库单，全部入库的入库单和部分入库的入库单，等等。假如你一不小心，把一张本来准备入一半的入库单全入了，那也不要惊慌，去重新调整一下你的数据文档，在相应的类型相应的状态的单据列表中新增一张就行了。

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

　　（6）  在业务功能测试通过之后才开始

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

　　（7）  寻求开发人员的协助

　　在报表测试中很常见的一个问题，是需求文档中可能没有定义报表的各个数据项的算法，这时候你需要找开发人员帮忙，向他们了解准确的算法和相应的公式。

　　（8）  多个报表相互对照

　　这是一项“高级”的报表测试技能，需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外，还能够进行横向的联系，知道不同报表之间存在的关系。例如，一个简单的例子，库存报表中，你可以看到商品的出入库情况，而在销售报表中，你可以看到商品的销售金额和销售成本金额，在应收应付报表中，你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间，是否存在一些关联呢？是否会存在一些可以相互验证的地方呢？这个问题，留给大家来思考 ^_^

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

　　如果只是简单的把某个日期范围内的所有入库情况统计出来，可能不会出错；但是如果还要考虑按照供应商或商品汇总，同时要选取特定的类型或状态的单据，再进行一些响应的计算，恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样，越是复杂的业务，越有可能出错。

　　（10） 留意四舍五入对报表数据的影响

　　从这一条开始，后面的内容可以说也是一些在实际测试时要注意的事项。

　　这也是一个常见的问题。在一般的进销存系统中，都会存在这种情况，无论小数点后保留几位，总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致，因为拆零引起的，例如10/30*30≠10；或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。

　　（11） 留意进/存/销时使用不同单位对报表数据的影响

　　例如采购时是5箱，每箱有100盒，而销售单位是盒，入库之后，可能会要求按照销售单位来统计，这时要注意开发人员是否会选择了错误的单位，把500盒弄成5盒。

　　（12）   留意业务单据中存在多个日期字段时对报表数据的影响

　　一般来说，一张单据上都会有多个日期字段，比如采购单就有采购日期、单据日期、审核日期，而入库单也会有单据日期、入库日期，诸如此类。那么在测试时，一定要留意，开发人员是否按照要求选择了正确的日期，包括日期选取的一致性——是否存在这边取采购日期，那边取审核日期的情况。