报表测试经验分享

太鼓达人

提高对业务逻辑和数据逻辑的熟悉程度 提高对业务逻辑和数据逻辑的熟悉程度。其实对任何一个软件进行测
试，都必须要熟悉它的业务，包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如
对于单据的增、删、改，通过对界面的浏览和探索性的操作，大概都可以弄明白它的业务流程和业务规则，
因为这些内容 比较直观，而且在不同的行业中也差不了太多。但是在报表中， 比较直观，而且在不同的行业
中也差不了太多。但是在报表中， 是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项，
它的算法或者说数据来源，恐怕是比较难看出来了。 所以对于报表业务的熟悉，主要是两个方面：数据项的
算法和数据来源，也就是说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化
，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就无法验证报表中的数据是否
准确，也无法通过报表去检查业务系统的正确与否 。

    覆盖所有可能的查询统计方式，而不是以自己的使用习惯为准。对于报表的使用者来说——一般是企业的
中层或高层领导，他们对于报表的要求可能会是多方面。如，生产线上的管理人员，他们可能关注的是每个
产品的进度，而企业的管理者，他们更多是每个产品的进度。假如一个报表提供 的是关注整个加工单的进度
。假如一个报表提供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用
到的查询统计。

    使用或搭建完全受控的数据环境弄清楚数据的流转过程，即，数据从哪里来？中间经过了哪些处理？ 最终
如何进行展现？ 首先，应该保证准备足够多的有效的数据。前面也提到了，在实际测试报表时，应当尽可能
的覆到报表所提供的各种查询统计方法，因此至少应盖到报表所提供的各种查询统计方法，因此至少应该保证
每一种查询统计方法都应该有对应的数据，得到的结果都不会是0，否则等于没有覆盖到这个被测的查询统计
算法。当然数据也不是越多越好，能保证全部覆盖，并且刚好够用就可以了，因为数据 的准备和生成也是很
花时间的 的准备和生成也是很花时间的 。

    其次，要保证数据的可控。数据并不是随意生成的。因为如果无法控制数据来源，那么即使知道报表中每
个数据项的算法，也无法最终验证报表的查询统计结果是否正确。

    测试数据准备循序渐进，数据逻辑由简单到复杂，数据量由小到大。不要上来就用很复杂的数据进行测试
。所以如果希望高有效、更高质量的完成报表的测试，那么就要重视并增加对于数据准备工作的关注： 用于
验证报表功能的数据，一定是专门为报表准备的，并且是经过精心设计，   要分析影响数据项算法的的各种因
素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法；同时，才能保证无论使用哪
个数据项的算法进行计算，其结果都是可以预知的——因为数据来源已经被我们控制了 。 对于算法比较复杂
，又提供了多种查询统计方式的报表，如果想完整的测试，就需要准备大量的数据。而如果想高效、高质量的
完成这项功能，就一定要理解数据准备工作的重要性

    经过精心设计的数据还有一个好处，就是当在进行业务功能的测试时，不再需要使用一些随意的数据，而
是可以通过业务测试的过程，把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要，
进行相应的操作。 如果留心，你也会发现报表测试同其他业务功能测试的有个区别。业务功能（例如单据的
新增、审核等）的测试用例设计，通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍
历或覆盖；而对于报表 业务流程和业务规则的组合的遍历或覆盖，虽然没有太复杂的业务流程和规则，但是
算法更 加复杂，同时报表功能本身就是一种对数据的加工处理，因此会更偏重于对于各种数据来源和算法的
遍历或覆盖，也就是要准备各种正常的、异常的数据，来验证报表是否取到的该取的数据、没有取不该取的数
据，并且最后计算出了正确的结果 。

    特征性数据的准备，如果由多人同时对一个系统进行测试，虽然大家各自使用的数据都是经过精心设计的，
但是在实际进行报表测试时，还是很难保证其他人的数据不会对自己的测试结 试时，还是很难保证其他人的
数据不会对自己的测试结果产生影响，最明显的一个问题就是原来自己对结果是可以预知的，但是现在掺杂
了别人的数据，就需要花时间去区分这种 “ 假 ”的错误和真的错误。有一个经验是可以借鉴的，就是在初期，
团队内对数据的准备达成一致，使数据中的某一项具有特征性，例如 的准备达成一致，使数据中的某一项具
有特征性，例如 分别使用不同的工单号。最后测试报表时，通过限定选 分别使用不同的工单号。最后测试报
表时，通过限定选取的数据来源，来保证相互之间尽可能的没有影响

    做好数据环境的备份和维护，维护你的数据文档。如果想减少回归测试的工作量，那么应该考虑在一些关键
的 “ 点 ” 上备份测试数据。例如所有工单的工序已经完成，但还没有进行 上备份测试数据。例如所有工单的
工序已经完成，但还没有进行 QA时，那么可以备份一下，下次再测的时候可以直接在数据库中恢复这部分原
始数据 。

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

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

    多个报表相互对照。 这是一项 “高级 ”的报表测试技能，需要对整个系统中的各种业务的熟悉程度达到一
种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外，还能够进行横向的联
系，知道不同表的影响之外，知道不同报表之间存在的关系，是否存在一些关联呢？是否会存在一些可以相
互验证的地方呢？同一张报表不同的统计时间段之间的数据是否也有一定的逻辑关系？

    着重对那些算法复杂、与业务功能关联较多的报表的测试 。这就像业务功能的测试一样，越是特殊的数据
。越是复杂的业务，越有可能出错。

    留意四舍五入对报表数据的影响。 9这也是一个常见的问题。在一般管理系统中，都会存在这种情况，无
论小数点后保留几位，总是难以避免明细和汇总之间的差别。

    留意业务单据中存在多个日期字段时对报表数据。那么在测试时，一定要留意，开发人员是否按照要求选
择了正确的日期，包括日期选取的一致性。

    留意不同状态的单据对报表数据的影响。

    留意那些被当做默认规则的因素。 有些规则——例如单据类型或者单据状态是作为默认规则写死在SQL
语句或者数据库的存储过程里面，这些规则不会体现在界面，也不会由用户选择决定。但是这些规则恰恰
是最容易被忽略的部分。所以，一定要同开发人员反复确认， 保证自己已经了解了同报表各数据项计算有
关的各个因素

    保证测试人员可以通过UI 找到自己所需的所有找到自己所需的所有原始数据 。在进行系统测试时，无论
是报表，还是一般的业务功能测试，都不要去直接通过SQL语句查询数据库中的内容，而是通过UI来输入，
再通过UI 体现处理的结果进行验证，因为这是系统测试，将来用户是决不会去直接查数据库的。

    检查大数据量对报表的影响。报表测试也会涉及到性能测试，主要是在大数据量查询统计的测试。大数
据量一是说原始数据多，二是被操作、计算的数据多，三是某个数据项被是经过多次计算得出的。特别是对
于一些算法比较复杂的报表，10万条数据和100万条数据的响应时间将表现出巨大的差别。

szc123qq

楠族开心果

感谢分享