1. 小城测试工程师的破局为什么我在菏泽押注AI测试1.1 重复劳动的尽头我看到一条不一样的路2019年冬天我在菏泽一家做软件外包的公司做功能测试。公司不大测试团队加上我总共三个人每天的工作内容高度一致打开JIRA、按测试用例点点点、截图、提Bug、写测试报告。一个月大概要手工执行两百多条用例遇上发版高峰期连续加班到晚上十点是常事。做完一整轮回归测试之后我的脑子往往是麻木的。这种麻木是双重的一方面是身体累另一方面是心累——我隐隐约约意识到同样一批用例上个月点了这个月点下个月还要点唯一变化的可能只是按钮的位置和弹窗的颜色。我的技能没有积累我的时间在被匀速消耗。这样的状态持续了大概一年。转折点是在2020年春天我被分到一个App端的兼容性测试项目里要覆盖十几款安卓机型每款机型上都要把核心流程跑一遍手工操作的工作量直接翻倍。我当时实在受不了了就从网上找是否有自动化的工具能帮我减轻工作量。搜索结果里出现了大量自动化测试的内容顺着这些内容我一步步接触到了Selenium、Appium这类工具。学着学着又发现网上关于AI测试的讨论多了起来而且看起来比传统自动化更「聪明」——能自己识别控件、能自己生成用例、能对模糊结果做判断。当时我对AI测试的理解还停留在很浅的层面一度以为就像给测试工具装了个脑子让工具自己想怎么点就怎么点。后来真正做起来才发现AI测试和传统自动化是完全不同的两条技术线但正是这两条线之间的差距成了我从小城走向国际项目的关键跳板。1.2 AI测试与传统自动化测试的分水岭在哪里很多测试同行对AI测试的最大误解是以为它只是传统自动化测试的升级版比如让脚本更智能一点元素定位失败时自动换一个策略。这种理解不能说全错但远远低估了AI测试带来的变化。我个人的体会是两者的核心分水岭在三个维度上。第一个维度是输入对象。传统自动化的输入是明确的你要告诉工具哪个按钮的ID是什么哪个输入框的XPath是什么一切以确定性为前提。而AI测试的输入可以是模糊的你给它一张截图告诉它找到登录按钮它基于图像识别或语义理解去自己判断按钮在哪你告诉它帮我生成一组测试登录页面的用例它基于大模型的推理能力直接给出测试步骤和预期结果。一个依赖定位信息准确一个依赖业务理解充分两者的起点就不同。第二个维度是对变化的态度。传统自动化脚本最怕一个字变。开发把按钮的ID从login_btn改成login_button脚本就崩了必须等人去改脚本。AI测试正好相反它天然容忍变化基于视觉定位的AI测试哪怕按钮的文字颜色变了、位置挪了几像素照样能认出来基于大模型判定的测试哪怕页面文案完全不同只要表达的业务意图一致它也能给出正确的判断。这一点在做复杂业务系统的回归测试时价值极大。第三个维度是输出边界。传统自动化只能回答是/否——运行通过没通过。AI测试可以做更多它可以告诉你这个页面布局异常的概率是87%可以给缺陷自动分类分级可以生成可读性很强的自然语言测试报告甚至能根据历史缺陷趋势预测当前版本的薄弱环节在哪。这不是测试工具了这更像一个具备分析能力的测试同事。想明白这三个分水岭之后我确定这是一个值得认真投入的方向。我当时所处的环境——小城市、小团队、没有技术牛人带——反而成了我的优势没有那么多框架束缚我可以自己摸索出一条真正适合普通测试工程师落地的AI测试路线。这条路线我从零开始走了两年多下面把我验证过的路径完整分享出来。2. 从零搭建一套能跑的AI测试框架工具选型与落地细节2.1 技术选型我最终用哪几个工具组了框架刚开始研究AI测试时我犯过一个所有新手都会犯的错被工具晃花眼。网上一搜AI测试平台一大把有的号称能自动生成用例有的说自己能秒级定位缺陷还有的宣称零代码全自动测试。我一开始也动了用现成平台的念头但试用下来发现绝大多数商用平台的问题是准备成本极高——业务接入、数据标注、权限审批一个平台要对接好久而且它内部的实现是黑盒出了问题你根本不知道是AI判断错了还是平台本身有Bug。后来我调整了策略不追求全自动AI平台而是走了一条更务实的路用轻量级的AI能力赋能现有的自动化测试框架只把AI用在能明显降低人力成本、提升判断质量的地方。这个思路下面我最终敲定了一套组合职责工具/方案选型理由自动化执行框架基于Python的Pytest Appium/Selenium社区成熟、资料多、脚本语言简单后续扩展性好AI视觉识别OpenCV模板匹配 截图比对自研封装轻量、不需要额外算力适合处理元素定位兜底和UI布局对比AI语义能力大模型API接入先用云端API跑通后续可以部署开源模型用于测试用例生成、缺陷文案判断、异常描述分类是AI测试含金量最高的部分推理判定服务自建的模型参数配置与API网关可理解为微型图灵测试服务器统一管理模型调用、参数调节、日志记录方便测试脚本以API方式稳定获取AI判断结果报告生成脚本自动汇总测试数据交给大模型生成自然语言总结消灭人工写测试报告的时间同时还能给出风险提示这套组合的核心思想是传统自动化负责执行AI负责判断和生成。执行需要确定性AI做判断时带有不确定性两者解耦出了问题也容易定位。文件目录结构也分享一下ai_test_framework/ ├── src/ │ ├── ui_automation/ # 基于Appium/Selenium的执行层 │ │ ├── app_driver.py │ │ └── element_locator.py │ ├── ai_engine/ # AI能力封装层 │ │ ├── llm_client.py # 大模型API调用 │ │ ├── vision_matcher.py # 视觉识别模块 │ │ └── config.py # 模型参数配置文件 │ ├── report/ │ │ └── report_generator.py │ └── test_cases/ │ ├── test_login_flow.py │ └── test_payment_flow.py ├── config/ │ └── model_config.yaml # 图灵测试服务器的参数配置 └── run_all.py2.2 模型服务器的参数配置与API方式接入最关键的实操环节我前面提到图灵测试服务器这不是一个标准术语而是我给自己搭的模型推理服务起的叫法。它的本质是一个常驻运行的模型服务我通过HTTP API的方式向它发请求它能返回AI的判断结果。这个设计让我在写测试脚本时完全不用关心模型具体部署在哪、底层用什么框架只需要像调用一个普通接口一样拿结果。先看我的模型配置文件config/model_config.yamlmodel: server_url: http://localhost:8810/v1 # 模型服务地址 model_name: qwen2.5-7b-instruct # 开源模型 api_key: sk-test # 本地服务可不鉴权 generation_params: temperature: 0.1 # 测试场景要低随机性尽量稳定输出 top_p: 0.9 max_tokens: 1024 frequency_penalty: 0.2 presence_penalty: 0.0 vision: match_threshold: 0.92 # 视觉匹配置信度阈值这几个参数看着简单其实每一行都有讲究尤其temperature。做测试判定时我们希望AI的输出尽量稳定、可复现同一个页面截图今天判断是故障明天也必须是故障。如果把temperature调到1.0甚至更高AI会变得有创意同一张图它可能给出完全不同的判断这在测试场景里是灾难。所以我的经验是测试场景AI参数随机性越低越好。temperature一般0.1~0.3之间top_p可以固定在0.9左右max_tokens按输出长度需求来基础判定任务256就够生成测试用例或报告时再加到1024以上。接着是API接入的Python封装我直接给出来这是最核心的代码片段import requests import yaml import json import logging logger logging.getLogger(__name__) class LLMClient: def __init__(self, config_pathconfig/model_config.yaml): with open(config_path, r, encodingutf-8) as f: cfg yaml.safe_load(f) self.server_url cfg[model][server_url] /chat/completions self.model_name cfg[model][model_name] self.api_key cfg[model][api_key] self.params cfg[generation_params] def judge_bug_severity(self, description: str) - dict: 让AI根据缺陷描述判断严重级别 prompt f你是一名资深测试工程师请根据以下缺陷描述判断严重级别。 严重级别只允许从以下四个中选一个致命(Critical)、严重(Major)、一般(Minor)、轻微(Trivial)。 输出格式为JSON包含severity和reason两个字段。 缺陷描述{description} resp self._call(prompt) return self._parse_json_response(resp) def _call(self, prompt: str, temperatureNone) - str: payload { model: self.model_name, messages: [{role: user, content: prompt}], temperature: temperature if temperature is not None else self.params[temperature], top_p: self.params[top_p], max_tokens: self.params[max_tokens], frequency_penalty: self.params[frequency_penalty], presence_penalty: self.params[presence_penalty], } headers {Content-Type: application/json, Authorization: fBearer {self.api_key}} resp requests.post(self.server_url, headersheaders, jsonpayload, timeout60) if resp.status_code ! 200: logger.error(fLLM API error: {resp.status_code} {resp.text}) raise RuntimeError(fModel server error: {resp.status_code}) return resp.json()[choices][0][message][content] def _parse_json_response(self, content: str) - dict: 容错处理模型偶尔会输出多余文本需要剥离JSON content content.strip() start content.find({) end content.rfind(}) if start -1 or end -1: return {severity: 未知, reason: content[:50]} return json.loads(content[start:end1])这段代码最值得注意的地方是_parse_json_response。大模型的输出不一定每次都是干净的JSON有时它会多解释一句根据以上分析我的判断是...之类的话。如果你不做容错直接json.loads很容易崩。这个坑是我跑了半个月之后才踩到的做了剥离处理之后稳定了很多。2.3 从一条用例跑通到测试全流程铺开框架搭好之后我没急着写一堆测试脚本而是从一条登录用例开始跑通。这个策略很重要——验证链路通不通、哪里容易出错、延迟高不高都要在最小范围里看清楚。第一步跑通一条App登录用例。在这个环节AI主要承担两个工作一是当Appium的常规定位ID定位、XPath定位失败时自动切到视觉识别兜底二是用大模型判断登录成功页和预期是否一致。第二步是异常检测。我在测试脚本里写了一个通用方法每个关键页面操作完成后自动截一张图与基线截图做像素级对比偏差超过阈值的页面再交给视觉模块和大模型做二次判定。这一步最有价值的地方在于传统脚本只能检查预埋的插件是否弹出比如你预埋了登录失败弹窗的检查点脚本就只会检查这个点但AI异常检测没有预先定义任何异常它是通过看整个页面的差异来发现问题的。有一次我们是弹窗文案错了传统脚本根本不会管文案内容是AI视觉比对发现页面和基线不一致才顺藤摸瓜查出来。第三步是把AI能力铺成流水线变成测试全流程的一环测试数据准备让AI根据业务规则自动生成合法的注册数据、支付数据节省测试造数时间。测试用例生成输入需求描述让AI输出覆盖范围更全面的测试用例初稿人工审核补充。测试执行自动化脚本 AI视觉定位兜底。缺陷分析AI自动给缺陷分类分级并提取关键字模块、页面、错误类型。测试报告AI基于测试数据生成自然语言总结包括风险提示。这条链路跑通之后我手里的测试产出效率有了质的提升。原来的手工用例执行从每天几十条提升到几百条更关键的是AI替我承担了大量判断的工作我终于能从重复劳动里抽身出来研究更深的问题。3. 让AI真正懂业务模型调优与提示词工程的经验3.1 通用模型在测试场景里的水土不服很多测试同行拿到大模型API之后第一反应是直接往上怼测试问题然后发现效果不对劲于是得出AI测试不行的结论。其实问题可能不在AI而在你没有理解通用大模型的边界。我做过一个实验让一个通用大模型判断缺陷严重级别。我输入用户在支付页面点击确认支付时页面卡住无响应但稍后检查发现订单已生成大模型给的回答是严重Major——交易状态不明确建议优先处理。这个判断不能说是错的但真正的测试工程师会知道这是一个**致命级Critical**问题用户看不到结果极大概率会重复支付造成资金损失。通用模型缺乏业务上下文它只能在文本表面意思上做推理。这说明一个关键点AI测试不等于把问题丢给模型这么简单。想让AI真正为测试服务核心工程是在两个地方下功夫一是提示词工程把测试思维写进模型请求里二是上下文注入把业务背景和行业规则告诉模型。只有做好这两件事AI才是懂测试的AI而不是什么都懂一点但都不够深的通用模型。3.2 提示词工程实战把测试思维写进模型我调提示词的过程可以拿缺陷分级这个例子完整还原。第一版提示词很简陋效果也一般请判断这个Bug的严重程度{description}换成更完整的提示词模板后效果立竿见影你是一名具有10年经验的软件测试工程师正在负责一个B2C电商App的测试。 请根据以下缺陷描述判断其严重级别。 严重级别定义 - Critical致命导致系统无法上线、资金损失、核心功能完全不可用、数据丢失或安全问题 - Major严重主要功能无法正常使用但存在绕过方案 - Minor一般功能可运行但体验明显受损有临时替代方案 - Trivial轻微外观、文案、布局等不影响功能的细节问题 判断规则 1. 优先考虑影响范围涉及资金、数据、安全的问题自动提升一级 2. 考虑用户可感知程度用户无法看到操作结果时优先判为Critical 3. 如果存在绕过方案最高只能到Major 输出JSON格式包含severity只能取Critical/Major/Minor/Trivial、reason判断理由不超过50字、suggestion修复建议不超过50字。 缺陷描述{description}这个模板最大的变化是给了模型判断框架。它不是让模型从零开始想问题而是给它提供了一套测试专家的思考逻辑影响范围、用户感知、绕过方案。模型在给定框架里做判断准确率提升非常明显我后来粗略统计过缺陷分级准确率在80%以上处理速度快了几个量级。同样逻辑也用在测试用例生成、测试数据生成、报告总结上。核心原则就一句话你想要专家的判断就在提示词里给出专家的思维模型而不是指望模型自己悟出来。这背后是大模型的推理特点——它在你给定的上下文约束下表现得最好约束越清晰输出越可控。3.3 处理误报与边界意识AI测试不是万能钥匙AI测试用多了之后你会发现一个绕不开的问题误报。AI视觉比对会把文案正常变更当成页面异常大模型判断也会出现结论不一致的时候。怎么处理误报直接决定这套体系能不能长期跑下去。我的做法是给所有AI判断加一道人工复核出口。具体来说设计了三级判定流程第一级AI快速预筛。视觉比对发现有差异的截图交给大模型先判断一次正常变更直接过滤掉。第二级置信度阈值拦截。大模型判定为高风险时如果置信度低于95%不直接上报而是进入待确认池。第三级人工复核池。每天测试结束后测试人员只需要花十几分钟翻一下待确认池确认为真实缺陷后再提单。这样既保留了AI的高效筛查能力又用人工复核兜住了误报风险。我这里要特别对做游戏测试的朋友多说一句。热搜词里有一条是如何让AI测试游戏正好踩坑过。游戏测试比App测试更复杂因为游戏有实时渲染、帧率变化、动态特效单纯用像素比对做UI检测会产生大量误报。我的经验是游戏测试里AI更适合做三类工作一是静态UI资源检查图标缺失、图片拉伸、文案重叠二是战斗数值验证通过OCR识别飘字数字交给模型判断是否在合理区间三是关卡体验日志分析把大量日志文本交给模型总结共性异常。至于实时的、帧级的行为判定目前AI的可靠性还不够不要强行让人工智能承担它现阶段还做不好的事。边界意识说到底就是一句话AI测试是用来放大测试工程师的能力不是来取代测试工程师的判断的。认清这个边界AI测试的落地反而会更顺利。4. 国际项目实战AI测试如何帮我敲开大门4.1 从简历到面试为什么AI测试经验能拉开差距大概2023年初我所在的菏泽公司接到了一个跨境项目的测试需求——帮一家海外公司做支付核心链路的回归测试。项目组需要英语能力还行的测试工程师更重要的是他们希望测试团队能快速上手一套全英文测试平台而且测试周期非常紧。这个项目给了我很大的启发过去我总觉得在国际项目中自己的短板是英语和对海外业务的陌生感但真正到项目里发现对方最在意的其实是你能不能用最小的时间成本理解业务、搭建测试能力、产出可靠结果而AI测试恰好解决了这套问题。先说说面试环节。国际项目的面试官几乎都会问你做过哪些测试提效的工作。传统答案大多是搭了一套自动化脚本跑回归快了多少倍这种回答对方听太多了。而我的回答是我用AI视觉识别解决了跨版本UI回归的高误报问题用大模型做缺陷自动分级把排查缺陷的时间缩短了50%以上。面试官对这部分明显更感兴趣会追问模型参数怎么调、怎么保证输出稳定、误报率如何控制。这些是我实打实做过的东西答起来有底气。还有一个意外的加成因为AI测试的工作涉及到和模型API交互我自然要阅读大量英文技术文档很多大模型的文档只有英文版这反而倒逼我的英文阅读能力提升了一大截。等真正接触国际项目时我已经习惯了用英文读技术资料、写测试计划整个人的节奏是流畅的。后来我总结出一个经验技术上的能力升级往往会顺带解决语言和文化上的适应问题因为技术文档本身就是跨越语言障碍的最好媒介。4.2 国际协作项目中AI测试的真实工作方式到了国际项目里我发现AI测试的优势被放得更大了因为跨国协作有几个天然痛点AI恰好都能帮上忙。第一痛点是时差导致的异步协作。海外团队和我们有6到14个小时的时差你在办公时间跑出Bug提给海外开发人家可能已经下班了。这时候缺陷信息的质量就异常重要——描述是否清晰、是否包含足够的上下文、是否给出疑似原因。我让大模型在每次提缺陷时自动生成一份增强描述把操作步骤、实际结果、预期结果、截图、日志片段、可能的触发条件全部结构化输出。海外开发看到这样的缺陷描述基本不需要再返回来追问修复效率明显提高。第二痛点是业务领域的陌生感。海外项目的业务规则、合规要求和我们日常接触的不一样。比如支付卡单处理、退款流程每个国家有自己的逻辑。我拿到需求文档后第一件事不是写测试用例而是把需求文档的核心片段喂给大模型让它生成测试要点、边界条件和风险场景清单。然后我再结合自己的测试经验去审核、补充。这样做的好处是一个陌生领域的测试设计时间从几天压缩到了一天以内而且覆盖角度比我一个人看文档要全得多。第三痛点是跨语言缺陷沟通。海外项目缺陷单要用英文写我虽然英语读写没问题但要把一个复杂的业务异常讲得既准确又简洁还是有点费劲。大模型又帮了大忙我把中文描述丢给模型让它转成正式、简洁的英文缺陷报告顺带给出标题建议。整个缺陷提交流程的产出质量比我手写强太多了。我的体会是在国际项目中AI测试的价值不只是在测这个动作上而是在整个测试工作的信息传递链条上——生成、判断、翻译、总结每个环节都提效了。4.3 三个让我在国际项目里站稳脚跟的AI测试实操场景场景一支付流程的AI异常检测。支付链路是典型的不能漏任何异常的业务我设计了一套基于视觉比对和大模型判断的监控逻辑每一步页面变化自动截图比对文案异常、按钮缺失、流程跳转错误都能及时发现。有一次因为某个海外渠道的品牌logo下发了错误版本人眼很难注意到但AI视觉比对提示了页面差异人工复核后确认是高优先级的品牌合规问题避免了上线事故。场景二多语言UI的视觉回归测试。海外项目往往是多语言版本英文、德文、日文等同一套UI在不同语言下的文案长度不一样容易出现文字截断、重叠、溢出。传统脚本很难自动检查这类美观但影响体验的问题但我用AI视觉比对就很简单每种语言下都跑一遍核心流程截图交给视觉模块判断是否存在遮挡、截断等异常。这个场景在之前在国内项目里很少遇到但在国际项目中几乎天天都要用。场景三AI自动生成测试报告和风险提示。每次版本测试结束后我让模型基于测试执行数据、缺陷分布、遗留问题清单自动生成一份面向团队和管理层的总结报告内容包括关键缺陷列表、风险评估、建议上线结论。以前写一份这样的报告要花两个小时现在两分钟搞定而且风险提示部分的质量比我之前写的高很多——它会主动联想到一些我平时容易忽略的关注点比如注册页面连续失败率上升可能与后端限流相关。这种AI生成的报告在国际项目的周会汇报中被高层夸过不止一次。5. 给仍在小城或观望中的测试同行一条可复制的路径5.1 我踩过的坑从虚假期望到工具迷信写这部分之前我先说清楚AI测试不是点石成金的技术它是一条值得投入但需要避开很多坑的路。我把自己踩过的坑列出来希望你能少走弯路。第一个坑是虚假期望。我在刚接触AI测试的头两个月总幻想搭建一个AI平台测试就全自动了。真动手做之后才明白AI平台的构建和调优是一个持续迭代的过程。在最开始的头半年我的AI视觉比对模块误报率高达30%一度被同事嘲讽是制造Bug专家。千万别被网上的演示Demo骗了真实的AI测试项目有大量的脏活累活要做模型参数调优、提示词打磨、异常数据标注、阈值调整、人工复核机制的建立任何一步偷懒都会在准确率上还回来。第二个坑是工具迷信。有人觉得用了某AI测试工具就等于AI测试了这是误区。工具只是载体核心是你要理解AI测试的思维方式知道在哪个环节用AI、怎么验证AI的输出、怎么兜底。我见过用AI平台的人因为不知道平台采用的视觉算法特点遇到误报时完全束手无策。相反我自己用OpenCV写匹配逻辑虽然看起来简陋但出了问题我能看清楚原因能调整能优化。第三个坑是数据标注被忽略。AI视觉模型也好、大模型提示词也好它们的输出质量高度依赖参照数据。为了优化我的缺陷分级模块我前前后后手工整理了四个多月的历史缺陷记录给模型做few-shot示例。这个过程很枯燥很多同学坚持不下来就放弃了。但正是这些标注数据让模型的判断准确率和稳定性上了一个台阶。第四个坑是买课焦虑。小城市里没有技术圈子我当时特别容易被网络上的焦虑文案影响差点花大几千块钱买AI测试大师课。后来学进去了发现最好的学习资源几乎全是免费的官方文档、开源项目、技术社区里的分享文章。不要用买课来缓解焦虑动手搭一个最小可用的项目比看一百节课都强。5.2 普通人可复制的AI测试学习路径如果你也想从小城或者从基层测试岗走出来我的建议是把路径切碎成3个阶段每一步都做出可展示的产出。第一阶段1~2个月夯实基础产出最小Demo。先学会Python基础和Pytest的用法跑通Appium或Selenium的一个登录用例。同时了解大模型API的基本调用方式写一个最简单的把一段中文翻译成英文缺陷报告的小脚本放到自己的GitHub上。这一阶段的产出关键词是能跑。第二阶段2~4个月把AI能力接到测试流程里。在原有自动化脚本基础上选一个高频痛点动手改造。比如给你的元素定位失败处理加一个视觉识别兜底或者给测试报告生成加一个大模型总结。目标是把能用变成有用——这个改造过程可以写成你的项目实战文章是简历上最好的素材。第三阶段4~6个月做一个完整的AI测试小项目。比如基于AI视觉和语义判断的UI回归提醒系统或者基于大模型的缺陷分级分类器把上面所有能力集成在一个项目里做好参数配置、容错处理、结果可视化。这个阶段可以有底气地说自己是AI测试工程师了。我自己走完这三个阶段大概用了七八个月中间也有半个月因为公司发版压力太大几乎放弃但扛过来之后发现技术深度已经到了一个台阶。5.3 关于逆袭这件事我的真实体会回头看从菏泽小城到国际项目这个标题我必须诚实地说逆袭不是一个突然的转折而是一个累计的过程。我并没有在某个时刻突然开窍我只是一直在做一件看起来很朴素的事情把测试里最烦人的重复部分一点点地交给AI去做同时不停地学习AI背后的原理。从菏泽是被迫的因为这座小城没有大厂的工作机会但正因为如此我有了更多的时间思考和试错而AI测试给了我一个打破地域限制的机会。技术和经验是会自己长出翅膀的它会带着你走向更大的项目很多时候你自己还没有察觉路已经明朗了。最后分享一个很实用的经验作为收尾AI测试这条路千万不要一上来就想做整套大框架先从一个最小闭环开始跑通一个功能、验证一个场景再一步步扩展开来。我自己从最初一行代码到现在能支撑国际项目的测试体系中间最不后悔的决定就是当时先动手跑了第一条AI测试用例哪怕它真的很简陋。