AI时代:测试经理的20道AI大模型面试题(含答案)

前几天和一个做了8年测试的朋友聊天，他说他们公司开始推AI测试了，老板问他”你怎么看这件事”。他当时有点懵，说实话，不太知道该怎么回答。

这其实是很多测试经理现在面临的问题。AI来了，我们到底要做什么？要学什么？团队怎么带？

我整理了20个面试中经常出现的问题，配上我的理解。不一定对，但都是实际工作中会遇到的。

一、先搞懂基本概念

1. 大语言模型和以前说的”AI”是一回事吗？

说实话，不太一样。

以前我们说的AI，基本都是”专项AI”——比如专门做图像识别的、专门做语音转文字的。每个AI只能干一件事，而且得针对这个场景单独训练。

大语言模型（LLM）不一样，它是”通用”的。你跟它说人话，它能理解，还能干各种活——写代码、写文档、分析问题、甚至跟你聊天。

对测试来说，最大的区别是：以前的AI是工具，现在的AI更像是”助手”。你可以跟它对话，让它帮你干活，而且它还能理解上下文。

不过有个问题得注意：LLM的输出是”非确定性”的。你问两遍同样的问题，可能得到两个不太一样的答案。这对测试来说是个挑战——我们习惯了对确定的东西进行测试，现在得学会应对”不确定”。

2. Token是什么？为什么测试要关心这个？

Token就是大模型”看书”的最小单位。英文大概4个字母算1个token，中文大概1.5-2个字算1个token。

为什么要关心？三个原因：

第一，钱的问题。 用API调用大模型是按token收费的。你如果让AI帮你生成1000条测试用例，得算算成本。我们团队试过，生成一份中等规模的测试用例集，大概要花10-20块钱（看用什么模型）。看起来不多，但如果每天都用、每个人都用，得有个预算。

第二，输入长度限制。 每个模型都有token上限。比如GPT-4是8K token（大概6000字中文），Claude可以到100K。如果你把整个需求文档（几万字）直接贴给AI，它读不完，后面的内容就丢了。

第三，输出也可能被截断。 AI生成的内容如果太长，也可能被强制截断。我们遇到过生成测试用例时，生成到第15条突然断了的情况。

实际建议： 跟AI交互时，把任务拆小。不要一次性让它”帮我生成整个系统的测试用例”，而是”帮我生成登录模块的测试用例”。

3. 提示词工程（Prompt Engineering）到底是什么？

说人话就是：怎么跟AI说话，它才能听懂你要什么。

我举个对比的例子。

不好的问法：”帮我写个登录的测试用例”

这种问法，AI不知道你要什么格式的、要覆盖哪些场景、要详细到什么程度。它只能猜，猜错了你还得重新问。

好一点的问法：”你是一个有5年经验的测试工程师。现在需要为Web系统的登录功能设计测试用例。要求覆盖：正常登录、异常登录（密码错误、账号不存在）、边界情况（空输入、超长输入）。每个用例要包含：用例标题、前置条件、操作步骤、预期结果。用Markdown表格输出。”

看到区别了吗？你把背景、任务、要求、格式都讲清楚了，AI就不用猜了。

我们团队现在有个”提示词模板库”，把常见的任务（生成用例、生成脚本、分析缺陷）都写好了模板，大家直接用。效率提升很明显。

4. 大模型有什么毛病？测试工作中怎么避开？

说实话，大模型有几个挺让人头疼的问题：

幻觉（Hallucination）——它会编。你问它”你们的登录功能支持指纹识别吗？”，它可能真的给你编一个答案，而且编得很像那么回事。所以AI生成的内容，关键部分必须人工复核。

记性不好——你跟它聊了10轮，它可能忘了第1轮你说的是什么。所以不要把重要信息只放在对话里，要写到需求文档或者测试用例里。

逻辑能力一般——让它做复杂的业务逻辑判断，容易出错。比如”如果用户余额不足，而且今天是周五，而且他是中国区用户，应该怎么处理？”这种多层条件的判断，AI容易搞混。

知识有截止日期——它不知道最新上线的功能。所以跟它讨论具体项目时，得把相关文档发给它看。

我们团队的做法是：AI负责”初稿”，人工负责”把关”。这样既能提高效率，又不会出大问题。

二、AI能帮测试做什么？

5. AI能替代哪些测试工作？

先说结论：AI不太可能完全替代测试工程师，但会替代一部分重复性工作。

AI比较擅长的：

根据需求文档，生成测试用例初稿（然后人工优化）

生成测试数据，尤其是边界值、异常数据

根据测试用例描述，生成自动化脚本代码

根据报错日志，生成缺陷报告的初稿

分析代码变更，推荐需要回归测试的范围

AI不太行的：

制定测试策略——这个需要你理解业务、理解风险，需要判断

探索性测试——需要人的直觉，需要”乱点”和”尝试”

用户体验评估——”这个交互顺不顺手”，AI很难判断

复杂业务场景的设计——比如”双11大促的全链路压测场景”，AI不太懂业务

我自己的感受是：AI把测试工程师从”执行者”推向了”审核者+决策者”。以前我们花60%的时间写用例、写脚本，现在这部分可以让AI做初稿，我们花更多时间在做决策、做分析。

6. 怎么判断AI生成的测试用例好不好？

我们团队现在是这样做的：

第一步：看覆盖率。 把AI生成的用例和需求文档对比，看看有没有遗漏的功能点。我们用的办法比较土，但有效——拿Excel表，左边列需求点，右边列用例，人工过一遍。

第二步：看可执行性。 AI生成的用例，有时候步骤写得很模糊。比如”验证登录功能”——怎么验证？输入什么？点哪个按钮？这种用例得人工细化。

第三步：看冗余度。 AI有时候会生成很多相似的用例。比如”密码为空”、”密码为空格”、”密码为null”，可能就是同一个问题的三种表述。这种得合并。

第四步：抽样执行。 随机挑20%的用例实际执行一下，看看AI的预期结果对不对。如果准确率能到90%以上，说明AI生成的质量还可以。

一个小技巧： 如果AI生成的用例质量不好，不要急着否定AI，先看看是不是你的提示词写得不够清楚。我们经常是优化了提示词之后，生成的用例质量明显提升。

7. 自动化测试维护一直是个痛点，AI能帮忙吗？

能帮上忙，而且帮得挺大。

痛点1：UI变了，脚本全挂了

这是做自动化测试的人最头疼的事。前端改了个按钮的id，50个脚本都定位不到这个按钮了。

AI可以帮你分析DOM变化，推荐新的定位器。比如以前用的是id=login-btn，现在按钮改成class=btn-primary了，AI可以建议你改成css=.btn-primary。

更进一步，有些工具（比如Testim、Mabl）已经在做这件事了——当元素定位失败时，自动尝试其他定位策略，不需要人工干预。

痛点2：脚本失败了，不知道为什么

跑自动化测试，100个用例挂了30个。传统做法是逐个看报错日志，很耗时。

AI可以帮你把失败原因归类。比如”这15个失败都是因为’元素未找到’，可能是页面加载慢了；这10个失败都是因为’断言失败’，可能是数据问题”。这样你可以按类别去修复，效率高很多。

痛点3：测试数据准备麻烦

要做性能测试，需要1000个模拟用户。传统做法是写SQL脚本或者让开发帮忙。

AI可以根据你的数据模型，直接生成模拟数据。比如你说”我需要1000条用户数据，包含姓名、手机号、邮箱，手机号要符合中国大陆格式”，AI可以很快生成。

8. 回归测试怎么用AI提效？

回归测试最大的问题是：每次全量跑太慢，只跑一部分又怕漏。

AI可以帮你做”智能用例选择”——分析这次代码变更影响了哪些模块，然后推荐应该跑哪些测试用例。

原理大概是这样：把代码变更（diff）和测试用例的对应关系告诉AI，它会分析哪些用例最可能受到影响。我们试过，原本要跑500个用例，AI推荐跑150个，结果发现缺陷的效果差不多（漏测率只增加了2-3%），但时间缩短了70%。

另外，AI还可以帮你做”缺陷预测”——根据历史数据，告诉你哪些模块容易出bug，建议你多做探索性测试。

9. 性能测试能用上AI吗？

能用，但现在还不太成熟。

有一些工具在尝试，比如用AI生成更真实的负载模型（模拟用户的访问模式），或者用AI分析性能数据、自动定位瓶颈。

但我们实际用下来，感觉AI在性能测试里更适合做”辅助分析”——比如你跑完压测，把数据给AI，让它帮你分析”为什么TPS在这个时间点掉下来了”。至于测试场景设计、目标设定，还是得人来。

三、工具选型和平台建设

10. 如果要建团队的AI测试能力，你怎么规划？

这个问题我被问过好几次，说说我们的做法。

第一阶段：小范围试点（1-3个月）

不要一上来就全员推广，很容易翻车。先选1-2个场景，比如”AI辅助生成测试用例”，在小范围内试用。

选什么工具？我们当时试了几个：

ChatGPT API（灵活，但需要自己封装）

GitHub Copilot（写代码挺好用）

国内的智能助手API（成本低一些）

试完之后，出一份试点报告，讲清楚：用了什么、效果怎么样、有什么问题、值不值得推广。

第二阶段：制定规范+培训（3-6个月）

如果试点效果不错，开始推广。但这时候不能只把工具发给团队就完事了，得有配套的东西：

使用规范：什么场景可以用AI、什么场景不能用

提示词模板库：大家不用每次都从零开始写提示词

培训：教大家怎么写提示词、怎么评估AI生成的内容

第三阶段：平台化（6-12个月）

如果用了半年，效果确实好，可以考虑把AI能力集成到测试管理平台里。比如点在”生成用例”按钮，系统自动调用AI，生成完直接保存到用例库。

这样用起来更方便，也更容易量化效果（比如”这个月AI生成了500条用例，节省了XX小时”）。

11. 现在有哪些AI测试工具值得看？

说几个我们用过或者调研过的：

测试用例生成：

Testim、Mabl——国外的，比较成熟，但贵

MeterSphere——国内的，有AI能力集成，性价比还行

代码辅助：

GitHub Copilot——写自动化脚本时挺好用，能省不少时间

Tabnine——类似Copilot，但更轻量

视觉测试：

Applitools——用AI做UI截图对比，适合有大量页面需要回归的场景

Percy——类似Applitools

选工具的时候，我们主要看五个维度：跟现有工具链能不能集成、生成内容准不准、团队学习成本高不高、多少钱、数据能不能私有化部署。

最后这点（数据安全）特别重要。我们一开始有人直接把公司代码贴到ChatGPT里去问问题，被信息安全部门警告了。后来制定了规范，只能用公司统一申请的API，不能直接用公网的ChatGPT。

12. 用AI测试，数据安全问题怎么解决？

这是个严肃的问题。

风险点：

你把公司的代码、需求文档上传到公有云AI，这些信息可能被”记住”

测试数据里可能有敏感信息（手机号、身份证），如果直接发给AI，就泄露了

AI生成的代码，可能有安全漏洞

我们的做法：

第一，制定规范。明确哪些信息可以发给AI、哪些不行。比如”代码可以，但配置文件不行”、”模拟数据可以，但真实用户数据不行”。

第二，尽量用支持私有化部署的AI。比如我们后来部署了一个本地的ChatGLM，数据不出公司内网，安全很多。

第三，AI生成的代码，必须经过安全扫描才能提交。

13. 怎么证明AI测试是值得投入的？

老板肯定会问这个问题：”我花20万买AI工具，能省多少钱？”

我们当时是这么算的：

效率提升：

以前写100条测试用例，要2天；现在AI生成初稿+人工优化，大概半天。节省75%的时间。

按我们团队10个人算，每人每周省4小时，一年就是2000小时。按人均成本30万/年算，节省的人力成本大概是30万。

工具成本：

AI工具采购：20万/年

实施和培训：5万

ROI = (30 – 25) / 25 = 20%

第一年可能回不了本，但第二年、第三年，工具成本摊薄了，ROI会更高。

除了钱，还有一些”软性价值”很难量化，但也得说：比如团队满意度提高了（不用干重复性工作了）、对业务的响应速度快了。

四、团队管理和人员转型

14. AI时代，测试工程师要学什么新东西？

说实话，变化挺大的。

以前测试工程师的核心能力： 需求分析、用例设计、自动化脚本、缺陷管理。

现在要新增的：

提示词工程——怎么跟AI对话，让它产出你要的东西。这个现在已经是必备技能了。

AI工具评估——市面上那么多AI工具，哪个适合你的场景？得会评估。

AI输出质量评估——AI生成的东西，你得能判断好不好、能不能用。

我们团队现在的要求是：初级测试要会用AI辅助日常工作（比如生成用例、生成数据），中级测试要能评估AI工具并优化工作流程，高级测试要能设计AI测试方案。

15. 团队里有人抵触AI，怎么办？

这个问题真的很常见。我见过几种抵触的原因：

“我怕被替代”——这是最多的。得跟他们讲清楚：AI是助手，不是替代者。它帮你干重复性工作，你可以去做更有价值的事。

“我觉得AI没用”——可能是试过但效果不好。这时候不要急着说服，拿数据说话。我们当时做了一个对比：同一份需求，传统方式写用例要4小时，AI辅助要1小时。大家看到实际效果，自然就接受了。

“我不想学新东西”——这个比较麻烦。只能靠培训和激励。我们后来设了一个”AI应用创新奖”，谁用AI解决了实际问题，给奖励。

16. 怎么设计AI测试的培训？

我们做的是分层培训。

全员都要学的： AI基础知识、提示词工程入门、AI工具使用规范。大概4小时。

按角色深入的：

测试工程师：学怎么用AI生成用例、生成脚本

自动化工程师：学怎么用AI优化脚本维护

测试经理：学怎么评估AI工具、怎么算ROI

持续学习： 建一个内部群，大家分享”我用AI做了什么”。定期举办”提示词优化工作坊”，一起讨论怎么把提示词写得更好。

17. AI会不会替代测试经理？

短期（3-5年）不会，但工作方式会变。

测试经理的核心价值在哪里？决策、沟通、判断。这些事，AI很难做。

比如：这个项目要不要做性能测试？测到什么程度？发现了一个缺陷，要不要阻塞发布？这些问题需要你权衡风险、理解业务、跟各方沟通，不是AI能搞定的。

但日常工作方式会变。以前可能要亲自写测试计划、亲自审查用例，现在可以让AI做初稿，你来做审核和决策。

我自己的感受是：学会跟AI协作，比抗拒它更有用。AI不会替代你，但”会用AI的测试经理”会替代”不会用AI的测试经理”。

五、一些前瞻性思考

18. 除了大语言模型，还有哪些AI技术可以用在测试里？

说几个：

计算机视觉（CV）——已经比较成熟了。比如用CV做UI自动化，不依赖元素定位，直接”看”页面。Applitools就是这么做的。

代码大模型（Code LLM）——专门用来生成和理解代码的，比如CodeGeex、Code LLaMA。生成测试脚本时，比通用大模型更准确。

多模态大模型——可以”看懂”截图、视频。比如你截一个页面图，它能告诉你”这个页面有哪些元素、分别在哪里”。将来可能做到”截图→自动生成测试用例”。

其他的，比如强化学习、知识图谱，也有人在研究，但还没到成熟应用的阶段。

19. “AI完全自主测试”可能实现吗？

我的看法是：部分场景可以，但完全自主不太现实。

为什么？因为测试的本质是”质疑”——你要去找系统的毛病，要思考”这里会不会有问题”。这种批判性思维，AI不太擅长。AI更擅长的是”执行已知的任务”，而不是”发现未知的问题”。

但部分场景可以实现高度自动化。比如回归测试，AI可以自动选择用例、自动执行、自动分析失败原因。这在一定程度上已经能做到。

探索性测试，AI可以辅助，比如给你推荐”可以试试这些场景”，但主导的还是人。

20. 如果要你给CTO汇报”AI测试战略”，你怎么讲？

这个问题我被问过。说说我们的套路。

开场不要讲概念，讲问题。 “我们现在回归测试要跑2天，自动化脚本维护成本很高，想用AI解决这个问题。”

然后讲方案，分阶段讲。 “第一阶段我们先试点3个月，看效果。如果好，再推广。”

然后讲钱。 “预计投入25万，节省人力成本30万，ROI大概20%。”

最后讲风险。 “主要风险是AI生成内容的质量不稳定，我们的应对措施是’AI生成+人工审核’。”

结尾要一个明确的决策。 “今天想请您批一下试点预算，3个月后我再来汇报结果。”

最后的话

AI来了，测试经理要做什么？我觉得核心就三点：

第一，自己先搞懂。 不知道AI能干什么、不能干什么，就没法带领团队。

第二，选好场景，小步快跑。 不要一上来就搞大平台，先在一个小场景里试用，看到效果再推广。

第三，关注人。 团队的能力转型、心理疏导，可能比技术本身更重要。

这篇文章里的观点，都是我们在实际工作中摸索出来的，不一定对，但都是真实体会。如果你也在做AI测试相关的事，欢迎交流。