用户验收测试 (UAT)

用户验收测试是最终的验证阶段，在此阶段，企业或用户群体的代表会确认系统是否满足其设计初衷的需求，并能胜任其预期用途。它通常在功能测试之后进行，环境与生产环境高度相似，其结果将决定是否发布。

它回答的问题与之前的测试不同。开发人员和质量保证测试旨在确定系统是否按规范运行；验收测试则旨在确定规范的内容是否真正满足业务需求。即使开发工作通过了所有功能测试，仍然可能无法通过验收，原因可能是规范不完整、流程被误解，或者没有考虑到某个未被记录的实际案例。

最常见的混淆点在于验收测试和可用性测试。验收测试由熟悉业务流程的人员进行操作，通过模拟场景来确认系统是否支持这些流程。可用性测试则观察典型用户在没有指导的情况下使用产品，以了解产品是否易于理解和使用。将两者混淆是一个严重的错误：一个系统可能被了解业务流程的利益相关者接受，但对于其目标用户而言却仍然无法使用。

参与者的选择决定了测试能够发现什么。由项目团队或全程参与并了解系统预期运作方式的利益相关者进行的测试，验证了构建版本是否符合共识，并且很少发现其他问题。而让实际操作系统但未参与设计讨论的人员参与，则可以揭示预期流程与实际流程之间的差距。

场景设计应遵循实际工作，而非仅仅罗列功能列表。通过梳理系统必须支持的操作任务，包括实际应用中常见的各种棘手例外情况，可以发现逐个检查功能所无法发现的问题。真实数据同样重要，因为即使系统在干净的测试数据下运行正常，但在生产环境中面对格式错误、不完整或异常的数据记录时，也常常会出错。

由于验收测试阶段位于通常已经延期的整个流程的末尾，因此其结构上很容易受到压缩的影响。参与者只能在计划时间的一小部分内完成验收测试，他们还要挤出时间来处理日常工作，并将发现的缺陷进行分类，以便在发布后进行修复。为了防止验收测试沦为形式主义，必须合理安排测试时间，提前确保参与者的时间，并事先约定何种严重程度的缺陷会导致发布延期。

缺陷分类标准应在测试开始前就达成一致，而不是在发现缺陷后迫于压力再进行协商。明确哪些类型的问题会阻碍产品发布，哪些问题会在发布后立即修复，哪些问题需要记录下来以备后用，可以避免在商业压力最大、判断最不可靠的时候产生争论。

因为验收确认了系统是否符合业务用途，但并未说明最终用户是否能够实际使用系统，因此两种验证方式都是必要的。实际上，验收阶段的规划通常包含在…… 产品开发 作为发布流程的一部分，而真实用户是否能够完成任务这一单独问题则通过以下方式得到解答： 用户研究而对于内部系统而言，场景的运行现实性通常取决于是否涉及…… IT部门 以及系统上线后提供支持的团队。