使用测试用例进行商业智能 (BI) 测试
托马斯·汉密尔顿
什么是 BI 测试？
商业智能（BI） 商业智能测试（BI测试）是指收集、清洗、分析、整合和共享数据，从而获得可执行的洞察，进而推动业务增长的过程。BI测试验证暂存数据、ETL流程和BI报告，确保实施正确无误。BI测试保证数据的可信度和从BI流程中获得的洞察的准确性。
您可以在此处了解有关 ETL/商业智能的更多信息 教程
BI测试流程
BI 测试遵循数据管道本身的结构。每个阶段都必须通过测试，下一个阶段才值得测试，因为上游的缺陷会在下游表现为误报。
- 需求分析： 明确报告必须回答哪些业务问题，以及数据来自哪些源系统。如果这里的信息含糊不清，后续的报告将无法验证。
- 源数据验证： 对数据源进行分析：包括行数、数据类型、空值率和重复值。您无法针对未测量过的数据源验证转换结果。
- 分阶段验证： 确认前任tract 完全着陆，应用筛选规则后，核对计数与源计数匹配。
- ETL和转换测试： 核实每张地图ping 以及业务规则，包括派生列、聚合和代理键生成。
- 数据仓库 以及立方体测试。 检查维度表和事实表的完整性、缓慢变化维度的处理以及层次结构中每一级的聚合准确性。
- 报告和仪表盘测试： 将报告数据与仓库数据进行比较，再与数据源进行比较，并检查筛选器、钻取功能和安全角色。
- 性能测试和回归测试： 测量负载窗口持续时间并报告响应时间，然后在每次管道更改后重新运行该套件。
和解是整个过程的基石： 在每个阶段，关键数字的数量和总和都必须是 trac能够追溯到源头。一份看起来正确但无法核对的报告，并非经过测试，而只是经过检查。
BI测试类型
本教程中的场景分为六大类。给它们命名有助于测试计划覆盖所有方面，而不仅仅是容易检查的部分。
| 类型 | 它验证了什么 | 典型技术 |
|---|---|---|
| 数据完整性 | 所有预期的记录都已到达 | 源和目标之间的行计数核对 |
| 数据转换 | 业务规则应用正确 | 将转换后的输出与手动计算的预期值进行比较 |
| 数据质量 | 值必须有效、唯一且在范围内 | 空值、重复值、格式和引用完整性检查 |
| 元数据测试 | 数据类型、长度和约束条件均符合规范。 | 源和目标之间的模式比较 |
| 报告测试 | 数据、格式和向下钻取功能均正确 | 将报表输出与仓库查询结果进行交叉核对 |
| 安全测试 | 用户只能看到其角色允许的数据。 | 使用不同的角色凭据运行相同的报告 |
的选择 BI工具 它会影响每种类型的执行方式，但不会影响需要哪些类型。安全测试是最常被忽略且代价最高的测试，因为行级安全缺陷会在不产生任何可见错误的情况下，将数据暴露给各个业务部门。
BI测试测试用例和场景
以下场景几乎适用于任何 BI 项目。请按其验证的管道阶段进行分组，并按顺序运行，因为暂存阶段的缺陷会导致后续所有阶段失败。
ETL验证测试场景
- 验证数据从源系统正确映射到目标系统
- 验证所有表及其字段都已从源复制到目标
- 验证配置为自动生成的密钥在目标系统中是否正确创建
- 验证未填充空字段
- 验证数据没有乱码或被截断
- 验证目标系统中的数据类型和格式是否符合预期
- 验证目标系统中没有数据重复
- 验证转换是否正确应用
- 验证数字字段中数据的精度是否准确
- 验证异常处理是否健全
暂存数据测试场景
- 核对检查-应用过滤规则后，STG（暂存）表和目标表之间的记录数相同
- 根据给定的键组合插入未加载到目标表中的记录
- 重新发送目标表中已存在的记录，并确认它们没有被重复加载。
- 当 day_02 加载时值列发生变化时更新键的记录
- 逻辑上删除目标表中的记录
- 流程表加载的值
- 引用表加载的值
数据加载测试场景
- 检查目标数据库和源数据库是否连接良好且没有访问问题。
- 对于完整加载，请检查截断选项并确保其正常工作。
- 加载数据时，检查会话的性能
- 检查非致命错误。
- 验证如果子任务失败，调用的父任务是否也会失败。
- 验证日志是否已更新
- 核实地图ping 和 工作流程 参数配置准确
- 验证源系统和目标系统中的表数量是否相同
- 将阶段表的属性与目标表的属性进行比较。它们应该匹配。
BI 报表测试场景
- 显示日期和时间
- 关键数字的小数精度
- 在给定的页面中显示行数和列数
- 报告中的自由特征
- 特征和关键指标的空白值如何显示
- 无论特征搜索是基于关键字、文本还是两者都进行，都按指定方式进行。
- 文本搜索是否区分大小写，以及这是否符合要求
BI测试中的挑战
- 数据量。 仓库中存储着数亿条数据，因此无法进行详尽的比较。测试依赖于核对总数，以及对边界记录和高风险记录的定向抽样。
- 异质来源。 一个数据仓库可以从关系数据库、平面文件、API 和遗留系统中提取数据，每个系统都有自己的编码、日期格式和空值约定。
- 没有明显故障。 报告中出现错误数据本身并不构成错误，它只会导致错误的决策，因此，核对数据是唯一可靠的检测方法。
- 信息来源不断变化。 上游系统中的模式更改悄无声息地破坏了映射。ping元数据测试必须按计划进行，而不仅仅是在发布时进行。
- 尺寸缓慢变化。 历史准确性要求去年有效的记录仍然反映去年的值，这很难检验，也很容易出错。
- 环境平等。 测试环境很少包含生产规模的数据，因此加载窗口和查询性能问题只有在正式上线后才会出现。
共同点在于，BI缺陷都是无声的。上述所有缓解措施都是通过人为制造信号来弥补系统本身不产生信号的缺陷。
