邢台小程序开发验收的核心，是把“感觉做得还行”转化为“逐项可核对、可复现、可追责”的书面结论：以功能测试、性能测试、兼容性测试、安全与合规测试四类标准衡量产品质量，以源码、账号、文档、环境四类交付物确认资产归属，最终形成《验收报告》《缺陷清单》《交付清单》三份文件，作为尾款支付与质保起算的依据。一句话的标准答案：合格的验收 = 可执行的测试标准 + 可核对的交付清单 + 可闭环的缺陷责任。跳过测试标准只签收页面，等于把上线后的稳定性风险、合规风险与二次开发成本全部留在自己手里；只验功能不验交付物，常见结果是系统能跑、源码拿不到、服务器账号不在自己名下、换服务商时被迫重做。以下 10 组问答按“概念—流程—测试—交付—避坑—售后”的顺序展开，可直接作为 邢台 项目的验收执行手册使用。

小程序开发验收到底验什么？一套完整的验收标准包含哪些维度？

验收不是“打开看看能不能用”，而是对五个维度逐项打分并留痕：功能正确性、非功能质量、合规与安全、交付物完整性、文档与可维护性。前两项决定“好不好用”，后三项决定“资产是否真正属于你、后续能否被他人接手”。

• 功能维度：需求文档与原型中的每条主流程、每个状态分支是否可执行，异常分支（超时、重复提交、空数据、权限不足）是否有兜底提示。
• 非功能维度：启动耗时、首屏渲染、接口响应、包体大小、内存占用、弱网与断网表现、并发承载。
• 兼容性维度：iOS/Android 主流系统版本、不同屏幕尺寸与安全区、微信客户端版本、深色模式与字体放大。
• 合规与安全维度：隐私保护指引、授权时机、数据加密传输、接口鉴权与越权防护、支付金额校验、内容与类目合规、小程序备案状态。
• 交付维度：源码、数据库脚本、账号权限、部署文档、测试报告、知识产权归属。

建议把五类维度做成一张验收矩阵表，每行一条检查项，列写“验收方法、判定标准、结果、证据（截图/录屏/日志）、责任人”，验收会上逐行过，避免口头确认。

验收流程怎么排？初验、试运行、终验各自看什么？

规范做法是把验收拆成三个节点，用“先验功能、再验稳定、后验交付”的顺序降低扯皮概率。

1. 初验（功能验收）：在测试环境执行完整用例，输出《缺陷清单》并按等级分级；此时不签收，只确认“功能范围是否已完成”。
2. 试运行（灰度期）：上线到体验版或小范围真实用户，观察 7～15 天的真实数据：崩溃率、接口错误率、支付成功率、审核驳回记录、客服反馈。试运行是发现“演示环境正常、真实环境异常”的关键阶段。
3. 终验（交付验收）：缺陷收敛到约定阈值（如无致命/严重级缺陷、一般级缺陷有明确修复排期），同时完成源码、账号、文档交接，签署《验收报告》与《交付清单》，进入质保期。

流程上还要固定两个动作：一是每次提测必须有版本号与变更说明，避免“边改边验”导致结论失真；二是验收会议形成书面纪要，双方确认人签字，为后续争议留下依据。

功能测试怎么落地？有哪些“必测项”不能漏？

功能测试的抓手是“用例覆盖需求、边界覆盖异常”。先由需求文档拆出主流程用例，再补异常与边界用例，两条线都通过才算完成。

• 账号与权限：授权登录、拒绝授权后的降级路径、手机号绑定换绑、多角色权限隔离、退出登录后的缓存清理。
• 表单与提交：必填校验、长度与格式限制、重复点击与重复提交幂等、提交失败后的数据保留。
• 列表与分页：空数据、超长文本、图片加载失败占位、上拉加载与下拉刷新、分页重复或漏项。
• 支付与订单：金额由后端计算而非前端传参、支付回调验签、超时未支付自动关单、退款与对账、重复回调不重复发货。
• 消息与通知：订阅消息模板是否正确、触发条件是否遗漏、用户拒收后的替代路径。
• 后台管理：数据增删改查、导出、操作日志、权限分级、删除操作的二次确认与软删除。

实操建议：要求开发方在提测时同步提交《测试用例表》和自查记录，验收方按不低于 30% 的比例抽测并重点覆盖资金流、权限与数据删除类操作，这类问题的线上代价远高于展示类页面。

兼容性测试要覆盖多少机型和微信版本？邢台项目怎么定范围？

兼容性测试遵循“覆盖主流、兼顾长尾”，不必追求全机型穷举，但必须覆盖会影响成交路径的差异点。定范围的依据是目标用户的真实设备分布，可从公众号或小程序后台的机型、系统版本、微信版本统计中取值，取累计占比靠前的机型作为必测集。

• 系统维度：iOS 与 Android 各覆盖 2～3 个主流大版本，重点关注新系统的大字体、深色模式、安全区适配。
• 屏幕维度：小屏（如 5.5 英寸级）、常规屏、全面屏、平板或折叠屏展开态，检查底部按钮遮挡与横向溢出。
• 微信版本：至少覆盖当前主流版本与一个较早版本，验证基础库能力差异导致的接口不可用。
• 网络与场景：4G/5G、弱网（限速与高丢包）、断网重连、切后台再回前台、锁屏解锁后的状态恢复。

对 邢台 的本地生活、零售、政务民生类项目，还应补充真实场景测试：门店内扫码、地下室与电梯弱网、老年用户开启大字体后的排版、微信内跳转与分享卡片展示。兼容性缺陷建议以“机型 + 系统版本 + 微信版本 + 复现步骤”的格式登记，便于定位与回归。

性能测试有哪些硬指标？包体、首屏、接口响应时间怎么定阈值？

性能验收的关键是“先定阈值再测”，否则永远会被“我觉得还行”带过。阈值应写入合同附件或验收标准文档，测试时用同一网络环境、同一机型、同一数据量级对比，保证可复现。

还要关注“数据量级”这一常被忽略的变量：空库测试永远快，验收时应在接近真实规模的数据下测试列表分页、搜索与导出。若阈值未达标，应要求提供优化方案与复测时间，而不是接受“上线后再看”。

安全与隐私合规怎么验收？哪些项目属于一票否决？

安全合规是小程序验收中风险外溢最大的部分：功能缺陷影响体验，合规缺陷可能导致下架、驳回或处罚。验收时按“收集—传输—存储—使用—销毁”五步逐项核查。

• 授权与告知：配置《小程序用户隐私保护指引》，用户信息接口在用户明示同意后再调用，拒绝授权有可用降级路径，不强制授权、不频繁弹窗骚扰。
• 最小必要：只收集业务必需字段，位置、相册、通讯录等敏感权限按场景触发，而非一进页面就申请。
• 传输与存储：全站 HTTPS，敏感字段加密存储，不在前端日志打印手机号、身份证、token。
• 接口鉴权：用户身份由后端通过登录凭证换取，禁止前端传用户 ID 直接查询数据；管理端接口做角色校验，防止水平与垂直越权。
• 支付安全：金额与商品信息由后端计算，支付回调验签、防重放、订单幂等，禁止把商户密钥写入前端代码。
• 资质与备案：类目资质与经营范围一致，按监管要求完成小程序备案，内容不触碰违规类目。

可判定为一票否决的典型情形：明文存储或传输用户敏感信息、接口无鉴权可遍历他人数据、支付金额可被前端篡改、未配置隐私保护指引却已调用用户信息接口。这类问题必须整改完成后才能进入终验。

UI 还原度和交互体验怎么量化验收，避免“差不多就行”？

UI 验收要摆脱主观争论，用“设计稿比对 + 规范核对 + 交互清单”三件套量化。做法是把设计稿的关键页面与真机截图并排放在同一画布上比对，逐项记录偏差，而不是靠感觉评价。

• 视觉还原：主色值、字号字重、圆角、间距、阴影、图标风格与设计稿一致；关键页面偏差以像素级走查记录，超出容差即登记。
• 设计规范一致性：同类元素（按钮、输入框、弹窗、Toast、加载态、空状态、错误页）在全站表现统一，无“每页一个样式”。
• 交互完整性：每个可