這篇我按“先跑起來、再講取舍”的方式寫《我用測試經(jīng)驗做了次 AI 項目最先失效的是舊方法》。概念會講但重點放在代碼怎么組織、哪里容易踩坑。摘要摘要從測試崗位切入大模型方向很多人以為會寫Prompt就能上崗但真正讓項目上線翻車的往往是權(quán)限失控、日志缺失這些不起眼的工程細節(jié)。本文基于一次實際接入經(jīng)驗梳理測試工程師轉(zhuǎn)型大模型的能力躍遷路徑重點講清如何在資源有限的小團隊里避開過度設(shè)計的坑守住生產(chǎn)環(huán)境的底線。---目錄測試崗位的新變化為什么舊方法最先失效AI輔助測試工具很火團隊效率卻沒提升自動化用例生成從手寫腳本到模型驅(qū)動Agent測試框架別急著上LangGraph質(zhì)量評估Demo能跑上線怎么才算穩(wěn)總結(jié)測試工程師的差異化優(yōu)勢在哪---目錄測試崗位的新變化AI輔助測試自動化用例生成Agent測試框架質(zhì)量評估總結(jié)測試崗位的新變化我做測試這些年見過太多AI測試的概念被吹上天最后落地時發(fā)現(xiàn)團隊用的還是那套老路子——寫用例、跑腳本、看報告。區(qū)別只是工具換成了AI但問題沒變用例覆蓋了什么失敗怎么兜底線上出了事怎么定位大模型引入之后這些問題的復雜度呈指數(shù)級上升。以前測試一個接口輸入輸出是確定的斷言好寫?，F(xiàn)在測試一個Agent它可能調(diào)用三個工具、經(jīng)過兩輪推理、最后給你一個答案。你該怎么判斷它對不對光靠傳統(tǒng)的準確率、召回率不夠用了還得看它有沒有越權(quán)、有沒有泄露敏感信息、失敗時有沒有兜底邏輯。我參與過一個智能客服項目Demo階段模型回答得挺漂亮上線一周后運維報警有些用戶問價格Agent直接調(diào)用了內(nèi)部結(jié)算接口把成本價返回給了客戶。權(quán)限沒做隔離日志也沒記錄工具調(diào)用鏈排查花了整整兩天。這件事讓我意識到測試工程師轉(zhuǎn)型大模型最大的價值不是會調(diào)Prompt而是能把生產(chǎn)環(huán)境的底線思維帶進去。---AI輔助測試現(xiàn)在市面上AI測試工具很多代碼生成、用例推薦、缺陷預測聽起來都很香。但我觀察到一個現(xiàn)象很多團隊接入之后效率并沒有明顯提升反而Review時間變長了。原因很簡單AI生成的東西你更得仔細審。以前手寫用例邏輯是自己的一眼能看出問題。AI生成的用例你得逐條驗證它有沒有幻覺、有沒有遺漏邊界、有沒有安全風險。我自己的做法是把AI當初級測試員它負責出初稿我負責把關(guān)。但把關(guān)的標準不是對不對而是能不能上線。舉個例子用AI生成一批登錄接口的測試用例它會輸出正常登錄、密碼錯誤、賬號鎖定這些常規(guī)場景。但不會告訴你如果并發(fā)1000次請求模型會不會把敏感信息寫進日志如果傳入特殊字符會不會觸發(fā)注入這些需要你結(jié)合生產(chǎn)環(huán)境的約束去補充。所以AI輔助測試的核心不是替代你而是幫你覆蓋你平時容易忽略的維度。你的價值體現(xiàn)在知道什么能交給AI什么必須自己兜底。---自動化用例生成從手寫腳本到模型驅(qū)動自動化用例生成的思路變了但工程原則沒變。以前寫自動化我習慣用PytestRequests結(jié)構(gòu)清晰斷言明確?，F(xiàn)在用大模型生成用例流程大概是描述場景 → 模型輸出用例 → 腳本執(zhí)行 → 結(jié)果驗證?？雌饋眄槙车虚g有幾個坑。第一個坑是模型輸出的格式不穩(wěn)定。有時候它給你JSON有時候是Markdown表格解析起來很頭疼。我的解法是加一層結(jié)構(gòu)化校驗用Pydantic定義好用例的schema模型輸出不符合就直接拒掉不讓它污染測試數(shù)據(jù)。from pydantic import BaseModel, Field from typing import List, Optional class TestCase(BaseModel): case_id: str Field(..., patternr^CASE_\d{4}$) scenario: str input_data: dict expected_output: dict security_check: Optional[bool] False tool_calls: Optional[List[str]] None class Config: json_schema_extra { example: { case_id: CASE_0001, scenario: 用戶查詢訂單狀態(tài), input_data: {order_id: ORD123456}, expected_output: {status: shipped, tracking: SF123456789}, security_check: True, tool_calls: [get_order_status] } }第二個坑是邊界場景覆蓋不足。模型擅長生成常規(guī)路徑但對異常流、并發(fā)、超時這些場景往往力不從心。我的做法是把這些模型不擅長的維度單獨抽出來用傳統(tǒng)自動化手段補充兩者結(jié)合。---Agent測試框架最近LangGraph這類Agent框架很火很多團隊一上來就想搭一套完整的Agent測試體系。但我建議先冷靜一下小團隊資源有限別急著上復雜框架。我之前也踩過這個坑。項目初期花了兩周搭LangGraph工作流結(jié)果上線前發(fā)現(xiàn)權(quán)限配置沒做好日志鏈路沒打通測試覆蓋反而不如以前手寫腳本來得實在。Agent測試的核心不是框架多先進而是三個問題它調(diào)了哪些工具有沒有越權(quán)失敗時怎么兜底我的建議是先用最簡單的結(jié)構(gòu)驗證這三個問題等跑通之后再考慮框架升級。下面是一個輕量級的Agent測試骨架import asyncio from typing import Dict, Any class AgentTestRunner: def __init__(self, agent, permission_checker, logger): self.agent agent self.permission_checker permission_checker self.logger logger async def run(self, test_case: Dict[str, Any]) - Dict[str, Any]: # 1. 權(quán)限預檢 if not self.permission_checker.check(test_case): return {status: blocked, reason: permission_denied} # 2. 執(zhí)行Agent try: result await self.agent.invoke(test_case[input]) except Exception as e: self.logger.error(fAgent execution failed: {e}) return {status: error, detail: str(e)} # 3. 驗證輸出 validation self._validate(result, test_case[expected]) # 4. 記錄日志 self.logger.info(fCase {test_case[id]}: {validation}) return {status: passed if validation else failed, detail: validation} def _validate(self, actual: Any, expected: Dict) - str: # 簡化版驗證實際項目需要更完善的斷言邏輯 if actual.get(output) expected.get(output): return output_match return output_mismatch這個骨架沒有花哨的框架但把權(quán)限檢查、異常處理、日志記錄都嵌入進去了。跑通之后再考慮要不要引入LangGraph的StateGraph或者DAG編排。---質(zhì)量評估Demo階段的質(zhì)量評估和上線標準是完全不同的兩套邏輯。Demo看的是能不能跑上線看的是穩(wěn)不穩(wěn)定。很多團隊在Demo階段用準確率、BLEU分數(shù)評估模型效果覺得90%準確率就夠了。但上線之后那10%的失敗案例可能包含權(quán)限泄露、敏感信息暴露、工具調(diào)用異常這些致命問題。我的質(zhì)量評估分三層第一層是功能正確性這個和傳統(tǒng)測試一樣用例覆蓋、斷言驗證。第二層是安全風險重點檢查有沒有越權(quán)調(diào)用工具有沒有把用戶數(shù)據(jù)傳給第三方模型失敗時有沒有兜底返回第三層是可觀測性這個最容易被忽視。日志有沒有記錄完整的調(diào)用鏈指標有沒有暴露關(guān)鍵路徑的耗時和錯誤率告警能不能及時觸發(fā)有一個判斷標準如果線上出了事你能不能在10分鐘內(nèi)定位到是哪個環(huán)節(jié)、哪條數(shù)據(jù)、哪個工具調(diào)用導致的。做不到就說明可觀測性沒達標。---總結(jié)測試工程師轉(zhuǎn)型大模型不是去學怎么寫Prompt也不是去追最新的Agent框架。真正的躍遷在于把生產(chǎn)環(huán)境的底線思維帶進去守住權(quán)限、日志、可觀測這三條線。小團隊資源有限不要一上來就搞復雜框架。先用最簡單的結(jié)構(gòu)把核心問題跑通再逐步迭代。Demo能跑只是起點能守住生產(chǎn)環(huán)境才是硬通貨。我的建議是轉(zhuǎn)型初期重點補三個能力權(quán)限隔離的設(shè)計思路、日志鏈路的可觀測性、Agent失敗的兜底策略。這三樣比調(diào)Prompt更能讓團隊信任你也更難被替代。資料展示下面是我整理的AI大模型學習資料和工具包預覽適合收藏后按主題逐步學習。如果你想看完整資料目錄可以在評論區(qū)留言「資料」也歡迎告訴我你更關(guān)注AI大模型里的哪類內(nèi)容。