在软件研发流程中，测试是研发质量保障的一个重要环节。测试效率受环境稳定性和测试数据完整性两大因素的影响。尤其测试环境的可用性、稳定性，是软件测试工作连续性的一个重要前提。

今日和大家分享在测试环境治理中的实践经验，希望对大家有所启发。

    当前软件系统架构以分布式为主，主要由前端展示、应用服务、中间件及数据库等组成。实际的测试过程中各组成部分均容易引入环境问题，导致测试服务不可用，其中以应用服务和数据库为主。测试环境因重要性不如生产，发生故障不可用后不影响实际生产业务运行，结合成本角度考虑资源分配一般较少，受重视程度远不如生产环境。大企业中常见测试环境资源来自于正式环境淘汰的服务器资源。

    本文从前端页面展示、关系型数据库、中间件、数据库等，简述工作中常用的环境治理思路和方法。希望从此大家的软件项目中再也听不到环境有问题、测试“等米下锅”的声音了。

日常项目质量保障工作中常见的环境问题实例及具体解决方案如下：

一、应用服务层

1.服务未启动

微服务swagger接口调用报错，应用服务日志一般会有日志输出。或者某一套系统功能直接完全不可用。可通过服务error级别日志输出直观排查。一般服务未启动或者服务异常可通过重启服务解决。

查看Java进程命令：ps -ef | grep java

2.服务器磁盘（含NAS盘挂载）爆满已无可用空间。

这一类问题常见于报表类、文件类的服务，某一段测试时间周期内若经常性测试报表产出正确性、跑批文件生成正确性，则随测试频次的增加，服务器上文件不经常清理则容易出现。

解决方法：常用du、df、fdisk命令查看服务器磁盘使用率情况。

示例：

du命令用于检查文件和目录的磁盘使用情况。

基本用法：du -sh [目录或文件]

-s选项表示汇总每个参数的大小

-h选项表示以易读的格式显示大小

二、数据库

Ø关系型数据库

• 最为常见的情况为数据库表空间不足。其现象通常表现为插入数据操作失败，以及应用层在连接数据库执行数据操作语言（DML）语句时出现失败。

原因：测试执行过程不断的构造数据，并进行交易验证，随数据量的增加，表空间使用率不断增长，最终大致表空间资源不足。

以MySQL为例，可以通过表空间查看当前数据库中各表空间的使用率情况，并根据表空间情况Truncate对应的表数据，以释放表空间。该原理适用于所有关系型数据库，只需根据不同的数据库产品调整SQL语句即可。

SELECT

table_schema AS ‘Database’,

table_name AS ‘Table’,

ROUND(((data_length + index_length) / 1024 / 1024), 2) AS ‘Size (MB)’,

ROUND((data_free / 1024 / 1024), 2) AS ‘Free (MB)’,

ROUND(((data_length + index_length) / 1024 / 1024) – (data_free / 1024 / 1024), 2) AS ‘Used (MB)’,

ROUND((((data_length + index_length) / 1024 / 1024) – (data_free / 1024 / 1024)) / ((data_length + index_length) / 1024 / 1024) * 100, 2) AS ‘Table_space_utilization (%)’

FROM

information_schema.tables

ORDER BY

`Table_space_utilization (%)` DESC;

解决方案：可通过自动化解决方案每天进行表空间使用率监控，若超过90%，则配置对应的可Truncate的表清单（TRUNCATE [TABLE] 表名

），以业务日志表为主，即，无任何业务含义且不影响测试流程、日常生成大量数据的表。

• 还有一种情况：表被锁导致新数据无法进行DML操作。

ØRedis数据库（key-value键值数据库）

Redis支持存储的value类型相对更多，具有极致的高性能，功能丰富易于集成且开源免费，当前使用场景非常广泛。

测试过程中也会产生大量无效或过期的key-value键值。看完上面关系型数据库的环境治理方法，相信你已经想到了自动清理的方法。

自动清理实现方法步骤如下：

１.使用Redis支持的Python语言，通过编写Python脚本连接Redis库并结合系统时间判断需要删除的时间范围和key清单，一般进行通配符设置。

２.引入相关库from redis import StrictRedis ,Sentinel

３.获取当前系统时间

４.配置redis全量服务器的IP地址、用户名和密码等信息

５.将所有主服务器定义在删除列表中，测试环境一般是删除时间30天前的，可根据实际情况调整

６.定义要删除的key定义列表，比如key_list=[“RISK_{}*”,”RSK_{}*”,”DESCI_{}*”]

７.将发送完成的Key清单形式写入txt，统计并记录删除的key总数。

８.发送删除成功的邮件

删除Redis命令：DEL key

如上的操作，也是为了抵抗熵增定律带来的影响。

三、消息中间件（Message Broker）－

RabbitMQ

    其核心作用是作为“消息中转站”，实现生产者与消费者之间的异步通信。主要作用有：解耦、冗余存储、拓展性、削峰、可恢复性、顺序保证（先进先出）、缓冲、异步通信。

高频问题发生概率：

1. 节点崩溃时，消费者和生产者超时失败。
2. RabbitMQ中的私有消息，如Topic过滤，导致消息无法正确传递。
3. 当多个节点发送消息时，因网络失败而无法正确传递消息。
4. 消息exchange设置问题，导致无法传递消息。
5. 队列设置问题，导致消息积压，而消息无法正常消费。
6. 由于网络问题或者RabbitMQ节点不可用，导致连接工厂在一定时间内无法被创建或者被重置。
7. RabbitMQ节点中断时，消息可能发送延迟或丢失。

测试环境使用的MQ具有历史数据积累特性，对于使用MQ消息队列处理长审批流的系统，极易发生MQ使用率过高的情况，因此同样需要定期的自动化清理手段，以保障测试工作的连续性，减少测试等待。

MQ自动化理清思路及步骤：

1. 连接MQ后端管理URL页面，输入用户名和密码，进入MQ后端管理页面
2. 基于UI自动化进行元素识别及点击home按钮xpath
3. 获取MQ使用率
4. 跳转Queues队列菜单
5. 点击Number of Pending Messages排序
6. 删除MQ使用。
7. 定义URL归属的对应环境，如SIT1，MQ环境地址，清理前MQ使用率，清理后MQ使用率
8. 将其写入excel表格

环境	MQ地址	清理前使用率	清理后使用率
SIT1	http://xxx	95%	30%

９.调用企业邮箱服务协议及发送用户邮件地址，进行清理前后的使用率情况说明。

若登录MQ服务器也可以通过命令行删除数据：rabbitmqadmin delete queue name=

四、ES可用性维护（Elasticsearch搜索引擎）

读到这里，你大概已经掌握了环境治理的方法了。就是按照时间或者使用率对ES存储进行清理。思路和步骤如下：

1. 连接ES服务器：IP地址和端口、用户名和密码。
2. 定义系统日期：sysdate，ES服务文件进行年、月、日的标准格式化。
3. 定义cleanDate，要删除的日期
4. 对于cleandate和sysdate对比，判断需要删除的Index清单
5. 清理后的index清单汇总后写入附件
6. 发送清理结果至干系人邮箱。

测试工作中批量进行Index通配符删除：curl -X DELETE “http://localhost:9200/logs-*”

同样，若读者对Linux命令比较熟悉，同样的可以编写Shell脚本进行定时清理。

五、前后端交互或页面展示问题

这一类是网站类系统比较简单和常见的问题，对环境问题的分析及解决要求也较低，比如：前端访问后端接口服务时出现400、404问题，这种解决方案可自查HTTP协议即可。软件开发过程中最常用的状态码精简如下：

对HTTP状态码有兴趣的可以在互联网检索完整的类型分类和详细清单。若纯粹页面无法展示则可能为前端VUE代码包部署错误或前端页面开发本身存在缺陷。

• 对于测试环境治理，最重要的是在日常测试工作中，是否能第一时间想到环境治理的临时解决方法、终极解决方法，是否能够判断适合业务系统最科学合理的清理规则。

 持续稳定的、高可用的测试环境可为企业软件研发效能的提升提供较大助力，需要测试人员更灵活快速地制定最合适的环境治理策略，辅助测试质量保障及研发效能提升，保障技术承载的业务发展、成熟和持续增长。