测试平台搭建

去年秋天，测试我接手了一个支付网关的平台测试项目，团队只有三个人。搭建第一周就撞上问题：每次回归测试，测试光是平台环境配置就要耗掉大半天。有人手动改数据库连接串，搭建有人忘了切分支，测试跑出来的平台失败结果一半是环境导致的假阳性。那会儿我就下定决心，搭建得把测试平台搭起来，测试不然人全耗在重复劳动上。平台

搭建测试平台，搭建第一件事不是测试选技术栈，而是平台搞清楚“谁用、怎么用”。搭建我们当时列了个清单：开发要能自助触发冒烟测试，QA要能定时跑全量回归，运维要能看到测试环境健康状态。这三类需求指向同一个底层能力——环境隔离和任务调度。于是我们放弃了最初想用Jenkins一把梭的想法，转而把平台拆成三层：资源层管容器和数据库快照，调度层管任务队列和触发规则，展示层只做结果呈现和简单操作。

资源层我们选了Docker Compose而不是Kubernetes。原因很直接：团队没人熟悉K8s，而测试环境对高可用要求不高，能快速启停、快照恢复就够了。每个测试任务启动时，平台会从预置的镜像仓库拉取对应版本的服务镜像，再用一个干净的数据库快照初始化数据。这里有个细节：快照不是全量备份，而是只包含基础表结构和少量基准数据，测试用例自己负责造数。这么做的好处是启动速度快，从原来的8分钟压到40秒左右。

调度层用Celery加Redis。任务触发方式有三种：GitLab的webhook、平台界面上的手动按钮、以及定时任务。webhook是最常用的，开发推代码后自动触发对应分支的冒烟测试。这里踩过一个坑：Celery的默认并发模型是prefork，跑测试任务时如果用例里有阻塞IO，worker会卡住。后来改成gevent池，并发数调到20，才稳定下来。任务结果会写入一个专门的数据库表，包含用例名、状态、耗时、日志链接。日志直接存文件系统，数据库里只存路径，避免大字段拖慢查询。

展示层最初想用Vue写个完整前端，后来发现没必要。我们用Flask加Bootstrap搭了个极简页面，核心就三个视图：任务列表、任务详情、环境状态。任务详情里可以点“重跑失败用例”，这个功能使用频率最高。环境状态页会显示每个容器实例的CPU和内存占用，超过阈值就标红。有次一个测试任务把内存吃满，导致同宿主机的其他环境卡死，从那以后我们加了资源配额限制。

平台上线三个月后，回归测试的平均耗时从原来的两个半小时降到五十分钟。但真正省下的不是机器时间，是人的注意力。以前每次发版前，QA要花半天确认环境，现在点一下按钮就行。开发也愿意在提MR前跑一遍冒烟，因为反馈够快。有次一个开发跟我说，他本来只想改一行日志格式，结果冒烟测试报了个数据库连接泄漏，顺手就修了。这种意外收获，比平台本身的功能更有价值。

当然，平台不是银弹。我们至今没做测试用例的智能推荐，也没接代码覆盖率分析。不是不想，是优先级排不上。三个人维护一个平台，能跑通核心流程、让日常测试不卡壳，已经够用了。下一步打算把环境快照做成按需生成，而不是预置几个固定版本。但那是明年的事了，眼下先把手头的用例迁移完再说。