大道至简

测试平台做到一定阶段后，权限模型几乎一定会变成一个绕不过去的问题。 最开始，权限往往会被理解得比较简单： 谁能登录 谁能看页面 谁能点按钮 但只要平台真的开始承载真实任务，很快就会遇到更复杂的场景： 谁能执行哪个任务 谁能看哪个项目的报告 谁能改环境配置 谁能操作生产巡检或高风险任务 谁能接 Jenkins、改告警、动密钥 到这个阶段，权限就不再是“加几个角色枚举”的问题，而是平台边界的一部分。 这篇文章就只讲这个问题： 测试平台的权限...

测试平台做到一定阶段后，最容易冒出来的一类问题不是： 技术栈不对 页面不好看 接口不够多 而是更底层的一件事： 模块边界开始混了。 一旦边界混掉，后面通常会出现这些症状： 一个功能改动牵动很多模块 新需求一来，需求归属很快就说不清该落在哪一层 执行、环境、报告、权限互相引用 某些公共逻辑到处复制 平台明明还能跑，但越来越没人敢动 所以测试平台做大之后，真正决定它能不能继续长的，往往不是框架，而是边界。 这篇文章就只讲这个问题： 测试平台...

第一次做测试平台后端时，目标很容易被理解成： 用 Gin 起个服务 写几个接口 前端能调通 这当然是开始，但如果目标只是这样，后面平台很快就会出现几个典型问题： 接口越来越多，但对象边界越来越乱 任务执行逻辑、配置逻辑、报告逻辑混在一起 控制器层越来越重 调度、执行、查询、权限开始互相耦合 所以需要强调的是，Go + Gin 搭测试平台后端的关键，不是“框架怎么用”，而是： 怎么把平台后端先搭成一个能长的工程骨架。 这篇文章就只讲这个问...

使用方法：创建为.xcs的文件，导入xshell即可；SolarizedDarkModify[SolarizedDarkModify]text=839496cyan(bold)=00fffftext(bold)=e9e9e9magenta=c000c0green=80ff00green(bold)=3c5a38background=042028cyan=00...

第一次想做测试平台时，动机通常很朴素： 脚本越来越多 人越来越多 任务越来越杂 每次跑都得靠某个“熟悉脚本的人” 这时候很容易得出一个表面结论： 需要一个平台来把这些能力收起来 但如果继续往下问一句： 平台到底要解决什么问题 其实回答不清楚。 于是后面最常见的结果就是： 把脚本换了个页面入口 加了个任务列表 能点“执行” 然后很快又发现： 环境还是乱 日志还是散 报告还是不统一 失败还是不知道怎么排 新人还是接不住 所以需要强调的是，“...

线上复杂故障最难的地方，通常并不是“技术细节太深”，而是现场会同时出现几件坏事： 用户已经在报错 指标开始抖 多个同学同时给出不同判断 证据很多，但时间线很乱 这个时候如果没有一套稳定的方法，排障现场很容易迅速滑向几种低效状态： 一上来就猜根因 盯住自己熟悉的那一层不放 看到一个异常现象就把它当根因 问题还没切边界，就开始改配置或重启 所以复杂故障定位真正重要的，不是“知道多少命令”，而是有没有一套能在混乱现场里把问题收住的方法。 这篇...

很多复杂问题之所以难定位，不是因为证据不够，而是因为证据太散。 现场常见的情况是： 监控说某个时间点异常了 日志里看到了报错 抓包里也看到了一些异常现象 但团队还是回答不出来： 最早的异常到底从哪一层开始 当前看到的是根因还是连锁反应 下一步该先改哪一层 这类问题如果只看单一证据源，特别容易跑偏。 比如： 只看日志，很容易把所有问题都判断成应用逻辑问题 只看抓包，会把很多应用慢误判成网络慢 只看监控，会知道系统有波动，但不知道具体哪条链...

做接口或页面排障时，最常见的一种争议是： 客户端说后端返回不对 后端说客户端传参不对 测试看起来像两边都“有点道理” 如果没有抓包，这种问题很容易越讨论越散。因为每一方看到的，都只是自己那一层。 而抓包最有价值的地方，不是单纯“看到请求”，而是能帮助你先把边界切清楚： 请求到底有没有发出 请求到底有没有到达 响应到底有没有返回 返回之后客户端到底做了什么 只要这四件事能看清楚，很多“到底是谁的问题”其实很快就能收敛。 这篇文章就只讲一件...

接口联调现场最常见的一种低效状态是： 前端说后端返回不对 后端说请求参数就不对 测试说自己看见的问题和双方说的都不一样 然后三方都拿着各自视角在解释问题，但没有一个统一证据面。 这也是 Fiddler 在接口联调里最有价值的地方。它不只是“抓包工具”，更像是一个把联调问题变成可观察、可对比、可复现对象的中间层。 所以这篇文章不讲安装和菜单，而是只讲实战里最常见的几件事： 怎么快速判断是请求问题还是响应问题 怎么对比成功失败差异 怎么改请...

做 App 测试时，最常见的一种现场混乱是这样的： App 明明发了请求，但测试说自己没抓到 抓到了部分接口，但关键接口就是没有 页面报错了，但研发说后台没看到请求 同一个接口在浏览器里能通，在 App 里不通 这时候如果没有一个稳定的抓包工具，现场经常会变成纯口头对线。而 Charles 的价值，恰恰是把这些分散现象拉回到同一条链路里： 设备到底有没有把请求走到代理 HTTPS 到底有没有被正确解开 请求是没发、没到，还是回来的东西不...