前几天，在掘金看了一篇文章，有些感触。

https://juejin.cn/post/7685276242113019938
我想到软件测试行业里一个很有意思的现象：技术一直在进步，测试人员也在不断学习新东西，可我们评价一个测试人员的方式，好像并没有跟着进步多少。

过去，谁会自动化，谁就更有竞争力。

后来，大家开始比测试开发、质量平台、持续交付。

现在，又轮到 AI 测试、智能体、自动生成用例和自主执行了。

技术的名字一直在变，但有一件事似乎没变过：总有人习惯用自己掌握的那套技术，给其他测试人员划分等级。

于是，我想起了公司里发生过的一类故事。

一、公司花了很大力气，终于建成了一套先进的质量体系

这家公司的研发团队最近完成了一次质量体系升级。

过去，需求从开发到测试，再到发布，中间有不少重复工作。测试人员要分析需求、设计场景、维护回归集，发布前还要反复确认结果。遇到复杂业务变更时，大家经常需要花很多时间判断哪些功能可能受到影响。

管理层决定改变这一切。

新体系引入了 AI 辅助测试，把需求分析、测试设计、变更影响分析和部分自动化执行整合进了研发流程。

开发提交变更后，系统会分析影响范围，推荐需要执行的测试，并将执行结果汇总到发布决策页面。对于部分场景，AI 还能够根据页面结构变化调整操作方式，减少传统自动化维护成本。

这套方案听起来非常合理。

至少在项目汇报里，一切都很漂亮。

测试设计效率提升了，回归流程更加顺畅，自动化维护工作减少了，测试人员也终于不用再花那么多时间处理重复事务。

负责人认为，这才是现代软件测试应该有的样子。

团队里有一位资深测试人员，却没有表现出特别兴奋的样子。

他问了几个问题。

第一，系统推荐执行的测试，依据是什么？如果需求本身存在遗漏，或者变更影响分析不完整，系统如何发现那些没有被识别出来的风险？

第二，AI 可以调整自动化操作，但它调整之后，如何证明测试仍然验证着原来的业务规则，而不是为了完成任务，绕开了原本应该检查的条件？

第三，发布页面上的质量结论，是建立在完整、可信的验证证据上，还是只是把现有工具的执行结果汇总到了一起？

负责人有些不高兴。

他觉得，这些问题多少有点吹毛求疵。

技术升级已经取得了明显进展，为什么还要一直纠结这些细节？

更何况，新体系已经提高了效率。难道这还不能说明它的价值吗？

资深测试人员没有反驳，只是提出了一个建议：

先找一个业务复杂、变更频繁的核心流程，检验一下新体系能不能识别过去容易遗漏的风险，再决定是否全面推广。

项目最终还是上线了。

新体系也没有出什么明显的问题。

直到几个月后，一次涉及业务规则调整的版本发布，才让大家真正意识到，原来他们一直在讨论的那些问题，并不是多余的。

问题不在于 AI 没有生成测试。

也不在于自动化执行失败。

恰恰相反，测试流程顺利执行，报告也正常生成了。

问题在于，团队过于相信已有验证机制的完整性，却没有检查它是否覆盖了这次规则变化带来的新风险。

某个原本需要满足额外业务条件的操作，在特定的数据状态下被错误地允许了。现有测试关注了主要流程是否正常，却没有充分验证规则之间的组合关系。

最后，真正发现问题的，不是新平台，也不是某个高级技术功能，而是一个熟悉业务规则的测试人员。

这个人甚至没有参与最初的质量平台建设。

他只是注意到：这个版本修改的业务条件，与另外一条原有规则存在冲突。

如果没人提出这个问题，那么再漂亮的质量看板，也无法替团队承担漏测的后果。

当然，这不是说 AI 测试平台没有价值。

它确实减少了重复工作，也让测试人员有机会把精力放在更复杂的事情上。

但这件事说明了一个经常被忽略的事实：

提高测试执行效率，不等于提高了质量判断能力；拥有一套先进的验证机制，也不等于已经证明它足够可靠。

二、为什么我们总喜欢把技术能力当成职业等级？

这件事其实并不奇怪。

因为技术能力比其他能力更容易展示。

你设计了一套复杂的自动化架构，可以展示。

你实现了一套智能测试流程，可以演示。

你让一个原本需要人工操作的任务实现自动化，可以计算节省了多少时间。

这些成果有形、有过程，也容易在汇报中呈现。

但如果一个测试人员在需求评审时，识别出一处没有被明确规定的业务边界，并推动产品、开发补全规则，这件事应该怎么衡量？

如果另一个测试人员在发布评审时，指出现有测试证据不足以支持上线结论，避免团队因为过度自信而承担风险，这件事又应该怎么衡量？

它们不像平台建设那样，能够直接形成一个漂亮的成果展示。

于是，很多组织很自然地选择了一条更简单的路：用技术实现的复杂程度，近似衡量人员的能力。

这样做并非完全没有道理。

技术能力确实重要，尤其是在自动化、性能、安全和测试基础设施等专业领域。

问题在于，当一个方便使用的评价指标被当成了评价一切的标准，它就很容易失真。

会设计测试基础设施，不代表一定擅长识别业务风险。

理解业务规则，也不代表不需要学习技术。

擅长 AI 系统测试，不代表就天然比擅长传统系统测试的人更有价值。

这些能力之间不存在一条可以随意套用的高低排序。

然而，技术鄙视链依然很容易形成。

有人觉得业务测试没有技术含量，有人认为测试开发才算真正的技术岗位，也有人觉得只要引入了 AI，过去的测试方法就已经落伍。

每个人都可以用自己擅长的那一部分，证明自己的重要性。

但很少有人愿意先回答一个问题：

在当前这个项目里，究竟什么能力最能帮助团队减少真实的质量风险？

因为这个问题没有一个可以直接套用到所有人的答案。

它需要结合业务、系统复杂度、交付模式和团队现状来判断。

相比之下，建立一套技术等级制度要简单得多。

三、技术发展的速度，正在改变某些能力的价值

过去，测试人员积累职业优势的一种方式，是把别人还不熟悉的技术学会，再把它应用到工作中。

这种方式当然仍然有效。

但技术发展正在改变其中一部分逻辑。

AI 已经可以辅助分析需求、生成测试设计、编写测试脚本、总结执行结果，甚至通过工具调用执行多步骤的浏览器操作。

以 Playwright MCP 为例，AI 助手已经可以借助结构化的页面信息执行浏览器交互，而不必完全依赖传统脚本中预先写死的操作步骤。相关能力见 Playwright 官方文档。

这意味着什么？

意味着一些过去需要投入大量时间才能完成的技术工作，正在降低实现成本。

但这里有一个经常被误解的地方。

实现成本降低，并不代表这项工作失去了价值。

真正发生变化的，是仅仅依靠实现过程本身建立起来的竞争优势。

以前，你能把重复测试操作自动化，可能已经领先了团队里的大多数人。

现在，当 AI 能够辅助完成更多实现工作时，仅仅证明自己能把操作自动化，就不再足以说明全部价值。

你还需要判断自动化的范围是否合理，测试是否验证了正确的业务意图，以及系统给出的结果是否可信。

以前，你能够设计一套完整的回归体系，已经体现出很强的工程能力。

现在，你还需要考虑变更影响分析是否完整、质量门禁是否有效，以及发布决策是否建立在足够的证据上。

以前，你能写出复杂的测试脚本，是一种值得肯定的能力。

现在，当 AI 能够协助生成脚本时，你更需要判断脚本有没有真正发现问题，以及测试结果是否具有业务意义。

因此，我不认为 AI 会让所有测试人员失去价值。

我认为，它会让某些过去被高估的能力，逐渐回到更合理的位置。

这也不是软件测试独有的现象。

当某项能力越来越容易被工具获得时，单纯掌握这项能力，就很难永远构成强大的职业壁垒。

技术仍然重要。

但技术实现、问题定义、结果验证和风险判断，是不同层面的事情。

把它们混为一谈，才是很多技术争论的根源。

四、2026 年，软件测试真正发生了什么变化？

如果说上面的故事只是个人观察，那么最近的行业变化至少提供了一个值得关注的背景。

Applause 在 2026 年发布的数字质量报告显示，在其调查的测试相关受访者中，超过 92% 的人表示所在组织已经在测试过程中使用 AI；与此同时，29% 的受访者报告缺陷的数量或严重程度有所增加。

这是一项行业调查，不能直接代表所有公司，但至少说明：AI 使用范围扩大，并不自动等于软件质量同步改善。

来源：Applause《The State of Digital Quality in Functional Testing 2026》

这里恰好存在一个值得思考的问题。

当 AI 能够帮助团队更快地生成测试、执行测试、分析测试结果时，团队是否同时建立了与之匹配的验证机制？

如果没有，那么我们可能只是提高了错误结论的产生速度。

对于传统业务系统，测试人员需要关注业务规则、数据一致性、权限边界和异常恢复。

对于引入生成式 AI 的系统，情况还会更复杂。

同一个问题，多次输入可能得到不同的回答；回答内容即使表达流畅，也可能包含错误信息；某次测试表现良好，也不意味着模型在其他输入分布、上下文或对抗场景下仍然可靠。

这要求团队建立更加系统的评估方法，而不是只检查某次交互能否正常完成。

ISTQB 在 2026 年发布的 CT-AI v2.0 大纲，已经更加明确地聚焦于 AI 系统本身的测试，覆盖输入数据、模型测试以及生成式 AI 等内容；而 CT-GenAI 则聚焦于如何使用生成式 AI 辅助测试，以及相关的风险控制。

参考：CT-AI v2.0 官方说明；CT-GenAI 官方说明。

这里有一个值得注意的区别。

使用 AI 辅助测试，是一个方向。

测试包含 AI 的系统，则是另一个方向。

前者关注怎样利用 AI 改进测试工作，后者关注如何证明 AI 产品本身满足质量要求。

两者都需要技术，但都不能仅凭工具是否运行成功来作出质量结论。

当测试对象和测试手段同时发生变化时，只会重复执行既有流程的人，确实需要更新自己的能力结构。

但反过来说，那些仅仅因为掌握了新工具，就开始贬低其他测试人员的人，也没有真正理解这次变化。

因为技术升级提出的新要求，不是让所有人都去追逐最新工具，而是要求团队重新审视自己的能力和质量保障方式。

五、软件测试的新规则，不是技术不重要，而是技术必须证明自己

我认为，测试行业需要重新讨论的，不是功能测试和自动化测试谁更高级，也不是传统测试人员是否应该全部转型 AI 测试。

真正值得讨论的是：我们究竟应该根据什么判断一个测试人员的专业水平？

第一，能够把问题定义清楚，比快速提出技术方案更重要

当业务需求存在歧义时，首先需要明确实际业务规则，而不是急着让 AI 生成测试用例。

当系统出现问题时，首先需要判断问题发生在哪一层、影响哪些场景，以及现有证据能支持什么结论，而不是马上选择一个看起来先进的工具。

当团队考虑引入新的测试平台时，也需要弄清楚现有流程的瓶颈究竟在哪里。

是重复劳动太多？

是变更影响分析不准确？

是缺少可靠的回归数据？

还是上线决策没有足够的质量证据？

这些问题的答案不同，合理的技术方案也会不同。

技术越复杂，越需要认真考虑它是否解决了正确的问题。

第二，测试结果必须有证据，而不是只有一个结论

一个质量平台显示通过，不代表整个版本不存在重大风险。

一套自动化测试全部通过，不代表每项关键业务规则都已得到验证。

AI 给出了一份看似完整的测试报告，也不代表其中的分析和建议都是真实可靠的。

测试人员需要知道结果从哪里来，哪些条件得到了验证，哪些风险仍然存在，以及结论能够覆盖多大的范围。

特别是在 AI 测试逐步进入实际工作流程之后，这一点会更加重要。

如果自动化系统允许根据页面变化调整执行步骤，就需要验证调整后的操作仍然符合测试意图。

如果 AI 用于评估模型回答，就需要准备有代表性的测试样本、明确评分标准，并检查评估方式本身的可靠性。

如果质量门禁用于决定是否发布，就需要清楚哪些条件必须满足、哪些风险可以被接受，以及谁有权作出最终决定。

否则，再复杂的测试体系，也可能只是在把不确定性包装成一个看起来确定的结果。

第三，质量工作的价值不能只用过程指标衡量

执行了多少测试、自动化覆盖率达到多少、回归时间缩短了多少，这些指标都可以有价值。

但它们需要放在真实的质量目标下理解。

如果自动化执行时间明显缩短，却没有覆盖新增的高风险业务规则，团队得到的可能只是更快的回归，而不是更可靠的发布。

如果 AI 能够生成大量测试用例，却需要测试人员花费同样多的时间筛查错误和冗余内容，那么效率提升可能并没有预想中那么大。

如果一个质量平台增加了很多指标，却没有改善风险识别和发布决策，那么它的复杂程度就不能直接证明它的价值。

指标需要反映目标，而不是替代目标。

测试不是为了生产更多测试结果，而是为了获得足以支撑质量决策的证据。

第四，真正的专业，不是所有事情都由测试人员自己完成

复杂系统的质量，通常涉及产品、开发、测试、架构、运维和安全等多个角色。

测试人员需要理解技术方案，识别风险，设计验证方式，并推动问题解决。

但这不意味着每个测试人员都必须亲自实现每种技术方案。

当测试团队无法直接验证某项底层机制时，合理的工作方式是明确验证边界，要求相关责任人提供相应的测试证据和风险说明，而不是为了证明自己能力全面，就替所有专业领域作出保证。

能够识别自己的能力边界，与具备专业判断力并不冲突。

相反，知道什么已经被验证、什么尚未被验证、哪些结论需要其他证据支持，才是可靠质量工作的基础。

第五，技术学习应该有方向，而不是无限扩张的清单

我不反对测试人员学习新技术。

问题是，学习技术应该服务于职业方向和实际工作。

如果你负责复杂业务测试，那么深入理解业务规则、数据流转和异常处理，可能比增加一项新工具的使用经验更重要。

如果你负责测试基础设施，就应该关注系统的可维护性、可靠性，以及它是否降低了整个团队的质量保障成本。

如果你测试 AI 产品，就需要学习模型评估、数据质量、非确定性行为和相关安全风险。

不同岗位的能力要求本来就不同。

一个人不可能把所有新技术都学完，也没有必要把自己塑造成什么都会的全能型测试人员。

更合理的做法，是找到自己当前工作中真正需要解决的问题，再有针对性地补齐能力。

否则，学习就很容易变成一项没有终点的任务。

技术名词越积越多，职业焦虑却不一定减少。

六、我反感的不是技术高手，而是用技术给人划分等级的人

回到最初的话题。

我从来不觉得功能测试天然比自动化测试高级，也不认为自动化测试人员应该因为掌握更多技术而受到贬低。

每种能力都有适用场景。

一个人擅长业务分析，能够准确识别关键风险，是专业能力。

一个人擅长自动化工程，能够建设可靠、可维护的测试体系，同样是专业能力。

一个人能够深入分析复杂系统的性能、安全或数据质量问题，也有不可替代的价值。

真正的问题，是有人习惯把某种能力的优势，直接扩大成对其他岗位的否定。

这种思维在技术环境变化时尤其容易出现。

过去，自动化被认为比手工测试更高级。

后来，测试开发被认为比传统测试更有前景。

现在，又有人把 AI 测试看成下一道职业分水岭。

但技术发展的历史已经反复说明，工具会变，岗位的边界会变，某些过去稀缺的能力也会逐步普及。

如果我们每次都用最新的技术名词重新建立一条鄙视链，那么这种评价方式永远不会结束。

今天你因为掌握某种技术而觉得自己更高级，明天又会有人掌握一种更新的技术来评价你。

到最后，大家追逐的可能不是怎样做好测试，而是怎样确保自己始终站在鄙视链的上游。

这显然不是一个健康的职业发展方向。

我更愿意看到的是，测试人员根据自己的岗位和项目需求建立专业能力，而不是互相证明谁更落后。

技术能力应该被重视，但它需要和问题解决能力、验证能力、业务理解以及实际成果结合起来评价。

否则，我们只是建立了一套看起来更加技术化、实际上仍然很粗糙的职业等级制度。

七、最后，我想说的是

看完那篇掘金文章后，我最大的感触是：一个行业真正需要警惕的，可能不是技术更新得太快，而是我们评价人的方式跟不上技术变化。

当 AI 能够帮助生成测试、分析结果、执行部分流程时，测试人员当然需要学习新的方法。

但学习的目的，不是让自己拥有更多可以炫耀的工具。

而是让自己能够提出更好的问题，设计更可靠的验证方式，并对测试结果作出更准确的判断。

技术可以帮助我们减少重复劳动，却不能自动决定哪些风险值得关注。

自动化可以扩大测试覆盖，却不能保证我们选择了正确的覆盖目标。

AI 可以提供分析建议，却不能让未经验证的结论天然变得可信。

这些才是技术发展带来的真正挑战。

对于测试人员而言，未来需要的不是人人都成为同一种技术专家，而是每个人都能在自己的专业范围内，理解工具的能力边界，知道如何验证结果，并为自己的判断提供依据。

对于团队而言，也需要重新考虑质量工作的评价方式。

除了执行效率和自动化程度，还应该关注风险识别是否准确、质量证据是否可靠、缺陷是否得到及时发现，以及整个研发流程是否因此变得更加稳健。

当然，这些指标也不可能完全量化所有工作。

但至少，它们比简单地根据技术标签给人划分等级，更接近软件测试的实际目标。

软件测试不是一场永远追逐新工具的竞赛，也不是一场用技术给同行排座次的游戏。

技术最终要回到它应该服务的地方：帮助我们更准确地发现问题，更可靠地验证系统，并让团队能够作出有依据的质量决策。

当越来越多的执行工作能够借助工具完成时，真正值得重视的，恰恰是那些不能只靠执行本身来证明的能力。

你是否知道应该测试什么。

你是否能够判断结果是否可信。

你是否清楚结论的边界。

你是否真正帮助团队降低了质量风险。

这些问题，不会因为行业出现了新的技术名词就过时。

相反，工具越强大，我们就越应该认真回答它们。

因为在软件测试这个行业里，技术可以帮助你把事情做得更快。

但最终决定事情有没有做对的，仍然是你对问题的理解，以及你判断证据的能力。