 lovife
|
601714c476
|
test(scripts): 补测"没测过的四项"+ 清理工具扩展（F-99 / F-5）
一、load-test.py：把 docs/09 §9.5 里四项"没测过"的变成"测过"
· --base：另起一个 --fill.storage.provider=local 的实例（18080）量上传，
不把测试文件灌进真实七牛桶；
· --fixture-only：量名册导入本身（造 Excel 与导入接口分开计时 ——
脚本自己的成本不能算到系统头上）；
· --only export-big：造 N 份已通过的单（门禁绑定→草稿→上传→提交→
初审（班主任）→终审（管理员）→前置检查→创建→轮询），再逐卷解开验证 ZIP；
· --soak/--rps：长跑，每分钟采 RSS（从系统取，不是应用自报的堆）与
PG 连接数，比较前 1/3 与后 1/3 的均值 —— 判据是趋势，不是"跑完没崩"；
· 上传夹具换成真 JPEG（原来的"JPEG 头+随机字节"在服务端解码即失败，
量到的根本不是压缩成本）。
数字（docs/09 §9.5 有完整复现命令）：
上传 20 并发 40/40，串行 321ms（2850KB→1329KB，47%），并发 p50 620ms；
5000 行导入 20.2s（RSS 782MB）；150 人 194.6MB 导出打包 13.2s，
分卷 4 卷每卷可单独解开；长跑 51 样本 15300 请求 0 失败，
RSS 603.9→582.9MB 平稳，PG 连接定时任务高峰后正常回落。
二、F-99：这一轮压测工具自己撒了 8 次谎（都是"度量/夹具出问题时
现象长得像产品缺陷"）：前置未断言（--only upload 单跑全报"没有草稿"）、
假 JPEG、猜列名（part_no/file_name/file_path）、拿 HTTP 码当业务码、
跨租户同名 admin（库里 50 多个，改从 token 的 sub 取 uid）、
夹具接口不查返回码（PUT orgs 被拒→任务没发布→学生端整齐报 40008）、
PowerShell -First 截管道把"被堵"变成"卡住"、清理只删库行不删文件。
修法：bind_users/call_ok（夹具每个调用都断言业务码）、make_img 真图、
列名按 DDL、cleanup 连磁盘文件一起删。
三、dev-clean-e2e.py（F-5 落地）：
· --orphan-files：清"库里没有任何一行指向"的磁盘文件（判据来自
collect_file.std_path/raw_path + collect_export_file.file_path）——
实测 uploads 里 281 个文件/276MB 而库里只剩 16 行，已清 255 个/275.4MB；
· --demo-tasks：清【演示·旧】任务（只匹配带「旧」的 ——
【演示】审核台是当前演示态在用的，原来那句 LIKE 会把它一起删掉）；
· e2e 租户的业务行按 information_schema 动态枚举（写死清单必然漏新表）；
· --only-orphan-files：最安全的一档，只碰磁盘不碰任何库行。
⚠️ e2e 租户与"E2E 24数控1班"组织刻意未删：当前演示态正挂在其中一个班下面。
验证：python scripts/verify-all.py --quick → 通过 5 / 失败 0 / 跳过 0；
docs/09 §9.1~§9.5 已同步（含机器规格：12 物理核 / 59.6GB）。
|
2026-09-30 11:10:05 +08:00 |
|