↑↓ 选择 ↵ 打开 ⌫ 改范围 完整检索页

pgsql.cc 提供对 postgresql.org 官网内容的中文翻译,由 Pigsty 团队维护。

受支持版本: 当前版本 (18) / 17 / 16 / 15 / 14
测试与开发版本: 19 / devel
不受支持的版本: 13 / 12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1 / 8.0 / 7.4 / 7.3 / 7.2
历史版本PostgreSQL 7.3 已于 2007 年 11 月结束社区维护,本页译文保留供仍在使用旧版本的读者参考。新系统请看当前版本。

13.3. 测试结果评估 #

某些安装正确且功能完备的PostgreSQL实例, 可能会因为平台特有因素而在部分回归测试中“失败”,例如浮点 表示和时区支持的差异。目前这些测试是通过把输出与参考系统生成的输出做 简单的diff比较来评估的,因此结果会对细微的系统差异 很敏感。报告某项测试“失败”时,请务必检查预期结果与实际结果 之间的差异;你可能会发现这些差异并不重要。尽管如此,我们仍努力在所有 受支持平台上维护准确的参考文件,因此原则上应期待所有测试都能通过。

回归测试的实际输出位于src/test/regress/results目录中的文件里。测试脚本使用diff把每个输出文件与存储在src/test/regress/expected目录中的参考输出进行比较。任何差异都会保存到src/test/regress/regression.diffs中供你检查。(如果愿意,也可以自己运行diff。)

13.3.1. 错误消息差异

某些回归测试包含故意构造的非法输入值。错误消息可能来自 PostgreSQL代码,也可能来自宿主平台的系统例程。 在后一种情况下,消息会因平台而异,但应反映相近的信息。这类消息差异 会导致回归测试显示为“失败”,但可以通过检查确认其有效性。

13.3.2. Locale 差异

如果你在一个使用不同于 C 的排序规则 locale 初始化的已安装服务器上运行测试,那么可能会因排序顺序而出现差异以及后续失败。回归测试套件通过提供备选结果文件来处理这个问题,这些文件合起来已知能处理大量 locale。例如,对 “char” 测试,期望文件 char.out 处理 C 和 POSIX locale,而文件 char_1.out 处理许多其他 locale。回归测试驱动程序会在检查成功和计算失败差异时自动挑选最匹配的文件。(这意味着回归测试无法判断结果是否适合所配置的 locale。测试只是简单地挑选一个效果最好的结果文件。)

如果由于某种原因现有的期望文件没有覆盖某个 locale,你可以添加一个新文件。命名方案是 testname_digit.out。具体的数字并不重要。请记住,回归测试驱动程序会认为所有这样的文件都是同等有效的测试结果。如果测试结果是平台依赖的,应当改用第 13.4 节中描述的技术。

13.3.3. 日期和时间差异

如果你在一个夏令时切换日或其前一天或后一天运行 horology 测试,其中少数查询会失败。这些查询假定昨天午夜、今天午夜和明天午夜之间的间隔正好是二十四小时——如果其间夏令时生效或失效,这就是错误的。

大多数日期和时间结果依赖于时区环境。参考文件是为时区 PST8PDT(加利福尼亚州伯克利)生成的,如果测试不使用该时区设置运行,就会出现明显的失败。回归测试驱动程序会把环境变量 PGTZ 设置为 PST8PDT,这通常能确保正确的结果。但是,你必须为 PST8PDT 时区提供系统库支持,否则依赖时区的测试将会失败。要验证你的机器确实支持这一点,请键入:

$ env TZ=PST8PDT date

上面的命令应当以 PST8PDT 时区返回当前系统时间。如果 PST8PDT 时区不可用,你的系统可能返回的是 GMT 时间。如果缺少 PST8PDT 时区,你可以显式设置时区规则:

PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ

有些系统似乎不接受显式设置本地时区规则的推荐语法;在这类机器上你可能需要使用不同的 PGTZ 设置。

一些使用较老时区库的系统无法对 1970 年之前的日期应用夏令时修正,导致 1970 年前的 PDT 时间显示为 PST。这会导致测试结果中出现局部差异。

13.3.4. 浮点差异

某些测试涉及从表列计算 64 位(double precision)数。已经观察到涉及double precision列数学函数的结果存在差异。float8 和 geometry 测试尤其容易在不同平台之间、甚至在不同编译器优化设置下出现微小差异。需要人工目测比较来确定这些差异的真实意义,它们通常出现在小数点右侧第 10 位。

某些系统对pow()和exp() 发出错误的方式,与当前PostgreSQL代码所 预期的机制不同。

13.3.5. 多边形差异

若干测试涉及对加利福尼亚州奥克兰/伯克利街道地图地理数据的操作。地图数据被表示为多边形,其顶点用一对 double precision数(十进制纬度和经度)表示。首先创建一些表并装入地理数据,然后创建一些使用多边形相交操作符(##)连接两个表的视图,再对视图做一次 select。

在比较不同平台的结果时,差异出现在小数点右侧第 2 或第 3 位。出现这些问题的 SQL 语句是:

SELECT * from street;
SELECT * from iexit;

13.3.6. 行顺序差异

你可能会看到这样的差异:同样的行在输出中的顺序与预期文件中的顺序不同。 在大多数情况下,严格说来这并不是缺陷。大多数回归测试脚本并没有细致到 为每一个SELECT都使用ORDER BY, 因此按 SQL 规范,它们的结果行顺序并没有良好定义。实际上,由于我们看到的 是同一软件在同一数据上执行相同查询,通常在所有平台上都会得到相同的结果 顺序,所以缺少ORDER BY并不是问题。不过,有些查询 确实会表现出跨平台的顺序差异。(非 C 区域设置也可能触发顺序差异。)

因此,如果你看到顺序差异,一般无需担心,除非查询确实包含 ORDER BY而你的结果违反了它。不过,仍请报告该问题, 这样我们可以为那个特定查询加上ORDER BY,以在后续 版本中消除这种虚假的“失败”。

你可能会好奇,为什么我们不显式地为所有回归测试查询排序,从而一劳永逸地 解决这个问题。原因在于,那样反而会降低回归测试的价值,因为测试会倾向于 覆盖能产生有序结果的查询计划类型,而排除那些不能产生有序结果的计划类型。

13.3.7. “random” 测试

“random” 测试脚本中至少有一种情况旨在产生随机结果。这会使 random 回归测试偶尔(也许每五到十次尝试一次)失败。键入

diff results/random.out expected/random.out

应当只产生一行或几行差异。除非随机测试在反复尝试中总是失败,否则不必担心。(另一方面,如果在回归测试的多次尝试中随机测试从未被报告失败,你可能确实应该担心。)

提交更正

译文有误、术语不当或页面显示问题,请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题,请在当前版本的对应页面向上游反馈;上游不再修订已结束维护的版本。