企业官网建设流程全解析

昨天和一位在鹅厂做测试开发的老同学聊了将近两个小时。本来只是例行电话，结果从团队最近的项目聊到AI工具，话题就彻底收不住了。他现在所在的团队已经不是在“尝鲜”AI，而是真正把AI用在了日常测试流程里，还沉淀出了一套内部的使用思路。聊完回到家我又把几个关键点记成了笔记，今天整理出来，分享给所有正在琢磨“测试人员该怎么正确用AI”的同行。

这篇文章不打算追热点，也不做工具列表式的介绍，重点讲清楚三件事：测试人员用AI最容易在什么地方翻车；AI在测试工作中的正确定位是什么；以及哪些场景现在就能落地、具体该怎么操作。不管你是偏手工的测试工程师，还是做自动化、做测开的，这些思路应该都用得上。

1. 聊下来最反直觉的一点：AI让不少测试人员变“懒”了

1.1 最典型的现象：答案来得太快，判断力却跟不上了

老同学提了一个他们组里很普遍的现象：AI工具刚铺开的时候，大家热情非常高，遇到任何问题都先丢给AI。不管是写用例、查文档、解释报错，还是规划测试方案，全都问AI。最开始确实感觉效率变高了，但一个月后再复盘的时候发现，有几个人不但没有变强，反而变得依赖。

他举了一个很具体的例子。组里有个同事让AI帮忙补充登录接口的测试用例，AI很快就生成了一份看起来非常完整的用例，覆盖了正常登录、密码错误、账号锁定、参数缺失、Token过期等等，大概六七十条。同事很满意，直接贴进用例平台就准备拿去执行。结果测试一跑才发现，很多用例的预期结果根本就是错的——AI把接口文档里的字段描述直接当成了预期值，比如“当密码错误时，返回错误码1001”，但实际上这个接口的真实错误码是1002。更离谱的是，AI还把“输入密码时按Shift键导致大小写混乱”列成了一条高优用例，这种想当然的场景放在真实业务里根本不存在。

这个例子很典型，因为它说明了AI在测试场景里的一个本质问题：AI能快速给你一份“看起来正确”的答案，但它不会为答案的正确性负责。如果一个测试人员习惯了直接相信AI的输出，不再去核对需求文档、接口定义和业务逻辑，那他的判断力就会越来越钝。这就像天天开着导航开车，一旦导航出错，你自己连东南西北都分不清了。

1.2 关键不是“用不用AI”，而是“用AI的人处在什么水位”

其实我和老同学都认同，上面这些坑不是AI本身造成的，而是使用者的思路不对。同样是AI，有人能借助它把测试效率和覆盖面提升一个档次，有人却因为AI制造的“虚假效率”把质量给带偏了。

区别在哪里？区别在于，这个人是在“用AI放大自己的专业能力”，还是在“用AI替代自己的专业判断”。我拿生成测试用例来举例：

• 不会用的人：把需求文档丢给AI，让它“生成测试用例”，然后把AI生成的用例全部当成最终交付物，不做任何筛选和修改。
• 会用的人：自己先分析需求，梳理出核心业务流程和重点风险，然后让AI“根据以下测试点补充边界条件和异常场景”，把AI当成一个辅助补充信息的工具，最后再逐条review。

同样是AI生成用例，前者是“AI主导，人配合”，后者是“人主导，AI配合”。两者出来的结果，差距非常大。这也是我那位老同学最想强调的一点：AI能不能在测试里发挥价值，取决于使用者的思路，而不是工具本身有多强。

2. 测试人员用AI最容易踩的三个坑

2.1 坑一：把AI当搜索引擎，拿到答案直接信

现在很多人习惯用AI替代搜索引擎，问“pytest怎么mock某个接口”或者“JMeter怎么做参数关联”。AI确实能给出答案，但问题是，AI的技术答案很可能过时、不准确，甚至在某些冷门细节上是临时编的。我之前就踩过一回：让AI写一段Python脚本处理测试数据，它用了一个Python 3.10才有的语法特性，而项目的运行环境还是3.8，一跑直接报语法错。

测试人员如果拿AI给的命令、脚本去搭建测试环境或者写自动化脚本，至少要带着“验证”的心态去用：关键信息去官方文档核对，脚本先在小范围试跑。对AI的技术回答，我更建议做“信息来源判断”——如果它给不出依据，或者来源本身就模糊，就要提高警惕。很多时候AI给你的答案只是一个“概率上像正确答案”的文本，而不是真的经过了验证。

2.2 坑二：期望AI直接交出“成品代码/成品用例”

这个坑在AI编程工具流行之后尤其普遍。不少测试开发把AI生成的自动化测试脚本直接粘贴到项目里，结果一跑全是问题。不是AI生成的代码完全不能跑，而是它缺少与具体项目的结合：没有用项目里的统一封装、没有处理好登录态、没有考虑测试数据清理、断言写得过于简单或者干脆有逻辑错误。

老同学在这方面给了一个很实用的原则：把AI当成一个“能快速产出初稿的高级外包”。外包写的代码你敢不review就直接用吗？不敢。那AI生成的脚本也是一样，必须走完整的code review流程。而且他觉得，AI最适合做的不是“从零写一个大模块”，而是“在你已经搭好框架的情况下，帮你补齐单个用例、单个函数”。这个定位如果不摆正，很容易被AI生成的、看着很完整但一用就废的代码带进沟里。

2.3 坑三：不看上下文，乱把项目信息丢给AI

这里说的上下文有两层。第一层是“上下文信息”缺失。很多测试人员让AI分析问题，结果只丢一句“这个接口报500，帮我看看原因”。AI拿不到请求参数、后端日志、代码上下文，只能给你一段“可能是XX原因”的通用分析，这些分析往往没有实际价值，反而还会误导排查方向。

第二层是“信息安全”层面。把包含敏感信息的日志、生产环境的SQL、未脱敏的用户数据直接贴给外部AI工具，这在很多公司的规范里是不被允许的。我自己的习惯是：在上传任何信息之前，先判断一下里面有没有敏感内容，必要的时候先把手机号、身份证号、用户名这一类信息替换掉再发。同时，对AI给的建议，永远先判断“它看到的信息是否足够回答我的问题”。信息不够就先补信息，而不是反复用同一个残缺的问题去追问AI。

3. 正确的使用姿势：AI在测试里是“副驾”，不是“司机”

3.1 定位一：信息整理器，而不是决策者

测试过程中充满了信息噪音。一份需求文档可能有几十页，里面散落着各种规则；一份测试报告可能有几百条失败用例，需要从中提取规律；一堆报错日志里要定位最可疑的异常点。这些场景非常适合AI介入，因为AI擅长做总结、归纳和关键信息提取。

但注意，AI的归纳可能失真，它会在你不注意的时候把重要细节静默忽略掉。老同学团队的做法是：让AI做“整理”，人做“决策”。比如用AI把需求文档里的所有“必须”“不能”“仅限于”“除外”这类约束性词汇抓出来，整理成一份测试约束清单，但最终哪些约束要转化为高优用例，哪些只是业务背景说明，需要人来判断。AI负责把信息嚼碎了摆在桌面上，但“怎么吃、吃哪些”这种事，必须由人来定。

3.2 定位二：初稿生成器，而不是最终产物

这个定位在处理测试用例、自动化脚本、测试报告、甚至提给开发的Bug单时都成立。核心做法是：让AI先生成初稿，再由人来打磨。问题在于，你要拿这份初稿当“索引”还是当“答案”：

• 当索引用：把AI生成的用例当成线索，从里面发现自己没想到的边界点，再结合业务经验去增删改。
• 当答案用：把AI生成的用例直接提交入库，省掉自己的思考环节，等于把质量判断权交了出去。

真正成熟的测试人员，一定是用第一种方式。AI生成的初稿只是素材，你的判断才是让它变成可交付物的关键。

3.3 定位三：学习加速器，而不是权威知识库

老同学特别提了一点：AI对于测试人员来说，其实是一个极好的学习工具，但前提是你要把它当成“教练”而不是“答案机”。

举个例子。如果你完全不熟悉性能测试，与其直接让AI“帮我写一份压测方案”，不如让它“先讲一下性能测试的整体流程、常用指标、常见瓶颈，再结合一个典型的电商登录场景给一份压测设计思路”。第一种问法，你得到的是一份不确定可不可用的方案；第二种问法，你学到的是解决这一类问题的思路。区别很明显。

我个人也补了一句：AI给出的知识必须交叉验证，尤其是遇到版本差异、行业规范、合规要求这类问题，一定要去一手资料确认。AI很多时候会用一种非常权威的语气说出并不靠谱的内容，这种“权威感”是语气上的，不是事实上的。

4. 可以从明天开始用起来的五个AI测试实践场景

4.1 场景一：需求分析阶段，用AI做测试点挖掘

测试人员在需求评审前，最耗时间的工作就是把PRD里的功能点拆成测试点。这个工作非常适合让AI先做一遍初筛。

做法：把PRD或需求描述整理成精简版（注意去掉敏感信息），发给AI，让它结合需求列出功能测试点、异常场景、边界值、潜在风险。提示词可以参考下面这个模板：

你是一名资深测试工程师。下面是我负责的一个需求（粘贴需求内容）。 请帮我完成两件事： 1. 列出所有需要测试的功能点，区分主流程和次流程； 2. 针对每个功能点，补充3-5个容易遗漏的边界条件和异常场景。 输出格式：功能点 / 测试点 / 优先级。 先不要解释，直接输出结果。

这里有一个容易踩的细节：AI不了解你的业务背景，所以提示词里要补充“用户是谁”“这个需求的核心价值是什么”“哪些模块是本次改动重点”。这些业务上下文AI猜不到，你不给它就会跑偏。

4.2 场景二：测试用例设计阶段，用AI补边界值

我自己最常用的做法不是让AI一口气生成全套用例，而是先设计好主干用例，然后让AI“找漏洞”。这个用法更安全，因为主干用例是经过你思考的，AI只是作为补充视角。

下面是我为登录功能设计的测试用例（粘贴已有用例）。 请帮我从边界值、异常输入、并发、安全性、用户体验几个维度，补充我可能遗漏的测试场景。 只输出补充的场景，不要重复已有的。 请为每个补充场景标注补充理由。

这个做法相当于让AI扮演一个“挑刺的同事”。它提出的补充不一定全都合理，但往往能给你一些平时想不到的角度，比如极端输入组合、重复提交、缓存导致的脏数据等问题。最后你把这些补充场景和自己的理解融合一下，再用业务经验做一轮筛选，测试用例的完备度就会高很多。

4.3 场景三：缺陷分析阶段，用AI做初步定位

当测试环境出现一个比较难定位的Bug时，我习惯把核心报错日志做脱敏处理后丢给AI，让AI做第一轮分析。注意，我强调的是“第一轮分析”——目的不是让AI直接告诉我根因，而是让它帮我列出一个排查方向清单。

以下是页面/接口报错的关键日志（粘贴日志）。 请从日志中提取关键异常栈，列出可能导致这个错误的原因，按可能性从高到低排列。 为每个原因附上对应的日志证据。 如果日志信息不足，请直接告诉我还需要补充哪些信息，不要猜测。

这样做的价值在于，AI能帮你快速覆盖那些你不熟悉的技术栈，尤其是遇到一些冷门中间件、老代码框架的报错时，它能给出很多你完全想不到的排查方向。但根因最后一定得自己去看代码、复现、确认，不能AI说什么就信什么。

4.4 场景四：自动化脚本生成与维护阶段，用AI做“填空”

AI编程工具现在确实很强，但测试脚本生成时尤其要注意它和项目的耦合。我见过很多人让AI“生成一个完整的接口自动化脚本”，结果AI生成的代码自成一套体系，跟项目现有的框架完全对不上，根本没法用。

我的做法是：把项目里的自动化框架结构、公共方法、已有脚本样式作为背景信息给AI，让它在“你的框架”里补脚本，而不是让它从零生成。

我们的自动化测试框架是Python + pytest + requests。 公共方法在 common/api_helper.py 里，已有登录态获取函数是 def get_token(user):。 请参照现有脚本的写法和风格，为“修改用户信息”接口编写一条完整的测试用例。 断言要包含状态码、响应码和关键字段。 先输出脚本，再简要说明脚本中需要适配本项目的部分。

AI生成完脚本之后，一定要在本地跑通再提交。跑不通也没关系，把报错信息回喂给它，让它带着报错继续修。这个过程里，你既完成了脚本，也顺便把框架的基础用法过了一遍。

4.5 场景五：测试报告与质量数据分析

每周写测试报告、发质量周报，是很多测试人员的固定负担。AI可以把这部分繁琐的整理工作减轻很多。把原始测试数据整理成文本或表格，让AI生成报告初稿，效率会高不少。

以下是一周的测试执行数据（粘贴数据）。 请帮我生成一份测试周报，包含： 1. 总体执行情况； 2. 缺陷分析（按模块、按严重级别分布）； 3. 风险与建议。 要求：数据必须完全基于我提供的内容，不得编造。 如果数据不足以得出结论，请明确说明数据不足。

这里要特别警惕：AI有“脑补”倾向，它会为了答案的完整性而编出一些看起来合理的结论。所以你必须在提示词里明确要求它“只基于事实，不做主观推测”。报告生成之后，所有数字都要人工核对一遍，这步不能省。

我把上面五个场景汇总一下，方便参考：

5. 老同学反复强调的“提示词能力”到底是什么

5.1 提示词的本质是结构化表达，不是咒语

聊到后半段，老同学反复强调一个点：会用AI的人，和不会用AI的人，差别往往不在技术背景，而在“能不能把问题讲清楚”。这句话当时给我的触动挺大，因为这不就是我们测试人员天天在做的事吗？我们写Bug单要写复现步骤、写预期结果、写实际结果；我们做测试设计要描述场景、前置条件、操作步骤。这些都是结构化表达。

所以老同学觉得，测试人员学写提示词，其实是有天然优势的。一个好的提示词，本质上就是把“背景信息、任务目标、限制条件、输出格式”一次性表达清楚。这不是什么玄学，就是沟通能力在AI场景下的延伸。

5.2 一个可以直接套用的提示词框架

结合我自己的使用习惯，我整理了一个适合测试场景的提示词模板，你拿去改一改就能用：

角色：你是一名（测试角色），有（X）年经验。 背景：（描述项目/模块/技术栈/当前阶段，越具体越好） 任务：请帮我（具体任务，如设计测试用例/分析日志/写脚本）。 限制：只基于我提供的信息，不要做超出信息的推测；不要使用（某些不想要的方式）；如果信息不足，请先提问。 输出：请以（表格/列表/代码块）的形式输出，包含（字段1/字段2）。

这个模板里最关键的是“背景”和“限制”两部分。背景决定了AI输出的相关性，限制决定了AI输出的可靠性。很多人觉得AI答案质量差，往往就是因为背景信息给得太少，边界条件没有说明白，AI只能基于一堆模糊的假设来猜。

5.3 会提问，比会念咒更重要

所以我其实不太建议大家去网上背一堆所谓“AI魔法咒语”，那些东西的效用往往是暂时的。真正有效的，是你对自己问题的理解深度。当你能把“我的需求是什么、我希望AI做什么、我不要它做什么”这三句话讲清楚的时候，不管AI工具怎么迭代，你都能把它用得很好。

这个观点老同学也特别认可。他说他们团队现在培训新人，第一课不是教哪个AI工具好用，而是教怎么把自己的测试思路结构化地表达出来。工具会变，提示词的表面形式会变，但底层这个能力不会过时。

6. AI替代不了的那部分，才是测试人员的核心价值

6.1 AI能做的，和做不了的

聊到后面，我们不可避免谈到了焦虑感：AI会不会让测试人员失业？我的看法是，我们先把AI能做什么、不能做什么这个问题看清楚，再讨论焦虑也不迟。

这张表其实已经说明问题了。AI能做的，更多是“执行层”和“整理层”的工作；而真正决定一个测试人员价值的，恰恰是“判断层”和“决策层”的工作。

6.2 测试人员未来的四种核心能力

基于上面的分析，我觉得未来测试人员的核心竞争力，会越来越集中在四块：

• 业务理解力：懂用户、懂业务规则，知道什么值得测、什么不值得测。
• 测试设计力：能设计出高效的、不冗余的测试策略，而不是简单地堆用例数量。
• 工程化能力：能把AI工具和现有的测试框架结合起来，搭出完整高效的测试工具链。
• 推动力：能把质量风险讲清楚，推动团队和业务方一起解决质量问题。

老同学当时说了一句话，我记录下来：“AI会让很多初级的、重复性的测试工作消失，但也会让真正懂测试的人价值变大。关键在于你能不能从执行者变成设计者和决策者。”这句话我觉得是会慢慢被验证的。

6.3 与其焦虑，不如从一个小场景开始

最后聊到心态。我给测试同行的建议是：不用焦虑到把AI神话，也不用装作看不见。老老实实挑一个自己最痛、最频繁的场景，用AI去解决它，完整地走一遍“人主导、AI配合”的流程，亲身感受一下什么样的输出能用、什么样的输出不能用。走完这个流程，你对“AI到底能帮我做到什么程度”就有了真实的体感，这比看任何文章都管用。

聊天结束的时候，老同学说他还总结了一句话：AI不是来替代测试人员的，AI是来逼着测试人员变得更强的。这话听起来有点鸡汤，但结合我们聊的那些案例，我觉得它确实是现在正在发生的事情。未来的测试人员，大概率不会是被AI淘汰的，而是会被那些“会用AI的测试人员”拉开差距。与其停在原地纠结，不如今天就挑一个重复劳动最多的场景，认真用AI走一遍。等你自己跑通了，你心里自然会有答案。