Postgresql 自动化测试框架BuildFarm使用说明

一、 概述

BuildFarm是Postgresql数据库推出的一款为其量身定做的功能自动化测试框架，结合pg发布版本中自带的测试sql脚本，用这个框架可自动执行功能测试。

简单说BuildFarm系统分为client部分和server部分，所有的测试过程都在client中完成，server部分则负责测试结果的展示追踪等。经过试验和询问，从本框架官方作者及pg开发专家得到的消息是，目前为止server端只能使用官方提供的环境，也就是说如果你想看由server系统生成出来的web版的测试报告，只能注册一个farm账号，而官方则不提供个人搭建server系统的任何说明文档和技术支持。不过好在client端执行后会有完整的log文件，也会记录执行结果，再通过shell分析log的内容，完成server的一部分内容。

二、 client端的安装

client的安装比较繁琐，官方有一个说明文档，

http://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto

首先里面介绍了安装时需要的一些软件支持，里面的配置内容包括获取被测版本、设置缓存、执行测试方法等内容。

1. 获取测试版本

按照pg的架构，版本控制通过git实现，BuildFarm获取被测版本也从git仓库中获得。由于测试框架需要自动执行，所以获取版本也是写在配置文件里自动执行，此时需要在版本控制的服务器上添加一些内容。

安装了git的服务器，只是提供版本服务，若提供实时连接非验证的版本获取，还要安装git-core，使用时要用到他的组件git-daemon，当然因为没有验证过程，任何人都可以下载内容，在安全性上有一定折扣。

首先，假定当前版本服务器上，git正常安装，并且已经能够提供版本控制服务，目录为：

/home/tester/v8/test_built

（在test_built/文件夹里，有.git目录）

git-core的安装，目前只找到通过yum install git-core的办法，如果找不到，可多尝试几个源。

安装完成之后，切换到目录 /usr/libexec/git-core/ 通过命令执行：

./git-daemon  --verbose  --reuseaddr  --base-path=/home/tester/v8  /home/tester/v8

也可以根据需要，带&进入后台执行，或把这个命令加载在任务计划里。

--verbose：执行过程会显示到屏幕；

--reuseaddr：可以持续等待连接，持续提供下载服务；

--base-path：可以在git时，ip地址后面不必填写完整路径；

注意，此时需要在版本库文件目录（使用git init初始化的那个目录）的.git（隐藏目录）里touch一个名为 git-daemon-export-ok 的文件。

然后，到一个目录里（也可以是装了git的另外一台机器上），执行：

git  clone  git://(版本服务器ip)/test_built

如果可以克隆文件，则说明这部分内容配置完成。

2. 修改配置文件 build-farm.conf

29行：scm => ‘git’

30行：scmrepo => ‘git://(版本服务器ip)/test_built’

31行：scm_url => ‘git://(版本服务器ip)/test_built’

39行：build_root => ‘/home/test/clone_file’ #这个目录是克隆文件复制过来之后的测试目录，需要用户有权限。

45行：aux_path => ‘/home/test/buildfarm/build-farm-4’ #指向buildfarm的系统目录，包含需要执行的脚本文件。

48行：target => ‘’

49行：upgrade_target => ‘’ #48行和49行，是客户端发给server端时，server端的地址，目前只能发给官方提供的地址。

50行：animal

51行：secret #在buildfarm.postgresql.org上注册的用户名和密码。

94行到100行：#配置发送结果给邮件地址的内容，也需要通过server端配合使用。

111行：#缓存地址，需要一个用户有读写权限的目录，占用尺寸参考《客户端使用文档》。

三、 执行postgresql数据库的测试

使用buildfarm执行测试的时候，从git仓库里取来的是未经编译的源码。

1. 运行run__build.pl 或run_branches.pl开始执行测试

./run_build.pl  [ REL9_4_STABLE ] [ --nosend] [ --nostatus ] [ --verbose ] [--keepall] […]

REL9_4_STABLE 获取源码后的目录名，一般使用版本号，默认为HEAD

--nosend 执行完成后不发送报告 （实际测试中不应该设置此参数）

--nostatus 执行完成后不发送结果状态 （实际测试中不应该设置此参数）

--verbose 执行过程中输出到前段信息，默认为1，还可以设置2或者more来显示更多执行过程信息。

run_build.pl每次只能执行一个版本，但可以设置分别执行多个不同版本的执行计划，例如：

6 * * * * cd /home/buildfarm && ./run_build.pl --nosend

30 4 * * * cd /home/buildfarm && ./run_build.pl --nosend REL9_4_STABLE

 

run_branches.pl可以同时执行所有版本，通过设置--run-all参数，并且可以设置执行计划，例如：

6 * * * * cd /home/buildfarm && ./run_branches.pl --run-all

也可以通过在build-farm.conf文件中配置如下部分的参数来控制执行的多个版本：

    $conf{branches_to_build} = 'ALL';       --所有版本   

# qw( HEAD RELx_y_STABLE )  --指定版本，用空格分隔，如HEAD和RELx_y_STABLE

2. 检查执行后的日志

run_build.pl程序执行了获取数据库源码、编译数据库源码、初始化数据库、多次起停数据库进行相关测试、执行测试用例脚本，检查测试结果等操作。所有操作都生成对应的log文件，存放在XXX.lastrun-logs目录下，如下图：

3. Postgresql源码包中包含的测试执行脚本

\postgresql-9.4.0\src\test，如下图：

主要用例都放在regress目录下，其中还包括standby测试；

有data、expected、input、output、sql等目录和parallel_schedule、serial_schedule、standby_schedule等设置测试用例并行、串行执行的文件，如下图：

Sql目录下是测试用例的sql脚本，如下图：

Expected目录下是对应sql脚本的预期结果的.out文件（有些sql脚本生成多个对应的.out文件），如下图：

Input目录下是受操作系统影响的测试用例脚本，比如脚本中包含跟目录相关的变量：

COPY real_city FROM '@abs_srcdir@/data/real_city.data';

 

CREATE FUNCTION widget_in(cstring)

    RETURNS widget

     AS '@libdir@/regress@DLSUFFIX@'

    LANGUAGE C STRICT;

 

脚本文件为.source类型的文件，如下图：

Output目录下是与input目录下.source脚本对应的期望结果，也为.source类型的文件，如下图：

Data目录下是测试中所要用到的表数据的文本，文件类型为.data，如下图：

parallel_schedule文件中可以设置测试用例并行执行：

文件中以test:开头的行，为执行，后面跟着sql目录或input目录下的测试脚本名（不带文件扩展名），可以跟多个用例名，即这些在同一行中的测试用例并行执行。

test：与用例名之间由一个空格分隔，用例名与用例名之间也由一个空格分隔。

每个test：行之间为串行执行。

以ignore:开头的行，为不执行，跳过执行。

以#开头的行为注释行，在不希望执行的test：行前面也可以加#，跳过执行。

每个test：行也可以叫做一个并行组（one parallel group），按照惯例，每个并行组一遍不超过20个用例，这限制了运行测试所需的连接数。

parallel_schedule文件内容如下图：

serial_schedule文件中可以设置测试用例串行执行：

serial_schedule文件与parallel_schedule文件类似，但是只能设置串行执行，每行只能设置一个用例，文件内容如下图：

standby_schedule文件设置了和standby相关的测试用例的执行计划。测试用例脚本和期望结果也分别在sql目录和expected目录下。

注：这些设置执行计划的文件中，最后一行留出一个空行。

 

添加和修改用例：

一般情况下，我们添加的测试用例sql脚本，就放在sql目录下，对应的期望结果.out文件，放在expected目录下。并修改parallel_schedule文件，将添加的测试用例设置并行或串行执行。

修改一个已有的测试用例时，也要修改对应的sql目录下、expected目录下的对应文件和parallel_schedule文件中的对应值。

 

其他目录下的测试内容：

Test目录下除了regress子目录外还有一些其他子目录：

Example目录：包含一些测试程序的，测试大对象、lib等。

isolation目录：包含测试事务隔离相关的测试用例，其中specs子目录下是测试程序脚本，expected子目录下是期望结果，和isolation_schedule文件设置每个测试脚本的执行顺序。

Locale目录：包含一些本地化的测试程序和脚本，以及对应的预期结果。针对例如语言和字符集等的测试。

Mb目录：包含针对多字节字符的测试脚本和期望结果。例如测试中文、日文、韩文字符在数据库中的使用。

Performance目录：包含一些针对数据库性能的测试脚本，例如数据库连接、插入数据、创建索引、排序、vacuum等操作的用时。

Thread目录：测试线程的c程序。

 

每一级目录都有一个makefile文件，用来定义每个目录中程序和脚本的编译顺序和相互之间的依赖关系，还有不同级目录的关系。

三、 server端的安装

官网提供了server部分的代码下载，程序是使用perl脚本编写的一个web系统，

推测建站程序由BuildFarmWeb.pl.skel解决，但官方不提供支持，所以不知道实现的细节问题。

 

至此，所有BuildFarm可配置的部分都已经介绍完成，以后看官方是否提供server的个人搭建，如果提供，再介绍这部分的内容。

对于pg数据库本身，BuildFarm是一个非常好的自动化测试手段，并且集成了丰富的测试脚本，但对于其他数据库，通用性比较小，并且在展示方面仍然受到非常大的限制，这点体验很不好。