https://blog.csdn.net/mingli_a/article/details/42642311
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是一个非常好的自动化测试手段,并且集成了丰富的测试脚本,但对于其他数据库,通用性比较小,并且在展示方面仍然受到非常大的限制,这点体验很不好。