- 博客(40)
- 收藏
- 关注
RSS订阅原创 Web用例管理：维护步骤、定位器与版本
和。漏掉引用校验的后果是：删掉一个还在被 3 条用例使用的定位器，平台不报错，等到某天跑用例才报「元素找不到」。漏掉版本关联的后果是：上周那条通过的运行记录，这周改了用例之后再打开，已经没法说明当时到底跑的是什么。这篇把整条链路走通并给出可运行代码：用例的三段结构、动作白名单、引用反查、用例版本号、运行快照、版本差异。环境：本机 Windows / Python 3.11.8 / Playwright 1.62.0 / Chromium 151.0.7922.34。测试页面/steps。
2026-11-08 08:15:00
208
原创 Web 性能 + AI Lighthouse 分析
性能测试最容易产出一份没法用的报告：数字是真的，结论是假的。一个典型场景：同一个页面连续测三次，页面加载耗时分别是。三次都没报错、脚本都跑通了，但拿任何一个去汇报都是错的——真实值在这三个数之外，而多数人只会报手头那一个。这一篇把「怎么测才算数」拆成可执行的步骤，并给出全部实测数字、统计口径和可运行代码。测试页面为本地自建的/heavy（含 400 个多余 div + 一段 30 万次循环的同步脚本）。：本机。
2026-11-07 16:34:13
171
原创 Web 兼容性 + AI 跨浏览器
兼容性测试做到一半最容易卡住的地方，通常不是「怎么测」，而是「测多少组合」和「怎么把问题记下来」。前者决定成本，后者决定半年后还有没有人能复现。，每一步配可运行的代码和实测数字。代码在本机实跑：Windows / Python 3.11.8 / Playwright 1.62.0 / Chromium 151.0.7922.34（Chrome for Testing）。测试页是本地教学页面，不连公网、不用真实数据。浏览器安装与引擎切换见，视口设置见。
2026-11-06 22:18:15
150
原创 Web 视觉测试 + AI 截图比对
视觉回归最常见的两种失败方式：差异太多没人看，或者。后者更糟——真实缺陷被写成新基线，下一轮彻底看不见。这一篇把整条链路走通并给出实测数字：采集条件、像素差异计算、阈值策略、动态区域处理、AI 归类的边界。代码在 Windows / Python 3.11.8 / Playwright 1.62.0 / Chromium 151.0.7922.34 / Pillow 13.0.0 / numpy 2.2.6 上实跑，配套脚本。采集用，图像处理用。
2026-11-05 18:49:25
159
原创 Playwright 自动等待 + AI 失败诊断
昨天那批用例本地全绿，放到 CI 上十次红两三��。这一篇把两件事讲透：怎么等；用例挂了怎么判断该找谁。代码在 Windows / Python 3.11.8 / Playwright 1.62.0 / Chromium 151.0.7922.34 上实跑，配套脚本（那 3 个 failed 是 AI 假修复样本，设计内）。。
2026-11-04 17:15:20
374
原创 Web 自动化基础 + AI 元素识别
接口段一路顺下来：请求发出去，JSON 回来，按字段取。Web 段第一课的分水岭就在这里——。眼睛看到的是一张表，脚本看到的是一堆标签。这一篇把整条链路走通：工具能跑起来 → 在页面上找到元素 → 数据可重复 → 页面结果能对回接口 → 审 AI 写出来的用例。代码全部在 Windows / Python 3.11.8 / Selenium 4.45 / 本机 Edge 152.0.4191.53 上实跑。配套脚本在（那 4 个 failed 是，设计内）。。
2026-11-03 23:32:18
274
原创 接口任务执行：状态流转、取消与结果保存
同步请求是「发出去，等它回来」。异步任务是「发出去，它自己在后台跑」。于是多出三个问题：状态怎么流转、怎么等它做完、怎么在做完之前取消。配套脚本在，四个文件都能直接跑。代码在 Windows、Python 3.11 下实跑，pytest 3 passed。
2026-11-02 23:47:07
160
原创 接口链路编排：参数关联、依赖与失败分支
接口链路里最容易出错的三个地方，出问题时通常都不报错，只是结果不对：值从哪来、失败了怎么办、什么算对。这一篇把三者都变成配置里的显式约定。配套脚本在，四个文件都能直接跑。代码在 Windows、Python 3.11 下实跑，pytest 3 passed。
2026-11-01 08:34:42
463
原创 断言与数据模块：把配置变成可执行用例
Day31 把请求变成了数据，今天把断言也变成数据。然后会撞上一个新问题：同一个用例、同一个断言，这次红那次绿——到底是谁的错？这一篇给出一个配置驱动的接口测试执行器，以及一条判断规则。配套脚本在，四个文件都能直接跑。代码在 Windows、Python 3.11 下实跑，pytest 3 passed。
2026-10-31 23:49:59
800
原创 接口工作台：组织请求、环境与变量
「我在本地跑通了，到测试环境就全错」——这句话拆开看是三个问题，而三个都藏在一个很小的写法里。这一篇接着 Day30，把「怎么发请求」从代码变成数据，再理清环境和变量的边界。手打请求的问题很具体：换环境重打一遍，交给同事重写一遍。注意每个请求都带了「说明」字段。 这一行字是给接手的人看的，告诉他这一步在整条链路里干什么。没有它，别人看到一串路径只能猜。实跑：顺序就是依赖关系把「取消后再查」提到「取消订单」前面：「取消后再查」这次查到的状态是 CREATED，不是 CANCELLE
2026-10-30 18:22:58
102
原创 接口性能 + AI 压测分析
压测报告里最常见的一句话是「平均响应 143 毫秒，性能良好，可考虑上生产」。三个问题：平均 143 毫秒但 P99 是 921 毫秒；那个「143」本身就是错的（实算 100.2）；「可考虑上生产」但数据是合成的。配套脚本在，四个文件都能直接跑。代码在 Windows、Python 3.11 下实跑，pytest 3 passed。
2026-10-29 22:54:00
368
原创 接口 Mock + AI 自动生成数据
Mock 那条线：造出你等不到的错误，让「200 但内容不对」这种问题从碰运气变成必测。数据那条线：让 AI 造数据省下抄参数的力气，但审查的判断必须自己留着——单条审不够，还得整批审。两条线合起来是一句话：你得自己造出错的条件，也自己判断什么算对。
2026-10-28 17:31:26
316
原创 接口自动化 + AI 智能断言
一条断言到底抓不抓得住错」——这个问题困扰我很久。我们项目里有一条断言检查订单接口返回的金额应该是199.80。后来后端把金额格式改成了带千分位的"1,998.00"，测试照样绿。因为那条断言压根没写对，或者写的是assert 金额，而金额一直存在。写断言不难，难的是知道它管不管用。这一篇给出一个可以自己验的办法。配套脚本在，四个文件都能直接跑。代码在 Windows、Python 3.11 下实跑，pytest 结果 9 passed。
2026-10-27 23:24:11
179
原创 接口工具 + AI 文档生成
有一份接口文档，是我自己写的。写完那天是对的。后来后端把金额从double改成了varchar，文档没跟着改。，直到有人照着文档写代码被接口拒了。那天的排查挺浪费：先怀疑自己参数写错，再怀疑接口有 bug，最后才想起来「文档是旧的」。今天想把这件事变成能自动跑出来的检查，顺便说说接口文档到底能干什么、不能干什么。配套脚本在，五个文件都能直接跑。接口文档就在，用 requests 就能读，不需要装任何工具。规范见。
2026-10-26 23:53:16
197
原创 接口测试入门 + AI 自动生成用例
接口返回 200，不代表订单真的取消了；同一个请求换个账号还能成功，也可能说明对象权限没生效。接口测试要同时建立三层判断。这一篇接着 Day25。Day25 用 pytest 验证纯数据的规则，今天把同一套方法作用在一个真的 HTTP 服务上。所有代码在 Windows、Python 3.11 下逐段实跑，配套脚本在lab/day26/，pytest 结果为，那 4 个失败是教学设计的一部分——它们是「AI 候选实现」里被断言抓出来的四个缺陷。
2026-10-25 09:30:19
403
原创 Python测试与AI协作：用pytest验证代码而不是盲信答案
今天是 Python 阶段的最后一篇。七天学下来，从「点运行按钮报错」到「能用断言验证一个不敢信的函数」。预期值必须来自代码之外的第二个来源。Day15 我们用 SQL 算出一个数，然后 Day21 到 Day24 用了五种不同的 Python 写法去核对它，每一次都是 359.60。这件事比学会任何一个库都重要。如果只能带走一句，就是这句。
2026-10-24 23:39:05
155
原创 Python第三方库实战：requests、Pydantic与接口数据校验
read_rows只按文件后缀分派，。今天把它补上，顺便回答一个更基础的问题——这一篇要引入了：今天开始不再只用标准库，需要requests和pydantic。代码在 Windows、Python 3.11.8 下逐段实跑，127.0.0.1配套脚本在，01 到 05 按顺序可单独运行，每个脚本会自己启动服务。
2026-10-23 23:31:30
124
原创 Python面向对象与异常调试：把脚本拆成可维护的模块
昨天说过 Day11 那篇 Linux 里，AI 给的 Python 脚本有个小问题——今天正好讲清楚怎么自己找。total = total + float(row["amout"]) # 这里写错了：amoutprint("结果：", paid_total(raw_payments))三步读它：第一步，看最后一行。—— 意思是「字典里没有amout这个键」。第二步，往上看一层。找到写着的那段，它指到第 7 行。第三步，看那一行下面那串波浪线~~~~。它精确标出了是哪个字。
2026-10-21 17:32:14
402
原创 Python数据结构与函数：写出可复用的数据处理逻辑
很多人在这里停住：列表和字典都会写，def也见过，但一到「把逻辑封装起来」就不知道该封什么、封成什么样，写出来的函数只能被自己调用一次。这一篇接着 Day20 往下走。Day20 用几条最简的假数据把变量、判断和循环讲透了；今天换回真实的订单数据，把那几个循环收进可以反复调用的函数。昨天的循环、判断、累计，一个字都不用改。代码在 Windows、Python 3.12 下逐段实跑，输出是实际运行结果，不是推演。配套脚本在，01 到 08 可以按顺序单独运行。
2026-10-20 23:53:25
74
原创 Python基础语法：变量、类型、判断和循环
下面是故意有缺陷的教学候选，能够运行，却没有累计全部耗时。先预测输出，再说明应移动哪一行。答案是430。每轮先清零，因此四轮结束时的值分别是120、850、0、430，前一轮从未被保留。print放在循环外，只显示最后一轮留下的430。修复不是把print放进循环，也不是给total_ms改个名字，而是把初始化移到for前面。现在输出1400。再把records改为空列表，修复版输出0；错误版循环没有执行，也就没有机会创建total_ms。初始化位置既影响普通累计，也影响没有记录时的行为。
2026-10-19 23:09:48
186
原创 Python学习路线：搭好环境，跑通第一个脚本
程序输入是一份本地 UTF-8 JSON 文件，输出是订单总数。读取失败或结构不符合要求时直接报错，不伪造一个零条结果。本次不连接数据库，不请求网络接口，不计算金额，也不验证每条订单的业务字段。这样第一天的结果比较容易核对：四个订单对象就应该是四条，空列表应该是零条，空文件应该失败。后续学习按这个成果继续推进：Day20 解释数据结构并加入业务校验，Day21 定位错误，Day22 输出可重复生成的报告，Day23 评审 AI 辅助编写的脚本，Day24、Day25 再按任务选择工具与资料。
2026-10-18 08:11:16
425
原创 MySQL 性能 + AI 调优实战
朋友们好，我是楠风。Day15 验证查询结果，Day16 比较索引方案，Day17 沿慢查询和锁等待找证据。一个方案要同时通过正确性和性能验收，才算值得采用。设想订单列表加了索引，单次查询变快了，发布后下单却开始排队。这并不矛盾：读请求、状态更新、事务提交会争用同一套资源。只挑一条跑得漂亮的 SELECT，无法代表整个业务。本文以 MySQL 8.4 LTS、InnoDB 和独立实验库为参照，给出可执行实验，当前未提供本机实测性能数据。负载比例、并发档位和示例数据均用于教学；
2026-10-17 16:04:37
359
原创 MySQL 慢查询 + AI 智能分析
朋友们好，我是楠风。Day15先保证查询结果正确，Day16练习索引和执行计划。今天接着处理一个更接近排查现场的问题：订单列表接口响应变慢，怎么判断是SQL扫描太多、事务互相等待，还是请求还没进入数据库？下面给出可执行实验，当前未提供本机实测性能数据。所有数据均为教学合成数据，操作只用于自己控制的、没有其他业务连接的独立MySQL 8.4 LTS实验实例。全局日志设置影响整个实例，不能直接套到共享测试库或生产环境。
2026-10-16 18:41:41
287
原创 MySQL 索引 + AI 索引建议
朋友们好，我是楠风。Day15先把SQL的查询结果、金额、状态与事务边界核对清楚。今天接着讨论索引：面对订单列表查询，怎样提出一个候选索引，又怎样证明它值得保留。测试环境里有一种容易误判的情况：第一次查得慢，建完索引第二次查得快，于是记录“优化成功”。但这两次的缓存、后台负载、返回数据可能不同，新增索引还会影响写入。只有两个耗时数字，无法解释变化来自哪里。本文采用MySQL 8.4 LTS与InnoDB作为参照，给出独立实验表、10万行教学数据、固定查询、前后对照和恢复步骤。
2026-10-15 20:17:48
500
原创 MySQL 基础 + AI SQL 优化
朋友们好，我是楠风。上一阶段聊完Linux监控，我们开始补上测试工程师经常接触的另一块能力：MySQL。接口返回“支付成功”，页面也显示“已支付”，测试就结束了吗？还要看订单金额是否正确、失败支付有没有被算进收入、明细是否被重复汇总，以及失败时库存能不能回到原来的状态。今天从SQL基础讲起，再让AI辅助检查和改写查询。验收顺序是先确认业务含义与结果，再比较执行代价。如果一条SQL把159.80元算成319.60元，即使执行得很快，也不能通过测试。
2026-10-14 17:29:54
197
原创 Linux 监控告警 + AI 智能监控
朋友们好，我是楠风。Day 11—13，我们复习了 Linux 命令、AI 辅助写 Shell，以及性能瓶颈排查。今天接着把Linux 监控告警 + AI 智能监控串起来。先想一个场景：订单接口持续返回 500，CPU 却只有 20%，告警群里也没有消息。究竟是业务指标没有采集、规则没有命中，还是通知没有送到？这篇围绕已有测试环境，给出采集配置、看板查询、告警规则和验收方法，再说明异常检测模型怎样接入。数字和场景均用于教学，不代表线上实测效果。
2026-10-14 01:05:48
216
原创 Linux 性能瓶颈 + AI 智能排查：4 维诊断方法论
Day 11 讲了 30 个 Linux 命令 + 真实排查案例。Day 12 讲了 AI 辅助写 Shell 脚本。今天讲Linux 性能瓶颈——4 维诊断方法论 + AI 智能排查。Day 11-12 是"实操"，Day 13 偏"系统性方法论"。做了 5 年测试，我最大的感受是——性能调优的本质不是工具，是方法论。今天：学 4 维诊断方法论本周：用 1 个性能问题走完 4 步 SOP90 天：积累 10 个真实性能案例AI 提供方法论，落地靠你执行。
2026-10-12 21:52:23
392
原创 AI 自动写 Shell 脚本：测试工程师 5 个实战场景
Day 11 我讲了 30 个 Linux 命令 + AI 辅助排查。今天只讲一个核心AI 辅助写 Shell 脚本。我做测试 5 年，前 2 年写 Shell 脚本靠"翻 Stack Overflow + 试错"。后来用辅助写脚本，效率提升 5 倍 + 脚本质量更高。今天分享5 个实战场景，每个都能直接落地。做了 5 年测试，我最大的感受是——AI 写脚本的关键不是 AI 多强，是你多会提问。今天：用 AI 写 1 个日志轮转脚本。
2026-10-11 09:00:00
552
原创 Linux 命令 + AI 辅助排查：测试工程师实战指南
Day 7-10 我讲了 AI 工作流、Obsidian 第二大脑。进入 Linux 领域——测试工程师必备技能。服务挂了不知道怎么查日志满屏不知道看哪里性能慢不知道瓶颈在哪后来系统学了 Linux + AI 辅助，效率提升 10 倍。30 个常用命令（分组，实战必备）真实问题排查案例（用命令查分析）AI 辅助定位（ChatGPT + DeepSeek 两个工具实战）做了 5 年测试，我最大的感受是——测试工程师不懂 Linux 是短板。
2026-10-10 16:19:55
386
原创 AI 生成测试报告：自动周报月报，从此不再加班
Day 8 我讲了 4 种 AI 工作流，Day 9 讲了 Obsidian 第二大脑。今天讲最实用的——AI 生成测试报告。我做测试 5 年，最痛苦的除了写用例，就是写周报/月报。之前：每周一上午写周报，要 2-3 小时现在：AI 自动生成，30 分钟 review 即可今天分享怎么用 AI 自动生成报告，省出 80% 的时间。做了 5 年测试，我最大的感受是——测试工程师的时间应该花在测试上，不是写报告上。AI 把写报告这件事从"8 小时"压缩到"30 分钟"。
2026-10-09 22:43:32
329
原创 测试工程师的“AI 第二大脑“（知识沉淀）：3 大知识库实用化
Day 8 我讲了 4 种 AI 工作流（解决当下任务）。今天讲怎么沉淀长期资产——第二大脑。- Bug 截图：1000+ 张- 工具使用笔记：50+ 份- 项目经验复盘：20+ 个- 代码片段：500+ 个问题是——根本找不到。后来我用Obsidian（重点）+ 其他工具配合做"第二大脑"，彻底解决。今天分享我的 3 大知识库结构 + Obsidian 实战。打开一篇长笔记Copilot：「请总结这篇笔记的 5 个核心要点」→ 3 秒钟拿到摘要做了 5 年测试，我最大的感受是——
2026-10-08 19:23:25
453
原创 测试工程师的 AI 工作流设计（实战）：4 种模板让效率翻倍
Day 7 我讲了 7 种测试用例设计方法 + Dify 工作流（单个）。今天讲怎么把4 种工作流串起来，搭一条完整的测试自动化流水线。我做测试 5 年，见过太多测试工程师单点用 AI- 用 豆包 改 bug 报告- 用 DeepSeek 生成用例工具用得飞起，但没有工作流思维——今天用 A 工具，明天用 B 工具，全靠手动串联。今天分享我自己用 Dify 搭的4 种工作流模板，让 AI 嵌入日常工作流。问自己 2 个问题：- 输入是什么？（PRD？Bug？日志？- 输出是什么？（用例？报告？
2026-10-07 20:56:19
120
原创 测试用例设计进阶：从能写好到能写精
做了 5 年测试，我最大的感受是——写用例这件事，80% 的人没入门，15% 的人入门了，只有 5% 的人做到了极致。如果你现在还是 60 分，别慌。今天：找 1 个你之前写的用例，看看是不是"假用例"本周：选 1 个功能，用 7 种方法组合重写90 天：建立你的用例库1 年后回头看，你会发现自己进步巨大。
2026-10-06 11:00:28
337
原创 Bug 报告 7 个要素 + 5 个加分项：写一次就让开发服气
Bug 报告不是浪费时间的文档。它是测试工程师最重要的交付物之一。把 bug 报告写好，不仅让开发服气，更让你的测试效率提升 30%+。希望这篇文章能帮你写出让开发心服口服的 bug。
2026-10-05 11:37:34
371
原创 测试用例评审 10 个必查点：从执行者到评审者
用例评审不是浪费时间。从"写用例的人"到"评审用例的人"，是测试工程师的关键跃迁。希望这篇文章能帮你成为团队用例评审的核心成员。
2026-10-04 23:43:32
175
原创 黑盒 vs 白盒 vs 灰盒测试：一张图讲透
定义：不关心代码内部实现，只关心输入和输出。思维模型：把自己当作用户。黑盒测试 = 用户视角看到的是：界面、按钮、表单看不到的：代码、数据库、网络请求适用场景✅ 功能测试✅ UI 测试✅ 验收测试（UAT）✅ 接口测试（手动部分）实战案例：登录功能黑盒测试测试场景：用户输入用户名密码登录测试用例：1. 输入正确的用户名密码 → 登录成功2. 输入错误的用户名 → 提示"用户名不存在"3. 输入错误的密码 → 提示"密码错误"4. 用户名为空 → 提示"用户名不能为空"
2026-10-03 09:30:00
460
原创 测试金字塔到底怎么用？90% 的团队都用错了
测试金字塔的概念是Mike Cohn 在 2009 年提出的。/\/UI\ ← 顶层：UI 测试（10%）/----\/ API \ ← 中间：API / 集成测试（20%）/--------\/ 单元 \ ← 底层：单元测试（70%）3 个核心原则1. 越底层越多：单元测试占比最高（70%+）2. 越顶层越少：UI 测试占比最低（10%）3. 越底层越便宜：单元测试 1 分钟能跑完，UI 测试要几分钟为什么这样设计？底层测试覆盖核心逻辑，跑得快、容易维护。
2026-10-02 09:59:23
365
原创 一张图搞懂 7 种测试用例设计方法
写测试用例的决策树：有输入数据？├─ 有范围 → 等价类 + 边界值 ⭐⭐⭐├─ 无范围 → 错误猜测└─ 多条件 → 判定表 / 因果图有业务流程？├─ 简单流程 → 场景法 ⭐⭐⭐└─ 复杂流程 → 场景法 + 判定表多参数组合？└─ 参数配置类 → 正交实验法优先级：场景法 + 等价类 + 边界值，覆盖 80% 场景。测试用例设计不是艺术，是工程。场景法 + 等价类 + 边界值。把基础打扎实，再学高阶，事半功倍。希望这篇文章能帮你把用例写得更扎实。
2026-10-01 12:36:23
418
原创 5 年测试工程师的真实成长路径：从迷茫到清晰，我做对了什么
2020 年我把 Python / pytest / Selenium / Appium 都过了一遍，但没做过任何完整项目。面试的时候一问细节就答不上来。过去的 5 年，我走过一些弯路，也慢慢看清了一些方向。我是楠风测开，5 年测试工程师，做过功能测试、自动化测试、测试开发。**关键拐点**：能不能从 0 到 1 搭出一个完整的自动化项目。**这个阶段的痛点**：每天重复点点点，感觉没什么成长。**教训**：先把一个框架学透，比追 10 个框架有用。**核心心得**：技术变现不需要想太多，先做起来再说。
2026-09-30 20:56:16
551
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人