我有自己的课程想法，但是似乎只有一篇主要文章涵盖了基础知识：
数据完整性。确保已加载所有期望的数据。
数据转换。确保根据业务规则和/或设计规范正确转换所有数据。
数据质量。确保ETL应用程序正确拒绝，替换默认值，更正或忽略并报告无效数据。
性能和可伸缩性。确保数据加载和查询在预期的时间范围内执行，并确保技术体系结构可扩展。
集成测试。确保ETL流程可与其他上游和下游流程正常运行。
用户接受测试。确保解决方案满足用户的当前期望并预期他们的未来期望。
回归测试。确保每次完成新版本的代码时，现有功能均保持不变。
#1 楼
我同意那里没有太多东西-几年前，我参加了我的第一个（到目前为止，最后一个）数据仓库测试项目，发现很难找到好的建议。到目前为止，我还没有做出任何回应，因为我认为我仅完成一个项目的经验就很少，所以我在等着看你是否得到了更多有用的回应。一些好的资源：
Karen N Johnson撰写了有关BI测试的有用文章：第1部分，第2部分，这里专门介绍有关测试SCD的文章。我发现她对BI测试的评价非常有价值。
Software Testing Club上有一个BI Testing小组。
我记得我们面临的巨大挑战在有限的测试时间和资源下，以及在没有测试团队任何先验经验的情况下，突然变得非常熟悉数据仓库，从而决定最高风险在哪里。我们最终与开发人员紧密合作，并进行了许多探索性测试，以找出导致最大麻烦的领域。
我们再次使用的策略：
创建数据映射
电子表格以了解数据提要中的数据
最终存储在
最终数据仓库中对我们来说是一个有用的练习，即使我们
并不能为所有内容创建它们。
它帮助我们建立了很多<更好地理解数据如何流经系统，我们可以请设计师和开发人员进行审查。
重点：使用已知的数据集进行关键业务场景的字段级和行级测试，我们确定了
散焦：由于集成
测试是我们的主要重点，因此我们
想要再次扩大搜索范围，以发现我们未曾考虑过的任何情况，因此
以及确定特定的
测试，我们还获取了测试产生的许多
实际数据来源
系统，并对其进行了审核，以查看
还有什么其他丑闻出现了。 （相当多，因为它发生了-这对我们来说非常有生产力，并且遇到了很多可能会破坏批量生产的问题。）
不要忘记流测试-将您的方案扩展到例如，您不仅要处理单个订单，还要处理已提出，更新，修改，取消，重新打开，处理的订单。凌乱，丑陋，真实的东西。
#2 楼
ETL和DB测试之间有很多重叠之处，两者都需要相似类型的测试数据来对操作进行压力测试，这些操作稍后将代表现实。有关更多详细信息，请参见本文。#3 楼
通过手动运行作业来启动项目。
检查所有源数据是否已加载到目标中。
编写
SQL查询以比较源数据和目标数据。查看该列映射文档。
检查代理键是否生成唯一值。
检查代理键值不为空。
检查主键值不为空。
检查源计数和目标表。
源表中应用的业务逻辑是否在目标表中显示了正确的更新值。
检查目标表中是否存在重复项。
检查目标中是否没有列具有空值。
这些是做
ETL测试仪的基本要点。如果还有其他内容，请给我其他内容。#4 楼
这是一个很大的问题。如果没有更多细节，我认为无法完全解决。不过，对于更常见的情况，我还是会尝试。如果这是一个内部应用程序，只需要在一个环境中运行，那么您应该在细节上添加一些细节列出。我最喜欢的东西总是会在数据层的某个地方发现一些错误：
左语言
长字符串
数据库整理问题
如果要在多个站点上安装此语言，则可以测试所有不同的预计环境组合。
操作系统类型/版本
数据库类型/版本
底层存储
然后有一些我们永远不会记住的通常需要规范的东西-并进行了测试，例如灾难恢复过程，备份/还原，中断处理（例如网络崩溃）等。
两个词：负面测试。