去年開始，大模型成了測試圈的新寵。我也跟風試了幾個，最后把 Gemini 留在了日常工具欄里。為啥？因為它真能幫我“偷懶”，而且偷得很有技術(shù)含量。

但坦白講，剛開始用的時候，我差點把它卸載了。問它“寫個自動化腳本”，給我的代碼跑都跑不起來；讓它“生成測試用例”，結(jié)果全是些“輸入正確/錯誤用戶名”的廢話。折騰半天，效率沒提上來，火氣倒是漲了不少。

后來才想明白，不是Gemini不行，是我這個老測試不會“說人話”給它聽。 它是個聰明的助手，但不是我肚子里的蛔蟲。

今天，我就掏心窩子，把這一年多踩過的坑、攢下的“黑話”心得分享出來。不整那些虛頭巴腦的理論，就聊怎么讓Gemini真正成為你的左膀右臂。

第一招：別讓它猜，直接“喂”上下文

很多兄弟一上來就甩一句：“幫我測登錄功能”。Gemini能知道你測的是Web還是App嗎？前端是React還是Vue？后端認證用的是JWT還是Session？八成是瞎蒙。

結(jié)果就是，你拿到一堆需要重寫的廢稿。

我的做法很簡單：一次性把背景交代清楚。 多打幾行字，換來的是省下半小時的返工。

比如，我會這么問：

“我們有個React的Web后臺，登錄頁在/signin。用戶名框ID是email，密碼框是password，登錄按鈕class叫submit-btn。后端用JWT，成功后跳轉(zhuǎn)到/dashboard。請用Playwright寫個完整的E2E測試，記得加顯式等待和頁面跳轉(zhuǎn)斷言?！?/p>

你看，雖然啰嗦了點，但Gemini基本能一次吐出能跑通的代碼。這買賣，劃算！

以上所有代碼和元素名稱均為示例，實際使用時請?zhí)鎿Q為您項目的真實配置。了解您自己系統(tǒng)的技術(shù)棧和實現(xiàn)細節(jié)，是寫出有效提示詞的前提。

第二招：把你的“測試思維”塞給它

Gemini不懂什么叫邊界值、等價類劃分，除非你告訴它。

如果你只讓它“生成注冊用例”，它大概率給你一套小學生級別的答案。但如果你把你的思考過程“喂”進去，效果立馬不一樣。

試試這么說：

“除了常規(guī)的郵箱格式校驗，重點考慮這幾個邊界：超長郵箱（接近數(shù)據(jù)庫字段上限）、包含特殊字符（比如+、.）、國際化域名（如café@ex?mple.com），還有已注冊用戶重復提交的情況。按優(yōu)先級排個序?！?/p>

這時候，它輸出的東西，才真正有點“測試工程師”的味道。甚至還能幫你整理成表格，直接扔進你們的用例管理平臺。

小竅門：別指望一口吃成胖子。先讓它列個大綱：“注冊流程有哪些關(guān)鍵驗證點？”，等它給了框架，你再針對每個點深入追問細節(jié)。這就叫“引導式共創(chuàng)”。

第三招：讓它當你的“代碼速讀器”

咱們手里誰沒幾坨祖?zhèn)鞯淖詣踊_本？文檔沒有，邏輯繞得像迷宮。這時候，Gemini就是個絕佳的“代碼翻譯官”。

把一段老舊的Selenium腳本（脫敏的代碼模式）丟給它，然后問：

“這段代碼核心邏輯是啥？有沒有明顯的坑，比如硬編碼的sleep或者脆弱的xpath？”

它常常能一眼指出：“這里用了time.sleep(5)，建議換成WebDriverWait”，或者“這個xpath太依賴層級了，萬一UI微調(diào)就掛了，可以用data-testid屬性重構(gòu)”。

當然，別全信！但它能幫你快速定位可疑區(qū)域，省去你一行行啃代碼的痛苦。它的價值，在于把你的注意力從“看懂”解放到“決策”上。

一句忠告：永遠做那個“拍板的人”

Gemini最大的陷阱是什么？它回答得太流暢了，讓你誤以為它全對。

它可能給你一個pytest fixture，但忘了寫yield；也可能在API測試用例里，把Content-Type拼錯。這些細節(jié)錯誤，足以讓你在CI流水線上栽個大跟頭。

所以，我的鐵律是：把它當“實習生”，給初稿，但最終交付必須經(jīng)我手進行審查核驗。

拿到它的輸出后，三步走：

• 快速掃一眼：邏輯對不對路？
• 本地跑一遍：能不能跑通？
• 結(jié)合項目改一改：替換掉通用配置，加上你們項目的日志規(guī)范。

記住，它不懂你的系統(tǒng)，但你懂。 它負責加速“從0到1”，你負責確?！皬?到100”的質(zhì)量。

建立自己的提示詞模板

我電腦里有個 gemini-prompts.md 文件，專門存常用的提問模板。比如：

• 自動化腳本生成模板
• 測試用例擴展模板
• 日志分析模板（“這段錯誤日志可能是什么原因？”）
• 面試題生成模板（帶難度分級）
  每次用的時候微調(diào)一下，效率高很多。你也可以試試，慢慢積累屬于你自己的“AI 協(xié)作手冊”。

結(jié)語：會提問的測試，才是未來的贏家

其實，玩轉(zhuǎn)大模型的核心能力，根本不是什么高深技術(shù)，而是你會不會提一個好問題。

而咱們測試工程師，天生就是干這個的！我們最擅長拆解需求、定義邊界、追問“如果...會怎樣？”。這些能力，恰恰就是寫出頂級提示詞的秘訣。

Gemini不會取代任何一個優(yōu)秀的測試工程師。但會用Gemini的測試工程師，一定會把不會用的同行甩開幾條街。

希望這些“偷懶”心法，能幫你少走點彎路。