报表功能的基本要求，就是通过查询/统计/分析，提供用户所需的准确的数据。如果无法实现这个基本功能，则报表完全失去意义。
现在把一些报表测试的经验总结下，来跟大家一起分享正在进行报表测试或者准备开始作报表测试的朋友，希望大家都能轻松应对这项工作。
报表测试同其他业务功能测试的是有区别的：一般的业务功能在测试用例设计时，通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖；而对于报表功能，虽然没有太复杂的业务流程和规则，但是算法更加复杂，同时报表功能本身就是一种对数据的加工处理，因此报表它会更偏重于对于各种数据来源和算法的遍历或覆盖，也就是要准备各种正常的、异常的数据，来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确的结果。
（1） 提高对业务的熟悉程度
对于报表业务的熟悉，主要是两个方面：数据项的算法和数据来源，也就是说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就无法验证报表中的数据是否准确，也无法通过报表去检查业务系统的正确与否。如果业务功能本身存在缺陷，导致报表的数据不准，那么最后进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务功能测试通过之后，才开始考虑对报表进行测试。
2） 覆盖所有可能的查询统计方式，而不是以自己的使用习惯为准
对于报表的使用者来说——一般是企业的中层或高层领导，他们对于报表的要求可能会是多方面的，这些都是由用户在实际工作中的需要来决定的，所以假如一个报表提供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用到的查询统计方法，而不是以自己的使用习惯为测试的依据，而且至少应该保证每一种查询统计方法都应该有对应的数据，得到的结果都不会是0，否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好，能保证全部覆盖，并且刚好够用就可以了，因为数据的准备和生成也是很花时间的。
3） 使用或构造受控的数据环境
如果我们在测试过程中，无法控制数据来源，那么即使知道报表中每个数据项的算法，也无法最终验证报表的查询统计结果是否正确。如果希望高效、高质量的完成报表的测试，那么就要重视并增加对于数据准备工作的关注：用于验证报表功能的数据，一定是专门为报表准备的，并且是经过精心设计，要分析影响数据项算法的各种因素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法；同时，才能保证无论使用哪个数据项的算法进行计算，其结果都是可以预知的。特别是对于算法比较复杂，又提供了多种查询统计方式的报表，如果想完整的测试，就需要准备大量的数据。
4） 特征性数据的准备
这又是一个同数据准备有关的问题，也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试，虽然大家各自使用的数据都是经过精心设计的，但是在实际进行报表测试时，还是很难保证其他人的数据不会对自己的测试结果产生影响，最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的，是可控的，但是现在掺杂了别人的数据，就需要花时间去区分这种“假”的错误和真的错误。
有一个经验是可以借鉴的，就是在初期，团队内对数据的准备达成一直，使数据中的某一项具有特征性。最后测试报表时，通过限定选取的数据来源，来保证相互之间尽可能的没有影响。
（5） 做好数据环境的备份和维护工作
做好数据环境的备份，下次再测的时候可以直接在数据库中恢复这部分原始数据，减少回归测试的工作量
（6） 在业务功能测试通过之后才开始
这一点相信应该不难理解，如果业务功能本身存在缺陷，导致的数据不准，那么最后进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务的功能测试通过之后，才开始考虑对报表进行测试。
（7） 寻求开发人员的协助
在报表测试中很常见的一个问题，是需求文档中可能没有定义报表的各个数据项的算法，这时候你需要找开发人员帮忙，向他们了解准确的算法和相应的公式。
（8） 多个报表相互对照
这是一项“高级”的报表测试技能，需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外，还能够进行横向的联系，知道不同报表之间存在的关系。例如，一个简单的例子，库存报表中，你可以看到商品的出入库情况，而在销售报表中，你可以看到商品的销售金额和销售成本金额，在应收应付报表中，你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间，是否存在一些关联呢？是否会存在一些可以相互验证的地方呢？这个问题，留给大家来思考 ^_^
（9） 着重对那些算法复杂、与业务功能关联较多的报表的测试
如果只是简单的把某个日期范围内的所有入库情况统计出来，可能不会出错；但是如果还要考虑按照供应商或商品汇总，同时要选取特定的类型或状态的单据，再进行一些响应的计算，恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样，越是复杂的业务，越有可能出错。
（10） 留意四舍五入对报表数据的影响
从这一条开始，后面的内容可以说也是一些在实际测试时要注意的事项。
这也是一个常见的问题。在一般的进销存系统中，都会存在这种情况，无论小数点后保留几位，总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致，因为拆零引起的，例如10/30*30≠10；或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。
j(AB2V23284251Testing
（11） 留意进/存/销时使用不同单位对报表数据的影响
例如采购时是5箱，每箱有100盒，而销售单位是盒，入库之后，可能会要求按照销售单位来统计，这时要注意开发人员是否会选择了错误的单位，把500盒弄成5盒。
|23284251Testing
（12） 留意业务单据中存在多个日期字段时对报表数据的影响一般来说，一张单据上都会有多个日期字段，比如采购单就有采购日期、单据日期、审核日期，而入库单也会有单据日期、入库日期，诸如此类。那么在测试时，一定要留意，开发人员是否按照要求选择了正确的日期，包括日期选取的一致性——是否存在这边取采购日期，那边取审核日期的情况。
（13） 留意是否存在遗漏的单据类型
例如像出入库的报表，入库方向的，除了最主要的采购入库外，可能还会包括退货入库、盘盈入库、报溢入库；出库方向的，除了最常见的销售出库，还会包括盘亏出库、报损出库。那么在具体测试时，一定要准备充分这些相应类型的单据，并且要留意开发人员是否遗漏了相应的单据类型。
（14） 留意不同状态的单据对报表数据的影响
例如采购单，当采购单发出后，供应商会开始送货，可能第一批之送来了一半的商品，那么这时采购单的收货状态是“未完成” ；当供应商把商品送齐了以后，采购数量＝收货数量，则采购单的收货状态变为“已完成”。那这时留意，开发人员在采购报表中，是包含所需要的状态的单据，还是只包含了一部分？
（15） 留意那些被当做默认规则的因素
有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面，这些规则不会体现在界面，也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以，一定要同开发人员反复确认，保证自己已经了解了同报表各数据项计算有关的各个因素。
（16） 保证测试人员可以通过UI 找到自己所需的所有原始数据
在进行系统测试时，无论是报表，还是一般的业务功能测试，都不要去直接通过SQL语句查询数据库中的内容，而是通过UI来输入，再通过UI体现处理的结果进行验证——因为这是系统测试，不是集成测试，将来用户是决不会去直接查数据库的。因此，如果需要对报表的结果进行验证，应该通过其他的功能模块，去查询业务单据，或者其他报表，根据UI体现的结果，来进行确认。
（17） 检查大数据量对报表的影响
报表测试也会涉及到性能测试，主要是在大数据量查询统计的测试。大数据量一是说原始数据多，二是被操作、计算的数据多，三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表，10万条数据和100万条数据时的响应时间将表现出巨大的差别。
（18） 不要遗漏权限控制和访问安全性的测试
这里说的权限控制不是谁可以访问某个模块，谁不可以访问某个模块，而且数据的计算也没有直接的关系，而是侧重于报表设计的测试。我们都知道不同的报表是设计给不同的人看的，例如出入库报表是给仓库管理人员看的，里面不会包含商品的价格，而只会包含数量；而财务报表中，只会包含采购、销售的金额，而不会包含数量，这样才能保证可以相互对照，不会出现营私舞弊的行为。那么在测试时，应当考虑报表是否泄漏了不该泄漏的信息。当然，这里对业务的熟悉程度就是更高的要求了。
又如，不同的业务员只能看到同自己有关的业务，但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域，他们之间的销售情况是互相保密的。
还有一种情况，系统的用户可能会为他的供应商提供一个专门的程序或者Web页面，供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况，一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况，如果某个商品由多个供应商同时提供，那么其中一个供应商应该只能看到他提供的那部分，而看不到其他供应商提供的同一商品的情况。当然，这种功能一般都是通过外网（internet）来访问的，所以也还要考虑相应的访问安全性测试，以免泄漏重要的商业信息。
1.在测试报表之前，如果能熟悉待测试整个系统功能最好。这样更加有助于发现报表的数据和逻辑错误。
2.首先，把报表全部跑一遍。
测试目的：确保不会有低级错误。例如：界面字体错误，下拉列表取错，报表格式不统一，数据很明显的错误，是否报代码错误，等。
3.等以上的bug都改正之后，再测试报表中的每一个数据。确保每一个数值的计算是正确的。各种查询条件的组合下，产生的报表数据是正确的。
4.报表的一个重要的指标就是：性能。查询多少量的数据需要花费多少时间，需要明确定义，尽量达到最大的效率。这点的测试需要特定的测试环境来支持，包括软件、硬件、测试工具等。
5.比较人性化的报表通常有一些辅助功能，例如导出成EXcel文件、打印，等。
6.测试报表的方法：我个人主张主要从页面数据（包括页面查询数据）来验证报表数据是否正确，查找数据库数据只是作为辅助手段。除非你对该系统的数据库结构非常了解，确保不出出错，否则还是尽量不要直接查询数据库来核对报表数据。
暂时想到这些，以后有想法了再补充。
----6.28补充：
7.测试方法的补充
测试数据：自己首先添加简单的数据，验证报表统计数据的正确性。然后，再添加数据模拟业务的所有流程产生的数据，验证所有业务流程下数据的正确。这样一步步地深入，可以使得测试思路清晰，容易定位bug设计的业务。
6569
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
