在数据仓库的上下文中不可能进行详尽的测试。我一直在进行 ETL 测试。有一个极端情况错误，如果在源数据库中的一个表上创建了锁，则将数据迁移到目标数据库失败。任何测试人员都可以想象在事务期间表被自动锁定的场景吗？

我们使用 SQL 创建了一个锁以在测试环境中重现该问题。但是，在实时调试 LIVE 日志时，我们发现锁是由于长时间运行的 SQL 查询试图从数百万行数据中获取记录而创建的。该漏洞导致交易丢失和客户损失约 40 万美元。我们解决了这个问题并集思广益，以提高测试覆盖率。

ETL 测试是一个关键领域，因为它与 DB 相关，所以除了排列组合之外还有许多变量会影响它。我建议您对系统的基本功能进行详尽的测试，而不必担心 100% 的测试覆盖率。上述问题是测试人员无法控制的数据库设计问题。如果数据库分区正确，即使有 1000 个用户使用 SQL 查询，也可以快速获取数据。作为临时解决方案，我们将无法成功迁移的记录移至异常队列。

您引用的问题看起来更像是产品设计/架构问题，应该在 DEV 的代码审查/同行审查中发现。该产品应允许英国、澳大利亚和新西兰的用户同时使用该系统。当他们输入相同的数据时，不应该有任何冲突/冲突。

在 ETL 和数据仓库测试中可以进行大量的测试。如果您对要尝试和测试的内容有一组优先要求，这将很有帮助。

通常的 3 个“功能”检查是：

1. 你检查进来的数据没问题吗？(garbage in garbage out) 通常使用数据分析中的信息和查看业务规则将有助于识别潜在问题。

2. 数据处理好吗？我不知道您的自动化测试涵盖哪些内容，但您可能仍需要检查边界情况、除法问题、空值、引用完整性问题？

3. 数据输出看起来如何？这是您通常会发现业务规则实际上是否正确的时候。同时您也可以检查数据是否按照规范呈现。

如果它是一个新系统，那么在客户实际看到输出之后，他们很可能会改变对某些业务规则的看法，因此您可能希望为改变做好准备。:)

您可能需要测试其他“非功能性”指标，例如性能 + 负载测试、安全性等。

就最初的问题而言，我会尽可能地考虑预算和项目优先级。

作为一般原则，测试是关于风险/回报的，它归结为各种组合的金钱/时间/资源（人/机器）成本。

测试覆盖率曲线将是某种对数曲线，其中测试的最大好处发生在初始测试集中。

前 500 个测试提供 62% 的覆盖率，接下来的 500 个测试仅提供额外的 7% 覆盖率，接下来的 500 个测试提供额外 3% 的覆盖率，等等。显然，这是收益递减的情况，可以执行无限次测试次数，并没有真正获得对系统正确性的更好信心。我的数字是任意的来说明这一点。

您提到了一些我称之为单元测试的测试，但我认为您跳过了可以提高数据库正确性的测试步骤。请参阅这个关于测试类型的优秀 SE 答案。

这将发现一些在 UAT 之前您还没有意识到存在的问题。听起来应该有更广泛的验收测试（由 IT 部门），但听起来 UAT 的范围还不够广泛，如果 UAT 中仍然存在错误的话。业务分析在发现边缘案例或理解数据冲突方面做得不够好。这真的应该在设计阶段就已经理解（取决于您使用的实现方法以及您计划进行多少重构；但这是另一个讨论）。

更新以反映测试的退出标准。您可以查看 MSDN 文章 - Adventures with Testing BI/DW Application: On a crusade to find the Holy Grail

需要关注的关键领域是

• 验证 ETL 场景以获取完整的增量拉取
• 使用多个区域、多个数据集的生产数据进行测试
• 验证数据集市，报告数据集的结果

希望能帮助到你。