去年开始，大模型成了测试圈的新宠。我也跟风试了几个，最后把 Gemini 留在了日常工具栏里。为啥？因为它真能帮我“偷懒”，而且偷得很有技术含量。
但坦白讲，刚开始用的时候，我差点把它卸载了。问它“写个自动化脚本”，给我的代码跑都跑不起来；让它“生成测试用例”，结果全是些“输入正确/错误用户名”的废话。折腾半天，效率没提上来，火气倒是涨了不少。
后来才想明白，不是Gemini不行，是我这个老测试不会“说人话”给它听。 它是个聪明的助手，但不是我肚子里的蛔虫。
今天，我就掏心窝子，把这一年多踩过的坑、攒下的“黑话”心得分享出来。不整那些虚头巴脑的理论，就聊怎么让Gemini真正成为你的左膀右臂。
第一招：别让它猜，直接“喂”上下文
很多兄弟一上来就甩一句：“帮我测登录功能”。Gemini能知道你测的是Web还是App吗？前端是React还是Vue？后端认证用的是JWT还是Session？八成是瞎蒙。
结果就是，你拿到一堆需要重写的废稿。
我的做法很简单：一次性把背景交代清楚。 多打几行字，换来的是省下半小时的返工。
比如，我会这么问：
“我们有个React的Web后台，登录页在
/signin。用户名框ID是submit-btn。后端用JWT，成功后跳转到/dashboard。请用Playwright写个完整的E2E测试，记得加显式等待和页面跳转断言。”
你看，虽然啰嗦了点，但Gemini基本能一次吐出能跑通的代码。这买卖，划算！
以上所有代码和元素名称均为示例，实际使用时请替换为您项目的真实配置。了解您自己系统的技术栈和实现细节，是写出有效提示词的前提。
第二招：把你的“测试思维”塞给它
Gemini不懂什么叫边界值、等价类划分，除非你告诉它。
如果你只让它“生成注册用例”，它大概率给你一套小学生级别的答案。但如果你把你的思考过程“喂”进去，效果立马不一样。
试试这么说：
“除了常规的邮箱格式校验，重点考虑这几个边界：超长邮箱（接近数据库字段上限）、包含特殊字符（比如
+、.）、国际化域名（如café@exämple.com），还有已注册用户重复提交的情况。按优先级排个序。”
这时候，它输出的东西，才真正有点“测试工程师”的味道。甚至还能帮你整理成表格，直接扔进你们的用例管理平台。
小窍门：别指望一口吃成胖子。先让它列个大纲：“注册流程有哪些关键验证点？”，等它给了框架，你再针对每个点深入追问细节。这就叫“引导式共创”。
第三招：让它当你的“代码速读器”
咱们手里谁没几坨祖传的自动化脚本？文档没有，逻辑绕得像迷宫。这时候，Gemini就是个绝佳的“代码翻译官”。
把一段老旧的Selenium脚本（脱敏的代码模式）丢给它，然后问：
“这段代码核心逻辑是啥？有没有明显的坑，比如硬编码的sleep或者脆弱的xpath？”
它常常能一眼指出：“这里用了time.sleep(5)，建议换成WebDriverWait”，或者“这个xpath太依赖层级了，万一UI微调就挂了，可以用data-testid属性重构”。
当然，别全信！但它能帮你快速定位可疑区域，省去你一行行啃代码的痛苦。它的价值，在于把你的注意力从“看懂”解放到“决策”上。
一句忠告：永远做那个“拍板的人”
Gemini最大的陷阱是什么？它回答得太流畅了，让你误以为它全对。
它可能给你一个pytest fixture，但忘了写yield；也可能在API测试用例里，把Content-Type拼错。这些细节错误，足以让你在CI流水线上栽个大跟头。
所以，我的铁律是：把它当“实习生”，给初稿，但最终交付必须经我手进行审查核验。
拿到它的输出后，三步走：
- 快速扫一眼：逻辑对不对路？
- 本地跑一遍：能不能跑通？
- 结合项目改一改：替换掉通用配置，加上你们项目的日志规范。
记住，它不懂你的系统，但你懂。 它负责加速“从0到1”，你负责确保“从1到100”的质量。
建立自己的提示词模板
我电脑里有个 gemini-prompts.md 文件，专门存常用的提问模板。比如：
- 自动化脚本生成模板
- 测试用例扩展模板
- 日志分析模板（“这段错误日志可能是什么原因？”）
- 面试题生成模板（带难度分级）
每次用的时候微调一下，效率高很多。你也可以试试，慢慢积累属于你自己的“AI 协作手册”。
结语：会提问的测试，才是未来的赢家
其实，玩转大模型的核心能力，根本不是什么高深技术，而是你会不会提一个好问题。
而咱们测试工程师，天生就是干这个的！我们最擅长拆解需求、定义边界、追问“如果...会怎样？”。这些能力，恰恰就是写出顶级提示词的秘诀。
Gemini不会取代任何一个优秀的测试工程师。但会用Gemini的测试工程师，一定会把不会用的同行甩开几条街。
希望这些“偷懒”心法，能帮你少走点弯路。共勉！
