黑盒测试脚本应放在项目根目录下新建的blackbox/目录（与src/、tests/并列），需独立于业务代码、配备专用依赖、控制服务生命周期、严格校验响应状态码/头/体结构，并在CI中使用真实服务与数据库确保链路真实。
黑盒测试脚本该放在项目哪个目录？
黑盒测试不依赖源码结构，但必须和项目部署环境对齐。别把 tests/ 放在 src/ 或 app/ 里——它得能独立启动服务、构造请求、验证响应，和业务代码物理隔离。
- 放在项目根目录下新建的
blackbox/目录（与src/、tests/并列），避免被 pytest 自动发现为单元测试 - 确保
blackbox/下有requirements.txt，只装requests、pytest、python-dotenv这类运行时依赖，不装 Flask/Django - 若用 Docker 部署，脚本里访问服务地址写成
<a href="https://www.php.cn/link/fcbb3a1c04ec11f1506563c26ca63774">https://www.php.cn/link/fcbb3a1c04ec11f1506563c26ca63774</a>，而不是<a href="https://www.php.cn/link/faa306dfe19dc222de6991f234ab8c5a">https://www.php.cn/link/faa306dfe19dc222de6991f234ab8c5a</a>—— 黑盒测试进程在容器外跑，DNS 不通
怎么让测试脚本能自动拉起待测服务？
黑盒测试必须控制服务生命周期，否则 CI 里会因端口占用或服务未就绪失败。
- 用
subprocess.Popen启动服务，配合time.sleep(2)不可靠；改用轮询健康检查接口：requests.get("<a href="https://www.php.cn/link/fcbb3a1c04ec11f1506563c26ca63774/health">https://www.php.cn/link/fcbb3a1c04ec11f1506563c26ca63774/health</a>", timeout=1)，最多重试 10 次 - Django 项目用
python manage.py runserver --noreload --nothreading 0.0.0.0:8000，关掉自动重载和多线程，避免 fork 干扰进程管理 - Flask 项目禁用 debug 模式：
app.run(host="0.0.0.0", port=8000, debug=False, use_reloader=False) - 记得在
finally块里调用proc.terminate()+proc.wait()，否则 CI job 结束后残留进程占端口
HTTP 请求断言容易漏掉哪些关键点？
黑盒测试只看输入输出，但状态码、头、响应体结构缺一不可，光比对 JSON 字段会漏掉隐性问题。
- 必须检查
response.status_code，400 和 200 差一个字段验证逻辑，但脚本里不判就等于没测 - 验证
Content-Type头是否为application/json，某些错误路径会返回 HTML 错误页却仍用 200 - JSON 响应用
response.json()解析前先response.raise_for_status()，否则 500 时直接抛异常中断后续断言 - 对分页或时间字段等动态值，别硬比完整 JSON，改用
"id" in resp、isinstance(resp["created_at"], str)这类结构校验
CI 中执行黑盒测试为什么总超时或连不上？
本地能跑 ≠ CI 能跑，网络、并发、资源限制三者叠加最容易出问题。
立即学习“Python免费学习笔记（深入）”；
- GitHub Actions / GitLab CI 默认不暴露 localhost 端口给其他 job，得用
services:启后台容器，或改用docker-compose up -d启服务再跑测试 - 测试并发数设成 1：pytest 的
-n auto在黑盒场景下会导致多个测试争抢同一端口或数据库连接 - 加
--timeout=30参数给 pytest，防止某个请求卡死拖垮整个流程 - 数据库用真实实例（如 PostgreSQL 容器），别 mock —— 黑盒测试的价值就在于验证真实链路，mock 只是自欺欺人
黑盒测试真正的复杂点不在写几个请求，而在于让它稳定复现线上行为：服务启停节奏、网络延迟容忍、脏数据清理，这些细节不显眼，但每次 CI 失败大概率出在这儿。
