进入交付批次后，你可以通过运行中的应用检查实际效果，结合测试结果判断实现质量，再按需求项记录业务验收结论。
本篇面向参与测试和业务验收的成员，沿用“会员活动目标人群筛选”示例。批次创建及前序步骤见从已准入需求到第一次交付。
开始之前
先与交付负责人确认：
- 验收范围：本次包含哪些需求项，采用哪一版已确认的验收标准。
- 验收环境：使用沙箱中的应用，还是已部署的独立测试环境；对应哪个批次和代码版本。
- 账号与数据：准备所需账号、角色和测试数据，并明确数据口径。
- 操作分工：谁检查实际效果，谁有权限在批次中记录结果和完成阶段确认。
本例需要验证“组合条件筛选”和“覆盖人数预估”，不包含后续才实现的“保存筛选方案”。可以直接使用如何写清业务规则和验收标准中的固定样例。
页面入口取决于当前工作流、阶段、账号权限和项目接入情况。没有对应入口时，请交付负责人提供本次约定的验收地址与验证结果。
第一步：打开本次实现，确认正在看什么
原型用于讨论页面和交互；开发后的实际应用用于验证功能与数据。打开页面前，先核对地址、环境和版本，避免用原型展示或旧环境代替本次实现。
查看沙箱中的应用
批次提供 “查看代码与服务” 时，可以进入工作区的 “运行” 页，在 “沙箱服务” 中查看当前服务。
- 在 Workloads 中检查应用服务状态。
- 如已提供访问入口，在 Public Access 中找到对应服务的端口和地址，点击 “打开”。
- 核对打开的应用是否属于本次批次，再使用约定账号开始验证。
Public Access 是沙箱服务的公网访问入口。没有可用地址时，由负责环境的成员确认服务已启动，并按项目需要配置访问方式。创建访问地址本身不会启动应用。
批次提供 Browser 面板时，也可以观察其中的浏览器页面。需要手动操作且页面允许时，使用 “控制 Browser”。E2E 执行会与 Browser 面板共享浏览器会话，手动验收应与自动化执行错开，避免相互改变页面状态。
如果服务区域提示“当前显示上一次成功读取的结果”，先刷新并检查错误信息，再判断服务是否可用。
使用独立测试环境
项目接入测试环境时，应使用团队确认的测试地址。需要通过 “部署到 TEST” 部署的项目，由具备权限的成员完成部署和健康检查后，再开始验收。
沙箱中能打开页面，说明该沙箱内的应用可访问；独立测试环境仍需核对自己的部署版本、配置和数据。
第二步：查看自动化测试结果
工作台提供相应能力时，可以在 “API”、“E2E” 中查看最近一次结果。API 测试主要检查接口行为，E2E 测试通过浏览器验证操作流程；具体覆盖内容以本次测试用例和报告为准。
查看报告时，重点检查执行时间、运行编号（如有）、测试环境、用例内容和失败详情。代码或配置在测试后发生变化时，应重新验证受影响的内容，不能直接沿用旧版本的“通过”。
有权限且当前阶段允许时，可使用 “运行 API” 或 “运行 E2E” 发起检查。若提示已有任务排队或执行中，先查看已有任务的进展。报告提供 “查看完整报告” 或打开链接时，可以进一步检查详细结果。
报告未生成、发布失败或暂时无法读取，与测试用例失败是不同问题。保留页面诊断，让研发人员核对实际执行日志、当前代码和环境；没有可核实的结果时，应安排必要的验证，并明确记录尚未确认的内容。
第三步：按业务标准检查实际效果
自动化测试之外，验收人员需要按约定场景操作实际应用，检查本次需求是否得到满足。
使用前文的固定会员数据，可以依次验证：
日期场景使用已约定的北京时间，包含起止日期的完整一天。异常模拟由研发或测试人员在约定环境中安排。
每项检查都记录实际输入、预期结果、实际结果和必要证据。界面可以操作、测试显示通过，也仍需检查人数口径、边界条件和异常提示是否符合业务约定。
第四步：补充人工或外部测试报告
如果团队已有人工测试记录或外部工具生成的报告，可以在提供该能力的 “测试报告” 区域选择 “上传测试报告”。
当前支持 PDF、HTML、DOCX 和 Markdown 文件。选择文件后，填写 “测试结论” 和 “人工判定依据”，再点击 “保存报告”。
判定依据应说明测试的版本、环境、范围及结论，例如：
在本批次约定的 TEST 环境中，使用固定会员样例完成条件组合、日期边界、人数去重、空结果和统计异常检查。实际结果与验收标准一致，具体步骤及证据见报告。
以上仅为通过时的填写示例。尚未检查或未通过的项目，应如实写明。
上传报告用于留档，不会改变 API/E2E 的执行结果，也不会自动完成业务验收。
第五步：逐项提交业务验收结论
当批次进入业务验收阶段，由有权限的成员打开当前验收工作台，核对 “第几轮业务验收” 和需求项列表，再逐项填写：
- 验收人：实际负责本项验收的人员。
- 验收意见：检查了什么、使用什么环境和数据、结果怎样。
- 验收结果：选择 “通过”、“不通过” 或 “需要修复”。
- 缺陷说明：选择“不通过”或“需要修复”时必填，写明问题和复现方式。
确认内容后，点击 “提交本条验收”。提交成功后，页面展示已保存结论、验收人、意见、记录人和记录时间；本轮该项不再显示编辑表单。
例如，发现结束日期边界错误时，可以填写：
需求项：覆盖人数预估。测试环境使用约定的固定会员数据。选择金卡、上海，最近消费日期为 2026-09-01 至 2026-09-20；预期命中 A、B 共 2 人，实际仅命中 A 共 1 人。会员 B 的最近消费时间为北京时间 2026-09-20 23:59:59，应包含在结束日期内。请修复后重新验证起止日期边界。
已记录的未通过项需要按当前流程退回生产修复，再进入新一轮验收。修复后，应重新验证问题场景及受影响内容，并在新一轮中记录结论。
第六步：完成当前验收阶段
“已验收”数量表示已有结论的需求项数量，不代表这些需求项全部通过。 结束前要检查每项结论及缺陷处理情况。
本轮各需求项通过、满足当前流程要求后，由有权限的成员执行 “完成业务验收”，阅读确认内容，再提交阶段确认。操作完成后检查工作流状态，确认是否已进入下一阶段。
业务验收通过后，正式发布仍需按项目约定执行。标准流程中的“确认上线”只记录人工确认，本身不执行部署；发布与规格归档见从已准入需求到第一次交付。
预览无法打开、测试没有继续执行或验收按钮不可用时，参考任务没有继续执行时如何排查。