内部工具
上传需求文档或原型目录，自动生成测试用例 JSON 和 XMind。
2025年12月记录，分类「测试工具」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
质量度量不是为了年底汇报好看，而是找出下一年要重点改进的模块和流程。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
缺陷逃逸率 = 线上缺陷数 / 总缺陷数
自动化有效率 = 有稳定执行记录的用例 / 自动化用例总数
2025年11月记录，分类「性能测试」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。
网关限流测试要确认两个问题：该拦的流量能拦住，正常用户不会被误伤。
整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。
seq 1 200 | xargs -n1 -P50 -I{} curl -s -o /dev/null -w '%{http_code}\n' https://api.2025年10月记录，分类「AI测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
Prompt 改一个词，模型输出可能就变。把提示词当代码管理，至少要有版本、评审、回归和回滚。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
prompt版本: refund-v6
变更: 增加拒答边界
回归集: 120条客服问答 + 30条注入样本
2025年9月记录，分类「服务器运维」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
备份文件存在不代表能恢复。测试环境也应该做恢复演练，尤其是字符集、表数量、关键数据这些容易被忽略。
对测试来说，最后要落到可复现、可验证、可交接，文章也是按这个思路写的。
mysqldump --default-character-set=utf8mb4 djangoblog > back2025年8月记录，分类「接口测试」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
异步任务不能只看接口返回已提交。真正要验证的是任务入队、执行、失败重试、状态回写和重复提交。
记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。
result = app.send_task('tasks.sync_order', args=[order_id])
assert wait_2025年7月记录，分类「移动端逆向」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。
移动端抓包失败不一定是工具问题，可能是证书未信任、代理没生效、系统版本限制、应用做了证书校验。
我更关注它在真实提测流程里怎么落地，而不是单独演示一个命令或脚本。
手机代理 -> 电脑IP:端口
系统证书信任 -> 浏览器验证
App请求 -> 判断是否证书校验失败
2025年6月记录，分类「Web逆向」。这里不追求大而全，主要记录一个测试点从发现到落地的过程。
Web 侧排查接口签名问题时，Source Map 可以帮助理解前端参数拼装逻辑，但前提是只在授权项目里做分析。
这类问题如果只写结论，过一段时间就很难复用，所以我把判断依据也留了下来。
检查项:
- 生产包是否暴露 .map
- 签名逻辑是否泄露敏感常量
- 构建配置是否关闭 sourcemap
2025年5月记录，分类「安全测试」。这篇更像工作笔记，记录的是一次问题拆解和复用清单。
供应链安全不是扫描一下就结束。测试侧要关注依赖来源、漏洞等级、是否可利用、升级后兼容性。
整理时我特意把输入、动作、观察点和风险拆开，方便后面补用例。
syft packages docker:app:latest -o cyclonedx-json > sbom.json
grype sbom:sbom.js2025年4月记录，分类「性能测试」。内容按测试执行视角整理，尽量把背景、操作和验收口径讲清楚。
容量模型要从业务量推出来，而不是先定一个好看的 TPS。用户数、峰值系数、操作占比、数据量都会影响结论。
我当时想确认的不是工具能不能跑，而是这个点能不能稳定地变成测试资产。
峰值QPS = 日订单量 * 峰值系数 / 峰值秒数
目标容量 = 峰值QPS * 安全系数1.5
2025年3月记录，分类「持续集成」。这是一篇偏实战的记录，保留了当时的判断过程和后续沉淀。
接口测试依赖真实 MySQL、Redis、MQ 时，Testcontainers 可以让每次测试拥有独立依赖，减少共享环境带来的偶现失败。
对测试来说，最后要落到可复现、可验证、可交接，文章也是按这个思路写的。
with MySqlContainer('mysql:8.0') as my