定制软件 UAT 怎么做
定制软件的用户验收，是预定使用的人按验收清单逐条操作，并把每条结果记成通过、缺陷、范围变更或误用。签收只涵盖有当次操作证据的条目，没有证据的条目维持未验收。
先有清单，再开始操作
验收清单写的是每一条结果要怎么在演示或用户操作里被看见。那一份怎么从规格产生，见 定制软件验收标准怎么写。规格本身怎么写结果、负责人与范围外，见 定制软件需求规格怎么写。本文只写清单已经存在之后，怎么跑一轮用户验收。
操作中想改某一条结果，不在会上改清单。那是范围变更，见 定制软件范围变更怎么管。交付范围见 定制软件、网站与应用程序。没有清单、或清单指不出规格版本时，这一轮先不要开始。
大纲把用户验收放在验收测试里
ISTQB 认证测试员基础级大纲 v4.0.1 的修订表把 CTFL v4.0.1 标为 2024-09-15 的勘误，把 CTFL v4.0 标为 2023-04-21 的正式版。第 2.2.1 节写明，验收测试着重于确认（validation），以及显示是否已可部署，也就是系统是否满足用户的业务需要。理想情况下，验收测试由预定的用户执行。该节列出的主要形式包括用户验收测试（UAT）、运营验收测试、合同验收测试、法规验收测试，以及 alpha 测试与 beta 测试。
同一节写明，测试层级以测试对象、测试目标、测试依据、缺陷与失效、作法与责任来区分，以免活动重叠。公开的这一段没有列出用户验收记录的栏位，也没有给出通过比例或时限。本文不把没有写出的栏位算进大纲。下面的案例与记录，是购买方在验收清单已经写好之后用来跑这一轮的写法。
案例对到清单上的一条
每一则案例写八项：规格版本、验收清单的条目编号、操作的角色、起始数据、操作步骤、系统应留下的记录、谁执行、执行日期。八项缺任何一项，案例留在草稿，不进入当次操作。
案例只覆盖清单上已有的条目。聊天里新增的句子、或「顺便看一下」的画面，不另开案例。它若要进入清单，先回到验收那一篇补条目，或按变更那一篇另开请求。清单没有写的步骤，不当成这一轮的失败。
操作、记录、签收分开
操作的人是该条目已经写明的预定用户。记录的人写下当次看见的结果与系统留下的记录编号，不代替操作的人宣布通过。签收的人是规格里已经写明可以收下这一版的那一位。三个角色可以有人重叠，记录上仍分三栏。
预定用户缺席时，这一轮停在该条目，不由开发或在场的其他人代为操作后勾选通过。开发可以坐在旁边指出画面位置。勾选通过的是操作的人自己在记录上写下的结果。
缺陷、变更、误用分开记
缺陷是：操作的人按案例步骤做完，系统没有留下该条目要求的记录。范围变更是：操作的人要的结果与清单上的条目不同。变更另开请求，不把该条目改成刚刚说出口的句子，也不把变更算进缺陷。误用是：操作离开了案例写明的步骤或起始数据。误用记入同一笔记录，不把该条目标成失败，也不在会上把清单改宽。
三种结果各留自己的编号，并指回同一则案例。把三种都写成「有问题」，下一轮就分不出该修系统、该改规格，还是该重做一次操作。
签收前先留下证据
每一则已执行的案例保留：操作的人、日期、案例编号、看见的结果、系统留下的记录编号、以及通过、缺陷、变更或误用四者之一。证据是当次画面的截图或系统导出，并能对上那个记录编号。
口头一句「可以」没有写进上述栏位之前，该条目维持未验收。没有记录编号的截图，先补编号或标成证据不足，不进入签收。
签收只盖有证据的条目
签收写明规格版本、有证据且通过的条目、以及仍开着的条目。仍开着的包含未执行、证据不足、缺陷未再跑过、以及已另开变更请求的条目。签收不表示会上提过的每句话都已纳入。
缺陷留到下一次操作看见该条目要求的记录，才改成通过。变更请求在核准之前，签收版本维持当次的规格版本。把已经做出来的画面回写成当次通过，下一轮就失去对照。
什么时候先不要签收
验收清单指不出规格版本、预定用户还没写在条目上、或已执行的案例缺记录编号时，先不要签收。先补清单、补角色或补证据。会上想把条目改成刚刚看见的样子，同样先写变更请求。
本文不给出缺陷数、通过比例或验收天数。数字若要写，来自贵司自己的规则并注明日期，本文不代填。大纲的勘误日期是 2024-09-15。没有这一轮记录之前，用「每则案例是否指向清单条目、结果是否分成通过、缺陷、变更或误用、签收是否只盖有证据的条目」来检查验收有没有在按记录走。