opengauss 的回归测试

目录

一、回归测试说明

二、单独执行测试用例（开发调试）

---

一、回归测试说明

opengauss/postgresql 的回归测试，通过执行SQL比较输出打印，判断代码修改是否改变了其它功能逻辑。

OG的回归测试大体上和PG类似，主要是通过pg_regress执行，这是个C语言编写的可执行程序。它执行的测试流程是：安装、初始化、启动数据库实例，用gsql/psql连接，跑测试脚本，比较测试结果（调用smartmatch.pl），这是工作全部是pg_regress做的。和我以前接触的trafodion相比，pg_regress做了许多应该是脚本做的事情。

测试相关的可执行文件，Makefile、测试用例，都在源码目录 openGauss-server/src/test/regress 下面。可以在这个目录下单独编译和触发测试，例如：

make

make fastcheck_single

典型的运行回归测试的方法是，在regress目录下执行

make fastcheck_single

它会调用GNUMakefile里的 fastcheck_single 目标下的命令，可以先执行

make -n fastcheck_single

 看一下它都做了些什么操作。

这种方式调用pg_regress会做下面的工作：

1、将版本安装到 tmp_check目录下（make install DESTDIR=）。

2、初始化（gs_initdb）。

3、启动opengauss服务器。

4、调用gsql连接服务器跑测试用例。

5、比较expected目录下的out文件和对应的results目录下的out文件，会用到smartmatch.pl脚本，用来处理一些模糊匹配，如系统时间导致expected和results不同，会屏蔽掉。例如下面的差异部分，经过smartmatch.pl处理后pg_regress会认为相同。

 实际上包含 --?.* 的一整行都会被忽略掉，不会比较。

pg_regress 内部调用gsql 跑sql脚本，这些sql脚本就是测试用例，在openGauss-server/src/test/regress/sql目录下。

在openGauss-server/src/test/regress/expected目录下，是以前跑完脚本后，“正确”的结果。

在openGauss-server/src/test/regress/results目录下，是本次跑完脚本的结果，比较expected和results下对应的文本文件，相同则认为测试用例通过。

pg_regress 并不直接输入sql目录下的脚本，而是以regress目录下的parallel_scheduleXX或者serial_schedule作为输入，它们是文本文件，格式如下：

# test: large_sequence

test: create_schema
test: auto_analyze_test
test: display_leading_zero datefunc_compatibility
test: a_outerjoin_conversion
test: triggers_traverse
test: sequence_new
test: synonym

其实这是个批处理文件，告诉pg_regress去调用sql目录下的哪些sql文件，这些sql文件就是测试用例，例如，test: create_schema表示pg_regress会调用sql目录下的create_schema.sql，# 号表示注释，从名称来看，pg_regress可以并行执行脚本。

parallel_scheduleXX文件名通过pg_regress的命令行参数--schedule传入，

如果想增加测试用例，可以在sql目录下已有的脚本里增加，也可以在sql目录下新增一个脚本，如果是新增，例如my_test_case.sql，还需在parallel_scheduleXX增加形如：

 test: my_test_case.sql

sql目录下的sql脚本，格式与普通的sql脚本相同。

make fastcheck_single 会执行parallel_schedule0的里的测试，这也是gitee上合入前的看护测试。

也可以自定义批处理文件通过--schedule传给pg_regress。

回归测试的调用流程：

make fastcheck_single --> pg_regress --> gsql 

                                                              --> diff，smartmatch

regress目录下的GNUmakefile可以看到 fastcheck_xx 的定义，从而可以看到pg_regress命令行的使用，opengauss的对pg_regress做了修改，但是文档说明没有跟上，导致很难用。

二、单独执行测试用例（开发调试）

如果我想连接已有的opengauss实例，执行回归测试怎么办呢？（特别是有时我只想跑一个测试用例，而且要不断反馈不断修改。）

经过多次测试，我摸索出一套方法：

1、设置环境变量，例如

export GAUSSHOME=/mnt/disk01/OpenGauss/debug-opengauss-server
export PATH=$GAUSSHOME/bin:$PATH
export LD_LIBRARY_PATH=$GAUSSHOME/lib:$LD_LIBRARY_PATH

就是运行的opengauss实例的根目录设为GAUSSHOME，bin目录加到PATH，lib目录加到LD_LIBRARY_PATH。

2、使用下面参数直接调用pg_regress（到regress目录下调用）

./pg_regress --inputdir=. --top-builddir=../../..  -d 1 -c 0 -p 5432 -r 1 --single_node --schedule=my_seq_test --regconf=regress.conf

--inputdir 设为当前目录。

--top-builddir 是opengauss源码根目录。

-d 在pg_regress的帮助里没有，是datanode的个数，单节点就设为1。

-c 在pg_regress的帮助里没有，coordnode个数，单节点就设为0。

-p opengauss服务实例的端口号。

-r  2表示只安装数据库不运行，1表示安装运行数据库，并且跑回归测试，0表示安装并运行数据库，但是不跑回归测试，这里设为1

--single_node 表示单节点。

--schedule 指定一个文本文件，里面是test: xxx的格式，指定了测试用例脚本名，对应sql目录下的xxx.sql。

--regconf 是给pg_regress用的配置文件，我对regress目录下的regress.conf做了一点修改：performance_data_printing = off 否则会打印一些错误信息。

3、当出错时可以手动比较results和expected，例如：

vimdiff expected/large_sequence.out results/large_sequence.out

4、pg_regress内部掉用gsql的命令格式为：

gsql -X -p 5432 -a -q -d regression -C < sql/large_sequence.sql > results/large_sequence.out  2>&1

也可以自己直接调用，跑出结果文件和expected比较。

vimdiff expected/large_sequence.out results/large_sequence.out

参考：

pull request关联issue

Pull Request 关联 Issue - Gitee.com

commit 关联 issue

Commit 关联 Issue - Gitee.com

opengauss社区命令 

contributors/command.md · openGauss/community - Gitee.com