新上手报表，遇到哪些陷阱

首先，简单介绍下测试报表的几个步骤： 1. 理解业务逻辑，参加IPM来接收BA传递的上下文 2. 梳理业务场景，参加开卡和dev、BA一起确认测试覆盖场景 3. 书写测试用例，在DC前将测试场景转化为执行用例 4. 准备测试数据，在DC前后一般通过业务操作和数据库修改两种方式造数据 5. 校验报表，在DC后测试报表中相关数据的有效性和正确性，测试报表前端的正确性 报表测试遇到的bug类型挺多的，前后端都有，既有业务逻辑错误，也有纯代码问题。本文将结合实际遇到的场景来分析在报表测试中的“陷阱”，并提出相应的对策。

一、完全相信AC 场景1：dashboard新增字段，名字与之前报表的字段一致，但结果不一致。 原因分析：1. ba上下文缺失，对该字段的定义与前文逻辑不一致；2. 除了纵向的报表测试，缺少对已有报表的横向联系，比较具有统一指标的两个报表，看在相同时间内统计结果是否一致 反问，问题前移！ 除了基本的业务逻辑外，可以更深入的了解我们的开发背景，BA可能有惯性思维，当我们提问时，BA在尝试解答的过程可能会碰触到未研究的上下文。比如：新增字段对现有业务有什么价值？为什么这样统计该字段？约定的展示形式一定对用户友好吗？ 另一个好处是，报表是复杂的，尽管客户提出了这一需求，但可能对其统计逻辑不甚了解，QA在支持报表开发的UAT阶段，常常被客户反问其统计方式，那么在开发阶段的问题前移就保证了客户交付时的专业回答。

二、忘记报表是动态的 场景1：QA环境报表同步资源紧张，因此DC前dev只手动跑相关层级来同步报表，发现数据被及时同步，到客户测试阶段却发现报表未同步变化？ 场景2：我的订单结账后产值同步到报表，怎么我退帐后报表产值没变呢？ 准确的数据准备！使用历史数据、数据库改数可能高效，但通过走完业务流程的方式造数据更能覆盖边界场景，毕竟生产环境的数据都是客户真实使用产品产生的。 同步报表使用workflow！问题1虽然写了相关字段的代码，但未在workflow注册，手动同步时未运行历史脚本，所以未在测试环境发现该问题。如果QA环境不能手动同步，建议用history脚本同步数据变化；如果你们的项目资源充足可以支持自动同步，请忽略这一条。 关注变化！不要一次性测完后就不再关注，可以依据业务流程拆分测试用例，分几个阶段执行从而关注报表的变化。

三、测试idea用完了 场景1：当我们统计当月产值时，梳理测试场景，仅当月不结账、当月结账、次月结账这三种就够了吗？ 往相反方向思考！ 不要考虑你面前的数字/字段含义，而是尝试从相反的方向思考。退后一步，回到业务本身，重新评估情况。我们看结账字段，结账相反是什么？是退帐、再退后一步呢？是没有订单，这样的数据表现一样吗？不一样，结账后再退帐代表是有过产值，只不过现在是0；连订单都没有代表无产值，那应该表现为null，当然这只针对某中场景，还是要根据业务含义具体分析。这里提倡的是往反方向看、退后来看。 头脑风暴！ 询问其他角色的意见，比如针对这个问题BA和Dev就有不同的角度 BA：据我了解咱们客户行为可能还有退帐再结账、次月再加一个零件结账的行为，可以再加上当月结账次月再结账、当月结账退帐次月再结账、当月结账次月退帐结账。。。 DEV：从代码看，产值变化也会导致字段“产值更新时间”变化，可以顺便观察下这个字段是否受影响；新增字段上线后也会刷新历史数据，可以看下历史数据刷新

四、只是一张表？ 场景1： 测试小A：小D，这个数据没更新啊，看下原因 开发小D：收到。 测试小A：小D，这个数据没更新啊，在ods层更新了，在dwd层没更新，而且其他dwd层的数据都更新了，看下原因 开发小D：收到～ 两种提问方式，得到的反馈和解决问题的效率是不一样的。 研究原理！ 报表不仅包括业务系统中带有统计分析功能的报表，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。报表还包括只具有统计功能的报表，它与业务系统分离，往往需要经过多层处理，比如数据仓库的数据，会经过抽取、清洗、数据挖掘、数据再处理，前端的一些字段在业务系统中根本就没有。这样的数据准确性测试比较复杂，遇到错误时不知报表汇总原理来进一步定位是非常困难的。 因此我们在验证前需要了解数据从哪里来，如何汇总，数据入库的规则是什么，如何存放，在什么时间点进行汇总，需要了解页面上展现的数据来源于库中的哪些表哪些字段，根据什么样的规则来统计。在发现错误后，可以将问题细化，定位在哪个阶段发现问题，dev同学自然也可以更好的进一步定位。 磨练技能！ 在报表测试时sql技能是不可缺少的，数据核对时一般使用sql查询出的数据和代码运行出的数据进行核对，所以对sql的熟悉有助于提高测试效率。有余力的情况下，可以把报表的代码拉到本地学习，一方面可以看看高阶sql的语法，另一方面还可以进一步熟悉相关字段的统计逻辑，代码是最直观体现数据输入输出流程的东西。

五、注意力失明 情景1: 报表选择时间范围来搜索后，数据量与业务库不一致，dc加测试均未发现。 情景2: 明显的报表文案不一致，uat阶段才暴露出来。 停止盲目地遵循测试用例和测试矩阵！ 当你正忙于从测试清单中勾选其他测试项目，或者执行对于复杂的统计逻辑的测试用例，专注力都在校验每一行字段的正确性上，反而忽略了最简单的全局校验。因此在开始执行测试用例前，反思一下这个测试用例涵盖了哪些以及未涵盖哪些。 在按照测试用例和测试矩阵进行测试时，密切注意测试执行期间可能发生的任何其他事情，因为任何微妙的行为都可能表明即将发生灾难性系统故障。比如在报表设置埋点后，测试不同角色访问报表情况记录，发现一个专员的报表数据和管理层看到的数据一致，这在业务上是几率非常小的，除非这家店只有这一个专员，从而发现该角色的报表数据源不对。