报表功能的基本要求，就是通过查询/统计/分析，提供用户所需的准确的数据。如果无法实现这个基本功能，则报表完全失去意义。
对于用户来说，报表可以直接影响到他们的决策，例如可能因为报表对销售和库存情况反映的不准确，导致错误的大量进货；或者因为报表对应收应付金额计算的不准确，而导致企业对资金占用情况做出错误的估计，
从而导致错误的决策，最终造成用户在经营上的损失。诸如此类，相信只要大家留心，还可以找出很多这样的例子。
进销存系统中的报表多如牛毛，而且各种不同行业的进销存系统中的业务有区别，报表也有些区别，因此不太可能对各种报表逐个讲解，而主要是把一些报表测试的经验总结成了十几条可以在各种行业的报表测试中应用的“最佳实践”，来跟大家一起分享。希望下面的这十几条像一招招简单实用的“擒拿手”，可以供正在进行报表测试或者准备开始作报表测试的朋友随手拈来，见招拆招，轻松应对这项工作。
（1）提高对业务的熟悉程度
其实对任何一个软件进行测试，都必须要熟悉它的业务，包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改，通过对界面的浏览和探索性的操作，大概都可以弄明白它的业务流程和业务规则，因为这些内容比较直观，而且在不同的行业中也差不了太多。但是在报表中，是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项，它的算法或者说数据来源，恐怕是比较难看出来的——即使是很类似的一个数据项，在不同行业的实际业务中，它的算法和数据来源也可以能完全不同的。
所以对于报表业务的熟悉，主要是两个方面：数据项的算法和数据来源，也就是说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就无法验证报表中的数据是否准确，也无法通过报表去检查业务系统的正确与否。
（2）覆盖所有可能的查询统计方式，而不是以自己的使用习惯为准
对于报表的使用者来说——一般是企业的中层或高层领导，他们对于报表的要求可能会是多方面的，例如在进销存系统中，可能需要按不同商品进行分类统计，也可能是按供应商分类统计，这些都是由用户在实际工作中的需要来决定的，所以假如一个报表提供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用到的查询统计方法，而不是以自己的使用习惯为测试的依据。
（3）使用或构造受控的数据环境
数据对于报表测试来说是一个非常非常重要的问题。因为上面说到，报表的基本功能就是通过各种查询统计分析的方法，为用户提供准确的数据，帮助用户做出决策。那么那些用来进行测试的数据从哪里来呢？
首先，应该保证准备足够多的有效的数据。前面一条也提到了，在实际测试报表时，应当尽可能的覆盖到报表所提供的各种查询统计方法，因此至少应该保证每一种查询统计方法都应该有对应的数据，得到的结果都不会是0，否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好，能保证全部覆盖，并且刚好够用就可以了，因为数据的准备和生成也是很花时间的。
其次，要保证数据的可控。数据并不是随意生成的，如果使用通过自动化工具或者通过业务测试时随意的输入的数据来进行报表测试，一般来说是不太可能的。因为如果无法控制数据来源，那么即使知道报表中每个数据项的算法，也无法最终验证报表的查询统计结果是否正确。例如，系统的会有不同类型的单据，每种单据又会有不同的状态，某个报表的统计中，可能会涉及到多种类型和状态的单据，那么在准备数据时，就要充分考虑到这一点，准备各种不同的单据来满足测试的要求。又比如，如果整个系统中只有一个供应商，一个商品，那么测试按供应商分类统计或者按商品分类统计的报表时，意义也就不大了。
所以如果希望高有效、更高质量的完成报表的测试，那么就要重视并增加对于数据准备工作的关注：用于验证报表功能的数据，一定是专门为报表准备的，并且是经过精心设计，要分析影响数据项算法的各种因素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法；同时，才能保证无论使用哪个数据项的算法进行计算，其结果都是可以预知的——因为数据来源已经被我们控制了。
特别是对于算法比较复杂，又提供了多种查询统计方式的报表，如果想完整的测试，就需要准备大量的数据。而如果想高效、高质量的完成这项功能，就一定要理解数据准备工作的重要性。
经过精心设计的数据还有一个好处，就是当在进行业务功能的测试时，不再需要使用一些随意的数据，而是可以通过业务测试的过程，把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要，进行相应的操作。
如果留心，你也会发现报表测试同其他业务功能测试的有个区别。业务功能（例如单据的新增、审核等）的测试用例设计，通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖；而对于报表功能，虽然没有太复杂的业务流程和规则，但是算法更加复杂，同时报表功能本身就是一种对数据的加工处理，因此会更偏重于对于各种数据来源和算法的遍历或覆盖，也就是要准备各种正常的、异常的数据，来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确的结果。
（4）特征性数据的准备
这又是一个同数据准备有关的问题，也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试，虽然大家各自使用的数据都是经过精心设计的，但是在实际进行报表测试时，还是很难保证其他人的数据不会对自己的测试结果产生影响，最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的，是可控的，但是现在掺杂了别人的数据，就需要花时间去区分这种“假”的错误和真的错误。
有一个经验是可以借鉴的，就是在初期，团队内对数据的准备达成一致，使数据中的某一项具有特征性，例如分别使用不同的供应商，或者使用不同的商品。最后测试报表时，通过限定选取的数据来源，来保证相互之间尽可能的没有影响。
（5）做好数据环境的备份和维护
虽然数据是经过精心准备的，但是难免在操作过程中因为误操作导致环境的变化，例如不小心把一张单据变成了另外一种状态，或者某个类型的单据多做了一张。对于这种情况，一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表来保存我们事先准备的数据，可以一个文件保存一个类型的单据，例如采购单、入库单、出库单等等，文件中的每张表用来保存不同状态的单据，例如已经审核过的入库单，没有审核过的入库单，全部入库的入库单和部分入库的入库单，等等。假如你一不小心，把一张本来准备入一半的入库单全入了，那也不要惊慌，去重新调整一下你的数据文档，在相应的类型相应的状态的单据列表中新增一张就行了。
而如果想减少回归测试的工作量，那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础单据已经输入完成，但是还都没有开始审核或者出入库，那么可以备份一下，下次再测的时候可以直接在数据库中恢复这部分原始数据。
（6）在业务功能测试通过之后才开始
这一点相信应该不难理解，如果业务功能本身存在缺陷，导致的数据不准，那么最后进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务的功能测试通过之后，才开始考虑对报表进行测试。
（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）来访问的，所以也还要考虑相应的访问安全性测试，以免泄漏重要的商业信息。
摘自：http://www.51testing.com/html/44/n-109744.html
