谈谈测试人员的核心竞争力

尤其是我们做测试管理和具体测试实施的人，会更直接地感受到这种压力。以前一个需求从设计、开发到提测，中间还有相对明确的周期；现在很多功能可能在AI辅助下很快就能做出一个版本，甚至一天内就能反复调整。研发侧的效率提升了，测试侧如果还是完全按过去的方式接需求、写用例、执行、提缺陷，很容易被节奏推着走。

真正能让测试人员长期站得住的，应该是三件事：对业务的理解、对质量的判断力，以及持续学习的能力。

一、先要懂业务，否则测不出真正的问题

测试工作很容易陷入一种状态：需求写什么，我们就测什么；页面有什么，我们就点什么；接口返回什么，我们就校验什么。这样当然也能发现问题，但更多是发现表层问题。

到了AI应用场景里，这种方式就更不够用了。

比如智能问答，系统能返回答案，不代表答案真的可用。回答看起来很完整，也可能引用了错误制度、混淆了适用范围，或者把已经过期的内容当成现行规则。再比如智能问数，页面能展示结果，不代表指标口径就是对的；模型能生成查询语句，也不代表它理解了业务人员真正想查什么。

这类问题，如果测试人员不了解业务，是很难判断出来的。

我现在做AI相关测试时，一个很明显的感受是：很多问题不是“功能通不通”的问题，而是“业务上能不能信”的问题。能不能信，就要求测试人员知道这个场景原本是怎么工作的，业务人员为什么要用它，哪些结果会影响判断，哪些边界不能突破。

传统系统也是一样。做性能测试时，如果只看并发数、响应时间、TPS这些指标，也容易把问题看窄。真正有价值的性能测试，不只是压一压系统，而是要知道哪些业务高峰会同时发生，哪些批量任务会叠加，哪些接口是关键链路，哪些场景一旦慢下来会影响业务办理。

所以，测试人员不能只做系统的使用者，还要尽量做业务的理解者。只有理解业务，才能把业务风险转成测试场景；只有知道业务真正关心什么，才能判断哪些问题是必须优先处理的。

二、要有质量判断力，不能只停留在“发现问题”

以前我们经常说测试人员要发现缺陷。但现在我觉得，仅仅发现缺陷还不够。

因为很多问题被发现以后，真正困难的是怎么判断它的性质、影响和优先级。

特别是在AI应用里，质量问题不像传统功能那样容易判断。一个按钮点了没反应，这是明确缺陷；一个接口返回500，这是明确异常。但如果一个大模型回答不够准确、不够稳定、不够符合业务语境，这个问题该怎么定性？是模型能力问题、知识库问题、提示词问题、数据权限问题，还是产品设计问题？

如果测试人员只是写一句“回答不准确”，其实很难推动问题解决。研发也很难知道该从哪里改，业务也很难判断问题有多严重。

所以测试人员要做的，不只是把问题抛出来，而是尽量把问题说清楚。

比如要说明：这个问题出现在哪类场景下，是否可以复现，影响的是普通体验还是业务判断，是否涉及制度口径、数据权限、安全合规，建议从哪个环节排查。能说到这个程度，测试的价值就不一样了。

这也是我认为AI时代测试人员最不能丢的能力：质量判断力。

AI可以帮助我们生成测试点，可以辅助写用例，可以整理缺陷，也可以做一些结果分析。但AI不一定知道这个问题在当前业务背景下到底严重不严重，也不一定知道这个结果对用户意味着什么。最终的判断，还是要靠测试人员结合业务、系统、风险和项目实际来做。

尤其是在测试管理中，很多时候我们面对的不是单个缺陷，而是一类风险。比如需求输入不清楚、测试范围边界不明确、研发改动未同步、配置调整没有复核、脚本质量不稳定、评测标准没有统一。这些问题如果只在项目后期暴露，成本就会很高。

测试人员的作用，不应该只是等问题发生后登记缺陷，而是要在需求评审、方案审核、测试设计、执行分析这些环节里，尽量提前把风险识别出来。

三、要持续学习，不然很快跟不上变化

AI时代还有一个很现实的问题，就是要学的东西变多了，而且变化很快。

以前做测试，主要关注业务流程、数据库、接口、性能指标、安全规范等内容。现在做AI应用测试，还要理解大模型、RAG、向量库、知识切片、提示词、智能体、模型评测、拒答能力、幻觉问题、长文本性能、Token生成速率等内容。

这些东西不可能一下子全部学透，也没有必要把每个测试人员都变成算法专家。但至少要知道它们大概是什么，问题可能出在哪一层，测试时应该关注哪些风险点。

比如做智能问答测试，如果不了解RAG，就很容易只盯着最终回答，而忽略知识库文档质量、切片策略、召回准确率、引用来源、权限过滤这些问题。做AI性能测试，如果不了解大模型调用的特点，就容易只套用传统系统的性能指标，而忽略首字响应时间、Token输出速度、长上下文输入、并发下稳定性这些更贴近AI场景的指标。

所以持续学习不是一句口号，而是现实需要。

但我觉得测试人员的学习，不能只停留在看概念、追热点。更重要的是把学到的东西变成自己的测试方法。比如把项目里发现的问题沉淀成检查清单，把专项测试经验沉淀成用例集，把常见风险整理成评审关注点，把手工执行步骤逐步改造成自动化工具。

这样学习才会真正有用。否则看了很多材料，过一段时间还是不知道怎么落到测试工作里。

四、AI会改变测试工作，但不会替代测试人员的判断

我不太认同一种过于简单的说法：AI来了，测试人员就会被替代。

更准确地说，AI会替代一部分重复性、低判断含量的工作。比如初步生成测试用例、整理会议纪要、归类缺陷、生成脚本模板、批量分析结果等。这些工作以后一定会越来越多地交给AI完成。

但测试人员真正有价值的部分，不是机械地产出这些内容，而是知道这些内容该不该这样做。

AI生成的测试点是不是覆盖了关键风险？
AI写出来的用例是不是符合当前业务场景？
AI判断的结果是不是可靠？
AI整理出来的问题分类是不是准确？
哪些内容可以直接采用，哪些必须人工复核？

这些都需要测试人员来把关。

所以我更愿意把AI看成测试能力的放大器，而不是简单的替代品。它能提高效率，但前提是测试人员要会设计工作流程，让AI在合适的位置发挥作用。

比较理想的方式，是让AI参与测试工作的多个环节，但不要让AI直接替人做最终判断。比如需求阶段用AI辅助识别模糊点和风险点，设计阶段用AI生成初版测试点，执行阶段用工具批量运行用例，分析阶段用AI辅助归类问题，最后由测试人员结合业务风险和质量标准做判断。

也就是说，AI可以帮我们干更多事，但测试人员要负责定义标准、设计流程、审核结果。

五、测试人员要把个人经验沉淀成方法和资产

这几年做测试管理，我还有一个感受：很多测试经验如果不沉淀，很快就会散掉。

一个项目里发现的问题，如果只是当时解决了，下个项目还可能再出现。一个人掌握的方法，如果没有整理出来，换个人就又要重新摸索。一个团队如果长期靠个人经验支撑，短期能运转，长期一定会吃力。

所以测试人员要提升竞争力，还要有意识地把经验沉淀下来。

比如性能测试中，哪些场景容易被遗漏，哪些需求信息必须提前确认，哪些指标变更必须走流程，哪些混合场景需要重点验证，这些都可以沉淀成风险排查清单和方案评审要点。

AI测试也是一样。智能问答怎么测，智能问数怎么测，智能写作怎么测，智能审查怎么测，不同场景关注点肯定不一样。测试过程中发现的拒答问题、幻觉问题、引用错误、权限风险、长文本性能问题，都应该逐步整理成专项用例集、评测集和准出标准。

这些东西看起来是文档、模板、用例和工具，但本质上是测试能力的沉淀。

真正成熟的测试团队，不能只靠某几个人“有经验”。更好的状态是：经验能够被复用，新人能够按模板上手，项目能够按标准推进，问题能够按机制跟踪，质量判断能够有依据。

这也是我现在比较关注的一件事：不只是完成某个项目的测试，而是尽量把项目里的方法、问题和标准留下来。

六、结语：测试人员要证明自己的判断价值

AI时代，测试人员一定会面对压力。研发效率提升了，项目节奏变快了，系统也越来越复杂。测试如果不变化，就会越来越被动。

但我也觉得，这恰恰是测试人员重新定义自身价值的机会。

过去测试人员的价值，可能更多体现在执行测试、发现缺陷、保障上线。以后测试人员的价值，会更多体现在理解业务、识别风险、判断质量、设计流程、沉淀体系。

简单说，就是不能只问“这个功能有没有问题”，还要问：

这个场景真正的业务风险是什么？
这个问题会影响谁？
这个质量标准够不够清楚？
这个测试结果能不能支撑上线判断？
这次项目经验能不能变成下次可复用的方法？

我认为，在AI时代，测试人员保持竞争力的关键，不是比AI更快地写用例，也不是比工具更快地执行脚本，而是要比AI更懂业务、更懂质量、更能承担判断责任。

工具会变，技术会变，项目形态也会变。但只要测试人员还能把业务风险看清楚，把质量问题讲明白，把复杂工作沉淀成方法，就仍然有不可替代的价值。