提高对业务逻辑和数据逻辑的熟悉程度 提高对业务逻辑和数据逻辑的熟悉程度。其实对任何一个软件进行测试，都必须要熟悉它的业务，包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改，通过对界面的浏览和探索性的操作，大概都可以弄明白它的业务流程和业务规则，因为这些内容 比较直观，而且在不同的行业中也差不了太多。但是在报表中， 比较直观，而且在不同的行业中也差不了太多。但是在报表中， 是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项，它的算法或者说数据来源，恐怕是比较难看出来了。 所以对于报表业务的熟悉，主要是两个方面：数据项的算法和数据来源，也就是说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就无法验证报表中的数据是否准确，也无法通过报表去检查业务系统的正确与否 。
覆盖所有可能的查询统计方式，而不是以自己的使用习惯为准。对于报表的使用者来说——一般是企业的中层或高层领导，他们对于报表的要求可能会是多方面。如，生产线上的管理人员，他们可能关注的是每个产品的进度，而企业的管理者，他们更多是每个产品的进度。假如一个报表提供 的是关注整个加工单的进度。假如一个报表提供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用到的查询统计。
使用或搭建完全受控的数据环境弄清楚数据的流转过程，即，数据从哪里来？中间经过了哪些处理？ 最终如何进行展现？ 首先，应该保证准备足够多的有效的数据。前面也提到了，在实际测试报表时，应当尽可能的覆到报表所提供的各种查询统计方法，因此至少应盖到报表所提供的各种查询统计方法，因此至少应该保证每一种查询统计方法都应该有对应的数据，得到的结果都不会是0，否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好，能保证全部覆盖，并且刚好够用就可以了，因为数据 的准备和生成也是很花时间的 的准备和生成也是很花时间的 。
其次，要保证数据的可控。数据并不是随意生成的。因为如果无法控制数据来源，那么即使知道报表中每个数据项的算法，也无法最终验证报表的查询统计结果是否正确。
测试数据准备循序渐进，数据逻辑由简单到复杂，数据量由小到大。不要上来就用很复杂的数据进行测试。所以如果希望高有效、更高质量的完成报表的测试，那么就要重视并增加对于数据准备工作的关注： 用于验证报表功能的数据，一定是专门为报表准备的，并且是经过精心设计， 要分析影响数据项算法的的各种因素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法；同时，才能保证无论使用哪个数据项的算法进行计算，其结果都是可以预知的——因为数据来源已经被我们控制了 。 对于算法比较复杂，又提供了多种查询统计方式的报表，如果想完整的测试，就需要准备大量的数据。而如果想高效、高质量的完成这项功能，就一定要理解数据准备工作的重要性
经过精心设计的数据还有一个好处，就是当在进行业务功能的测试时，不再需要使用一些随意的数据，而是可以通过业务测试的过程，把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要，进行相应的操作。 如果留心，你也会发现报表测试同其他业务功能测试的有个区别。业务功能（例如单据的新增、审核等）的测试用例设计，通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖；而对于报表 业务流程和业务规则的组合的遍历或覆盖，虽然没有太复杂的业务流程和规则，但是算法更 加复杂，同时报表功能本身就是一种对数据的加工处理，因此会更偏重于对于各种数据来源和算法的遍历或覆盖，也就是要准备各种正常的、异常的数据，来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确的结果 。
特征性数据的准备，如果由多人同时对一个系统进行测试，虽然大家各自使用的数据都是经过精心设计的，但是在实际进行报表测试时，还是很难保证其他人的数据不会对自己的测试结 试时，还是很难保证其他人的数据不会对自己的测试结果产生影响，最明显的一个问题就是原来自己对结果是可以预知的，但是现在掺杂了别人的数据，就需要花时间去区分这种 “ 假 ”的错误和真的错误。有一个经验是可以借鉴的，就是在初期，团队内对数据的准备达成一致，使数据中的某一项具有特征性，例如 的准备达成一致，使数据中的某一项具有特征性，例如 分别使用不同的工单号。最后测试报表时，通过限定选 分别使用不同的工单号。最后测试报表时，通过限定选取的数据来源，来保证相互之间尽可能的没有影响
做好数据环境的备份和维护，维护你的数据文档。如果想减少回归测试的工作量，那么应该考虑在一些关键的 “ 点 ” 上备份测试数据。例如所有工单的工序已经完成，但还没有进行 上备份测试数据。例如所有工单的工序已经完成，但还没有进行 QA时，那么可以备份一下，下次再测的时候可以直接在数据库中恢复这部分原始数据 。
在业务功能测试通过之后才开始，这一点相信应该不难理解，如果业务功能本身存在缺陷，导致的数据不准，那么最后进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务的功能测试通过之后，才开始考虑对报表进行测试。
寻求开发人员的协助。 在报表测试中很常见的一个问题，是需求文档中可能没有定义报表的各个数据项的算法，这时候你需要找开发人员帮忙，向他们了解准确的算法和相应的公式 。
多个报表相互对照。 这是一项 “高级 ”的报表测试技能，需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外，还能够进行横向的联系，知道不同表的影响之外，知道不同报表之间存在的关系，是否存在一些关联呢？是否会存在一些可以相互验证的地方呢？同一张报表不同的统计时间段之间的数据是否也有一定的逻辑关系？
着重对那些算法复杂、与业务功能关联较多的报表的测试 。这就像业务功能的测试一样，越是特殊的数据。越是复杂的业务，越有可能出错。
留意四舍五入对报表数据的影响。 9这也是一个常见的问题。在一般管理系统中，都会存在这种情况，无论小数点后保留几位，总是难以避免明细和汇总之间的差别。
留意业务单据中存在多个日期字段时对报表数据。那么在测试时，一定要留意，开发人员是否按照要求选择了正确的日期，包括日期选取的一致性。
留意不同状态的单据对报表数据的影响。
留意那些被当做默认规则的因素。 有些规则——例如单据类型或者单据状态是作为默认规则写死在SQL语句或者数据库的存储过程里面，这些规则不会体现在界面，也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以，一定要同开发人员反复确认， 保证自己已经了解了同报表各数据项计算有关的各个因素
保证测试人员可以通过UI 找到自己所需的所有找到自己所需的所有原始数据 。在进行系统测试时，无论是报表，还是一般的业务功能测试，都不要去直接通过SQL语句查询数据库中的内容，而是通过UI来输入，再通过UI 体现处理的结果进行验证，因为这是系统测试，将来用户是决不会去直接查数据库的。
检查大数据量对报表的影响。报表测试也会涉及到性能测试，主要是在大数据量查询统计的测试。大数据量一是说原始数据多，二是被操作、计算的数据多，三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表，10万条数据和100万条数据的响应时间将表现出巨大的差别。
原文：含辞未吐气若幽兰
网友评论