这对我来说不再是一个真正的问题，而是出于好奇和帮助一位前同事。
在转到质量保证部门之前，我领导了一个 UAT 团队。这个团队由以前的用户组成，他们实际上不再使用他们正在测试的系统，除非他们在测试时使用。这对我来说似乎很奇怪，而且我总是在吸引实际用户方面受到业务部门的反对。这很常见吗？
不过，关于我真正的问题，应该多久使用一次 UAT。目前，在我的组织内，仅在对 SOX (Sarbanes-Oxley) 影响应用程序进行更改以及 SOX 影响对其他应用程序进行更改时才使用 UAT。虽然我想更频繁地参与 UAT，但我收到了来自业务的回击。我想开始将它们用于影响客户或最终用户的任何更改。涉及用户验收测试的正常情况是什么？
我看到应用程序改进的关键领域之一是最终用户积极参与测试和开发，最好是从头到尾作为团队的一部分。
用户越远离开发、实施和测试，应用程序就越不可能满足他们的业务需求。
实际上，我经常看到两个极端：
最终用户过多地参与测试（即工作直接从开发人员转到 UAT，绕过任何正常的系统测试并浪费大量业务用户时间）。最终，这将导致您描述的情况，他们最终会说“足够了”并停止测试。这可能会导致另一个极端
用户根本不参与，然后将应用程序强加于他们根本不起作用并被放弃
在您的情况下，我的建议是争取访问用户或用户的代理，例如优秀的业务分析师。
您应该承认他们的时间非常宝贵，然后从他们那里获取他们想要测试的内容，并基本上代表他们执行 UAT。然后，在这一切都修复并正常工作之后，向他们展示结果，当他们实际进行自己的测试（如果他们这样做）时，它应该只是一个快速的橡皮图章过程来接受已经工作的系统。恕我直言，这就是 UAT 的全部内容。
免责声明这完全基于我的经验。我相信还有其他人在尝试获得良好的 UAT 反馈时会有完全不同的体验。
注意我认为 UAT 比正式更非正式。我喜欢正式的 UAT，但我所在的地方根本没有预算。:-(
不幸的是，在涉及 SOX 合规性的情况下，您和用户之间可能存在多层隔离（由于追求 SOX 合规性的人是大公司）。
例如，在我的公司（一家跨国制造公司），我们有开发人员 --> 开发经理 --> 业务分析师 --> 制造工厂经理 --> 用户（有时，用户和工厂经理之间存在一层.) 我无法想象你的有什么不同。
你只需要拿走你能得到的。您不会从业务方面获得 1 对 1 的时间。那个时间必须由开发时间来分配。他们可能愿意抽出一些订单输入人员的一小时时间来向您展示他们是如何实际使用该应用程序的，但他们肯定不会为开发人员的时间付费。他们有一个工厂要运行，而你们这些软件人已经花了他们太多钱。（实际上他们就是这样看待我们的。）
我认为可以肯定地说 UAT 没有“正常”。你有一些公司使它成为一个大问题。他们得到焦点小组，他们得到反馈，他们做调查，提供激励。你还有其他人根本没什么大不了的。他们真的不在乎，只要它“完成工作”。他们将做这项工作定义为“使用该软件的人没有抱怨它”。
公司越小，用户群越小，用户群越公开，可能涉及的 UAT 就越多。公司越大，就越容易说“你想要更多？嗯，那太糟糕了。” 拥有庞大的用户群也是如此——你不在乎有几个人离开。与引入更多具有新功能的人相比，这不值得花时间。如果你有一个公共用户群，他们就有更多的选择来切换到别的东西。如果是内部软件，他们没有太多选择，所以开发人员有更多的权力来关闭它们。
就个人而言，我们很乐意听取用户的意见，即使我们属于（根据我上面的标准）最可能滥用他们的类别：大型（$2b+）大型（7k+ 用户）私人（内部）。实际上不是我们，而是中间的管理层混淆了用户群的真实感受以及任何 UAT 的结果。
不幸的是，我们没有正式的 UAT。少数支持人员了解新功能是我们所拥有的最接近 UAT 的东西。