Raina测试_个人页

2026年11月

• 11.11 09:38:37
  发表了文章 2026-11-11 09:38:37

  版本提测前，测试可以利用 AI 提前做好的 4 件事

  版本提测前，测试除了准备测试环境、输出测试用例，还可以提前做好这四项工作： 1. 影响分析 ：通过 Git Diff 了解代码变更，明确回归范围。 2. 流程梳理 ：根据源码生成流程图，理解关键接口的实现逻辑。 3. 并发扫描 ：排查潜在的竞态、重复提交和幂等性问题。 4. 实现检查 ：对照测试用例和代码变更，提前发现功能实现缺口。 这四项工作并不是为了增加测试流程，而是希望把一部分原本需要在正式测试中逐步发现的问题，尽可能提前处理。 尤其是现在 AI 辅助开发越来越普遍，开发实现功能的速度变快了，但代码影响分析、业务逻辑梳理和测试验证准备等工作，依然需要测试人员认真完成。 第一件事：通过 G
• 11.10 09:56:02
  发表了文章 2026-11-10 09:56:02

  我将 AI接口自动化的能力接到测试平台上

  我这边开发了一个 AI 测试平台，今天讲讲，我怎么将AI+接口自动化应用到这个平台上  首先是接口资产管理 可以将 openapi 或者 swagger 文件，直接导入到系统中 导入之后，就能够看到相关的接口了，这个时候能将接口都导入进来 当然也可以手动创建接口 进行接口调试 那么在这里 AI能够做到什么呢？ 首先第一个是单用例生成，这个是我们在实际接口测试中的一个场景，对单接口进行测试，下面我们进行演示一下 首先在对话框中选择想要的进行生成接口用例的接口 选择后，直接点击按钮发送，之后它就会根据接口的请求信息，还有接口用例的设计方案，生成接口用例，下面是其中一个的接口用例，有正向、
• 11.09 10:13:38
  发表了文章 2026-11-09 10:13:38

  我做了一个测试工程师专属的面试题网站，面试前快速复盘

  不少测试小伙伴准备面试的时候会遇到一些问题：网上面试题零散分布，东找一点西拼一点，很多答案老旧，分不清哪些是现在面试官真正会问的； 整理笔记耗大量时间。 所以我搭建了一个 测试工程师师专属的面试题网站。 如果你想系统复习，可以从测试理论、用例设计、接口、性能、自动化一路往下看；如果简历里写了电商、支付、即时通讯、直播或 SaaS 项目，也可以直接进入对应业务专题，重点准备项目追问；如果正在补 AI 测试，还能单独查看大模型、Agent、AIGC 评估和 AI 安全相关内容。 网站同时提供 阅读模式和练习模式 。阅读时可以通过文章大纲快速定位问题；练习时可以先看题目、自己组织答案，再展开解析。遇
• 11.06 10:49:35
  发表了文章 2026-11-06 10:49:35

  如何根据项目代码生成测试用例

  不少测试同学都有过类似的想法： 能不能让 AI 直接阅读项目代码，自动生成某个功能或模块的测试用例？ 从技术实现上看，这件事并不难。AI 可以分析接口、条件分支、异常处理和数据流转，再按照固定格式整理成测试用例。 但如果真正用于项目测试，“直接生成”并不是最稳妥的方式。 代码描述的是系统当前如何实现，不一定完整代表业务原本应该如何运行。如果代码中存在逻辑遗漏、实现偏差，或者部分规则没有写在代码里，完全以代码为依据生成用例，就可能把这些问题一并带入测试设计。 因此，我采用了一种更适合实际工作的方式： 1. 先让 AI 深入阅读指定功能的相关代码； 2. 根据代码还原业务流程，提炼测试点； 3.
• 11.05 10:15:06
  发表了文章 2026-11-05 10:15:06

  测试提效 Skill：基于需求文档自动生成测试计划

  在测试工作里，写测试用例之前，通常还有一个很容易被忽略的环节： 测试计划。 很多时候，需求文档刚写完，大家就急着拆测试点、写用例、排执行时间。但如果一开始没有把测试目标、范围、优先级、环境、数据、人员投入和风险梳理清楚，后面很容易出现这些问题： 用例写了很多，但和本次需求范围不完全匹配； 重点功能没有提前标出来，执行时才发现时间不够； 测试环境和测试数据准备晚了，提测后被环境问题卡住； 需求变更后，测试范围和排期没有同步调整； 评审时大家关注用例细节，却忽略了整体测试策略。 所以这次 OpenTest新增了一个能力：根据需求文档生成测试计划。 核心作用是 先基于需求文档生成一份结构化的测试计划
• 11.03 10:46:00
  发表了文章 2026-11-03 10:46:00

  AI测试平台

  随着 AI 技术普及，很多团队都希望搭建一套 AI 测试平台：统一管理各类测试资产，把 AI 能力嵌入测试流程，帮助日常测试提效。 同时现在不少企业招聘里，测试平台搭建、二次定制开发，也已经是测试工程师很重要的加分项。如果只会使用现成工具，很难做出差异化竞争力。 基于这些考量，我这边也开始进行AI测试平台的开发。市面上同类产品虽然不少，但大多很难贴合自己的业务场景。  所以还是打算按照真实测试需求， 从零搭建一套适配度更高的平台。平台定位覆盖测试全流程常见场景，接入 AI 能力赋能测试提效 。 目前核心功能已经完成了一些，后续也会持续迭代扩充能力。 核心功能介绍 一、需求管理 首先是
• 11.02 10:29:32
  发表了文章 2026-11-02 10:29:32

  花了几个月，终于把测试全流程 Skill 搭好了

  从年初开始，我断断续续一直在搭建测试相关的提效 Skill。 最初只是想解决几个具体问题：需求文档太长，怎么更快梳理测试点；接口文档不完整，怎么辅助生成用例；重复的页面操作，能不能交给自动化工具执行。 但随着使用场景越来越多，我逐渐发现，单独解决某一个环节还不够。 测试工作是一条连续的链路：从理解需求、分析风险，到设计用例、准备数据、执行测试，再到提交缺陷、回归验证和结果分析。任何一个环节没有衔接好，后面的效率都会受到影响。 于是，这件事从“做几个实用skill”，慢慢变成了“搭一套测试全流程 Skill”。 前后花了几个月，目前这套体系终于基本成形：共整理了 70+ 个 Skill，覆盖用例

2026年10月

• 10.30 09:54:38
  发表了文章 2026-10-30 09:54:38

  我开发了一个测试工具

  不少测试人员会遇到这些问题：手工编写用例效率偏低，需求改动后修改繁琐；普通 AI 工具仅支持一次性生成，无法灵活局部调整；写用例、调试接口还要切换多款软件。 基于日常测试过程里的真实痛点，我开发了 【RainaTest】 桌面端测试工具，支持 macOS / Windows ， 能够根据需求文档、截图、接口信息等素材对话生成测试用例，支持增量修改、差异对比；内置接口执行能力，可调试运行接口、生成测试报告；兼容多种大模型，自带测试实用工具箱，一套工具覆盖测试多个工作环节。 下面给大家介绍下目前已更新的主要功能，工具目前还在完善中，接下来也会围绕测试全流程持续迭代新功能\~ 工具展示： 相对传统方
• 10.29 10:14:51
  发表了文章 2026-10-29 10:14:51

  手把手教你使用Claude Code

  现在不少测试同学都会借助 Cursor、Codex、Trae、Claude Code 这类 AI 工具提升日常工作效率。 之前我已经分享过 Cursor、Codex 、Trae的从零上手教程，收到很多小伙伴反馈，希望能讲讲 Claude Code 的基础用法。这篇文章，就给大家带来 Claude Code 的完整使用教程。 内容包含 安装教程（Mac、Windows系统） 订阅和接入国内大模型 如何导入&使用Skill 如何配置&使用MCP 一些常用场景 一、如何安装 现在对于 claude code的安装条件变得严格，安装都需要进行K学上网，如果没有的话，需要先了解一下这一块的内容 Mac
• 10.28 10:18:26
  发表了文章 2026-10-28 10:18:26

  AI 辅助鸿蒙 APP UI 自动化实践

  之前分享过 Android 和 iOS 平台的 AI 辅助 UI 自动化方案。不少伙伴看完之后，都希望能配套鸿蒙端的实现。 鸿蒙 UI 自动化的实战落地并不简单。 相比 Android 和 iOS，鸿蒙生态下 UI 自动化相关的实战资料还不算多。经过多轮调研与踩坑验证，整理出基于 Hypium + HDC 的鸿蒙 APP UI 自动化完整实践方案。 覆盖自动化落地全链路：从前期技术调研与方案探索、脚本编码开发、用例执行与测试报告输出，再到问题定位、脚本迭代修复。希望可以给正在做鸿蒙端自动化的同学提供参考，减少重复踩坑。 为什么选择 Hypium + HDC 做鸿蒙 APP UI 自动化，绕不开
• 10.27 09:39:48
  发表了文章 2026-10-27 09:39:48

  解决 UI 自动化定位痛点 ! 我封装了这套Skill

  做UI自动化测试的不少同学可能都有遇到过这种问题：脚本运行极其脆弱，前端稍微调整页面样式、DOM 结构、文案，整套定位代码直接大面积报错，后续维护成本翻倍。 目前稳定的元素定位优先级里， data-testid 是大家比较认可的，它和样式、页面结构解耦，只要标识不变，无论前端怎么重构页面，自动化脚本都无需改动，是保障用例长期稳定运行的最优解。 元素定位稳定的优先级如下： 理论上我们只需要让前端在交互元素上统一补充 data-testid 就能解决问题，但实际情况总是不理想： 1. 前端开发日常业务排期紧张，额外增加埋点属性会占用开发时间，普遍抵触； 2. 团队缺少统一规范，手动新增容易出现命名
• 10.23 10:31:53
  发表了文章 2026-10-23 10:31:53

  用 AI 做小程序 UI 自动化测试：从搭环境到生成报告

  哈喽，我是 Raina。  之前我们分享过 Web 、APP和桌面端的 UI 自动化测试方案。后来也有不少同学问：小程序端的自动化能不能结合 AI 去实现呢？ 答案是可以，而且微信官方已经提供了对应的框架： miniprogram-automator 。 这篇文章就结合一次实际落地过程，讲清楚小程序 UI 自动化怎么跑起来，以及如何借助 Skill 把“探索页面、生成脚本、执行用例、输出报告”这条链路串起来，尽量少写重复代码，让方案更容易在团队里推广。 为什么选 miniprogram-automator 小程序自动化方案有不少，但综合适配性和稳定性来看，官方的 miniprogra
• 10.22 11:10:16
  发表了文章 2026-10-22 11:10:16

  什么是 Jev？在测试领域中可以怎么应用？

  最近有个AI热点概念： Jev ，一款专门用来做判断的 AI 模型。 它和 ChatGPT、Claude 这类通用大模型不同：不聊天、不写代码文案，专门给程序做决策判断，API 调用后直接返回代码可读取的结构化结果 核心能力： Noul 是非判断 ：输出 0\~1 概率值，做二分类判定。例：校验接口返回是否符合预期。 Choice 多选判定 ：最多支持 255 个自定义选项，选出最优结果并附带置信度，适合 UI 自动化选择页面元素、判断业务分支。 Score 分级打分 ：2\~10 档评分，用来评估风险等级、缺陷严重程度这类有强弱差异的场景。 最近有些测试同学对这方面感兴趣，我花时间调研并简单
• 10.21 09:46:44
  发表了文章 2026-10-21 09:46:44

  基于 JEV 的 UI 自动化改造实践：从页面探索到失败修复

  最近讨论度很高的 AI 模型： JEV 。 它和常见的大模型不太一样。ChatGPT、Claude 这类模型更擅长对话、生成文本、写代码、解释问题；JEV 的定位更窄一些，主要用来做判断。调用接口后，它会根据输入内容返回结构化结果，程序可以直接读取这个结果，再决定下一步怎么执行。 这个特点很适合放在自动化流程里。 以 UI 自动化测试为例，传统脚本通常是提前写好步骤：点击哪个按钮、输入什么内容、断言哪个元素出现。只要页面结构稳定，这种方式没有问题。但在实际项目里，页面经常会出现一些不确定情况： 同一个业务入口在不同环境里文案不完全一致； 页面上有多个相似按钮，需要判断应该点哪一个； 执行失败后
• 10.20 10:18:58
  发表了文章 2026-10-20 10:18:58

  需求文档不完整，测试用例怎么写？我用 Playwright CLI + Skill 跑了一套新流程

  很多测试同学写用例时，最头疼的不是设计测试点，而是需求资料不完整。 常见情况有两种： 一种是没有完整需求文档。需求分散在会议纪要、聊天记录、原型截图里，甚至只有一个已经开发出来的页面。 另一种是有文档，但写得比较粗。比如只写了「支持新增、编辑、删除」，但字段规则、按钮状态、异常提示、权限差异、页面跳转都没有展开。 这种情况下，如果完全靠测试自己脑补，很容易出现几个问题： 用例步骤和实际页面对不上； 测试点遗漏，尤其是异常场景、权限场景和边界场景； 需求和页面不一致时，不知道应该以哪边为准； 用例写完后，执行阶段才发现理解有偏差，又要返工修改。 我的方案 针对上面的痛点，我最近尝试了一套新的流程
• 10.19 10:47:15
  发表了文章 2026-10-19 10:47:15

  测试人必备：快速基于接口文档!表结构进行造数

  造数是测试日常高频工作。很多时候我们只能在页面一步步手动操作来造测试数据，反复点击很耗时间；也有同学直接手写 SQL 插库，或是手动拼接接口请求，同类场景反复编写，重复工作量很大。 那么，有没有更轻量化、快速的造数方案？ 本文分享一套 Skill 实现思路：基于接口文档、HAR 包、CURL 语句或者建表 SQL，自动产出 Postman 请求 JSON、SQL 脚本、Python 造数脚本，一键生成测试数据，减少重复编码，提升造数效率。 我的方案：封装 seed-test-data 造数 Skill 核心能力：  ✅ 多输入源兼容：有接口文档就用文档，没有文档可以用 HAR/CUR
• 10.16 09:39:43
  发表了文章 2026-10-16 09:39:43

  测试人必备：快速基于接口文档/表结构进行造数

  造数是测试日常高频工作。很多时候我们只能在页面一步步手动操作来造测试数据，反复点击很耗时间；也有同学直接手写 SQL 插库，或是手动拼接接口请求，同类场景反复编写，重复工作量很大。 那么，有没有更轻量化、快速的造数方案？ 本文分享一套 Skill 实现思路：基于接口文档、HAR 包、CURL 语句或者建表 SQL，自动产出 Postman 请求 JSON、SQL 脚本、Python 造数脚本，一键生成测试数据，减少重复编码，提升造数效率。 我的方案：封装 seed-test-data 造数 Skill 核心能力：  ✅ 多输入源兼容：有接口文档就用文档，没有文档可以用 HAR/CUR
• 10.15 10:52:56
  发表了文章 2026-10-15 10:52:56

  基于Skills的接口自动化测试｜新增知识图谱 + 增量代码生成

  哈喽，我是 Raina～ 之前我们分享过一套 AI 驱动接口自动化 方案：基于 JSON 编排实现接口链路串联，代码框架封装在 Skill 里，比较适合代码基础薄弱、希望快速落地接口自动化的同学。 但在企业真实场景里，还有一类更普遍的需求： 团队已经有自己搭建好的接口自动化框架，日常以增量方式新增接口用例，而不是每次从零生成一套工程。 这类同学往往不需要 Excel / JSON 编排那一套，而是希望 AI 能直接生成 pytest 用例代码，并且不破坏现有工程结构——在原有框架上「加文件、加用例」就行。 那么，能不能在原有方案基础上，补上「接口依赖可视化 + 增量代码生成」这两块能力？ 针对
• 10.14 11:14:42
  发表了文章 2026-10-14 11:14:42

  AI 赋能测试：一套基于源码的 Skill 矩阵，不用啃代码也能全链路提效

  哈喽，我是 Raina～ 很多测试同学都会遇到这个难题：项目源码阅读门槛高，不少测试本身看不懂代码。就算能读懂，接口调用层层嵌套、业务分支分散在不同文件，梳理完整业务链路的成本很高。 业务复杂度上来后，问题就更多了：分支梳理不全容易漏测，难以确定压测接口；需求、接口文档更新滞后，和实际代码实现脱节。我们大多只能通过页面操作推测业务，很难快速拿到代码里真实的业务规则。 有了 AI 之后，就有了更省力的办法：不用人工研读代码，让 AI 解析源码，直接产出测试可用的各类资料。 这段时间我陆续封装了多套源码方向的测试 Skill：生成接口文档、输出代码变更回归清单、绘制业务流程图、反向还原需求、扫描并
• 10.13 10:17:00
  发表了文章 2026-10-13 10:17:00

  测试工程师必备：源码并发风险扫描 Skill 来啦！

  实际项目里，测试同学往往很难提前判断 哪些接口需要压测 ，也识别不出 哪些接口潜藏并发风险 。 大多都是线上出了故障之后，才后知后觉去补性能压测。缺的不是工具，而是 白盒层面的前置识别手段 ——流量一冲高，各类并发问题就容易集中爆发。 那么：我们 能不能让 AI 直接读源码，提前把并发隐患挖出来，而不是等线上出了问题才来补救？ * 一、黑盒模式的 4 个常见问题 在没有白盒扫描之前，团队里最常见的 4 类痛点： 1. 并发风险靠经验判断   哪些接口存在并发隐患、需不需要做压测，大多是资深测试或者产品凭经验来定。新人很难识别出来，很容易漏掉风险点。 黑盒功能测试很难挖到代码层面问题
• 10.12 10:05:15
  发表了文章 2026-10-12 10:05:15

  开源一个支持多数据源的 MySQL‑MCP

  日常测试工作里，我们经常要核对业务数据：校验接口入库结果、排查 bug 底层数据、核对业务流程前后的数据变化，都免不了要和数据库打交道。 现在很多测试同学，也会借助 AI 来做这块的提效，不用手写复杂 SQL，通过自然语言就可以查询库表数据。开源的 MySQL MCP 就是很常用的工具，对接数据库之后，直接用自然语言就能转换成 SQL 执行查询，给测试的数据核查工作带来不少便利。 但在实际使用中会有些局限：这套开源实现 只支持配置单个数据库 。  实际的业务项目，大多是多套数据库并存，业务数据分散在不同库、不同实例中，单数据源的能力，很难适配复杂项目的测试核查需求。 针对这个测试工作
• 10.10 11:29:42
  发表了文章 2026-10-10 11:29:42

  测试工程师必备：代码一键生成业务流程图Skill

  日常做测试，遇到复杂业务时，我很依赖后端提供的业务设计流程图。 有了流程图，我可以快速吃透内部实现逻辑，更有针对性地设计测试用例，甚至在前期就能识别出流程隐患，推动开发提前修复，避免问题流入测试阶段打乱整体迭代节奏。 但在 AI 普及之前，流程图需要开发手动绘制，耗时成本高，很多时候很难拿到完整的文档。 现在借助 AI，直接基于源码生成业务逻辑图就变得简单很多。 基于这个真实工作场景，我封装了一款 Skill，可以读取项目代码，快速输出模块与业务流程图。 测试同学如果拥有代码权限，可以直接自行生成；没有权限的话，也可以把这个 Skill 交给开发同事协助产出。 基于代码生成流程图，对测试有哪些
• 10.08 09:50:28
  发表了文章 2026-10-08 09:50:28

  测试工程师必备：HAR 一键生成 Skill！禅道建用例 ! 提 Bug 不再受版本限制

  前段时间在开发禅道提交Bug的skill时，遇到了一个问题：禅道官方提供的 cli 和 mcp 有版本限制，只有比较高的版本才可以使用，不少团队还在使用低版本禅道，这套能力就直接无法使用，提 Bug、建用例想用 AI 提效，链路直接断掉。 针对这个版本兼容痛点，我想到一个思路—— 开发一个用来创建 Skill 的 Skill ：不再依赖禅道原生接口工具，而是把浏览器抓下来的 HAR 文件当作输入数据源 ，自动梳理请求、凭证和变量，再生成对应业务 Skill，从根源绕开版本约束。 并且我把它封装成通用能力，并不局限禅道这一个系统。 比如公司内部自研的工时填报系统、Bug 管理平台，都可以通过一份

2026年09月

• 09.29 15:51:53
  发表了文章 2026-09-29 15:51:53

  测试工程师必备：HAR 一键生成 Skill！禅道建用例 / 提 Bug 不再受版本限制...

  测试工程师必备：HAR 一键生成 Skill！禅道建用例 / 提 Bug 不再受版本限制...