最近十几年，关于软件测试行业未来的讨论越来越有意思，其中最有趣的莫过于软测岗位消失这个。
AI 能写代码了，于是有人说测试开发要被替代；
大厂开始调整组织架构、合并 QA 和研发序列，于是有人说测试岗位正在消失；
还有人强调，测试人员必须突破技术门槛，否则只能被淘汰。
这些观点里，有些确实反映了现实，有些也值得测试人员警惕。
但是，把这些现象放在一起，就直接得出 “软件测试正在走向消亡” 的结论，小黑子我始终无法认同。
尤其是在看了一些相关讨论之后，我越来越想问一个问题：
有些人所理解的软件测试，究竟是什么？
如果测试就是写自动化脚本，那么 AI 能写代码之后，测试似乎确实没有太多存在的必要。
如果测试只是重复执行用例，那么开发人员也能执行，AI 甚至可以执行得更快。
如果测试的价值只是把确定的规则转化成程序，再让程序自动运行，那么随着工具越来越强，这种工作的价值自然会下降。
但问题在于，软件测试真的只有这些吗？
我认为，很多所谓的 “测试消亡论”，最大的问题并不是对 AI 技术发展判断错误，而是先把测试的定义缩小了，再用这个缩小后的定义去判断整个行业的未来。
像社区里有文章谈到了一个很现实的问题：测试不同的产品，需要不同的专业知识。测试云原生产品，需要理解虚拟化和相关基础设施；测试 AI 产品，需要理解模型及其运行机制。技术能力不足，确实可能连理解被测系统都很困难。
对此，我没有异议。
如果要测试一个 Agent Runtime 产品，却连容器、网络、文件系统的基本概念都不理解，确实很难深入开展工作。
对于这类产品，技术知识本身就是测试能力的重要组成部分。
但我觉得，这类讨论很容易出现一个问题：把特定专业领域的技术门槛，扩大成整个测试行业的价值标准。
测试基础设施、云原生、AI 模型，与测试电商交易、营销活动、账户权限、企业管理系统，是完全相同的工作吗？
显然不是。
它们需要的知识结构不同，面对的风险不同，验证方式也不同。
前者可能要求测试人员深入操作系统、网络协议和底层架构；后者可能更考验业务理解、流程分析、状态验证、数据一致性以及对异常场景的判断。
如果你测试的是高度专业化的基础设施产品，相关技术知识可能决定你能不能开始工作。
如果你测试的是复杂业务系统，技术能力固然重要，但你是否理解业务规则、是否知道数据在不同系统之间如何流转、是否能判断某个异常状态会造成什么后果，同样可能决定你能不能发现真正的问题。
这两种能力没有必要被人为对立起来。
问题不在于技术是不是门槛，而在于为什么有人总想用某一种技术门槛，去定义所有测试人员的价值。
更何况，一个讨论高薪岗位招聘要求的，和一个讨论整个测试行业是否会消失的，本来就不是同一个命题。
高薪岗位有高薪岗位的要求，专业领域有专业领域的门槛。
但不是所有测试岗位都必须走同一条技术路线，也不是每个测试人员都必须成为底层架构专家，才能证明自己的工作有价值。
如果把职业发展的某一条路线当成所有人的标准，再据此判断其他测试人员的价值，未免把问题想得太简单了。
我一直对测试行业里的一种倾向比较反感：谈到测试能力，就强调编程；谈到测试价值，就强调自动化框架；谈到职业成长，就强调平台建设、工程化和技术深度。
这些东西当然有价值。
自动化框架可以减少重复劳动，测试平台可以提升执行效率，工程化可以让测试稳定运行。这些都是测试工作的重要组成部分。
但我想问的是：这些东西为什么能够代表软件测试的全部？
不知道从什么时候开始，有些讨论仿佛默认了一个前提：测试人员如果不能写代码、不能做平台、不能深入技术，就很难证明自己存在的价值。
更有意思的是，当 AI 开始能够写代码、生成脚本、创建测试用例时，同一套评价标准又被拿来证明测试人员即将被淘汰。
这条逻辑看起来很顺畅，实际上从起点就值得质疑。
因为它把测试工作中最容易被量化、最容易被工程化的部分，直接等同于了整个测试工作。
我并不是在否定测试开发。相反，优秀的测试开发人员可以通过工具和自动化解决很多复杂问题。
我反对的是把测试开发当成软件测试的全部，再把软件测试的未来完全寄托在技术实现能力上。
测试开发是一种能力和工作方向，不是软件测试的唯一形态。
一个测试人员可以非常擅长编写自动化框架，却未必擅长识别需求中的矛盾；一个人可以精通底层技术，却未必理解某项业务规则为什么这样设计。
反过来，一个长期负责复杂业务的测试人员，即使没有开发过大型测试平台，也可能非常清楚系统的关键风险在哪里，知道哪些状态组合容易出错，知道一次看似普通的改动可能影响哪些业务链路。
这些能力不能因为不容易用代码行数、自动化覆盖率或者技术栈来衡量，就被当成不重要。
如果一种评价体系只能看见技术实现，却看不见测试真正解决的问题，那么有问题的未必是那些没有走技术路线的人，也可能是这套评价体系本身。
举一个很普通的例子。
一个电商系统，用户提交订单，支付平台返回成功，后台订单状态更新，库存系统扣减库存，随后触发发货流程。
这些环节可以分别通过接口测试，也可以通过自动化脚本验证。
但假设发生以下情况：
支付平台已经扣款，订单系统却没有更新状态；
系统重试之后，用户被重复扣款；
库存已经扣减，订单却进入了取消状态；
退款成功，但订单和财务记录仍然显示未退款。
每一个系统的接口可能都有正常返回，每一个模块的局部测试也可能通过了。
问题出在哪里？
问题出在业务规则、跨系统状态和异常恢复之间的关系上。
测试人员需要知道，什么状态组合才是合理的，哪些操作必须具有幂等性，失败后应该如何恢复，什么情况下需要补偿处理，以及系统最终应该达到什么状态。
这时候，测试的目标就不是简单地检查一个接口有没有返回 200，也不是再生成一批相似的输入数据。
真正需要验证的是：这条业务链路在正常、异常和恢复过程中，是否始终符合预期。
AI 可以帮助编写脚本，可以根据已有资料生成测试场景，也可以协助分析日志和定位问题。
但如果业务规则本身就没有被完整说明，或者测试人员没有确认什么才是正确的业务行为，生成再多的脚本也解决不了根本问题。
脚本能够忠实地执行规则，却不能仅凭执行次数证明这套规则就是正确的。
尤其在真实项目中，很多问题并不是完全不知道怎么写代码，而是根本没有人提前意识到这个场景应该被验证。
有时候，测试人员的工作是追问产品经理一个被忽略的异常流程；有时候，是发现几个看起来互不相关的功能修改之后，组合起来产生了新的风险；有时候，是在缺陷发生后，把用户操作、系统日志、数据库记录和第三方服务的行为串在一起，确定问题真正出在哪里。
这些工作未必需要多高深的技术，但需要对业务和系统有足够深入的理解。
我实在无法理解，为什么有些人可以轻易地把这些工作归入低价值的 “点点点”，仿佛只要没有构建技术平台，就没有什么值得讨论的专业能力。
如果连业务本身都没有理解清楚，再先进的测试工具，也可能只是在更高效地验证一个不完整的假设。
有些关于测试的讨论，总是围绕代码、框架、架构以及开发流程展开。
但真正的软件产品，并不只存在于代码仓库和测试环境里。
对于用户而言，他们并不关心某个接口是不是通过了自动化测试，也不关心测试框架采用了什么设计模式。
他们关心的是产品能不能正常使用，数据有没有丢失，交易有没有出错，账户权限是否正确，服务中断之后能不能恢复。
而对于企业而言，测试工作的实际意义，也不仅仅是让开发人员更快地交付代码。
还包括尽早发现业务缺陷，降低线上事故风险，减少错误发布造成的损失，以及避免问题在多个系统之间扩散。
特别是涉及交易、账户、支付、设备、网络、第三方服务等复杂链路时，单个组件表现正常，并不能保证整个系统在真实使用场景下正常。
这时候，需要有人站在更完整的业务流程上，检查各个部分的行为是否符合预期。
这个角色可以与开发密切合作，也可以借助 AI 和自动化工具。但如果只因为组织架构发生变化，就认为这类验证工作已经不再需要了，那只能说明忽略了软件质量问题本身的存在。
我不认为业务测试天然高于技术测试，也不认为技术测试就一定不懂业务。
我想强调的其实很简单：软件测试有不同的专业方向，但不能因为某一种方向更容易包装成技术能力，就认定其他方向的价值更低。
尤其是那些真正承担业务交付、需要面对客户问题和线上风险的团队，他们所关注的问题，并不一定能够通过单纯提升技术栈来解决。
这是另一种经常出现的论据。
最近，围绕大厂 QA 转研发、测试与研发序列合并的讨论明显增多。有人据此认为，企业正在逐步取消测试岗位，以后测试人员要么成为研发，要么被淘汰。
我不否认企业会调整组织架构，也不否认 AI 提效、成本控制和研发流程变化会影响测试岗位的数量。
企业可以减少某些岗位，可以把测试人员划入研发序列，也可以要求研发承担更多质量责任。
但这里有一个最基本的逻辑问题：
测试岗位发生变化，不等于测试工作不再需要。
一家公司的组织架构中不再有独立的 QA 部门，不代表产品从此不需要验证。
如果 QA 并入研发之后，研发人员开始承担更多测试工作，编写更多测试代码，建设更多自动化能力，那么发生变化的首先是工作分配方式，而不是软件质量问题突然消失了。
原来由专职测试人员完成的验证工作，可能被拆分给开发人员，也可能由自动化系统承担一部分，还可能有一部分工作因为成本压力而被削减。
这些情况需要分别讨论，不能一概而论。
当然，我也不打算粉饰现实。如果一个团队的工作长期停留在机械执行重复用例、没有主动发现问题的能力，那么企业在控制成本时，确实可能认为这类岗位可以缩减。
如果 AI 已经能够以更低的成本完成部分工作，企业也完全可能重新评估人员配置。
但是，这说明的是某些岗位和工作内容面临变化，并不意味着所有测试岗位都没有价值。
同样，个别业务线的组织调整，也不能直接代表整家企业，更不能用来证明整个行业的发展方向已经确定。
更值得追问的是：调整之后，谁来负责复杂业务链路的验证？谁来识别需求和设计中的风险？谁来判断自动化结果是否足以支撑发布？出了线上问题，谁来调查并确认修复是否彻底？
如果这些工作仍然存在，那么它们就需要被明确分配、执行和验证。
至于最终由谁承担，是独立的 QA、嵌入研发团队的测试人员，还是由其他角色共同完成，可以根据团队规模、产品风险和实际成本来决定。
我并不主张每家公司都必须保留独立测试部门，也不认为每个项目都需要按照同一种组织模式开展测试。
但请不要把 “公司不再设置独立 QA 岗位” 与 “软件不再需要测试” 混为一谈。
岗位可以合并，职能可以转移，工作内容可以自动化，但这些变化本身并不能证明质量保障的需求已经消失。
否则，按照同样的逻辑，企业只要把某种工作划归其他部门，就能宣布这项工作不再有存在的必要了。
这显然说不通。
有人可能会继续追问：现在开发人员有 AI 帮助，可以写单元测试、接口测试和集成测试，为什么还需要专门的测试人员？
这个问题值得认真讨论。
开发人员本来就应该承担质量责任，也应该主动验证自己的代码。单元测试、代码检查、集成测试以及必要的自动化回归，都可以成为研发流程的一部分。
如果过去一个项目过度依赖测试人员来发现所有问题，却没有要求开发人员对自己的代码负责，那么这样的工作方式本身就存在问题。
但是，开发自测能力提高，不意味着专业测试能力就失去了意义。
原因并不复杂：写出代码的人能够理解代码，但这并不天然意味着他已经覆盖了所有重要的验证视角。
开发人员通常更熟悉自己实现的逻辑，这当然是一种优势；但如果需求本身存在遗漏，测试范围存在盲区，或者某些异常场景从一开始就没有被考虑，那么单纯围绕现有实现补充测试，也可能继续遗漏同一个问题。
这不是在指责开发人员，也不是认为开发人员缺乏测试思维。
实际上，开发和测试都可能存在盲区。独立的验证视角之所以有价值，正是因为不同角色可能从不同角度理解需求、发现风险。
对于简单、稳定、低风险的功能，开发自测加自动化可能已经足够。
对于复杂业务、跨系统链路、高风险变更，团队则可能需要更深入的测试设计、场景分析和独立验证。
这些安排应当由真实风险和成本决定，而不是预先规定所有测试都必须由某个职位完成，或者所有测试都可以交给开发。
如果开发人员已经能够完整承担这些工作，团队当然可以重新分配岗位。但我们仍然要区分：一个人具备了测试能力，与测试这项专业工作没有必要存在，是两回事。
说到这里，我想明确表明自己的态度。
我不认为 AI 对测试行业没有冲击。
恰恰相反，AI 正在降低很多重复性工作的成本。
简单的测试代码可以生成，规则明确的用例可以批量创建，接口回归可以自动执行，日志分析和缺陷定位也可以借助 AI 提效。
过去一个测试人员需要花费大量时间处理的事情，未来可能只需要很少的时间。
这必然会影响企业对测试人员数量和能力结构的要求。
只会机械执行测试、不会分析问题、缺乏主动性，又无法适应工具变化的人，确实可能面临更大的职业压力。
对此没有必要回避。
但我不理解的是，为什么有些人会把这种变化直接上升为测试行业的消亡。
技术进步本来就会让一部分工作方式过时。自动化替代人工执行，本身就是测试行业追求的目标之一。
假如我们过去花费大量精力，就是为了减少重复劳动，那么当 AI 进一步降低重复劳动的成本时，难道不应该重新分配精力，把更多时间用于分析复杂问题、验证业务风险和提升产品质量吗？
当然，企业未必会把节省下来的时间投入更充分的测试，也可能直接缩减团队。这取决于企业的成本策略、产品特点和风险承受能力。
所以我不会断言未来测试岗位一定增加，也不会承诺所有测试人员都能顺利转型。
但必须区分两件事：企业因为效率提升而减少岗位，与软件产品从此不再需要质量验证，是两个完全不同的结果。
AI 能替代多少测试任务，需要依据实际能力来判断；测试人员是否还有价值，则不能只看任务能否被自动化。
我并不反对测试人员学习技术，也不反对走测试开发、质量工程、自动化平台、AI 测试等专业路线。
如果你负责的产品需要深入技术，那么补足相关知识是必要的；如果你希望进入特定的高技术门槛岗位，那么学习相关专业领域的知识也完全合理。
但这不是所有人的唯一出路。
测试人员同样可以在业务理解、系统分析、风险识别、测试策略、生产问题调查和复杂链路验证等方向建立专业能力。
技术能力与业务能力不是二选一。
对很多项目而言，既能理解业务，也能看懂系统实现、分析数据和定位问题的测试人员，反而更有机会把两者结合起来。
AI 的发展也应该促使我们重新审视工作方式：哪些事情可以交给工具，哪些事情需要更深入的判断，哪些原本由于时间和资源不足而没有充分验证的风险，现在可以更便宜地被覆盖。
测试人员当然要适应变化，但不应该被迫接受一种简单粗暴的判断：只有成为研发，才能证明自己有价值。
如果一个人原本就喜欢开发，转向测试开发或研发当然没有问题。
如果一个人的优势是复杂业务验证、风险分析以及生产问题排查，也不应该因为没有成为底层技术专家，就被认为没有成长空间。
真正值得关注的，是我们能否持续为产品解决问题，而不是我们的职位名称是否足够符合某一种技术潮流。
我并不认为软件测试是一份永远不会受到冲击的职业。
AI 会发展，企业会调整岗位，某些测试工作会逐渐自动化，一些传统岗位也可能减少甚至消失。
这些都是现实，测试人员没有必要对此视而不见。
但是，我同样不认为，只要 AI 能写代码、大厂开始合并 QA 和研发，软件测试就一定会走向消亡。
更让我在意的是某些讨论中的傲慢：自己熟悉的工作方式，就是整个行业的全部；自己能够自动化的事情，就是测试的全部；自己认为不再需要独立岗位的工作，就被认定为不再有价值。
我不反对技术进步，也不否认技术能力的重要性。
我只是觉得，评价一项工作的价值，至少应该先弄清楚它究竟在解决什么问题。
如果一个人只了解测试自动化，就用自动化能否实现来判断整个测试行业；如果一个人只关注某些高薪技术岗位，就用这些岗位的门槛来评价所有测试人员；如果一个人只看到大厂缩减或合并岗位，就直接宣布整个职业的终结，那么这样的结论未免下得太早了。
软件测试的本质，不是某种固定的岗位名称，也不是某一套工具，更不是要求测试人员必须拥有某一种技术栈。
它是围绕软件是否符合预期、业务风险是否得到控制、系统在真实条件下是否可靠而开展的一系列验证活动。
不同团队可以选择不同的组织形式，不同的产品可以采用不同的技术路线，未来的测试人员也完全可能和今天有很大区别。
但在这些变化之外，软件依然会出现需求遗漏、业务逻辑错误、数据不一致、异常恢复失败和复杂系统交互问题。
这些问题是否需要被发现，答案应该不难理解。
所以，与其急着宣布测试行业即将消失，我更希望那些讨论技术趋势的人先回答一个问题：
当 AI 写完了代码、生成了测试用例，也执行完了所有自动化之后，你凭什么确定这个产品就真的没有问题？
如果答案仍然是需要验证需求是否完整、检查业务是否正确、判断风险能否接受，那么我们讨论的就不是测试是否还需要存在，而是这些工作应该由谁完成、采用什么方法完成，以及如何以更合理的成本把它们做好。
这才是我认为值得继续讨论的事情。
AI 会改变测试，但不能仅凭 AI 能力的提升，就把测试的价值简单地归零。
技术可以不断进步，岗位也可以不断变化。
但在宣布一个职业即将消失之前，至少应该先弄明白：这个职业到底在解决什么问题，还有你本身到底是不是测试？