内部工具
上传需求文档或原型目录，自动生成测试用例 JSON 和 XMind。
2022年10月记录，分类「服务器运维」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
这次接口超时一开始被怀疑是应用线程池不够，后来从慢日志看到某个列表查询扫描了几十万行。问题不复杂，但定位顺序很典型。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
EXPLAIN SELECT * FROM orders WHERE use2022年9月记录，分类「Docker」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。
容器网络问题经常表现成接口超时或数据库连不上。那次我遇到的是容器内能 ping 通 IP，但服务名解析失败，最后定位到 compose 网络和容器重建顺序不一致。
我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。
d2022年8月记录，分类「自动化测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
Page Object 很容易被写成另一种面条代码：所有元素和所有动作都塞进一个类，最后比裸 Selenium 还难读。我后来更关注页面对象到底有没有表达业务动作。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
class OrderPa2022年7月记录，分类「Linux」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
服务器问题不能靠感觉猜。这篇是我整理的一套基础排障顺序，适合页面打不开、接口超时、服务重启失败这类场景。
整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。
ss -lntp
df -h
free -m
journalctl -u ngin2022年6月记录，分类「JMeter」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
这篇不是讲 JMeter 菜单怎么点，而是整理三个最影响压测可信度的小问题：参数化、断言和关联。任何一个没处理好，TPS 都可能是假的。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
线程数: 50 -> 100 ->2022年5月记录，分类「Docker」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
这篇记录的是把 Django、MySQL、Nginx、Redis 这类依赖拉到一份 compose 里的过程。目标不是追求生产级复杂度，而是让测试环境能快速重建。
对测试来说，最后要落到可复现、可验证、可交接，文章也是按这个思路写的。
docke2022年4月记录，分类「postman」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。
Postman 很适合联调，但变量乱了也很容易把人带坑里。我整理这篇，是为了让集合可以在本地、测试环境、预发环境之间稳定切换。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
pm.environment.s2022年3月记录，分类「pytest」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
fixture 写不好，自动化会越来越像一团共享状态。这篇记录的是我把登录、造数、清理和环境配置拆开后的做法，重点是让单条用例可以独立运行。
我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。
@py2022年2月记录，分类「接口测试」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
最开始我写接口脚本就是 requests.get/post 到处飞，能跑，但维护很痛。接口多了以后，鉴权、超时、日志、重试、断言都重复，所以我把它收敛成一个小客户端。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
2022年1月记录，分类「Git」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
这篇是一次提测混乱后的整理。那次多个需求共用测试环境，分支被来回合并，最后谁的代码进了环境都说不清，所以我把提测、验证、回滚做成了固定动作。
整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。
git log --oneline --