Postgresql回归测试

发表于:2009-05-04来源:作者:点击数: 标签:PostgresqlPostgreSQL
回归测试 是一套复杂完整的测试, 用来测试嵌入在 PostgreSQL 里的的 SQL 实现。 它同时测试标准 SQL 操作和PostgreSQL的扩展SQL。 运行测试 回归测试可以就一套已经安装好并且在运行的 服务器 进行测试, 也可以就制作树里面临时安装的服务器进行测试。 详
回归测试是一套复杂完整的测试, 用来测试嵌入在 PostgreSQL 里的的 SQL 实现。 它同时测试标准SQL 操作和PostgreSQL的扩展SQL。

运行测试

        回归测试可以就一套已经安装好并且在运行的服务器进行测试, 也可以就制作树里面临时安装的服务器进行测试。 详细些说,有"并行"和"串行"运行测试之分。 串行模式顺序运行每个测试,而并行模式启动多个服务器进程,并行地运行一组测试。 并行测试使我们对进程内部通讯和锁的正确工作有足够的信心。 由于历史原因,串行测试通常对一个现存的安装进行测试,而并行测试是"独立"的,不过这么做没有什么技术原因。

        制作之后和安装之前运行回归测试,你可以在顶级目录键入

gmake check

        (或者你可以进入 src/test/regress 然后在那里运行命令。) 这样将先制作几个辅助文件,比如一些用户定义的触发器函数,然后再运行测试驱动脚本。 最后你会看到类似下面的东西

======================
All 96 tests passed.
====================== 
        或者是一些关于某项测试失败的信息。先看看下面的 Section 26.2 然后再想想一个"失败"是否代表严重的错误。

        因为这个测试方法运行临时的服务器,所以如果你是 root 用户, 那这个方法不能运行(服务器不能以 root 身份启动)。 如果你已经以 root 身份制作了,你就什么也干不了。 这时候你应该把测试目录的权限变成某个用户可以写, 然后以那个用户身份登陆,再开始测试。比如

root# chmod -R a+w src/test/regress
root# chmod -R a+w contrib/spi
root# su - joeuser
joeuser$ cd top-level build directory
joeuser$ gmake check
        (这里唯一可能的"安全隐患"就是那个用户可能会背着你修改回归测试的结果。用你的常识管理用户权限。) 
        如果不是上面那样,安装后就可以运行测试.

        如果你配置 PostgreSQL 安装到一个原来安装有老的 PostgreSQL 的目录里,然后在安装新版本之前执行 gmake check, 那么你可能发现测试失败,因为新程序试图使用已经存在的共享库。 (典型的症状是抱怨未定义的符号。) 如果你想在覆盖老版本之间运行测试,那么你需要带着 configure --disable-rpath 制作。 不过,我们不建议你使用这个选项编译作为最终安装的数据库

        并行的回归测试会在你的用户 ID 下启动相当多的进程。 目前,最大的并发数是 20 给并行测试脚本,这意味着 60 个进程: 一个服务器进程,一个psql以及通常还有一个 shell 父进程用于每个测试脚本的psql。 因此,如果你的系统有每用户的进程数限制,那么请确保这个限制至少是 75,否则你就可能在并行测试时看到随机出现的失败。 如果你没有办法提升该限制,那么你可以通过设置 MAX_CONNECTIONS 参数,把大的并行测试程度降低。

        在某些系统上,缺省的 Bourne 兼容的 shell(/bin/sh)在管理太多并行的子进程的时候会出乱子。 这可能导致并行测试锁住或者失败。 出现这种情况时,请在命令行上声明另外一个 Bourne 兼容的 shell,比如:

gmake SHELL=/bin/ksh check
        如果没有可以替换的 shell,那么你可以象上面那样通过限制连接的个数来绕开。

        安装后运行测试, 初始化一个数据区然后启动服务器,像我们在 Chapter 16 里面描述的那样,然后键入

gmake installcheck

或者是跑一个并行测试

gmake installcheck-parallel

        该测试将与在本地主机和缺省端口号上运行的服务器进行联接, 除非你用PGHOST和PGPORT环境变量设置为其它值。

        有一些正确安装并且具有完整功能的 PostgreSQL可能会在一些回归测试中"失效", 这些主要是因为浮点数的形式和时区支持的问题。 目前的测试只是简单的用 diff 与参考系统的输出进行比较, 因而对一些细小的系统区别很敏感。 当一项测试报告"失败"时,只要检查一下预期和实际的结果, 你就会发现区别并不大。 当然,我们仍然在努力维护所有我们支持的平台的准确的参考文件, 这样我们就可以假定所有测试都通过。

        回归测试的实际输出是在 src/test/regress/results 目录里的文件里。测试脚本使用 diff 以比较每个输出文件和存放在 src/test/regress/expected 目录里的参考输出。任何区别都存放在 src/test/regress/regression.diffs 里面供你检查。(或者如果你愿意的话,你也可以自己运行 diff。)

错误信息差别

        有一些回归测试涉及到有意的非法输入值。 错误信息可能会来自 PostgreSQL 代码或来自主机平台系统过程。 对于后者,信息可能在平台之间区别比较大,但应该反映相似的信息。 这些信息上的差别将会导致一个"失败"的回归测试, 我们可以通过检查文件发现这一点。

区域差别

    

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