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

概述一、 概述 BuildFarm是Postgresql数据库推出的一款为其量身定做的功能自动化测试框架，结合pg发布版本中自带的测试sql脚本，用这个框架可自动执行功能测试。 简单说BuildFarm系统分为client部分和server部分，所有的测试过程都在client中完成，server部分则负责测试结果的展示追踪等。经过试验和询问，从本框架官方作者及pg开发专家得到的消息是，目前为止serv 一、概述

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的安装，目前只找到通过yuminstallgit-core的办法，如果找不到，可多尝试几个源。

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

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

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

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

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

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

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

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

gitclonegit://(版本服务器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

304***cd/home/buildfarm&&./run_build.pl--nosendREL9_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(headRELx_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目录下是受 *** 作系统影响的测试用例脚本，比如脚本中包含跟目录相关的变量：

copYreal_cityFROM'@abs_srcdir@/data/real_city.data';

CREATEFUNCTIONWidget_in(cstring)

RETURNSWidget

AS'@libdir@/regress@DLSUFFIX@'

LANGUAGECSTRICT;

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

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

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

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

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

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

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

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

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

每个test：行也可以叫做一个并行组（oneparallelgroup），按照惯例，每个并行组一遍不超过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是一个非常好的自动化测试手段，并且集成了丰富的测试脚本，但对于其他数据库，通用性比较小，并且在展示方面仍然受到非常大的限制，这点体验很不好。

总结

以上是内存溢出为你收集整理的Postgresql 自动化测试框架BuildFarm使用说明全部内容，希望文章能够帮你解决Postgresql 自动化测试框架BuildFarm使用说明所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。