AI已经能写测试用例、能自动找缺陷了,软件测试未来会变成什么样?

欢迎来到「AI 时代・千行百业何去何从」栏目。

每一期，我们拆解一个真实职业：AI 已经能做什么，哪些工作仍然离不开人？未来变化有多快，会怎样影响工作机会和收入？普通人又该往哪里发展，提前做哪些准备？

第二十九期，我们从 软件测试 讲起。

软件测试正在被AI推到更前面：用例、脚本、缺陷线索，都可能先由工具生成。

因为AI已经开始碰到软件测试最日常的工作：写用例、跑脚本、看日志、找缺陷。

过去，一个功能上线前，测试人员要反复点页面、填表单、换设备、记录问题。现在，很多基础检查可以先交给工具完成，人再去判断哪些结果可信、哪些风险还没被覆盖。

这让很多人担心：当测试执行变得越来越自动化，软件测试会不会变成最先被压缩的岗位？

先看背景。工信部数据显示，2025年我国软件业务收入154831亿元，同比增长13.2%；其中信息技术服务收入106366亿元，占全行业收入的68.7%。软件还在变大，越大的软件系统，越需要稳定、安全和可控的质量保障。 [1]

软件测试值得研究，因为AI已经能接手一部分测试执行和用例生成，但软件质量的责任不会因为工具变聪明就消失。

要判断这个职业怎么变，先要看清测试人员到底在做什么。

测试不是随手点点页面，而是从需求、场景、数据、执行到复测的一整套流程。

假设一个电商App要上线“满200减30”的优惠券功能。测试人员拿到的不是一个按钮，而是一串可能出错的业务规则。

满200是商品原价，还是优惠后的金额？部分退款后，优惠券怎么算？用户跨店下单、叠加会员折扣、取消其中一件商品，会不会导致金额错乱？

大致流程是：

真正难的地方，往往不是点一次按钮，而是想到“哪些情况容易出错”。比如优惠券金额刚好等于门槛、网络中断后重复支付、旧版本用户升级后数据不一致。

华为云CodeArts TestPlan的产品介绍中，也把测试计划覆盖到测试计划、测试设计、测试用例、测试执行和测试评估等全流程，而不是只把测试理解成最后点一遍。 [3]

软件测试的核心不是机械点击，而是把需求变成可检查的场景，并在上线前尽量发现真实风险。

这也决定了AI最先改变的，不是所有测试工作，而是其中更标准、更重复的环节。

AI最容易先进入用例初稿、单元测试、接口脚本、日志分析和回归测试。

最先被改变的，是测试用例和测试脚本的起稿。

以前，测试人员要根据需求文档手动列出一条条用例：输入什么、点哪里、预期结果是什么。现在，AI可以先给出一版场景清单，人再删掉没用的、补上漏掉的、改成项目里能执行的格式。

开发侧也一样。GitHub Copilot文档明确把生成单元测试作为使用场景之一，可以让Copilot Chat为函数生成单元测试，也可以用提示文件生成聚焦的测试用例。 [5]

华为云CodeArts智能助手文档也提供了生成单元测试用例、批量生成单元测试用例和测试用例修复等能力。这说明“AI写测试”已经不是概念，而是进入了开发工具和测试平台。 [4]

但AI生成一批测试，并不等于这些测试就真的有用。如果需求本身写得不清楚，或者业务规则藏在老系统里，工具也可能漏掉关键场景。

AI最先压缩的是用例起稿、脚本编写、重复回归和日志整理；测试人员会从“自己写完所有用例”转向“判断、补全和验证AI给出的结果”。

国内行业也已经开始把这种变化纳入标准和评估体系。

智能化测试已经进入研发流水线，测试不再只发生在上线前的最后一关。

从国内看，软件测试的变化已经从单个工具，走向一整套质量保障流程。

中国信通院云大所2025年介绍，信通院联合业界企业编制《智能化软件测试能力成熟度模型》，覆盖需求分析、计划制定、设计开发、测试执行、回归验证五个关键环节，并提到“大模型+5个测试环节、15个测试场景”。 [2]

这句话对普通读者的意义是：AI测试不是只帮你写几条用例，而是在尝试进入需求理解、计划安排、用例设计、执行反馈和回归验证的完整链路。

国内云厂商的测试平台也在做类似事情。CodeArts TestPlan把测试设计、用例、执行、缺陷、报告和仪表盘放在一个平台里；接口自动化、性能自动化、自定义自动化也已经是常见能力。 [3]

但推进速度并不一样。研发流程清晰、代码管理规范、自动化基础好的团队，会更快接入AI测试；如果需求经常口头变更、环境不稳定、历史系统混乱，AI也很难一下子把测试变聪明。

国内软件测试正在从手工执行走向智能化质量保障；变化快慢取决于团队有没有清晰需求、稳定环境和自动化基础。

那么，工具越来越强以后，人还要负责什么？

复杂缺陷常常需要人复现、追问、判断影响范围，并把风险讲清楚。

回到优惠券例子。AI可以列出“满减门槛、叠加优惠、退款后金额”这些测试点，但它未必知道公司真正担心什么。

有些公司最怕金额算错，有些公司最怕用户投诉，有些公司最怕促销被薅羊毛。测试人员要理解业务优先级，决定哪些场景必须先测，哪些问题不能带病上线。

再比如，一个Bug只在低端安卓机、弱网、连续切换页面后出现。AI可以帮你看日志，但要把问题稳定复现出来，仍然需要人设计步骤、控制变量、判断是前端、接口还是数据问题。

测试还要和人沟通。发现问题后，要写清楚复现步骤、影响范围和严重程度；上线前，要把风险讲给产品、开发和业务负责人听。

GitHub文档也提醒，Copilot在为基础函数生成测试时表现较好，复杂场景需要更详细的提示和策略。这正好说明，越复杂的业务越需要人把上下文补进去。 [5]

人要负责理解业务风险、设计关键场景、复现复杂缺陷和推动问题解决；AI能帮忙测试，但不能替团队承担上线质量责任。

所以，岗位会不会减少，要看一个人做的是哪一层测试工作。

测试岗位的压力会先落在低重复、低判断的执行层，质量分析和测试开发能力会更重要。

压力最大的是只做低复杂度手工执行的人。

如果每天主要是在固定页面点固定流程、按表格记录通过或不通过，AI和自动化脚本都会让这类工作变少。公司不一定马上裁人，但很可能不再为同样的重复测试配那么多人。

更常见的变化，是岗位要求上移。企业会希望测试人员懂一点代码，能维护自动化脚本，能看接口和日志，能判断线上风险，而不只是照着用例执行。

国内没有一个权威数字能直接说明“AI让测试岗位减少了多少”。更稳妥的判断，是看工作内容：重复执行被工具压缩，复杂质量问题仍需要人负责。

海外数据可以作为参照。美国劳工统计局把软件开发人员、质量保障分析师和测试人员放在同一组，预计2025—2035年整体就业增长10%；其中软件质量保障分析师和测试人员2025年年薪中位数为104300美元。这是美国口径，不能直接套到国内，但说明测试相关工作不会因为AI出现就整体消失。 [6]

软件测试不会整体消失，但低复杂度手工执行会被压缩；越能做自动化、分析风险、推动质量改进，越不容易被简单替代。

接下来，测试人员真正值得投入的能力，会和过去不太一样。

更有价值的测试人员，会把业务理解、自动化能力、专项测试和AI协作结合起来。

如果AI能帮你写一版用例，那你更要证明：你能判断这版用例够不够。

第一，懂业务和用户场景

不要只记测试步骤，要知道这个功能为什么存在，谁会用，哪里出错会造成最大损失。懂业务的人，才能判断AI漏掉了什么。

第二，学自动化和测试开发

至少要理解接口、数据库、日志、脚本和持续集成。你不一定一开始就写复杂平台，但要能把反复做的测试变成可重复运行的检查。

第三，往专项能力深挖

性能测试、安全测试、兼容性测试、移动端测试、数据质量测试，都比普通功能点击更需要方法和经验。专项越清楚，AI越像工具，而不是替代者。

第四，学会用AI做质量放大器

让AI生成用例、补边界场景、解释日志、整理缺陷描述，再由你判断和修正。关键不是“让AI替你测”，而是让AI帮你覆盖更多可能性。

更值得积累的，是业务理解、自动化能力、专项测试、风险判断和AI协作能力。

这些能力不一定一口气学完，但可以从手头一个真实功能开始。

未来的测试人员会更像质量风险的发现者、解释者和推动者。

软件测试仍然能做，但不能再把“会点页面、会写测试用例表格”当成长期优势。

变化离你多远？如果团队已经有自动化脚本、持续集成、缺陷仪表盘、AI写用例工具，变化已经在身边。如果公司还主要靠手工点，变化会慢一点，但方向不会倒回去。

影响有多大？重复执行越多，压力越直接；越能处理复杂场景、搭建自动化、分析线上问题，受到的冲击越小。

现在怎么准备？先别急着追所有工具。更重要的是，把一个功能测透：需求怎么拆，风险怎么排，用例怎么自动化，缺陷怎么复现，报告怎么让团队愿意改。

软件测试仍然有未来，但发展不能停在重复执行上；越能理解业务、设计场景、使用工具并讲清风险，越能把测试经验变成长期价值。

SECTION 09

参考资料

本篇结论来自软件业统计、智能化测试评估、主流研发工具文档和职业资料的交叉核对。

下期预告

下一期，我们看 教研。

我们把视线转向课堂背后的工作：一节课怎么设计，题目怎么选，学生学得怎么样，正在被新的工具重新拆开。

AI已经能生成教案、能分析学情了，教研未来会变成什么样？