Oracle存储过程单元测试报告必须结构化，需包含用例标识、输入值、预期输出、实际输出、执行耗时及异常堆栈；UTPLSQL框架配合ut_coverage是当前最优解，支持多格式报告与覆盖率统计，但需注意断言参数顺序、NULL比较方式及SQL*Plus输出净化。
Oracle 存储过程单元测试报告不能靠 DBMS_OUTPUT 临时拼接
直接用 dbms_output.put_line 打印“pass/fail”看似简单，但无法结构化提取、不支持断言失败定位、不记录输入参数和执行上下文，最终生成的“报告”只是日志碎片。真实可用的测试报告必须包含：用例标识、输入值、预期输出、实际输出、执行耗时、异常堆栈（如有）。这要求测试逻辑与报告生成解耦，且数据可持久化或导出。
用 UTPLSQL 框架 + ut_coverage 是当前最稳的组合
UTPLSQL 是 Oracle 原生兼容、活跃维护的开源测试框架，它把测试用例写成包内过程，自动收集结果并支持 XML/HTML/JSON 多种报告格式。关键点在于：测试包必须以 UT% 或 %_UT 命名；每个测试过程需用 UT_ASSERT_EQUAL 等断言函数；运行前需调用 ut.run 并指定报告器。
- 安装后执行
ut.run('my_test_pkg', ut_reporter_html())即可生成带样式 HTML 报告 - 若需自动化脚本调度，用 SQL*Plus 调用：
@run_tests.sql，其中run_tests.sql包含SET MARKUP HTML ON SPOOL ON和SPOOL test_report.html - 覆盖率数据需额外启用：
ut_coverage.coverage_start+ut_coverage.coverage_stop，否则 HTML 报告中无行覆盖率数字
UT_ASSERT_THROWS 和 UT_ASSERT_EQUALS 的参数顺序别颠倒
这两个断言函数第一个参数是「预期值」，第二个是「实际值」——和多数语言（如 JUnit）相反。写反会导致测试通过但逻辑错误被掩盖。比如：
ut_assert.equals('should return 100', 100, my_proc(5)); -- ✅ 正确：预期在前如果写成 ut_assert.equals('...', my_proc(5), 100)，当 my_proc(5) 返回 99，断言会报错说 “expected <99> but got <100>”，让人误以为是预期设错了。
- 所有
UT_ASSERT_*函数的第 1 个字符串参数是描述文本，必须非空，否则报告里该用例显示为 “” - 对 NULL 值比较要用
UT_ASSERT_IS_NULL，不能用UT_ASSERT_EQUALS，否则 NULL = NULL 判定为 FALSE - 大对象（CLOB/BLOB）比较建议先用
DBMS_LOB.GETLENGTH校验长度再抽样比对，避免内存溢出
自动生成报告的 SQL*Plus 脚本要关掉无关输出
直接在 SQL*Plus 里跑 ut.run 默认会混入连接信息、SQL 提示符、空行，污染 HTML 结构。必须显式关闭干扰项：
SET FEEDBACK OFF
SET VERIFY OFF
SET TRIMSPOOL ON
SET PAGESIZE 0
SET LINESIZE 32767
SPOOL coverage_report.html
EXEC ut.run('hr.test_pkg', ut_reporter_html());
SPOOL OFF漏掉 TRIMSPOOL ON 会导致每行末尾补空格，HTML 渲染错位；PAGESIZE 0 不设会导致分页符插入报告中间；而 FEEDBACK OFF 不关，会在报告开头多出 “PL/SQL procedure successfully completed.” 这类干扰文本。
真正麻烦的是跨环境适配：开发库用 UTPLSQL v3，测试库可能只装了 v2，两者的 ut_reporter_html() 接口不兼容——得先查 SELECT * FROM ut_version 再动态拼执行语句，这个逻辑没法塞进纯 SQL 脚本里，必须用匿名 PL/SQL 块包装。
