ZQPool测试用例

1.测试概述

本测试用例适用于ZQPool产品测试。测试内容主要针对跨机房容灾高可用、数据库读写分离、收敛数据库连接等特性，以便根据实际业务需求对产品进行评估。

2.测试方法

本次测试采用黑盒测试手段进行功能性验证测试。

3.测试环境

3.1硬件环境

硬件类别	配置	数量	备注
ZQPool服务器	CPU：8核内存：16GB 本地硬盘：20GB 网卡：至少一块网卡，建议1000M+。	2台	无

3.2.ZQPool和数据库环境

数据库版本为PostgreSQL11，一主两备数据库集群，其中一主一备在A机房，另一个备库在B机房。
ZQPool1和ZQPool2分别部署在A、B两个机房，每个ZQPool都配置了所有主备数据库实例。

4.测试用例

4.1.测试用例列表

编号	测试用例
ZQ001	同城跨机房容灾高可用切换测试用例-主备切换
ZQ002	同城跨机房容灾高可用切换测试用例-PG数据库发生脑裂
ZQ003	同城跨机房容灾高可用切换测试用例-ZQPool宕机
ZQ004	读写分离测试用例-配置SQL的readonly注释，jdbc关闭autocommit
ZQ005	读写分离测试用例-配置SQL的readonly注释，jdbc开启autocommit
ZQ006	读写分离测试用例-不配置SQL的readonly注释
ZQ007	读写分离测试用例-pgjdbc负载均衡-打开autocommit，添加readonly注释
ZQ008	读写分离测试用例-pgjdbc负载均衡-打开autocommit，不添加readonly注释
ZQ009	读写分离测试用例-pgjdbc负载均衡-关闭autocommit，添加readonly注释
ZQ010	读写分离测试用例-pgjdbc负载均衡-关闭autocommit，不添加readonly注释
ZQ011	数据库连接池测试用例-并发数超过前端连接数限制
ZQ012	数据库连接池测试用例-并发数超过后端读写连接数限制
ZQ013	数据库连接池测试用例-收敛数据库连接数
ZQ014	数据库连接池测试用例-数据库短暂断开，zqpool连接池重连
ZQ015	数据库连接池测试用例-添加了readonly注释的请求并发数大于be_rd_conns
ZQ016	两个应用使用同一个ZQPool，使用不同的连接池
ZQ017	ZQPool接口测试用例-获取连接池状态
ZQ018	ZQPool接口测试用例-获取连接池信息
ZQ019	ZQPool接口测试用例-添加节点
ZQ020	ZQPool接口测试用例-移除节点
ZQ021	ZQPool接口测试用例-修改前端连接信息
ZQ022	ZQPool接口测试用例-修改后端连接信息
ZQ023	ZQPool接口测试用例-添加一个连接池
ZQ024	ZQPool接口测试用例-移除一个连接池
ZQ025	ZQPool接口测试用例-修改连接数

4.2.同城跨机房容灾高可用切换测试用例

4.2.1.主备库切换

测试目标	验证ZQPool在主备数据库实例发生切换时，能否正确感知并自动将应用的新请求路由到最新主库实例上。
前置条件	1.ZQPool已配置连接到所有的主备PG数据库，并成功建立连接池。 2.主数据库和备用数据库均处于正常运行状态，并且已经设置好实时同步或主备切换机制。 3.应用已成功连接至ZQPool并正常发送数据库请求。
测试步骤	1.确保ZQPool正在从主数据库接收并处理来自数据库的请求。 2.模拟数据库出现故障，触发数据库的主备切换。 3.观察ZQPool是否可以感知主备切换，将请求发送到新的主库。 4.在备用数据库升级为主数据库后，模拟多个不同类型和复杂度的数据库请求，包括读写操作，验证请求是否都能正确执行且结果符合预期。
预期结果	1.当数据库发生主备切换后，ZQPool可以正确感知到主备切换，并将来自应用的新的SQL请求发送到主库。 2.备库升级为主库后，写请求能正确执行且结果符合预期。
测试过程	1.将主库从a1切换到a2。 2.使用psql连接zqpool，执行下面语句更新pgbench库的pgbench_accounts表。 UPDATE pgbench_accounts SET abalance=1 WHERE aid=1; 3.更新sql执行成功
测试结果
备注	无

4.2.2.PG数据库发生脑裂

测试目标	验证当数据库发生脑裂时，ZQPool会把请求发送到哪个主库
前置条件	1.两个ZQPool节点都配置了所有的主备库实例。 2.应用程序在jdbc连接串中配置了两个ZQPool的地址。 3.应用与两个ZQPool都正常连接，正常发送请求
测试步骤	1.模拟脑裂的场景，将一个备库提升为主库，这时集群中有两个主库。 2.观察应用发送到ZQPool的SQL请求被发送到了哪个主库。
预期结果	1.当出现脑裂情况时，应用发送的sql写请求会被ZQPool发送到timeline大或lsn大的主库。
测试过程	1.将备库1提升为主库 2.查询两个主库的lsn和timeline，可以看到备库1的timeline和lsn大于主库。 3.使用jdbc发送写请求到ZQPool，观察发现写请求会被发送到timeline或lsn更大的备库1。
测试结果
备注	无

4.2.3.ZQPool宕机

测试目标	验证当ZQPool发生宕机时，当两个ZQPool都配置了所有的数据库实例，jdbc是否会将sql请求发送到另一个ZQPool
前置条件	1.两个ZQPool都配置了全部的数据库实例。 2.应用程序在jdbc连接串中配置了两个ZQPool的地址。 3.应用与两个ZQPool都正常连接，正常发送请求。 4.jdbc配置targetServerType=any
测试步骤	1.使用jdbc持续的向ZQPool发送SQL请求。 2.将ZQPool1程序进程杀掉，模拟宕机情况。 3.观察jdbc会将sql请求发送到哪个ZQPool。 4.重启ZQPool1程序，模拟宕机恢复的情况。 5.观察jdbc会将sql请求发送到哪个ZQPool。
预期结果	1.jdbc在检测到ZQPool1无法正常响应后，将请求发送到ZQPool2。 2.ZQPool1重启后，jdbc在检测到ZQPool1恢复正常，会重新将请求发送到ZQPool1。
测试过程	1.使用jdbc持续的向ZQPool发送SQL请求. 2.将ZQPool1程序杀掉，模拟宕机的情况在将ZQPool1程序杀掉后，jdbc旧的连接会报错然后程序关闭该连接。 3.观察发现jdbc新建立的连接会连接到ZQPool2，后续的SQL请求会发送到ZQPool2。 4.重启ZQPool1程序，模拟宕机恢复的情况。 5.观察发现jdbc会与ZQPool1建立新连接，后续的SQL请求都会发送到ZQPool1。
测试结果
备注	无

4.3.PG数据库读写分离测试用例

4.3.1.配置SQL readonly注释

4.3.1.1.jdbc关闭autocommit

测试目标	验证在jdbc关闭autocommit，sql添加readonly注释的情况下，ZQPool会如何发送读SQL。
前置条件	1.jdbc设置autocommit=false。 2.应用程序正确配置了ZQPool。 3.应用与ZQPool正常连接，可以正常发送请求。 4.数据库状态均正常。
测试步骤	1.将sql添加/readonly/注释后，发送到ZQPool。 2.观察ZQPool会将sql请求发送到哪个数据库。
预期结果	ZQPool会把添加了/readonly/注释的sql请求全部发送到主库
测试过程	1.将添加了/readonly/注释的SQL请求发送到ZQPool ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 1 10000 2.查看数据库发现ZQPool会把请求发送到主库
测试结果
备注	无

4.3.1.2.jdbc开启autocommit

测试目标	验证在jdbc打开autocommit，sql添加readonly注释的情况下，ZQPool会如何发送读SQL。
前置条件	1.jdbc设置autocommit=true。 2.应用程序正确配置了ZQPool。 3.应用与ZQPool正常连接，可以正常发送请求。 4.数据库状态均正常。
测试步骤	1.将sql添加/readonly/注释后，发送到ZQPool。 2.观察ZQPool会将sql请求发送到哪个数据库。
预期结果	ZQPool会把添加了/readonly/注释的sql请求随机发送到ZQPool配置的standby节点。
测试过程	1.将添加了/readonly/注释的SQL请求发送到ZQPool。 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 1 10000 2.查看数据库发现ZQPool会把请求随机的发送到某个备库
测试结果
备注	无

4.3.2.不配置SQL readonly注释

测试目标	验证在sql不添加readonly注释的情况下，ZQPool会如何发送读SQL。
前置条件	1.应用程序正确配置了ZQPool。 2.应用与ZQPool正常连接，可以正常发送请求。 3.数据库状态均正常。 4.jdbc打开autocommit
测试步骤	1.不在sql中添加/readonly/注释，发送到ZQPool。 2.观察ZQPool会将sql请求发送到哪个数据库。
预期结果	1.ZQPool会把没有添加/readonly/注释的sql请求全部发送到主库。
测试过程	1.将没有/readonly/注释的读SQL发送到ZQPool。 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 1 10000 2.观察发现，ZQPool会把该SQL请求全部发送到主库
测试结果
备注	无

4.3.3.pgjdbc负载均衡

4.3.3.1.打开autocommit，添加readonly注释

测试目标	验证在jdbc连接串增加loadBalanceHosts=true&targetServerType=any，打开autocommit，jdbc会把请求发送到哪个ZQPool，是否读写分离
前置条件	1.jdbc中在连接串增加loadBalanceHosts=true&targetServerType=any。 2.jdbc中设置autocommit=true。 3.应用程序正确配置了所有的ZQPool。 5.应用与所有ZQPool均正常连接，可以正常发送请求。数据库状态均正常。
测试步骤	1.多次使用jdbc发送普通的读请求到ZQPool。 2.观察jdbc会将普通的读请求发送到哪个ZQPool。 3.多次使用jdbc发送添加有/readonly/注释的读请求到ZQPool。 4.观察jdbc会将添加有/readonly/注释的读请求发送到哪个ZQPool，观察ZQPool将请求发送到哪个数据库。
预期结果	1.jdbc会将普通的读写请求负载均衡到两个ZQPool。 2.读写分离，添加有/readonly/注释的请求会被ZQPool随机发送到某个备库。
测试过程	1.多次使用jdbc发送不添加/readonly/注释的请求到ZQPool ./zqpool_transaction.sh “jdbc:postgresql://10.197.165.36:5436,10.197.165.37:5436/sundb?loadBalanceHosts=true&targetServerType=any” kuafu chase 10 10000 2.观察发现jdbc会将普通的读请求负载均衡到两个zqpool 3.多次使用jdbc发送添加/readonly/注释的请求到ZQPool ./zqpool_transaction.sh “jdbc:postgresql://10.197.165.36:5436,10.197.165.37:5436/sundb?loadBalanceHosts=true&targetServerType=any” kuafu chase 10 10000 4.观察发现jdbc会将添加了/readonly/注释的请求负载均衡的发送到某个ZQPool，ZQPool会把请求随机的发送到某个备库节点
测试结果
备注	无

4.3.3.2.打开autocommit，不添加readonly注释

测试目标	验证在jdbc连接串增加loadBalanceHosts=true&targetServerType=any，打开autocommit，jdbc会把请求发送到哪个ZQPool，是否读写分离
前置条件	1.jdbc中在连接串增加loadBalanceHosts=true&targetServerType=any 2.jdbc中设置autocommit=true 3.应用程序正确配置了所有的ZQPool 4.应用与所有ZQPool均正常连接，可以正常发送请求。 5.数据库状态均正常。
测试步骤	1.多次使用jdbc发送不添加/readonly/注释的请求到ZQPool。 2.观察jdbc会将不添加/readonly/注释的请求发送到哪个ZQPool，观察ZQPool将请求发送到哪个数据库。
预期结果	1.jdbc会将普通的读写请求负载均衡到两个ZQPool。 2.不添加/readonly/注释的读请求会被ZQPool全部发送到主库。
测试过程	1.多次使用jdbc发送不添加/readonly/注释的读请求到ZQPool。 2.观察jdbc会将不添加/readonly/注释的读请求负载均衡的发送到某个ZQPool，ZQPool会把请求全部发送到主库。
测试结果
备注	无

4.3.3.3.关闭autocommit，添加readonly注释

测试目标	验证在jdbc连接串增加loadBalanceHosts=true&targetServerType=any，关闭autocommit，jdbc会把请求发送到哪个ZQPool，是否读写分离
前置条件	1.jdbc中在连接串增加loadBalanceHosts=true&targetServerType=any 2.jdbc中设置autocommit=true 3.应用程序正确配置了所有的ZQPool 4.应用与所有ZQPool均正常连接，可以正常发送请求。 5.数据库状态均正常。
测试步骤	1.多次使用jdbc发送普通的读写请求到ZQPool。 2.观察jdbc会将普通的读写请求发送到哪个ZQPool。 3.多次使用jdbc发送添加/readonly/注释的请求到ZQPool。 4.观察jdbc会将添加/readonly/注释的读请求发送到哪个ZQPool，观察ZQPool将请求发送到哪个数据库。
预期结果	1.jdbc会将普通的读写请求负载均衡到两个ZQPool。 2.读写不分离，添加/readonly/注释的读请求也会被ZQPool全部发送到主库。
测试过程	1.多次使用jdbc发送普通的读写请求到ZQPool 2.观察jdbc会将普通的读写请求负载均衡到两个ZQPool 3.多次使用jdbc发送添加了/readonly/注释的请求到ZQPool。 4.观察发现jdbc会将添加/readonly/注释的读请求负载均衡的发送到某个ZQPool，ZQPool会将请求全部发送到主库。
测试结果
备注	无

4.3.3.4.关闭autocommit，不添加readonly注释

测试目标	验证在jdbc连接串增加loadBalanceHosts=true&targetServerType=any，关闭autocommit，jdbc会把请求发送到哪个ZQPool，是否读写分离
前置条件	1.jdbc中在连接串增加loadBalanceHosts=true&targetServerType=any 2.jdbc中设置autocommit=true 3.应用程序正确配置了所有的ZQPool 4.应用与所有ZQPool均正常连接，可以正常发送请求。 5.数据库状态均正常。
测试步骤	1.多次使用jdbc发送不添加/readonly/注释的请求到ZQPool。 2.观察jdbc会将不添加/readonly/注释的读请求发送到哪个ZQPool，观察ZQPool将请求发送到哪个数据库。
预期结果	1.jdbc会将普通的读写请求负载均衡到两个ZQPool。 2.读写不分离，不添加/readonly/注释的读请求会被ZQPool全部发送到主库。
测试过程	1.多次使用jdbc发送不添加/readonly/注释的读请求到ZQPool。 2.观察jdbc会将不添加/readonly/注释的读请求负载均衡的发送到某个ZQPool，ZQPool会把请求全部发送到主库。
测试结果
备注

4.4.数据库连接池测试用例

4.4.1.并发数超过前端连接数

测试目标	验证当应用连接到ZQPool的并发数超过ZQPool前端连接数的限制，是否会报错
前置条件	1.工具正确配置了ZQPool 2.数据库状态均正常。 3.ZQPool状态正常
测试步骤	1.设置ZQPool的fe_max_conns参数为100。 2.使用工具尝试与ZQPool建立200个连接。 3.观察在超过前端连接数限制后，新建连接是否会报错
预期结果	1.在达到100个前端连接限制后，新建立的连接都会返回FATAL: sorry, too many clients already的错误
测试过程	1.配置ZQPool的fe_max_conns参数为100。 2.使用jdbc尝试与ZQPool建立200个连接 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 200 10000 3.超过100个连接后，返回FATAL: sorry, too many clients already的错误
测试结果
备注

4.4.2.并发数超过后端读写连接数限制

测试目标	验证当应用连接到ZQPool的并发数超过ZQPool后端读写连接数的限制，是否会报错
前置条件	1.工具正确配置了ZQPool。 2.数据库状态均正常。 3.ZQPool状态正常
测试步骤	1.设置ZQPool的be_rw_conns参数为100，fe_max_conns=200。 2.使用工具尝试与ZQPool建立150个活动连接，每个连接都会向ZQPool发送多个请求。 3.观察在超过后端连接数限制后，新建活动连接是否会报错
预期结果	1.在达到100个后端读写连接限制后，新建立的连接都会返回FATAL: sorry, too many clients already(backend)的错误
测试过程	1.设置ZQPool的be_rw_conns参数为100，fe_max_conns=200。 2.使用jdbc尝试与zqpool建立150个连接 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 150 10000 3.超过100个后端读写连接数限制后，返回FATAL: sorry, too many clients already(backend)的错误
测试结果
备注

4.4.3.收敛数据库连接数

测试目标	验证数据库连接是否收敛
前置条件	1.应用正确配置了ZQPool 2.数据库状态均正常 3.ZQPool状态正常
测试步骤	1.设置ZQPool前端连接数（fe_max_conns）限制为2000，ZQPool后端连接数限制（be_rw_conns=500） 2.与ZQPool建立1000个空闲连接 3.观察数据库的连接数
预期结果	1.数据库主库实例的连接数量为500
测试过程	1.设置ZQPool前端连接数（fe_max_conns）限制为2000，ZQPool后端连接数限制（be_rw_conns=500） 2.使用jdbc与ZQPool建立1000个连接 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 1000 10000 3.查看数据库的实际连接数，可以看到数据库的实际连接数只有500左右。 SELECT COUNT(*) FROM pg_stat_activity;
测试结果
备注	无

4.4.4.数据库短暂断开，连接池重连

测试目标	验证ZQPool和数据库之间发生闪断，ZQPool是否会重连
前置条件	1.jdbc正确配置了ZQPool 2.jdbc与ZQPool可以建立正常的连接 3.数据库状态正常 4.ZQPool状态正常
测试步骤	1.使用jdbc向ZQPool发送sql请求 2.观察请求是否可以被正常执行 3.将ZQPool连接的主数据库重启，模拟中断的情况 4.数据库重启成功后，再次使用jdbc向ZQPool发送sql请求 5.观察请求是否执行成功
预期结果	1.在数据库重启后，再次使用jdbc向ZQPool发送sql请求，请求在短时间内无法执行成功，会报An I/O error occurred while sending to the backend.错误。 2.等待ZQPool重新刷新后端连接池后，写请求执行成功。
测试过程	1.使用jdbc向ZQPool发送写sql，写测试数据 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 10 1 2.请求可以被正常执行，数据库可以查到刚刚插入的数据 3.重启主库 4.立刻使用jdbc向ZQPool发送写SQL请求，请求执行失败 5.等待一会，当ZQPool重新刷新后端连接池后，请求执行成功。
测试结果
备注	无

4.4.5.添加了readonly注释的请求并发数大于be_rd_conns

测试目标	验证当应用连接到ZQPool，发送只带readonly注释的请求的并发数大于be_rd_conns时是否报错。
前置条件	1.工具正确配置了ZQPool，仅配置了一个ZQPool 2.数据库状态均正常。 3.ZQPool状态正常
测试步骤	1.设置ZQPool中两个备库的be_rd_conns参数为10。 2.发起30个带有/readonly/注释的并发 3.观察超过102=20个并发连接的限制后是否报错 4.发起15个带有/readonly/注释的并发 5.观察超过10个限制，但是小于102=20个总限制后是否报错
预期结果	1.在超过20个后端并发读连接限制后报错
测试过程	1.设置ZQPool中的be_rd_conns参数为10 2.使用jdbc与ZQPool建立30个带有/readonly/注释的连接 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 30 10000 3.可以观察到，有10个连接报错FATAL: sorry, too many clients already (backend) 4.使用jdbc与ZQPool建立15个带有/readonly/注释的连接 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 15 10000 5.可以观察到，连接不报错正常执行
测试结果
备注	无

4.4.6.两个应用使用同一个ZQPool，使用不同连接池

测试目标	验证两个应用使用同一个ZQPool，但使用不同的连接池，是否会互相影响
前置条件	1.ZQPool配置了两个连接池 2.两个应用分别配置了同一个ZQPool的不同连接池 3.数据库状态正常 4.ZQPool状态正常
测试步骤	1.将ZQPool中两个连接池的be_rw_conns参数均设为20。 2.两个应用分别发起15个并发写连接观察连接是否会报错
预期结果	1.连接不会报错，请求返回正确结果
测试过程	1.在ZQPool中两个连接池的be_rw_conns均设为20。 2.使用jdbc同时连接ZQPool的两个连接池，和每个连接池建立15个连接 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu chase 15 10000 ./dfq_transaction.sh jdbc:postgresql://10.197.165.36:5436/sundb kuafu1 chase 15 10000 3.可以看到，虽然应用连接到ZQPool的总连接数为30，但每个连接池是单独计算，互不影响，所以每个连接池连接15个连接时（小于连接池20个后端连接的限制）不会报错。
测试结果
备注	无

4.5.ZQPool接口测试用例

4.5.1.获取连接池状态

测试目标	验证是否可以通过接口获取连接池状态
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP
测试步骤	1.使用api工具访问ZQPool获取连接池状态接口 2.观察接口是否调用成功并返回正确的结果
预期结果	1.接口调用成功并返回正确的连接池状态
测试过程	1.使用API工具访问ZQPool获取连接池状态接口 2.接口调用成功，返回了对应的连接池状态信息
测试结果
备注	无

4.5.2.获取连接池信息

测试目标	验证是否可以通过接口获取连接池状态
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP
测试步骤	1.使用api工具访问ZQPool的获取连接池信息接口 2.观察接口是否调用成功并返回正确的结果
预期结果	1.接口调用成功并返回正确的连接池信息
测试过程	1.使用api工具访问ZQPool的获取连接池信息接口 2.接口调用成功，返回了连接池信息
测试结果
备注	无

4.5.3.添加节点

测试目标	验证是否可以通过接口添加节点到连接池
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP
测试步骤	1.使用api工具访问ZQPool的添加节点接口 2.观察接口是否调用成功并返回正确的结果 3.查询连接池信息，查看后端数据库节点是否被添加到连接池
预期结果	1.接口调用成功并成功添加节点到连接池。
测试过程	1.使用api工具访问ZQPool的添加节点接口 2.接口调用成功 3.查询连接池信息，后端节点已经添加到连接池
测试结果
备注	无

4.5.4.移除节点

测试目标	验证是否可以通过接口移除连接池中的某个节点
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP
测试步骤	1.使用api工具访问ZQPool的移除节点接口 2.观察接口是否调用成功并返回正确的结果 3.查询连接池信息，查看后端数据库节点是否被添加到连接池
预期结果	1.接口调用成功并成功的移除连接池中的某个节点
测试过程	1.使用api工具访问ZQPool的移除节点接口 2.接口调用成功 3.查询连接池信息，后端节点已经成功从连接池移除
测试结果
备注	无

4.5.5.修改前端连接信息

测试目标	验证是否可以通过接口修改连接池的前端连接信息
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP
测试步骤	1.使用api工具访问ZQPool的修改前端连接信息接口 2.观察接口是否调用成功并返回正确的结果
预期结果	1.接口调用成功并成功的修改连接池的前端连接信息
测试过程	1.使用api工具访问ZQPool的修改前端连接信息接口 2.接口调用成功 3.查询连接池信息，前端连接信息已经被正确修改
测试结果
备注	无

4.5.6.修改后端连接信息

测试目标	验证是否可以通过接口修改连接池的后端连接信息
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP
测试步骤	1.使用api工具访问ZQPool的修改后端连接信息接口 2.观察接口是否调用成功并返回正确的结果
预期结果	1.接口调用成功并成功修改连接池的后端连接信息
测试过程	1.使用api工具访问ZQPool的修改后端连接信息接口 2.接口调用成功 3.查询连接池信息，后端连接信息已经被正确修改
测试结果
备注	无

4.5.8.移除一个连接池

测试目标	验证是否可以通过接口添加一个连接池到ZQPool
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP
测试步骤	1.使用api工具访问ZQPool的添加连接池接口 2.观察接口是否调用成功并返回正确的结果
预期结果	1.接口调用成功并成功添加一个连接池到ZQPool
测试过程	1.修改配置文件，增加一个连接池配置 2.使用api工具访问ZQPool的添加连接池接口 3.接口调用成功 4.查询连接池信息，新的连接池已经添加成功
测试结果
备注

4.5.8.移除一个连接池

测试目标	验证是否可以通过接口移除一个连接池
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP
测试步骤	1.使用api工具访问ZQPool的移除连接池接口 2.观察接口是否调用成功并返回正确的结果
预期结果	1.接口调用成功并成功从ZQPool中移除一个连接池
测试过程	1.使用api工具访问ZQPool的移除连接池接口 2.接口调用成功 3.查询连接池信息，该连接池已经被成功移除
测试结果
备注	无

4.5.9.修改连接数

测试目标	验证是否可以通过接口修改连接池前后端连接数配置
前置条件	1.ZQPool状态正常。 2.防火墙放通对应端口和IP 3.已经通过查询获取连接池信息接口获取了前后端连接数信息
测试步骤	1.调用接口，传入pool_name和fe_max_conns参数来修改前端连接数，将fe_max_conns设置成小于当前实际前端连接数量的值。 2.观察接口是否调用成功，使用jdbc发送新的连接到ZQPool，使总前端连接数量大于新的fe_max_conns，观察是否报错。 3.调用接口，传入pool_name和be_rw_conns参数来修改后端读写连接数限制，将be_rw_conns设置成大于当前实际后端读写连接数量的值。 4.观察接口是否调用成功，使用jdbc发送新的读写连接到ZQPool，使总读写连接数大于旧的be_rw_conns限制，小于新的be_rw_conns，观察是否报错。 5.调用接口，传入pool_name和be_rd_conns参数来修改后端只读连接数限制，将be_rd_conns设置成大于当前实际后端只读连接数量的值。 6.观察接口是否调用成功，使用jdbc发送新的添加了readonly注释的请求连接到ZQPool，使总只读连接数大于旧的be_rd_conns，小于新的be_rd_conns，观察是否报错。
预期结果	1.修改前端连接数限制小于当前实际前端连接数后，建立新的前端连接会报错 2.修改后端读写连接数限制后，建立的读写连接数可以超过旧的后端读写连接数限制 3.修改后端只读连接数限制后，建立的添加了readonly注释的连接数可以超过旧的后端只读连接数限制，不会报错。
测试过程	1.调用接口，传入pool_name和fe_max_conns参数来修改前端连接数，将fe_max_conns设置成小于当前实际前端连接数量的值。 2.接口调用成功 3.观察发现，使用jdbc发送新的连接到ZQPool,使总前端连接数量大于新的fe_max_conns,超过数量的连接会报错 4.调用接口，传入pool_name和be_rw_conns参数来修改后端读写连接数限制，将be_rw_conns设置成大于当前实际后端读写连接数量的值。 5.接口调用成功 6.观察发现，使用jdbc发送新的读写连接到ZQPool，使总读写连接数大于旧的be_rw_conns限制，小于新的be_rw_conns不会报错 7.调用接口，传入pool_name和be_rd_conns参数来修改后端只读连接数限制，将be_rd_conns设置成大于当前实际后端只读连接数量的值。8.接口调用成功 9.观察发现，使用jdbc发送新的添加了readonly注释的请求连接到ZQPool，使总只读连接数大于旧的be_rd_conns，小于新的be_rd_conns，不会报错。
测试结果
备注	无