手工测试还有没有前途？不会自动化会不会被淘汰？35 岁以后还怎么做测试？这些问题，其实是很多测试工程师工作几年后都会遇到的职业焦虑。
手工测试岗位不会一下消失，但只会手工回归、不会接口、不会自动化的人，路会越走越窄。自动化测试值得学，它能直接抬高测试工程师的上限，但不是说每个人都要马上转成测试开发。
手工测试还有前途吗？
这个焦虑和真实工作环境有关。大多测试工程师的日常并不轻松：版本发布前两天，开发连续提测三次，你要反复执行登录、下单、退款、审批、权限切换、消息通知、导出报表等主流程；晚上十点开发说"最后一个 Bug 修好了，再帮忙回归一下"，你又把几十条老用例重新跑一遍。
有些后台系统光是切换不同角色账号，验证按钮显隐、字段权限和流程流转，一轮就能跑掉一两个小时。大家担心的并不只是学不学工具，更担心做这种重复工作还能撑多久。
手工测试不会完全消失，但纯点点点式测试的含金量确实在下降。现在招聘网站上很多岗位都要求"熟悉自动化测试""了解 Selenium、Playwright、接口自动化"等。公司想要更全面的测试工程师，但很多团队并没有把自动化真正做好。自动化已经慢慢变成测试岗位的筛选条件，不过真要把它做好也没那么容易。手工测试工程师不需要因此否定自己的经验，业务理解、风险判断、异常分析和用户视角依然很重要，只是你得把这些经验和接口、自动化、数据分析等技能连起来。
不会自动化会不会被淘汰？
短期看，不会自动化的人不会立刻失去工作。长期看，完全不接触自动化，求职和晋升都会更被动。
因为一方面，回归用例一多，纯手工很容易拖慢发布；另一方面，接口链路异常、性能抖动、资源竞争、内存泄漏这类问题，光靠手工点页面也很难查。再加上很多大厂的中高级岗位本来就更偏向测开，纯功能测试岗的薪资天花板也在往下走。
所以测试工程师至少要学几件事：判断什么场景该做自动化、看懂现有脚本或测试步骤、会补写核心回归流程、执行失败时能分清是环境问题、元素变了、数据错了还是产品出了 Bug。团队缺的就是这种人，你不用自己造一套复杂框架，但至少要知道脚本在测什么、失败了怎么查、结果对不对。
不会代码还能不能做自动化测试？
可以入门，但完全排斥代码，后面会比较吃亏。
如果你刚开始接触自动化，或者暂时不打算学写代码，可以根据自己的基础选一个更简单的起点。这里介绍两条路径。
路径一：零代码工具流
可以用 CueCast（UI 层，免费）、Apifox（接口层，免费 & 付费）这类可视化、低代码/零代码的自动化测试工具。你可以通过点击、拖拽、填参数的方式，把业务流程或接口场景配出来，再设置任务跑起来。这种方式更容易上手，也更适合先替代最烦的冒烟测试。这条路的关键不在代码，在业务。你不需要懂try...except，但必须懂业务逻辑和数据构造。比如，你知道下单前必须先生成 Token，知道优惠券和商品类目是否互斥，这种业务认知是代码代替不了的。
路径二：AI 流
你可以借助 ChatGPT（国外，免费&付费）、阿可AI（国内，免费）等 AI 工具，用自然语言描述测试步骤，AI 生成 Python、Java 脚本。它还能帮你逐行解释变量、条件判断和定位器的含义。把报错日志、页面 HTML 或接口文档直接贴给 AI，它也能帮你分析问题。
但 AI 也容易出错。AI 生成的定位器表达式可能会因为页面动态变化而失效，你需要手动微调；AI也可能编造不存在的API或属性，需要你人工核对；所有AI生成的脚本务必先在测试环境验证，绝不可直接用于线上。而且调教 AI 本身也要花时间，不是一句话就能得到完美脚本。
另外，近期也有一些 AI Agent 可以直接操作浏览器或电脑界面，比如 OpenAI 的 Operator，阿可AI 的本地模式，Anthropic 的 Computer Use / Cowork，可以像人一样点击、输入、读取页面内容，全程不用写代码。这条路门槛很低，但风险也高。目前这类 Agent 还不够稳定，复杂页面下可能点错或填错字段。务必在隔离的测试环境和低权限账号下使用，绝不要给它删除订单、真实支付这类高风险操作权限。
这是两条入门路径，前者让工具更容易上手，后者帮你学习代码，都可以帮助测试工程师开始接触自动化。
自动化测试适合哪些场景？
自动化最适合流程稳定、执行频率高、每次发版都要回归、手工操作耗时的内容。登录、注册、下单、支付、审批流、权限切换、报表导出和核心接口校验，通常都该优先做。
举个常见场景：一个后台审批系统每次发布要验证不同角色登录、提交申请、审批通过、审批驳回、查看通知、导出记录和权限边界。手工执行一轮要 20 到 30 分钟，一周回归四次，这类稳定流程就适合先做自动化。测试人员可以把精力放到异常流程、数据组合、业务规则和探索性验证上。
不适合的场景：需求每天都在变的新功能、交互没定型的页面、探索性测试、视觉检查，以及依赖多个外部系统且环境不稳定的流程，都不适合急着大规模投入。
所以自动化不要一上来铺太大，先做最稳定、最重复、回归最频繁的流程。
手工测试工程师应该怎么开始？
如果你现在完全不会自动化，不要立刻去啃 Selenium 源码，也别一上来就学一堆框架。
1. 先找一条重复且稳定的流程
第一条自动化用例尽量满足 4 个条件：每周都会跑、步骤相对固定、结果容易判断、出问题后影响比较大。登录、权限切换、订单状态流转、审批节点、导出和通知校验，都比刚上线的新功能更适合拿来练手。
2. 用登录流程做第一个样板
登录流程适合做第一条样板，因为步骤清楚，成功失败都容易判断。你可以先列 4 条最基础的检查项：正确账号密码能登录成功，错误密码会提示失败，用户名为空时不能提交，退出登录后访问首页需要重新认证。
接着把这 4 条检查项拆成 3 个部分：测试数据（账号、密码、角色）、操作步骤（打开页面、输入信息、点击按钮）、结果断言（页面标题、用户信息、错误提示或跳转状态）。
3. 先补接口和测试数据能力
数据准备和接口状态会直接影响自动化能不能稳定跑，比如账号是否可重复登录、订单是否需要前置状态、优惠券能不能和某类商品同时使用。所以在做 UI 自动化之前，得先学一点接口和测试数据：知道怎么调用接口、怎么造测试数据、怎么写断言、怎么复用前置步骤。
4. 跑通之后先别急着扩量
第一条跑通之后，不要立刻扩到几十条用例，先判断它是不是真省了时间：每次执行能省下多少手工时间，脚本失败后要花多少时间修，能不能比手工更早发现问题。
判断标准：如果一条脚本每周只能省 10 分钟，却要花 30 分钟维护，那这条自动化就不值得继续扩。相反，如果一条脚本每周都要回归 3 次，每次能省 20 分钟，维护成本又很低，那它就适合继续沉淀。
5. 再决定走哪条学习路线
做到这一步，再考虑自己更适合哪条路就会更清楚。如果你更希望先解决重复回归的问题，可以继续使用可视化、低代码/零代码工具，把登录、下单、表单提交等高频测试流程自动化。如果你想往测开方向发展，再系统补 Python 或 Java、UI 自动化框架、定时执行、测试报告和持续集成，会顺很多。
Java 和 Python 先学哪个，主要看团队环境和岗位目标。公司用 Java 就学 Java，团队用 Python 就学 Python，没有明确要求时 Python 更适合入门。前期也不用学太深，先掌握变量、条件判断、循环、函数、异常处理这些基础，目标是能读懂和修改测试脚本，能根据报错定位问题，这已经足够支撑早期实践。
如果你想先从零代码工具开始试一遍，可以根据这个指南实操一下：手把手教你录出一条能反复用的测试用例
35 岁以后还怎么做测试？
35 岁本身不是问题，连续很多年都在做同一种基础回归才是问题。如果到了 35 岁，主要工作还是手工点点点，竞争压力一定会越来越大。如果你能做测试方案设计、接口和 UI 自动化、判断质量风险、推动跨角色协作，甚至能把团队里的重复流程沉淀下来，工作就会稳很多。
会自动化只是能力提升的一部分，不是全部。业务复杂度、质量管理、测试平台、性能测试、团队协作和项目经验，都会影响测试工程师后面的路。对手工测试工程师来说，别花大量时间焦虑自己会不会被替代反复纠结该不该学自动化。先把重复劳动交给工具，把时间留给更难替代的事。先开始，把自动化用起来，比空谈学不学、转不转有用得多。