33.2. 测试评估#
- 33.2.1. 错误消息差异
- 33.2.2. 区域设置差异
- 33.2.3. 日期和时间差异
- 33.2.4. 浮点数差异
- 33.2.5. 行排序差异
- 33.2.6. 堆栈深度不足
- 33.2.7. “random” 测试
- 33.2.8. 配置参数
一些正确安装且完全正常工作的PostgreSQL安装可能会““失败””某些回归测试,原因是平台特定的工件,例如浮点数表示和消息措辞不同。目前使用简单的diff
比较来评估测试,与在参考系统上生成的输出进行比较,因此结果对系统细微差异很敏感。当测试报告为““失败””时,请务必检查预期结果和实际结果之间的差异;您可能会发现差异并不显著。尽管如此,我们仍致力于在所有受支持平台上维护准确的参考文件,因此可以预期所有测试都会通过。
回归测试的实际输出位于src/test/regress/results
目录中的文件中。测试脚本使用diff
比较每个输出文件与存储在src/test/regress/expected
目录中的参考输出。任何差异都将保存在src/test/regress/regression.diffs
中供您检查。(在运行除核心测试之外的测试套件时,这些文件当然会出现在相关子目录中,而不是src/test/regress
。)
如果您不喜欢默认使用的diff
选项,请设置环境变量PG_REGRESS_DIFF_OPTS
,例如PG_REGRESS_DIFF_OPTS='-c'
。(或者,如果您愿意,也可以自己运行diff
。)
如果由于某种原因,特定平台为给定测试生成了“failure”,但检查输出后您确信结果有效,则可以添加一个新的比较文件,以便在将来的测试运行中消除失败报告。有关详细信息,请参见第 33.3 节。
33.2.1. 错误消息差异#
一些回归测试涉及故意无效的输入值。错误消息可能来自PostgreSQL代码或主机平台系统例程。在后一种情况下,消息可能因平台而异,但应反映类似的信息。消息中的这些差异将导致一个“failed”回归测试,可以通过检查来验证。
33.2.2. 区域设置差异#
如果您针对使用除 C 以外的排序顺序区域设置初始化的服务器运行测试,则由于排序顺序和随后的失败,可能会出现差异。回归测试套件通过提供备用结果文件来处理此问题,已知这些文件共同处理了大量区域设置。
要在使用临时安装方法时在不同的区域设置中运行测试,请在make
命令行上传递适当的与区域设置相关的环境变量,例如
make check LANG=de_DE.utf8
(回归测试驱动程序取消设置LC_ALL
,因此无法使用该变量选择区域设置。)要使用无区域设置,请取消设置所有与区域设置相关的环境变量(或将其设置为C
),或使用以下特殊调用
make check NO_LOCALE=1
在对现有安装运行测试时,区域设置由现有安装确定。要更改它,请通过将适当的选项传递给initdb
来使用不同的区域设置初始化数据库集群。
通常,建议尝试在生产使用所需的区域设置中运行回归测试,因为这将演练生产中实际使用的与区域设置和编码相关的代码部分。根据操作系统环境,您可能会遇到故障,但至少您将知道在运行实际应用程序时会遇到哪些特定于区域设置的行为。
33.2.3. 日期和时间差异#
大多数日期和时间结果都取决于时区环境。参考文件是针对时区PST8PDT
(加利福尼亚州伯克利)生成的,如果测试不是在该时区设置下运行,将会出现明显的故障。回归测试驱动程序将环境变量PGTZ
设置为PST8PDT
,这通常可确保正确的结果。
33.2.4. 浮点差异#
某些测试涉及从表列计算 64 位浮点数(double precision
)。已经观察到涉及double precision
列的数学函数的结果存在差异。float8
和geometry
测试特别容易出现跨平台的小差异,甚至在不同的编译器优化设置下也会出现。需要人工肉眼比较来确定这些差异的实际意义,这些差异通常在小数点右侧的 10 位。
某些系统将负零显示为-0
,而其他系统仅显示0
。
某些系统从pow()
和exp()
发出错误信号的方式与当前PostgreSQL代码预期的机制不同。
33.2.5. 行排序差异#
您可能会看到相同行按与预期文件中出现的顺序不同的顺序输出的差异。在大多数情况下,严格来说,这不是一个错误。大多数回归测试脚本并不像对每个SELECT
使用ORDER BY
那样死板,因此根据 SQL 规范,它们的结果行顺序没有得到很好的定义。在实践中,由于我们看到的是由同一软件在相同数据上执行的相同查询,所以我们通常在所有平台上获得相同的结果顺序,因此缺少ORDER BY
并不是问题。然而,某些查询确实表现出跨平台的排序差异。在针对已安装的服务器进行测试时,排序差异也可能是由非 C 区域设置或非默认参数设置(例如work_mem
或规划器成本参数的自定义值)引起的。
因此,如果您看到排序差异,不必担心,除非查询确实有ORDER BY
,而您的结果违反了该排序。但是,请无论如何报告它,以便我们可以在该特定查询中添加ORDER BY
,以消除未来版本中的虚假“失败”。
您可能想知道,为什么我们不显式地对所有回归测试查询进行排序,以一劳永逸地解决此问题。原因是,这会让回归测试变得没那么有用,因为它们倾向于练习产生有序结果的查询计划类型,而排除不产生有序结果的查询计划类型。
33.2.6. 堆栈深度不足#
如果errors
测试结果在select infinite_recurse()
命令处导致服务器崩溃,则表示平台对进程堆栈大小的限制小于max_stack_depth参数指示的限制。可以通过在更高的堆栈大小限制下运行服务器来修复此问题(建议使用max_stack_depth
的默认值 4MB)。如果您无法这样做,另一种方法是降低max_stack_depth
的值。
在支持getrlimit()
的平台上,服务器应自动选择max_stack_depth
的安全值;因此,除非您手动覆盖了此设置,否则此类故障是一个可报告的错误。
33.2.7.“random”测试#
random
测试脚本旨在产生随机结果。在极少数情况下,这会导致回归测试失败。键入
diff results/random.out expected/random.out
应该只产生一行或几行差异。除非随机测试重复失败,否则您不必担心。
33.2.8. 配置参数#
在针对现有安装运行测试时,某些非默认参数设置可能会导致测试失败。例如,更改enable_seqscan
或enable_indexscan
等参数可能会导致计划更改,从而影响使用EXPLAIN
的测试结果。