最重要的是，我构建了一个自动化工具，该工具使用XML业务规则来比较模式，数据，查找并确保数据端到端正确流动没有截断，计算错误等。诚然，这是一项正在进行的工作，我只花了2天的时间，但它为我完成了90％的工作，因此其余时间，我的团队和我可以测试业务的情况
但是我们在UAT中发现了许多新问题，这些新问题指向不符合业务规则或业务流程的新方案，并且因此破坏了代码。这些方案不是简单方案或逻辑方案。例如。目前，一块货物位于英国，澳大利亚和新西兰。主要是源数据冲突，因为人们以某种方式从不同的源输入了相同的数据，以至于数据本身是有效的，但合在一起就没有意义。
我的经验在ETL，所以我想把问题扔出去，你也可以吗？-
测试一切符合业务需求和源之间的合同，并处理UAT和BAU？像Web /桌面应用程序一样，并假设使用他们的系统的人绝对可以做所有事情，并承担最坏的事情并测试所有事情？ （详尽的测试，这是不可能的，因为排列几乎是无限的）
还是有一个快乐的媒介？
#1 楼
在数据仓库的环境中不可能进行详尽的测试。我曾经参加过ETL测试。有一个极端的错误，即如果在源数据库中的一个表上创建了锁，则数据向目标DB的迁移将失败。是否有任何测试人员可以想象一个在事务期间表自动锁定的场景？我们使用SQL创建了一个锁，以在测试环境中重现该问题。但是，在实时调试LIVE日志时，我们发现该锁是由于长时间运行的SQL查询而创建的，该SQL查询试图从数百万行的数据中获取一条记录。该错误导致交易丢失，给客户造成约40万美元的损失。我们修复了该问题，并采取了集思广益的方法来提高测试覆盖率。
ETL测试是一个关键领域，并且由于它与数据库相关，因此除了排列组合之外，还有很多影响它的变量。我建议您对系统的基本功能进行详尽的测试，而不必担心100％的测试覆盖率。上面的问题是测试人员无法控制的数据库设计问题。如果对数据库进行了正确的分区，则即使有1000个用户使用，SQL查询也可以快速获取数据。我们将无法成功迁移的记录作为临时解决方案移到了异常队列中。
您引用的问题更像是产品设计/体系结构问题，应该在代码审查中解决/ DEV的同行审查。该产品应允许来自英国，澳大利亚和新西兰的用户同时使用该系统。当他们输入相同的数据时，不应有任何冲突/冲突。
#2 楼
在ETL和数据仓库测试中可以进行很多测试。如果您对要尝试的测试有优先级的要求，这将很有帮助。
通常的3种“功能”检查如下：
您检查输入的数据是否正常？ （将垃圾填满）
经常使用数据概要分析中的信息并查看业务规则将有助于识别潜在的问题。
数据处理还可以吗？
我不知道什么您的自动化测试可以解决，但是您可能仍然需要检查边界情况，划分问题，空值，参照完整性问题？
数据输出的外观如何？
这通常是在确定业务规则时实际上似乎是正确的还是不正确的。也是当您能够检查数据是否按照规范显示的时候。
如果客户使用的是新系统，则很有可能实际上看到了他们可能会改变某些业务规则的想法的输出，因此您可能希望为更改做好准备。 :)
您可能还需要测试其他“非功能性”指标，例如性能+负载测试，安全性等。
就我而言，我会尽可能地给予预算和项目优先级。
#3 楼
更新以反映测试的退出标准。您可以查看MSDN文章-测试BI / DW应用程序的历险记：在寻找圣杯的十字军东征中要关注的关键领域是
完整，增量拉动的ETL方案
使用多个区域，多个数据集的生产数据进行测试
验证数据集市，报告数据集的结果
希望对您有所帮助。
#4 楼
一般而言，测试是关于风险/报酬的，而风险/报酬则以金钱/时间/资源（人/机器）的各种组合形式落到成本上。测试覆盖率曲线将是某种形式的对数曲线，其中在测试中获益最大的是初始测试。
前500个测试覆盖率达到62％，接下来的500个测试仅覆盖率额外的7％的覆盖率，接下来的500个测试将额外的3％的覆盖率，依此类推。显然，这是一种收益递减的情况，在这种情况下，人们可以执行无限数量的测试，而对系统的正确性却没有真正的信心。我的数字可以说明这一点。
您提到了一些我称为单元测试的测试，但是我认为您正在跳过一些测试步骤，这些步骤将为您提高数据库的正确性。请参阅有关测试类型的出色SE答案。
这将解决一些直到UAT才意识到的问题。听起来应该有更广泛的验收测试（通过IT），但是如果UAT中仍然存在错误，那么听起来UAT的范围还不够广泛。业务分析在发现边缘情况或理解数据冲突方面做得不够好。这确实应该在设计阶段就已经理解了（取决于您使用的实现方法论以及计划进行多少重构；但这是另一个讨论）。
评论
有趣的链接和很多精心设计的要点。作者没有提到单元测试，接口测试。集成测试只是通过而已，而不是以整体方式处理。
– Marcus D
17年4月6日在10:19