Postgresql回归测试(2)

　　注意: 因为使用了 USA 的夏时制规则，所以这些问题总是出现在四月的第一个星期天， 和十月的最后一个星期六，以及它们后面的那个星期一 — 不管你居住的地方的夏时制是从什么时候开始的。 还要注意这个问题在太平洋时间(UTC-7或者UTC-8)的午夜出现或者消失， 而不是你本地时间的午夜。因此，这些问题可能在星期六的晚上出现， 或者一直到星期二的大部分时间都存在，具体现象取决于你居住的地方。

　　大多数日期和时间结果依赖于时区环境变量。参考文件是为时区 PST8PDT (伯克利，加州)准备的，因而如果测试没有设置为那个时区是显然会失败的。 回归测试的驱动器把环境变量 PGTZ 设置为 PST8PDT，基本可以保证正确的测试。

　　浮点数差别

　　有些测试涉及到对表中的数据列进行 64位浮点数(double precision)计算的问题。 我们观察了涉及到计算double precision字段的数学函数的结果的差别。 float8和geometry(几何类型)测试尤其容易在不同平台之间产生小差别。 这时需要肉眼对这些差别进行比较， 以判断这些差别究竟有多大，我们发现是在小数点右边10位数。

　　有些系统把负零显示为 -0，而其它的只是显示 0。

　　有些系统在pow()和exp() 出错时产生的信号与目前 Postgres 代码里期望的机制不一样。

　　行顺序差别

　　你可能会看见同样的行以与预期文件的不同的顺序输出。在大多数情况下， 严格说来这不算臭虫。大多数回归测试脚本都不会迂腐到在每个SELECT中都使用ORDER BY的地步， 因此根据 SQL 规范里的词汇的说明，它们的结果集的顺序并非定义得非常好的。尤其是因为我们是在同样的数据上运行同样的查询， 因此我们在所有平台上通常都获得同样的结果， 因此即使缺少ORDER BY也不算什么大问题。 不过有些查询的确存在跨平台的排序问题。 (如果你使用了非 C 的区域设置，也可能造成排序差异的问题。)

　　因此，如果你看到一个排序差异，应该不是什么要担心的问题(除非出问题的查询的确使用了 ORDER BY)。 不过，如果有这样的现象，请告诉我们，这样我们就可以在那条查询上加一个 ORDER BY， 这样我们就可以在以后版本里消除着种伪"失败"。

　　你可能会问，为什么我们不对所有回归测试的 SELECT 进行排序以一次性消灭所有这类问题。 原因是这样做只能让回归测试用处更少，而不是更多，因为它们会试图使用那些生成顺序结果的查询规划，而不再使用那些不排序的查询规划。

　　"随机"测试

　　随机测试脚本的目的是测试生成随机结果。 在很罕见的情况下，这会导致回归测试中的随机测试失败。 键入

　　diff results/random.out expected/random.out

　　会产生仅仅一行或几行差别。 你不必担心这些，除非随机测试在重复测试中总是失败。

原文转自：http://www.ltesting.net