模拟测试数据
模拟测试数据是订货算法上线前的"验算题库"。算法本身是一段计算逻辑，写完之后很难凭眼睛判断它对不对，需要一组组已知输入去跑出订货数量，再和门店经验比对。本功能让你自己维护这些输入组合——不同星期、不同库存、是否促销、退货率高低、几点估清——一次配好长期复用，每次改完算法都能拿同一批用例回归验证。
功能路径：系统菜单 → 零售POS → 智能订货 → 模拟测试数据
一、功能概述
1. 数据从哪来、到哪去
一条测试数据 = 算法的全部输入参数 + 一个算出来的订货数量。它不参与门店真实订货，只服务于 订货算法版本管理 的数据测试与测试结果两个页签。
典型闭环：
- 在本功能录入或修改测试数据，覆盖需要验证的场景；
- 进入订货算法版本管理的【数据测试】页签，选中算法版本与测试数据，执行【测试选中】或【测试全部】；
- 在【最新测试结果】区核对算出来的订货数量是否符合预期；
- 不符合就回到 订货算法 改逻辑、存新版本，再跑同一批用例；
- 全部通过后，把该版本切换为生效版本，门店订货才真正用上。
2. 两种操作视图
| 视图 | 适用场景 |
|---|---|
| 表格页签 | 批量查看、检索、比较多条测试数据的参数差异 |
| 卡片编辑页签 | 单条数据精修，一屏看全算法要用到的所有输入参数 |
| 编码备注页签 | 维护这条用例的备注说明 |
窗口顶部是 退出 / 编辑 / 刷新 / 报表 / 帮助 五个按钮，【报表】带下拉，里面是报表机器与直接打印。刚打开时表格是只读的，行导航条上的 新增、删除、修改、保存、取消 全部灰着；点【编辑】后整窗解除只读，这些按钮才可用。
改完一行不会自动写库：导航条上的【保存】把当前行提交，【取消】则丢弃这一行尚未保存的改动。新增出来的行在保存前，行首会带一个 * 标记，底部"总记录数"也仍然按已保存的行数统计。
表格视图适合"看一眼这批用例覆盖了哪些场景"，卡片编辑适合"把这条用例的退货率改成超标"。
二、字段说明
每条测试数据的字段就是算法能读到的变量，字段是否填全直接决定测试结果可不可信。
表格里每一列的标题（数据用途、订货周期、星期几……）与算法代码里的中文变量名逐字相同：版本管理跑测试时，系统是按列标题去取对应的变量值再喂给算法的。所以列标题不要改名、也不要删列，改了之后那一列的值算法就取不到了。
1）基础标识
| 字段名 | 含义 |
|---|---|
| 数据编号 | 新增时由系统按流水号自动生成的四位编号，不能自己填；用它到测试结果里回查 |
| 数据用途 | 这条用例验证什么场景，例如"促销上浮验证""高退货率下调验证" |
| 订货周期 | 订货周期序号，日常订货一般为 1，多周期门店按实际周期填写 |
| 星期几 | 订货日对应的星期，取值 1–7，界面上显示成"星期一"到"星期天" |
2）销量与库存
| 字段名 | 含义 |
|---|---|
| 日均销用量 | 物料在该门店的日均消耗量，算法的基础参数 |
| 今日销售数 | 同期历史销售数量 |
| 昨日订货数 | 上周同期的实际订货数量，用于同期订货量平滑 |
| 当前结存数 | 下单前门店的实际结存，算法据此算缺口 |
| 最低库存 | 备货标准算出的库存下限 |
| 最高库存 | 备货标准算出的库存上限 |
| 最低起订数量 | 订货模板的起订下限，算出的数量低于此值时归零 |
| 最高起订数量 | 订货模板的起订上限，算出的数量高于此值时取上限 |
3）微调规则参数
| 字段名 | 含义 |
|---|---|
| 参加促销 | 勾选表示该物料当期做促销，用于验证促销上浮逻辑 |
| 近七天星期一订货量 ～ 近七天星期天订货量 | 最近 7 天逐日的实际订货量，用于同期平滑 |
| 近7天平均退货率 | 最近 7 天的实际退货水平 |
| 退货率标准 | 企业设定的合格线，超过即触发订货量下调 |
| 昨天估清时间 | 前一天的售罄时刻，格式 HH:MM |
| 近3天估清时间 | 近 3 天的售罄时刻，格式 HH:MM |
| 上周同期估清时间 | 上周同一天的售罄时刻 |
| 上周同期销售数 / 上二周同期销售数 / 上三周同期销售数 | 近 3 周同星期的销量，同期预测算法的权重输入 |
| 去年公历同期销售数 | 去年同一公历日的销量，大促节日的对比基准 |
| 去年农历同期销售数 | 去年同一农历日的销量，春节、中秋等农历节日的对比基准 |
| 安全系数 | 安全存量调整系数，按门店容忍度设定 |
| 节假日 | 勾选表示当天为节假日，触发节日预测修正 |
| 公历节日 | 当天对应的公历节日名称 |
| 农历节日 | 当天对应的农历节日名称 |
去年公历同期、去年农历同期两组销售数参与节日权重计算。验证春节、中秋这类日期浮动的节日时，只填公历同期不够，农历同期也要填，否则算法取到空值，测试结果不能反映真实表现。
三、业务操作步骤
步骤 1：打开功能
系统菜单 → 零售POS → 智能订货 → 【模拟测试数据】。窗口打开后默认停在表格视图，列出当前账套已维护的全部测试数据。
步骤 2：规划要覆盖的场景
每条用例都要自己定参数组合，所以先想清楚要验什么再动手。建议第一批先建 5–8 条，分别对应日常销售、促销、节假日、高退货率、提前估清、起订下限、起订上限，「数据用途」按场景命名，后面在测试结果里一眼能认出来。
已有相近用例时不要从零录：选中一条改存为新编号，只动差异字段，是搭场景最快的办法。
步骤 3：新增一条用例
- 点顶部【编辑】解除只读，用表格下方的行导航按钮新增一条记录；
- 数据编号由系统自动生成，只需要填「数据用途」，建议带场景含义，方便在测试结果里一眼认出；
- 新增行不是空白行——除编号与用途之外，每个参数列都会自动带入一组固定的演示默认值，见下表；先看清带进来的值，再只改这次要验证的那几个字段；
- 表格列很多，退货率、估清时间、节日等要靠横向滚动才看得到；嫌来回滚动麻烦，可以切到【卡片编辑】页签按字段逐条录入；
- 点导航条的【保存】把这条用例写库；还没保存就点【取消】，这一行会被丢弃。
自动带入的演示默认值：
| 参数 | 带入值 | 参数 | 带入值 |
|---|---|---|---|
| 订货周期 | 1 | 参加促销 | 是 |
| 星期几 | 1 | 近七天星期一～星期天订货量 | 60 / 70 / 80 / 90 / 100 / 110 / 120 |
| 日均销用量 | 100.5 | 近7天平均退货率 | 0.08 |
| 昨日订货数 | 101.6 | 退货率标准 | 0.05 |
| 今日销售数 | 99.7 | 昨天估清时间 | 19:25 |
| 当前结存数 | 10.8 | 近3天估清时间 | 16:55 |
| 最低库存 | 80.9 | 上周同期估清时间 | 18:55 |
| 最高库存 | 120.1 | 上周／上二周／上三周同期销售数 | 76.5 / 75.8 / 80.6 |
| 最低起订数量 | 20 | 安全系数 | 0.2 |
| 最高起订数量 | 200 | 安全存量 | 18 |
「节假日、公历节日、农历节日、去年公历同期销售数、去年农历同期销售数」这五项没有默认值，新增后是空的，做节日类用例时必须自己填。
步骤 4：复制已有用例做变体
要验证"同一场景只改一个变量"时，不要从零录。选中一条已配好的数据，点【编辑】解除只读，在行上点右键用菜单里的【复制增加】，系统会给这条副本生成新编号、参数原样带过来，只改差异字段（例如只把退货率从 0.02 改成 0.15）。两条用例结果一比，就能确认这条微调规则真的生效。
步骤 5：修改与删除
- 点【编辑】解除只读，直接在表格或【卡片编辑】页签改，改完点导航条的【保存】提交；
- 确认不再需要的用例，点【编辑】后用行导航按钮删除并确认；
- 已经跑过、结论可信的用例建议长期保留，算法每次迭代后的回归测试都要靠它们，删掉之后只能重新录入。
步骤 6：送去跑测试
切到 订货算法版本管理 的【数据测试】页签，选中要验的算法版本，勾选刚配好的测试数据，点【测试选中】。右侧【最新测试结果】区出现每条用例算出的订货数量，逐条与预期比对。
四、场景覆盖建议
一批能用的测试数据，应当能回答"每条微调规则是否按设计生效"。建议至少覆盖：
| 场景 | 关键参数设置 | 验证目标 |
|---|---|---|
| 日常常规销售 | 不勾促销、不勾节假日，退货率低于标准 | 基础预测与补货缺口计算正确 |
| 促销活动 | 勾选【参加促销】 | 订货量按促销系数上浮 |
| 节假日 | 勾选【节假日】并填节日名称、去年同期销量 | 节日权重修正生效，大促节日向去年同期倾斜 |
| 高退货率 | 【近7天平均退货率】高于【退货率标准】 | 订货量下调 |
| 提前估清 | 估清时间早于设定的告警时刻（如 18:00 之前） | 订货量上调，且"昨天"与"近 3 天"两级判断分别生效 |
| 起订下限 | 算出的数量低于【最低起订数量】 | 订货数量归零 |
| 起订上限 | 算出的数量高于【最高起订数量】 | 订货数量取上限 |
| 低库存兜底 | 【当前结存数】低于【最低库存】 | 补齐到最低库存线 |
配置时还要注意：
- 数字与格式要合规。 星期几填 1–7 的整数，估清时间填 HH:MM，退货率填小数而不是百分数，格式不对算法会取不到值。
- 参数尽量取自真实历史。 凭空编一组漂亮数字，测试一定通过，上线一定出问题。
- 参数不要留空。 同期销量、近七天订货量这类微调参数缺失时，对应规则等于没被验证过。
- 算法加了新变量，用例要同步补。 例如新增一类节日，就要补一条该节日的测试数据，否则新版本上线没有任何覆盖。
五、权限与前置条件
- 测试数据的新增、修改、删除影响算法验证结论，建议只开放给系统管理员和算法维护人员，门店与采购岗以查看为主。
- 本功能自身不依赖业务单据，任何时候都可以录入；但要让测试结论有意义，订货算法、门店订货模板、备货规则 的口径应先定下来。
- 测试数据按账套独立保存，切换账套后需要重新维护。
- 定期（例如每季度）按门店最新销量刷新一批用例，避免用两年前的销售水位去验证今天的算法。
六、常见问题
1. 跑完测试，某条用例的订货数量为 0
- 原因：多为起订下限拦住了小数量，或算出的补货量本身为零（结存已高于最高库存）；也可能是必填参数缺失导致算法没走进计算分支。
- 处理：先看【当前结存数】与【最高库存】的关系，再核对【最低起订数量】，最后逐段检查算法逻辑，确认参数被读到。
2. 改了参数，测试结果没变
- 原因：格子还在编辑状态、没点【保存】（没写库），或者在算法版本管理里测试时选中的是另一个算法版本。
- 处理：回到本功能点导航条的【保存】把这一行提交，确认参数已经落住；再到【数据测试】页签核对当前选中的版本号。
3. 促销、节假日、退货率三种规则同时命中，结果对不上手算
- 原因：微调规则按算法里的书写顺序依次叠加，上浮与下调是连乘而非取最大值。
- 处理：先用只命中单一规则的用例逐条验证，再配一条多重命中的用例验证叠加结果。
4. 经典用例被误删了
- 原因：批量清理自定义数据时连带删除。
- 处理：本功能没有一键还原，需要按场景重新录入。建议定期用顶部【报表】导出一份留底，误删后按备份重建。
5. 测试全部跑得很慢
- 原因：用例数量多，每条都要完整跑一遍算法。
- 处理：日常迭代只跑与本次改动相关的场景（【测试选中】），全量测试留到版本切换前做一次。
6. 保存时提示「名称字段 数据用途 不允许为空,请检查并输入!」
- 原因：「数据用途」是这条记录的名称字段，保存前必须有值；新增行后直接去填参数、没给这行起名就点【保存】（或翻页、切页签触发提交）就会弹这个提示，提示末尾会带上出问题的窗体与控件名（frm_AoDemoData.Nvg_Code）。
- 处理：回到「数据用途」这一列填上场景名再保存。同一批用例建议按场景命名（如"促销上浮验证""高退货率下调验证"），既满足必填，也方便在测试结果里认出是哪条。
附：本文档变更记录
| 日期 | 变更 |
|---|---|
| 2026-11-09 | 初稿 |
| 2026-11-10 | 按当前版本订正：数据编号自动生成、顶部按钮清单、补齐新增行自动带入的演示默认值清单与无默认值的五个节日字段；列名与算法里的参数名对齐 |
| 2026-11-10 | 按运行中的客户端界面复核：顶部实为 退出/编辑/刷新/报表/帮助 五个按钮（查找与附件不显示），导航条确有【保存】【取消】；页签补上【编码备注】；【复制增加】改标为行右键菜单项；星期几列显示中文星期；新增表格页签实测截图 |
| 2026-11-10 | 列名按数据集 DisplayLabel 逐列核对订正：近7天平均退货率、近3天估清时间（此前漏了数字）；补「列标题即算法变量名，改名后算法取不到值」的机制说明；写库时机统一表述为点【保存】 |
| 2026-11-10 | 按运行时实测补常见问题：「数据用途」为必填名称字段，未填保存时的提示原文与处理方式 |