我一直在谷歌上搜索并了解 UAT 是什么以及如何执行它们，但我不太了解如何在这种情况下应用它。
我的接受标准是来自重复配置文件的所有历史数据，这些数据是交易、交互和自定义字段，例如booleans并strings合并到主记录中。
我对 UAT 的“测试”部分感到困惑……有什么要测试的？我们不只是查看配置文件并确认数据存在吗？这算不算测试？
我正在努力制定测试计划，因为我真的不知道要测试什么。
非常感谢任何帮助/建议/阅读/文章。
背景：我们有大约 300 万条记录（记录是 CRM 中的组成资料），我们已经确定至少四分之一的记录是重复的（常见情况是一个人有 5 个以上的资料）。
我们已经完成了建立标准并确定哪些重复项将被标记为主记录的活动，然后将重复记录合并到主记录中。
我们的下一步是验证主记录，以确保来自重复记录的历史配置文件数据保持不变（事务、交互以及任何自定义字段，如作为注册的一部分添加的布尔值和字符串，并合并到主记录中）。
任务：我要为多个团队制定一个 UAT 计划以验证合并（我确实表示我的背景与所询问的内容无关......但我会尝试，因为公司中没有其他人有任何想法在这一点上做什么，预算真的很紧张，所以不能雇用承包商）
拥有 300 万条记录和 25% 的重复记录，您有 750,000 条需要合并和验证的组成记录。单独合并和验证所有 750,000 个成分需要大量的手动工作。
据推测，您将使用一些自动化来识别和合并所有这些组成记录。对于您的用户验收测试，您不需要验证每个合并，您只需要验证不同场景的样本。你的任务是设计一个代表这些不同场景的测试用例列表。简而言之，您正在尝试进行全面（非随机）的抽查
通常，您可以根据用于创建自动化的相同业务规则来设计场景。
例如：
作为测试用例的一部分，您需要为我上面提出的问题提供答案，以便告诉测试人员他们在寻找什么。本质上，您提供了一个场景和期望的结果。测试人员需要验证实际结果与预期结果是否匹配。如果匹配，则测试用例通过。如果不匹配，则测试用例失败。
在某些情况下，您可能想要组合方案，以理清您的标准中可能存在的冲突。
鉴于您有一个现有的数据库可供使用，您可能希望识别特定记录以用作 UAT 的一部分。您的测试用例可以识别特定记录、合并前数据和预期的合并后结果。然后，测试人员将查找这些记录并验证结果是否符合预期。1
一旦您设计了完整的场景列表和期望的结果，您将拥有一个用于用户验收测试的综合测试计划！
1在软件开发中，即使是测试也是自动化的，而不是手动进行检查——但对于一次性项目来说，自动化水平可能不是必需的——这比手动进行更多的工作。）