存储过程逻辑正确性无法靠索引报告或执行日志验证，必须通过输入-输出比对闭环实现；需用Python+allpairspy构建正交参数组合，显式声明输入映射，调用前后插入控制表并校验关键指标（如COUNT、SUM），禁用COMMIT和DBLINK以保障测试隔离。
直接用 DBMS_AUTO_INDEX.REPORT_LAST_ACTIVITY 或类似索引报告函数，无法验证存储过程逻辑正确性——它只管索引生成行为，不碰业务结果。真正可行的自动化验证，必须绕过“黑盒执行”，转为“输入-输出比对”闭环，核心是控制变量、隔离环境、结构化断言。
为什么不能只靠执行日志或返回码？
存储过程编译通过（STATUS = 'VALID'）≠ 逻辑正确；执行无报错（SQLCODE = 0）≠ 结果准确。尤其在移植场景中，常见问题包括：
- 日期格式隐式转换导致过滤条件失效（如
'20211115'vs'2021-11-15'） - 临时表未清空，跨批次污染结果
- 动态 SQL 拼接时引号/括号缺失，实际执行的语句与预期不符
- 游标循环中
EXIT WHEN c%NOTFOUND位置错误，漏处理最后一条
这些错误不会抛异常，但会让下游报表多出/少掉几万行数据——人工肉眼根本看不出。
用 Python + allpairspy 构建参数组合驱动框架
关键不是“测所有输入”，而是用正交组合覆盖边界和依赖路径。比如一个统计过程有 4 个日期参数、2 个枚举字段、1 个数值范围，全量组合是 3⁴×5²×10 ≈ 20,000 种，但用 allpairspy 只需 60–80 组即可覆盖两两交互。
- 输入映射必须显式声明：如
'x2': {'X2': [BaseInfo.getTradeDate()[1]]}，避免硬编码时间字符串 - 每组参数生成唯一
id（如str(time.strftime('%Y%m%d%H%M%S'))），用于插入测试专用结果表的test_run_id字段 - 调用前后都加
SELECT COUNT(*), SUM(amount) FROM result_table WHERE test_run_id = 'xxx'，只比这两个值，不比全量行 - 失败时自动导出差异 SQL：
SELECT * FROM old_result MINUS SELECT * FROM new_result
如何让 Oracle 端配合自动化断言？
存储过程本身不提供断言能力，必须靠外部封装。最轻量做法是在调用前后插入控制表：
INSERT INTO proc_test_log (run_id, proc_name, step, ts)
VALUES ('20261027195501', 'XXXXXX', 'before', SYSTIMESTAMP);然后在过程末尾加：
INSERT INTO proc_test_log (run_id, proc_name, step, ts)
VALUES ('20261027195501', 'XXXXXX', 'after', SYSTIMESTAMP);- Python 脚本执行前先清空该表，执行后查
step = 'after'是否存在，不存在即过程中途异常退出 - 避免用
DBMS_OUTPUT.PUT_LINE——它默认被截断且不可编程捕获 - 禁用所有
COMMIT和DBLINK调用，否则测试数据会污染生产环境
真正难的不是写比对脚本，而是把每个存储过程的“预期行为”翻译成可计算的指标——比如“客户维度表更新后，valid_from 必须等于当前交易日，且无重复 customer_id”。这个定义一旦模糊，自动化就变成假阳性的噪音源。
