★ FEATURED ARTICLE 这两年聊“软件测试的未来”绕不开一个词焦虑。焦虑来自自动化工具越来越强来自AI写用例、AI找Bug的demo一个比一个惊艳更来自团队里开始流传“测试是不是要被优化掉了”这种话。我自己的看法是测试不会被干掉但测试这个岗位的画像一定会被改写而且改写速度比我们想象中快。如果你现在还在用十年前那套“点点点写文档”的方式工作确实会慌但如果你愿意往前迈一步把自动化、AI当成杠杆而不是威胁这反而是测试从业者话语权变大的一次机会。这篇文章不想聊虚的就结合我这些年在一线带测试团队、做自动化平台、尝试把AI塞进测试流程的实际经历聊聊自动化到底改变了什么、AI现在到底能干哪些活、哪些是噱头以及最关键的——评测师这个角色会往哪儿走、你现在该补什么能力。1. 自动化不是“替代手工”是把手从重复劳动里抽出来1.1 自动化测试的真正价值不在“省人”在“提速反馈”很多人一提自动化第一反应就是“少招几个人”。这个认知从我实操来看是错的。自动化测试最核心的价值不是降低人力成本而是把反馈回路缩短。以前一个版本提测手工回归一轮要两三天自动化跑一遍可能就半小时。反馈快了开发改Bug的成本就低了产品迭代节奏才能上来。这才是自动化在商业上的真正意义。我见过一个项目手工回归用例大概一千二百条每次发版前全量回归要三个人连续干三天还经常漏测。后来花了大概两个月时间把其中八百条稳定用例做成接口自动化加UI自动化发版前跑一次全量大概四十分钟。注意这四十分钟不是替代了那三个人的三天而是让“每次修改后都能跑一遍”变成可能开发提测前自己就能触发质量问题前移了。所以如果你在跟领导汇报自动化价值别只讲“节省了多少人天”要讲“反馈周期从多少小时缩短到多少分钟”。后者才是业务方真正关心的东西。1.2 自动化用例的维护成本才是决定项目成败的关键很多团队自动化搞不下去不是工具不行而是用例维护成本失控。需求一变更一堆脚本跟着改改到后面没人愿意动自动化资产慢慢就腐烂了。我踩过这个坑早期做UI自动化定位全部写死开发改了个按钮ID脚本就废了每周光修脚本就要花一天。后来总结出几条经验用例分层UI、接口、单元测试分开管理能走接口层的绝不上UI层因为UI层最脆。元素定位优先用稳定的业务属性比如data-testid而不是xpath层级哪怕多花点开发成本也要约定好。用例跟需求关联需求变了先评估用例影响范围不要盲目改。定期做用例健康度检查长期不跑的、频繁失败的该删就删别心疼。这些听起来不性感但自动化能不能长期跑下去靠的就是这种“脏活累活”。1.3 自动化率不是KPI覆盖率才是我见过有团队把“自动化用例占比”当核心指标结果大家拼命把低价值用例也脚本化数字好看但Bug检出率没提升。自动化率本身没有意义它只是过程指标。真正要盯的是关键业务链路有没有被自动化覆盖自动化跑出来的结果有没有被人认真看失败用例有没有被跟踪到闭环我个人比较推荐按业务风险来定自动化优先级核心交易链路、高频回归模块、容易出现低级错误的场景优先做边缘功能哪怕是点点点也不急着自动化。自动化不是越多越好是越准越好。2. AI进入测试哪些是实打实能用的哪些还在画饼2.1 AI写用例从“辅助生成”到“人设校正”现在用大模型生成测试用例已经不是新鲜事。把需求文档、接口定义、历史缺陷数据喂进去能生成一批覆盖正常路径、边界值、异常场景的用例效率确实高。但我实际用下来AI生成的用例有个通病表面看着很全实际有很多是“正确但无用”的用例比如把同一个边界值换个写法生成好几条或者偏离真实业务逻辑。所以我的用法是AI负责出初稿人来负责“业务校验”。拿一条核心链路来说AI能帮你把“用户下单-支付-发货-确认收货”这条链路上的正向、逆向、并发、超时场景都列出来等于给了你一个checklist但哪些场景在真实业务里会发生、哪些只是理论可能存在必须由懂业务的人来判断。这个“判断”本身就是评测师的新价值。另外AI生成用例的质量很大程度上取决于你喂给它的上下文。接口文档不全、需求描述模糊的时候生成的东西就不太能看。所以做这件事之前先把输入质量搞定别指望AI能从一团乱麻里抽出金线。2.2 AI找Bug从“跑脚本”到“看异常分布”传统的自动化是“断言驱动”你写好了预期结果跑出来不一致就算失败。但AI找Bug的逻辑不太一样它是“异常驱动”通过学习历史数据建立“正常模式”然后找出偏离这个模式的点哪怕你事先没定义断言它也可能发现问题。举个例子某次我们在压测一个报表导出接口传统断言只检查状态码和响应时间但AI模型发现某些请求的成功率分布跟历史基线明显偏移虽然单看每个请求都是成功的但这个“偏移”最后定位到是数据库连接池参数被某次发布改掉了。这种问题传统自动化很难发现AI的“离群点检测”反而能发现。不过要泼盆冷水AI找Bug目前更适合做辅助巡检、异常监控、数据驱动分析它还不能代替人的测试设计。你让它独立负责一个模块的验收它可能给出大量误报反而增加人工确认成本。所以现阶段最务实的方案是AI负责“广撒网”人负责“深挖”。2.3 测试数据与脚本生成的实战组合再分享一个我实际在用的组合拳。写自动化脚本时最烦的是造数据。以前靠SQL硬插、靠手工页面录数据、靠接口调用造数据费时费力。现在我用LLM辅助写数据工厂把数据表结构、字段含义、接口入参格式告诉模型让它生成造数脚本的骨架我再调整业务规则部分。这比从零写快很多。类似地生成接口自动化脚本时先让AI根据OpenAPI文档生成Pytest风格的测试框架我再往里面填业务断言。五分钟能搭出以前一小时才写完的壳子。注意我反复强调“我来填断言”因为断言是测试的灵魂这是评测师无论如何不能外包出去的东西。3. 评测师的新工作方式人机协作而不是人机对立3.1 从“执行者”转向“审查者”和“设计者”自动化普及之后测试最重的工作不再是“执行”而是“设计”和“审查”。你设计什么样的测试决定了自动化能发现什么问题你审查AI生成的用例和脚本决定了最终交付质量。这个转变对技能栈的要求完全不同。以前你只要会点点点、会写用例、懂点SQL就能干活现在你得会读代码、懂架构、知道数据怎么流转、能跟开发讨论接口设计甚至要在需求阶段就介入把可测试性设计进去。说白了评测师越来越像“质量架构师”而不是“手工作业员”。我团队里有个A同学刚转测试的时候只会手工后来被逼着学Python、学接口测试、学Git半年后已经能独立负责一条业务线的自动化框架维护。他说最大的转折是某次线上事故开发都定位不到问题他用接口日志和数据库数据比对锁定了是缓存与DB不一致那个瞬间他意识到测试做的不只是“找Bug”而是“理解系统”。3.2 技能树重构代码能力不再是加分项而是入场券如果你现在问我想招什么样的测试我的回答很简单必须会写脚本哪怕写得不漂亮。因为这行当的底层逻辑变了一个不会写脚本的评测师在自动化时代基本只能做探索性测试的辅助角色很难主导质量工作。但不是说要人人成为代码高手。我个人建议按“测试开发”的标准去补基础会Python或Java、懂HTTP协议、会SQL、会用Git、能看懂接口文档和基本的数据结构这就够了。更深的技术栈比如性能调优、安全测试、AI模型评估是下一阶段的方向不用一口吃成胖子。3.3 测试左移与右移评测师职责范围的扩张“左移”和“右移”这两个词这几年被说烂了但它的确是评测师角色变化最实质的体现。左移是把质量活动往前推从需求评审、架构设计阶段就开始介入而不是等开发完代码再测右移是把质量活动往后延伸线上监控、日志分析、用户行为数据回流都成为测试的一部分。我自己的体验是左移做得好后端Bug会少很多。因为你在需求阶段就能发现逻辑漏洞、边界缺失连代码都不用写就消灭了一批问题。右移做得好能发现很多测试环境里根本复现不了的问题比如特定浏览器版本的渲染差异、弱网环境下的竞态条件、某些数据组合下的概率性崩溃。所以评测师的工作边界正在从“测试环境里跑用例”扩展成“全生命周期质量保障”。这是角色变重了不是变轻了。4. 核心环节拆解一个实际项目里怎么组合自动化与AI4.1 项目背景与整体策略拿我最近参与的某跨平台系统项目举例覆盖Web端、移动端、小程序还有个管理后台。团队六个测试人员开发两个feature team共十二人迭代节奏是两周一个版本。刚开始靠手工回归累且漏测多后来我们定了这样一套组合策略接口自动化做核心链路全覆盖小程序和Web复用同一套后端接口所以接口层价值最高。UI自动化只覆盖各端最高频的十条主流程求稳不求全。AI辅助生成用例和异常巡检在每次迭代里跑一次输出可疑清单给测试人工确认。测试数据统一用数据工厂脚本生成AI辅助写脚本人工做业务校验。这个方案的核心逻辑是把自动化资源集中在最稳、最值得复用的接口层UI层控制在一个低成本水平AI层用来做“人想不到”的补充人工把精力花在真正需要判断力的地方。4.2 工具选型与参数设计工具选型上接口自动化我们选了Pytest加Requests配合Allure报告已经在团队里跑得很熟。UI自动化选了Playwright因为它对小程序和Web的兼容性都还可以而且自带wait机制脚本稳定性比早期Selenium时代好很多。AI部分我们接了大模型做用例生成也用了时序分析工具做线上异常巡检。这里提几个参数设计上的经验。接口测试用例超时时间我一般设成连接5秒、读取10秒避免网络抖动造成误报重试机制只在特定幂等接口上用比如查询类写操作坚决不重试否则会造成脏数据。UI自动化的等待策略我不用固定sleep全部改成显式等待等待元素可交互最多等15秒超了就算失败这样脚本稳定性和执行时长都比较可控。4.3 一次完整的迭代质量保障流程一个典型迭代的流程是这样的需求评审阶段评测师参与把可测试性和验收标准在需求里写清楚。开发提测前开发自己跑一遍冒烟用例通过才提到测试环境。测试环境部署完成后接口自动化全量回归先跑一遍耗时大概二十分钟结果同步到群。用例执行阶段测试人员先看接口自动化结果失败的快速定位是真Bug还是环境问题同时跑关键UI主流程。AI巡检脚本在每天凌晨跑一次把异常清单推到任务池第二天早上人工确认。上线前再做一次全量回归加线上冒烟。这套流程跑下来最明显的变化是测试人员不再需要加班到深夜去做回归因为日常的重复回归已经被自动化吞掉了。同时因为AI巡检的存在一些偶发问题能更早暴露不再完全依赖用户的线上反馈。5. 踩坑记录自动化与AI落地中最常见的四个问题5.1 用例设计跟不上自动化节奏最常见的问题不是脚本写不出来而是用例本身的原子性差。很多老测试写用例时习惯一条用例里塞十几个步骤、五六个断言这种用例自动化之后一旦中间一步失败后面全挂排查起来极其痛苦。我现在的原则是一条用例只验证一个核心场景尽量做到“失败即定位”否则脚本跑完你还要花大量时间在猜“到底哪一步出了问题”。建议大家在把手工用例转成自动化之前先做一次用例重构。把“大而全”的用例拆成“小而专”的用例。这个过程很枯燥但做完之后自动化的可维护性会好非常多。5.2 AI生成结果的误报处理AI巡检刚上线那阵子误报率是比较高的一堆正常波动被标记成“异常”测试人员一天要确认几十条差点被搞到放弃。后来我们做了两个改进一是给模型加了“静默期”机制新上线的功能前两天不做异常判断等基线数据积累够再说二是把判断阈值从固定值改成动态百分位比如偏离正常范围95%才报警。改进后误报率降了一大截AI巡检才开始真正被团队接受。这个教训蛮有代表性AI工具落地技术本身只占一半另一半是“怎么跟现有工作流融合”。一上来就让它全自动决策一定会炸必须是“AI建议人确认”的节奏逐步建立信任。5.3 自动化覆盖的虚假安全感还有一次事故让我印象很深。某个核心模块的接口自动化一直都是绿的结果线上出了个严重问题原因是某个字段在特定条件下会被置空而自动化用例里的数据恰好都能避开那个条件。所以自动化覆盖率再高也不能给你真实的安心感它只能证明“你覆盖过的场景是好的”不能证明“没覆盖的场景也是好的”。这个问题的解法没有银弹只能靠两条腿走路一是测试设计时主动做变异思考站在开发最容易写错的角度补用例二是保留一部分探索性测试尤其是核心链路的异常组合机器和人在测试这件事上永远互补而不是替代。5.4 团队技能断层怎么补最后聊一个组织层面的坑。自动化AI落地受影响最大的是那些只会手工测试的老同事。如果团队只是定个KPI逼大家学很容易产生对抗情绪。我比较推荐的做法是“结对转型”让会自动化的人带一个手工为主的同事做一个真实项目而不是丢一堆教程让他们自己看。一个迭代下来基本就能上手。同时给转型设定一个现实的周期不要指望一个月速成。我当时给的预期是半年内能独立维护一条业务线的自动化用例前三个月以学习为主后三个月边做边补。实际走下来大部分人都能达到少数人还会超出预期。团队整体能力上来了自动化和AI的落地阻力自然就小了。6. 评测师这个角色未来到底会长什么样6.1 三五年内最可能出现的岗位画像如果只看三五年内的趋势我觉得评测师这个角色会分化成几类。一类偏“质量架构师”负责测试策略、自动化框架设计、流水线建设更像开发工程师一类偏“业务质量分析师”深入理解业务做探索性测试、用户场景设计和线上质量分析重心在找别人找不到的深层问题还有一类偏“AI质量评估师”专门评估AI模型的效果、数据质量、偏见和边界行为这个方向在AI产品越来越多的背景下会越来越吃香。这三类不是互相排斥的很多人可能是“业务质量分析师为主顺带会做自动化”但无论哪一类底层都绕不开“理解系统”和“用代码表达验证逻辑”这两件事。这也是为什么我一直强调代码能力正在变成入场券。6.2 给正在做测试的人三条具体建议如果你现在正处在转型焦虑里我给三条可落地的建议第一花三个月把接口自动化的全流程走通。选一个你负责的小模块用Pytest或你熟悉的语言写接口用例接入CI出报告。这件事做完你就已经领先相当一部分同行了。第二把AI当成你的“实习生”。让它帮你生成用例初稿、查资料、写脚本骨架但你一定要做最终的判断和审核。这个过程既是提高效率也是在训练你自己的批判性思维。第三找一个你熟悉的业务线把线上日志和缺陷数据拿出来做一次分析。找出那些上线后才暴露的问题反推测试设计里漏掉的是什么。这一套“从线上反推测试”的方法论比你看十本书都有用。6.3 组织的质量文化也要跟着变最后说一句可能不那么中听的话自动化也好AI也好如果组织文化还是“测试就是最后一道关”那这些工具的价值都会被锁死。质量是设计出来的不是测出来的。这句话喊了很多年但真正落实的组织不多。只有当开发、产品、测试一起对质量负责自动化平台和AI工具才能发挥最大效用。评测师在这个过程里既是执行者也应该是这文化的推动者。7. 结尾一点个人体会测试这行我干了十几年看着它从“手工为主”到“自动化普及”现在又在经历AI的冲击。我的体会是每一次技术变革淘汰的不是某个人群而是某种不再适应环境的工作方式。自动化淘汰了“只会重复执行的人”AI正在淘汰“只会按部就班写用例的人”但同时也给真正理解业务、理解系统、能用工具表达验证逻辑的人放大了好几倍的价值。别把时间花在焦虑“会不会被替代”上把时间花在让自己变得“会用工具做判断”上。工具是杠杆人是支点支点不稳杠杆再长也没用。对一个评测师来说最值得投资的永远是你对系统的理解力和对风险的判断力。这两样东西短期内AI还替代不了。
阅读完成 · 觉得有帮助？
