UTPLSQL是Oracle生态中唯一成熟、开源、支持19c的PL/SQL单元测试框架，安装需绕过SYS权限、对象权限及INHERIT PRIVILEGES限制三重坑，测试时须严格匹配参数类型，CI/CD中必须指定ut_reporter_junit等结构化输出格式。
直接上结论：用 UTPLSQL 搭建，别自己造轮子。 它是 Oracle 生态里唯一成熟、开源、支持 19c 的 PL/SQL 单元测试框架，能跑在本地 XE、开发库甚至生产只读副本上，且不依赖外部语言（比如 Java 或 Python）。
安装 UTPLSQL 到 19c 数据库需绕过三个权限坑
UTPLSQL 不是 SQL*Plus 脚本一贴就完的事。它需要创建多个 schema（utplsql、ut_coverage 等），并授予特定对象权限 —— 这些在 19c 中默认被限制：
- 必须用
SYS或具备CREATE PLUGGABLE DATABASE权限的用户执行安装脚本，普通DBA角色不够； -
utplsqlschema 需要CREATE TYPE、CREATE PROCEDURE、CREATE SYNONYM，且不能被RESOURCE角色自动覆盖（19c 默认禁用该角色隐式权限）； - 若目标 schema（比如你的业务 schema
HR）启用了INHERIT PRIVILEGES限制（19c 新增安全策略），需显式运行：GRANT INHERIT PRIVILEGES ON USER sys TO USER utplsql;
写第一个测试包时，ut.expect() 的参数类型必须严格匹配
PL/SQL 是强类型语言，UTPLSQL 的断言函数不会自动做隐式转换。常见报错 PLS-00306: wrong number or types of arguments 往往不是语法错，而是类型对不上：
- 测试返回
NUMBER的函数，别传字符串字面量：ut.expect(my_func()).to_equal('123')❌ → 改成ut.expect(my_func()).to_equal(123)✅； - 比较日期字段时，别用
SYSDATE直接比：ut.expect(emp_hire_date).to_equal(SYSDATE)❌（精度和时区易漂移）→ 改用TRUNC(SYSDATE)或固定值DATE '2026-09-30'； - 测试游标或集合类型，必须用
ut.expect(cursor_var).to_have_count(5)这类专用匹配器，不能用to_equal()。
CI/CD 流水线里运行测试，ut.run() 的输出格式决定成败
UTPLSQL 默认输出是 PL/SQL 块内 DBMS_OUTPUT，Jenkins 或 GitLab CI 拿不到结构化结果。必须显式指定报告格式：
- 命令行调用（如 SQLcl）要用：
SELECT * FROM TABLE(ut.run('hr', ut_reporter_junit()));→ 输出 XML，可被 CI 解析为测试失败数； - 避免用
ut.run('hr')无参调用，它只打印到终端缓冲区，流水线会超时卡住； - 若集成 APEX，可用
ut_reporter_html()，但注意 HTML 报告默认存临时 LOB，需配合ut_coverage插件开启覆盖率收集，否则报告里显示 “0% covered” 是正常现象 —— 不代表没跑，只是没开开关。
真正难的不是装框架或写第一个 ut.expect()，而是让每个 PL/SQL 开发者习惯在改存储过程前先补测试用例，并把 ut.run() 加进 pre-commit hook。19c 的 DBMS_UTILITY.FORMAT_CALL_STACK 能帮你快速定位测试失败时的嵌套调用链，但前提是——你得先让测试跑起来。
