前言

随着商家使用导购产品的逐渐深入，商家对数据看板类的需求就愈发的强烈，比如 双11期间，商家创建了一个导购任务，要求导购去回访自己的客户，像他们推送大促商品的信息。商家创建任务后，自然而然的会关注如下信息：

• 我创建了这个任务，按照执行条件会覆盖多少导购和客户
• 任务下发后，有多少导购去执行了，执行成功和失败的比例有多少
• 导购执行回访后，带来的效果是什么，商品访问量、成交转化数等等

这是单一任务的视角，如果放到一个大的集团组织架构中，那么我们还需要通过多种部门组织的纬度去统计数目：

• 总部运营/高管视角下需要看到各个部门/门店的数据
• 区经督导去查看自己所管辖的部门/门店的数据
• 店长查看自己店铺下导购的数据

问题

面对这类测试需求，存在的痛点主要为：

1. 场景问题
   看数类项目可能会涉及非常多的场景。第一种是覆盖各种指标的场景，比如导购任务有执行导购、执行状态、回访金额等M种指标，每种指标可能存在N种状态枚举，总体的场景数就是 M X N。 第二种是架构变动引起的数据汇总的变动。比如导购所属部门的变动，部门所属架构的变动，在变动前和变动后去观察数据，需要按照一定的规则进行汇总。

2. 数据量问题
   看数类项目往往会遇到测试数据不够的情况，这个不够一方面包括了上面说的场景问题，已有的数据无法覆盖各种场景；另一方面，数据量的多少也是一个很重要的影响因素，在测试过程中经常发现一些大数量的分页分批逻辑存在问题，仅用少量数据并不能很好的触发和发现。数据量级对于看数存储和查询技术方案是否合理也有这重要影响，如果实际场景中数据量较大，可能会造成性能问题，比如客户数达到千万或者亿级，做实时汇总往往会存在性能瓶颈。

解法

对于上述两个问题，个人总结的一般做法为

1. 评审阶段。看一下产品的呈现方式是否合理，是实时、准实时（比如延迟小时级统计）、隔天，根据目标对象的数量级进行初步评估合理性。可以拉一下目前线上最大商家的量级进行评估参考。
2. 提测前。提前进行造数或者编写造数脚本，这个不仅能加快测试进度，提前提供给开发，也能提高开发的自测效率和质量。
3. 性能冒烟。在开发联调后期或者提测后冒烟时，有条件的话使用数据统计接口调用一下线上商家的数据，看一下是否存在超时等问题。尽量在提测前做，因为如果存在性能问题，可能需要改动方案，如果在测试后期遇到性能问题，最终需要改动产品或者技术方案，那么很大的一部分研发工作量都会被浪费。
4. 测试数据测试。通过自己构造的各种场景测试数据进行测试，自己构造的数据虽然量少，但是可控，可以用于验证一些基本逻辑和一些异常场景。通过提前构造或者编写脚本提高测试效率。
5. 线上数据测试。为了弥补测试数据量的不足以及可能的场景遗漏，选择线上数据量较大的商家进行测试，由于商家的数据量较大，很难完全通过明细去一个个加和进行验证。所以可性的方法就是用一些简单的约束条件进行自洽性的检查。

以下是常用的基本检查逻辑，如果存在异常的数据，然后再确认是否存在问题：

• 数据不应该有重复。
• 分页明细和总条数应当一致。
• 指标数据，总体应当等于部分之和。如概览里的客户总数和部门排行榜累加应当一致。
• 数据异常，如全是 0 或者 特别多。

通过上述做法，能够很大程度的把控看数类项目的风险，提高测试效率和质量。