我同意那里没有太多东西——几年前我进行了我的第一个（也是迄今为止的最后一个）数据仓库测试项目，发现很难找到好的建议。到目前为止我还没有回复，因为我认为我只完成一个项目的经验相当少，所以我在等着看你是否得到了更多有用的回复。

一些不错的资源：

Karen N Johnson有关于 BI 测试的有用文章：第 1部分，第 2 部分，这里有一篇专门关于测试 SCD的文章。我发现她所说的关于 BI 测试的内容真的很有价值。

软件测试俱乐部有一个BI 测试小组。

我记得我们面临的巨大挑战是，在有限的测试时间和资源的情况下，决定最高风险在哪里，并且需要在没有任何测试团队经验的情况下突然非常熟悉数据仓库。我们最终与开发人员密切合作，并进行了大量探索性测试，以确定哪些领域最令人头疼。

我们使用的策略，我会再次使用：

1. 创建数据映射电子表格以了解我们的数据馈送中的数据如何最终进入最终数据仓库对我们来说是一个有用的练习，即使我们没有为所有内容都创建它们。它帮助我们更好地理解数据如何通过系统流动，我们可以要求设计人员和开发人员进行审查。
2. 关注点：使用已知数据集对我们确定的关键业务场景进行字段级和行级测试
3. 散焦：由于集成测试是我们的主要关注点，我们还想再次扩大搜索范围以捕捉任何我们没有考虑过的场景，因此除了识别特定测试之外，我们还抓取了测试源生成的大量实际数据系统并对其进行审查，以查看其他讨厌的东西。（很多，因为它发生了 - 这对我们来说非常有成效，并且发现了很多会破坏生产批次运行的问题）。
4. 不要忘记流程测试——随着时间的推移扩展你的场景，例如，不要只处理单个订单，还有一个被提出、更新、修改、取消、重新打开、处理的订单。凌乱，丑陋，真实的东西。

ETL 和 DB 测试之间有很多重叠之处，两者都需要相似类型的测试数据来对操作进行压力测试，而这将在以后代表现实。有关更多详细信息，请参阅这篇文章。

1. 通过手动运行作业来启动项目。
2. 检查所有源数据是否已加载到目标中。
3. 编写SQL查询以比较源数据和目标数据。
4. 查看列映射文档。
5. 检查代理键是否生成唯一值。
6. 检查代理键值不为空。
7. 检查主键值不为空。
8. 检查源表和目标表的计数。
9. 源表中应用的业务逻辑是否在目标表中显示正确的更新值。
10. 检查目标表中是否有任何重复项。
11. 签入目标没有任何列具有空值。

ETL这些是作为测试人员要做的基本要点。如果还有其他内容，请给我其他内容。

这是一个很大的问题。如果没有更多细节，我认为无法完全回答。不过，对于更常见的情况，我会尝试。

如果这是一个内部应用程序，只需要在一个环境中运行，那么您应该首先向您列出的内容添加细节。我最喜欢的东西是那些总是在数据层的某个地方发现一些错误的东西：

• 特殊字符
• 不同的字母表（varchar vs nvarchar）
• 从右到左的语言
• 长字符串
• 数据库排序问题

如果要在多个站点上安装它，您可以测试所有不同的预计环境组合。

• 操作系统类型/版本
• 数据库类型/版本
• 底层存储

然后是我们永远不记得需要指定和测试的常见内容，例如灾难恢复过程、备份/恢复、中断处理（例如网络崩溃）等等。

用两个词：负面测试。