先把“能打开”与“可以接单”分开验收

农产品销售小程序上线前，测试容易被理解成检查页面是否能打开、按钮能否点击。对实际经营团队来说，更关键的问题是：顾客看到的商品信息是否对应当前批次，提交订单后门店能否按承诺的时间和方式处理，遇到缺货、天气变化或临时停采时，工作人员是否知道如何暂停接单、联系顾客并留下记录。验收应当围绕一笔真实业务从浏览到交付的路径展开，而不是只在开发环境里逐个点页面。

先确定本次验收范围。列出计划上线的商品、销售区域、可接单时间、配送或自提方式、可用支付入口、客服联系人和暂不支持的情形。若不同产品批次、包装规格或发货日期不一样，应在验收表中分开列项。范围没确认时，测试人员容易用一个商品的成功结果代替全部商品的检查，也容易把暂时未开放的功能误判为故障。

从商品卡片核对到可售条件

选取几种有代表性的商品逐项核对：名称、规格、计量单位、图片、售价、可售状态、发货或自提说明、售后联系途径是否与门店当前确认的资料一致。散装、称重或按箱销售的商品，要特别检查顾客下单时看到的单位与店内拣货、称重和结算时使用的单位是否相同；如果存在预售，应明确预计出货时间的表达方式，并由负责供货的人确认目前仍可兑现。

发现信息不一致时，不要让验收人自行猜测哪一处正确。把页面截图、商品资料来源、确认人和处理结果记在同一条问题记录中；若价格、规格或供货说明仍待确认，就将该商品标为暂缓验收。修改后重新打开顾客可见页面核对一次，并确认修订已同步到店员使用的清单。这样能区分“系统显示错误”和“源资料尚未定稿”，避免问题在多个群聊里来回传递。

用不同身份走完一笔订单

测试时至少覆盖首次访问者和已登录顾客两类情况，分别检查浏览、选择规格、填写必要信息、提交订单、查看订单状态以及联系门店的步骤。验收人员应记录每一步看到的提示，而不只是写“下单成功”。例如规格是否容易选错、配送范围是否清楚、顾客是否知道订单还需门店确认，都是影响一线人员后续处理的具体信息。付款操作应使用经批准的测试方式，不要用真实顾客账户或未经授权的真实交易来代替测试。

订单到达门店后，找实际负责接单的人完成后续演练：在哪里查看新订单、谁负责确认供货、由谁准备商品、如何记录已联系顾客、何时把订单交给配送或自提环节。把顾客页面的状态与门店实际处理动作并排核对，确认两边含义一致。如果页面显示“已接单”而门店仍需确认库存，就要调整状态说明或内部交接动作，不能让顾客和店员对同一个状态产生不同理解。

重点演练缺货、改期和联系失败

正常流程通过之后，再挑选最常见的异常做桌面演练。比如顾客下单后发现可售量需要复核、商品临时无法按原时间准备、顾客填写的信息不完整、门店电话暂时无人接听。每个场景都明确第一处理人、替补联系人、需要核对的订单信息、向顾客说明的内容，以及何时升级给负责人。这里的目的不是预先承诺任何异常都能解决，而是让团队知道发现问题后先停在哪一步、由谁作下一次判断。

若需要替换商品、调整时间或取消订单，应把顾客确认与门店操作分开记录：原订单是什么、变化由谁提出、顾客是否知情、最终按什么方案处理。对于没有得到顾客回复的情况，记录联系时间和渠道，并按门店事先约定的规则决定是否继续准备商品。不要让员工根据口头印象自行修改订单，也不要把尚未确认的替代方案说成已完成安排。

验收记录要能支撑复测与放行

每条问题至少写清复现步骤、预期结果、实际结果、涉及商品或订单、发现时间、责任人、处理进度和复测结论。问题可按影响划分为“阻止接单”“影响部分商品”“提示或展示待完善”等工作类别，但具体门槛由经营负责人结合本次上线范围确定，不宜照搬别家门店的规则。修复后由未参与修改的人按原步骤复测，确认顾客端页面与门店处理记录相互吻合，再关闭问题。

最终放行前由商品资料负责人、接单负责人和上线负责人共同核对范围：哪些商品已确认，哪些销售方式已演练，哪些问题尚未关闭，顾客咨询由谁承接，出现供货变化如何暂停或更新页面。没有完成确认的项目写明负责人和下一步，不用“基本没问题”替代验收结论。上线后第一批订单可以继续按同样的检查表抽查，发现页面说明与现场执行不一致时，及时回到资料来源和责任交接处修正。

这类验收的价值在于把顾客看到的信息、门店实际供给和一线人员的处理动作对齐。它不能替代对产品质量、支付安全或系统性能的专业测试，也不能证明未来不会发生缺货或延迟；它帮助团队在开售前暴露流程断点、明确待办，并为是否按当前范围开放提供可追溯依据。

若门店准备把确认过的商品资料和下单后的接单过程放入数字化工具，可将企雀的订单/库存相关能力列为评估项。用当前测试账号演练商品信息、订单状态、缺货联系与结果导出，核对数据怎样更新、谁能操作及异常如何交接；公开介绍不能替代当前版本演示，也不能据此推断自动同步、支付安全或供货保证。