<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[ceshiren_com的博客]]></title><description><![CDATA[]]></description><link>https://blog.csdn.net/ceshiren_com</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; ceshiren_com]]></copyright><item><title><![CDATA[UI 智能遍历测试：状态识别、路径规划与覆盖率评估]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/167492571</link><guid>https://blog.csdn.net/ceshiren_com/article/details/167492571</guid><author>ceshiren_com</author><pubDate>Sat, 10 Oct 2026 15:56:42 +0800</pubDate><description><![CDATA[本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。对于数据依赖较强的业务，仍然需要单独管理测试上下文。传统 UI 遍历工具通常先获取当前页面的控件树，识别其中可以点击、输入和滑动的控件，再选择相应操作执行。从工程实现来看，状态去重、路径规划、遍历规则、异常检测和覆盖率评估，是决定遍历效率的几个关键环节。例如，列表页面可能存在大量重复控件，通过限制相似控件的遍历次数，可以减少无意义的重复访问。]]></description><category></category></item><item><title><![CDATA[AI 测试开始被做成产品了：毕业生的第一个作品集，该往哪个方向选]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166489699</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166489699</guid><author>ceshiren_com</author><pubDate>Wed, 23 Sep 2026 18:08:14 +0800</pubDate><description><![CDATA[关注 「软件测试就业联盟」公众号，陪你走好校招求职的每一步有个计算机相关专业的毕业生问过我一个问题：手上还有四个月【推断】的准备时间，想做一份能写进简历、能在面试里讲三分钟【推断】、面试官能当场打开跑起来的测试方向作品集，该选什么题。我给的回答，和几年前不一样了。几年前我会说：做一个自己的测试框架吧，把请求封装、断言、报告、并发执行串成一条链，看上去很完整。现在我不会这么说了。原因很直接：AI 测试这件事，正在被厂商做成产品、被开源社区做成工具。]]></description><category></category></item><item><title><![CDATA[GitHub AI Scan不再依赖CodeQL默认配置：覆盖扩大后，怎么证明漏洞没漏？]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166489673</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166489673</guid><author>ceshiren_com</author><pubDate>Wed, 23 Sep 2026 18:06:50 +0800</pubDate><description><![CDATA[管理者看到的是“覆盖率上去了”，研发看到的可能是：同一段代码在不同仓库结论不同，旧漏洞没报，新PR却突然多了十几条建议。先构建小规模、可解释的数据集，至少包括SQL注入、路径穿越、命令注入、弱鉴权、敏感信息泄露，以及看起来危险但经过安全编码的负样本。代码做等价改写也很重要：变量改名、函数移动、增加无关日志后，漏洞本质没变，扫描结论不应突然消失。代码不复杂，难的是样本设计。覆盖扩大是好事，但它同时改变了测试问题：过去我们验收“扫描有没有开启”，现在必须验收“在不同配置背景下，扫描行为是否仍然可理解”。]]></description><category></category></item><item><title><![CDATA[Jev 进入 Agent Guardrail：高风险 Tool Call 该怎么测？]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166372667</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166372667</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 21:18:17 +0800</pubDate><description><![CDATA[这也是 LangChain 把 Jev 放进这一层的一个原因：它被设计成执行快速的结构化判断，而不是重新完成一次自由文本推理。([LangChain][1])当 Tool Call 开始真正影响外部系统，Guardrail 就不再只是一个“安全功能”，而是必须被系统测试的一条关键链路。而 Jev 最近进入 LangChain Agent Harness，也让这种“执行前风险判断”开始有了新的实现方式。Jev 进入 Agent Guardrail，真正值得测试工程师关注的，不是又多了一个模型。]]></description><category></category></item><item><title><![CDATA[我用AI把回归测试从3天压到3小时，提示词全公开]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166360649</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166360649</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 13:38:19 +0800</pubDate><description><![CDATA[不是没测完，是测完了不敢信——失败列表里一半是环境问题，一半是脚本挂了，还有几个是真正的bug。CI上几十条失败，你得挨个看日志、看截图、看视频，判断是产品bug、脚本问题、环境问题还是数据问题。后来我在每个提示词里都加了“如果信息不足，列出需要补充的信息，不要编造”。但如果你换个思路，让AI做影响面分析、做用例草稿、做脚本转换、做失败初筛、做报告初稿，你会发现它每个环节都能帮上忙。稳定性方面，因为回归范围更精准了，跑的全是相关用例，误报也少了很多。接口名是编的，字段是猜的，业务规则是它自己想象的。]]></description><category></category></item><item><title><![CDATA[应届测试开发的三条能力线：比背工具清单更能撑过前三年]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166360531</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166360531</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 13:34:53 +0800</pubDate><description><![CDATA[四个维度里，最容易被忽略的是项目复盘——很多人以为复盘就是写个总结，其实复盘是你把"这一次做过的事"变成"下一次可复用的方法"的唯一机会。工具会换，被测对象会换，甚至"测试"这个岗位的名字都会换。面对产品、老板、业务方，能把风险讲清楚——不是"可能有 bug"，而是"这条路径在 X 条件下会导致 Y 后果，我建议这么处理，代价是 Z"。这是三条线里最基础的一条，也是应届生最容易忽略的一条——大多数人以为"我复现出来了"就够了，其实"我复现出来了，并且写成了别人也能复现的步骤"才是能力。]]></description><category></category></item><item><title><![CDATA[Playwright 从入门到实战：我把 UI 自动化稳定性从 60% 提到 95%]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166360355</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166360355</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 13:33:45 +0800</pubDate><description><![CDATA[去年下半年，我们团队的 Selenium 测试套件遇到了一个诡异的问题：同样的代码，在 Chrome 89 上跑得好好的，Chrome 90 发布后突然开始随机失败。如果你现在的 UI 自动化还在 60% 左右的稳定性上挣扎，我建议先从一个最简单的动作开始——把测试代码里所有的 sleep 删掉，看看会怎样。更有意思的是团队氛围的变化。从 60% 到 95%，不是靠某一个“银弹”功能实现的，而是把自动等待、稳定定位、状态复用、API 准备数据、合理重试、Trace 调试这几件事组合在一起，一步步做出来的。]]></description><category></category></item><item><title><![CDATA[2026年小红书职级体系：薪资多少？测试开发面试都考什么？]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166359781</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166359781</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 13:28:42 +0800</pubDate><description><![CDATA[说明： 文中 R4、R5、R6 薪资为旧职级体系下的公开历史样本，主要用于理解过去不同岗位责任范围和薪酬结构，不代表小红书 2026 年现行职级体系或统一薪资标准。2024 年 8 月，小红书调整职级体系，其中比较明确的一项就是取消 R 职级，同时取消 L0，各级 Leader 改为任命制。网上查小红书薪资，R4、R5、R6 依然满天飞，R5 百万年包、R6 接近 200 万的数字也很常见。项目、代码、数据库、缓存、消息队列、网络、操作系统、性能，包括算法，本来就在测开的能力范围里。]]></description><category></category></item><item><title><![CDATA[Google 开源 ARTEMIS：AI Agent 如何接管 Android 真机测试？]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166359336</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166359336</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 13:18:27 +0800</pubDate><description><![CDATA[它不是帮你简单生成几段 Appium 脚本，而是让 AI Agent 直接操作 Android 真机或模拟器：理解自然语言测试任务、识别页面、点击控件、跨 App 执行业务流程，还能自动获取截图、Logcat、执行轨迹，并生成测试结果。更值得关注的是，ARTEMIS 原生支持 MCP，可以直接接入 Antigravity、Codex、Claude Code、Cursor、Windsurf 等 AI 编程环境。然后 ARTEMIS 自己完成页面观察、元素定位、点击、滚动、输入以及结果检查。]]></description><category></category></item><item><title><![CDATA[UI 测试的语义断言：Midscene aiAssert 比像素比对稳在哪、又会骗在哪]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166359250</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166359250</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 13:15:26 +0800</pubDate><description><![CDATA[Pass@1 是「只给模型一次机会就成功」的比例，Pass@3 是「给三次机会里至少成功一次」的比例——后者天然更高，衡量的是「多试几次能不能成」，跟前者根本不是一套口径，不能拿来直接对比，更不能和别处评测综述里某个长得相近的数字混着读。判断语义断言在你的业务场景里稳不稳，要盯的是 Pass@1 那一档，因为你的 CI 里一条断言通常只跑一次，没有「再来两次」的机会。它比的是「像不像」，不是「对不对」。更麻烦的是它可能给出过于宽松的「看起来对」——页面上明明金额是空的，模型却觉得「整体布局正常」就放行了。]]></description><category></category></item><item><title><![CDATA[Copilot会自动关闭自己提过的问题：AI代码评审最该测的，变成了“它为什么消失”]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166358929</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166358929</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 13:10:57 +0800</pubDate><description><![CDATA[测试对象也随之改变：不再只是某条评论对不对，而是问题从出现、复核、修复到关闭的完整轨迹是否可信。LLM评审受到上下文、模型采样、文件顺序和补丁范围影响，同一问题第二次未被提到，不代表它已经修好。模型评审本来就有概率性，更重要的是高危问题不能持续漂移，以及团队知道漂移发生在哪里。这段断言表达了一个非常重要的原则：没有再次报告，只能证明“本轮没看到”，不能证明“代码已修复”。这能减少PR页面噪音，也带来一个新质量问题：团队不能只统计AI发现了多少问题，还要验证每条问题在多次提交之间是怎样迁移的。]]></description><category></category></item><item><title><![CDATA[Agent 里为什么不该什么都交给大模型？Jev 给了一个新答案]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166358751</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166358751</guid><author>ceshiren_com</author><pubDate>Tue, 22 Sep 2026 13:09:59 +0800</pubDate><description><![CDATA[这版我特意把最后的落点放到了 “这对软件测试意味着什么”，而不是停在单纯介绍 Jev，这样更符合您公众号的用户群，也方便下一篇自然承接 《测试工程师为什么该关注 Jev？官方认为，在适合 System One 的任务中，相对于同等水平的通用 LLM，可以达到约 40～200 倍的速度差异。今天很多系统真正缺的，可能恰恰不是一个更大的模型，而是一个更快、更便宜、更适合程序直接调用的“判断层”。规则、决策模型、LLM、Agent、Tool 和人工兜底，到底有没有在正确的位置做正确的事情。]]></description><category></category></item><item><title><![CDATA[OpenAI把Codex Harness开放出来后，我反而更关心一个问题：Agent连续跑几天，到底该怎么测？]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166124922</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166124922</guid><author>ceshiren_com</author><pubDate>Sun, 20 Sep 2026 12:44:11 +0800</pubDate><description><![CDATA[Agents API负责管理Context、Tool以及Subagent，并提供可以让Agent处理文件、运行代码、保存中间结果的执行环境。官方说明，当Session接近Context限制时，系统会自动压缩之前的上下文，让Agent可以跨越多个Context Window继续工作。一个运行了两天、调用过300次工具、经历过Context压缩和3次故障恢复的Agent，你凭什么敢让它继续操作生产系统？C失败了，主Agent却不知道C失败了，最后仍然生成一个看起来非常完整的Root Cause。]]></description><category></category></item><item><title><![CDATA[我用 AI 把 Swagger 变成 500 条 pytest 用例，回归从 3 天到 3 小时]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166124861</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166124861</guid><author>ceshiren_com</author><pubDate>Sun, 20 Sep 2026 12:43:14 +0800</pubDate><description><![CDATA[关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集上个月我把订单中台的回归测试从 Postman 里拽了出来。之前 87 个接口，每次发版前手工点，3 天起步，点到后面人都麻了。现在 CI 上跑 500 多条 pytest，全量回归 3 小时出头，MR 只跑 smoke 的话 20 分钟。核心不是哪个神器，而是把 Swagger 当成数据源，让 AI 补测试场景，再让 pytest 去干重复劳动。下面是我实际落地的过程，代码是删减过的，但骨架能直接抄。]]></description><category></category></item><item><title><![CDATA[AgentOS + Harness + MCP 都火了：测试工程师真正该补的，是这套 Agent 质量工程能力]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166014856</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166014856</guid><author>ceshiren_com</author><pubDate>Sat, 19 Sep 2026 22:32:51 +0800</pubDate><description><![CDATA[Demo 里，让 Agent 读个文件、查个数据库、调个接口，甚至生成一段代码，都不算特别难。这张路线图真正想表达的，不是“12周学完就无敌”，而是 AI 测试开发这件事，已经不是只学一个 Prompt、一个框架或者几条自动化脚本就能解决的，它需要的是一条从模型认知、工具调用、智能体执行到评测闭环的完整能力路径。一个长期运行的 Agent，上下文里可能同时存在系统 Prompt、用户任务、历史对话、长期记忆、RAG 检索结果、工具说明、工具执行结果，甚至其他 Agent 发送过来的消息。]]></description><category></category></item><item><title><![CDATA[Playwright + axe-core + CI：把无障碍回归做成一条能拦住上线的流水线]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/166014820</link><guid>https://blog.csdn.net/ceshiren_com/article/details/166014820</guid><author>ceshiren_com</author><pubDate>Sat, 19 Sep 2026 22:31:35 +0800</pubDate><description><![CDATA[关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集一个面向政企的 B 端后台，验收前两周，甲方甩来一份信息无障碍整改清单：表单控件没有关联 label、数据表格缺少标题说明、按钮颜色对比度不够、弹窗打开后焦点乱跑——三十多条，条条要求上线前改完。团队这才想起来，招标要求里明明写着「符合 WCAG 2.1 AA」，而过去半年，无障碍这件事一直靠上线前找个人开着读屏软件随手点两下。随手点两下的结果，就是漏。]]></description><category></category></item><item><title><![CDATA[人社部新增“生成式人工智能系统测试员”——校招生的第一波政策红利来了]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/165890603</link><guid>https://blog.csdn.net/ceshiren_com/article/details/165890603</guid><author>ceshiren_com</author><pubDate>Fri, 18 Sep 2026 21:43:36 +0800</pubDate><description><![CDATA[但AI系统的失效模式完全不同：AI会“幻觉”（编造不存在的信息）、会产生偏见（对特定群体有歧视性输出）、会被越狱攻击（绕过安全限制输出不该输出的内容）、会泄露训练数据。这意味着，院校的专业设置和课程内容将直接对标这个岗位的能力要求，学校教的东西和企业要的东西，终于有了一个官方桥梁。这个工种是在“生成式人工智能系统应用员”职业下增设的，定位是应用层的质量保障，不是算法研发。面试官不是在找一个会写try-catch的人，他是在找一个能体系化思考“当AI组件不可靠时，整个系统怎么保持可控”的人。]]></description><category></category></item><item><title><![CDATA[DeepSeek Harness爆火，测试人能拿它做什么？这5个场景最实用]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/165890576</link><guid>https://blog.csdn.net/ceshiren_com/article/details/165890576</guid><author>ceshiren_com</author><pubDate>Fri, 18 Sep 2026 21:42:09 +0800</pubDate><description><![CDATA[上个月，团队里一个做了3年功能测试的同事找我聊天，说了一句让我印象很深的话：“DeepSeek我天天在用，但我就是拿它当搜索引擎，问问概念、查查报错。社区已经有现成的工具可以直接用——ai-code-reviewer，基于DeepSeek API的自动化代码审查工具，零依赖、单文件即可运行，支持30+编程语言，自动发现Bug、安全漏洞、性能问题。DeepSeek能替你完成60%-70%的重复劳动，但剩下30%的判断，永远是你的。DeepSeek的用例设计能力很强，但它强在“翻译”，不强在“补充”。]]></description><category></category></item><item><title><![CDATA[会AI的测试开发，薪资到底能高多少？我扒了100份JD]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/165890542</link><guid>https://blog.csdn.net/ceshiren_com/article/details/165890542</guid><author>ceshiren_com</author><pubDate>Fri, 18 Sep 2026 21:41:15 +0800</pubDate><description><![CDATA[他花了两个月时间，用LangChain搭了一个评测Agent，把手工维护的用例转化成结构化的评测集，然后用LLM自动做结果判定。我花了两个晚上，在拉勾、Boss直聘、猎聘上扒了100份测试开发相关的JD，手动整理了一份数据。效果好不好先不说，关键是他在面试的时候，能把这件事从头到尾讲清楚：为什么选LangChain不选别的框架、评测集怎么构建的、LLM判定的准确率怎么验证的、误判怎么处理的。我目前是做传统测试开发的，有X年经验，日常工作包括[你的日常工作内容]。确定的、可枚举的、可重复验证的。]]></description><category></category></item><item><title><![CDATA[我用ChatGPT把回归测试从3天压到3小时，提示词全公开]]></title><link>https://blog.csdn.net/ceshiren_com/article/details/165758217</link><guid>https://blog.csdn.net/ceshiren_com/article/details/165758217</guid><author>ceshiren_com</author><pubDate>Thu, 17 Sep 2026 21:59:51 +0800</pubDate><description><![CDATA[上个月我们发版前最后一次回归，从早上9点干到晚上11点，三个人轮着点，点到后面眼睛都花了。结果还是漏了一个优惠券叠加的边界场景，上线第二天客服就炸了。真正需要开发看的bug，我直接把它的分析附在工单里，开发也省事。它给我输出了十几条合并建议，还指出了三个我压根没想到的边界：优惠券并发核销、退款时库存回滚的时序、以及弱网下重复提交。它生成的脚本大概能直接用70%，剩下的30%是业务字段和数据库连接需要我改。回归测试从3天到3小时，省下来的时间我没摸鱼，拿去补了之前一直没空写的契约测试。回归跑完总有几个红的。]]></description><category></category></item></channel></rss>