簡(jiǎn)介面向通訊行業(yè)測(cè)試開發(fā)人員的一份AI提效方案設(shè)計(jì)PDF源自中興通訊一線測(cè)試域AI應(yīng)用負(fù)責(zé)人的實(shí)踐總結(jié)。文檔針對(duì)FTTR組網(wǎng)轉(zhuǎn)型帶來的測(cè)試復(fù)雜度上升、用例冗余和自動(dòng)化腳本交付效率低等問題系統(tǒng)介紹了基于大模型的端到端提效方案對(duì)比提示工程、RAG與精調(diào)選型后確定RAG為最優(yōu)路徑。內(nèi)容覆蓋AI輔助測(cè)試設(shè)計(jì)、腳本開發(fā)、執(zhí)行分析等環(huán)節(jié)包含GWT生成測(cè)試點(diǎn)、復(fù)用用例檢索、DSL設(shè)計(jì)及RF關(guān)鍵字腳本生成等具體技術(shù)實(shí)踐并詳述知識(shí)獲取、建模、評(píng)估與應(yīng)用的知識(shí)工程閉環(huán)支撐AI能力持續(xù)改進(jìn)。資源包共1個(gè)PDF文件大小6.37MB已有105人學(xué)習(xí)。適合具備軟件測(cè)試基礎(chǔ)、關(guān)注通信行業(yè)測(cè)試效率提升的研發(fā)人員與技術(shù)管理者可直接獲取完整技術(shù)方案與落地經(jīng)驗(yàn)用于優(yōu)化自身測(cè)試開發(fā)流程并為后續(xù)探索自生成、自校驗(yàn)、自修復(fù)等全流程自動(dòng)化打下基礎(chǔ)。1. 為什么通訊行業(yè)的端到端測(cè)試卡在“從需求到腳本”這一段通訊行業(yè)的端到端測(cè)試通常要覆蓋核心網(wǎng)、接入網(wǎng)、業(yè)務(wù)平臺(tái)和終端側(cè)的完整信令鏈路。做過的人都知道測(cè)試用例設(shè)計(jì)還能靠經(jīng)驗(yàn)堆真正吃時(shí)間的是“拿到需求文檔之后到第一條自動(dòng)化腳本跑通”這段路解析需求、梳理接口、設(shè)計(jì)場(chǎng)景、拼報(bào)文、寫斷言、調(diào)時(shí)序每一步都在消耗測(cè)試開發(fā)工程師的工時(shí)。AI測(cè)試開發(fā)想真正提效切入點(diǎn)不是把已有腳本跑得更快而是把“需求到腳本”這段人力密集的轉(zhuǎn)換過程自動(dòng)化。這篇筆記要講的就是一套基于AI的端到端測(cè)試開發(fā)提效方案從需求解析、場(chǎng)景生成到自動(dòng)化腳本生成與自愈的完整鏈路以及通訊行業(yè)落地時(shí)躲不開的參數(shù)選擇和踩坑點(diǎn)。2. 把“需求到腳本”拆成四段流水線需求解析、場(chǎng)景生成、腳本生成、腳本自愈2.1 需求解析用LLM把自然語言需求變成結(jié)構(gòu)化測(cè)試意圖需求文檔在通訊行業(yè)通常是Word、PDF或企業(yè)知識(shí)庫頁面內(nèi)容包含業(yè)務(wù)描述、信令流程、接口定義、字段約束。常見做法是先抽文本再交給LLM做信息抽取。這里的關(guān)鍵是不要直接讓LLM“寫測(cè)試用例”而是先讓它輸出一個(gè)結(jié)構(gòu)化的測(cè)試意圖test intent前置條件、操作步驟、預(yù)期結(jié)果、關(guān)聯(lián)接口、重要程度。你可以用JSON Schema約束輸出例如{ intent_id: INT-0001, source: 5G語音業(yè)務(wù)需求v2.3.docx, preconditions: [UE_A_REGISTERED, UE_B_REGISTERED, IMS_SESSION_ESTABLISHED], steps: [ { action: SEND_INVITE, target: SBC, params: { caller: 139XXXX0001, callee: 139XXXX0002, media_profile: AMR-WB } } ], expected: [ SBC返回183響應(yīng)且攜帶SDP, UE_B收到RING事件 ], related_interfaces: [UE-SBC, SBC-CSCF], priority: P1 }這個(gè)JSON的價(jià)值在于每一段后續(xù)流程都可以獨(dú)立校驗(yàn)前置條件是否可建立、步驟能否映射到已有工具函數(shù)、預(yù)期結(jié)果是否可斷言。解析階段要設(shè)置“抽取置信度”低于0.7的字段必須標(biāo)記為待人工確認(rèn)。我一般把temperature設(shè)為0讓LLM只做抽取不做發(fā)揮同時(shí)用prompt里的few-shot示例固定輸出格式。注意不要在這個(gè)階段讓模型補(bǔ)充“你認(rèn)為應(yīng)該有的步驟”那會(huì)污染后續(xù)場(chǎng)景生成。2.2 場(chǎng)景生成從接口契約和歷史流量里補(bǔ)全邊界與異常需求解析只解決了“用戶說了什么”還要解決“用戶沒說但系統(tǒng)會(huì)遇到什么”。通訊系統(tǒng)最怕的是異常場(chǎng)景對(duì)端無響應(yīng)、超時(shí)重發(fā)、消息亂序、編解碼錯(cuò)誤、網(wǎng)絡(luò)閃斷。讓AI生成這些場(chǎng)景需要喂給它接口契約OpenAPI、proto或ASN.1和歷史抓包。常見做法是把正常流程的報(bào)文作為種子讓LLM按故障模型超時(shí)、丟包、重復(fù)、篡改、亂序、超大字段生成變體。這里的關(guān)鍵是每生成一個(gè)場(chǎng)景都要能回溯到“它是在哪個(gè)正常消息上做的哪種變異”否則測(cè)試結(jié)果無法分析。跑過一百個(gè)需求后你會(huì)發(fā)現(xiàn)LLM生成的邊界場(chǎng)景里有價(jià)值的新場(chǎng)景占20%不到大部分是排列組合出來的重復(fù)項(xiàng)。解決方法是維護(hù)一個(gè)“場(chǎng)景指紋庫”用接口名消息類型變異操作做哈希生成時(shí)先查重。另外一個(gè)實(shí)用技巧是讓AI同時(shí)輸出“為什么這個(gè)場(chǎng)景可能觸發(fā)缺陷”這個(gè)理由會(huì)幫助測(cè)試工程師決定是否保留。對(duì)于通訊行業(yè)我建議把變異源限定在“會(huì)話建立、會(huì)話保持、會(huì)話釋放”三個(gè)主流程上因?yàn)榻^大多數(shù)現(xiàn)網(wǎng)故障都發(fā)生在這三段。2.3 腳本生成從意圖到可執(zhí)行的自動(dòng)化腳本拿到結(jié)構(gòu)化意圖后下一步是翻譯成自動(dòng)化測(cè)試腳本。通訊行業(yè)常用的自動(dòng)化框架有Robot Framework、pytest、以及廠商自研的TAP。我的選擇是pytest requests aioquic如果是傳統(tǒng)信令協(xié)議就加上scapy。腳本生成策略不是讓LLM直接輸出整個(gè)文件而是先輸出“調(diào)用序列”再按序列填充每個(gè)操作的具體參數(shù)。這一步的提示詞里必須寫清楚三件事框架內(nèi)已有的工具函數(shù)清單、斷言風(fēng)格規(guī)范、以及禁止使用的API。比如你期望生成的是def test_call_flow(env, user_a, user_b): # 前置注冊(cè) env.ue.register(user_a) env.ue.register(user_b) # 主流程INVITE invite env.sbc.send_invite( calleruser_a, calleeuser_b, media_profileAMR-WB ) assert invite.sip_status 183, fexpect 183, got {invite.sip_status} # 等待被叫響鈴 ring env.ue.wait_ringing(user_b, timeout10) assert ring, UE-B should ring but did not注意斷言風(fēng)格不要只做“接口返回200”的弱斷言要斷到業(yè)務(wù)結(jié)果UE是否響鈴。這個(gè)要靠提示詞約束要求每個(gè)用例至少有一個(gè)業(yè)務(wù)級(jí)斷言。此外要把超時(shí)參數(shù)暴露成環(huán)境變量或配置項(xiàng)而不是寫死在代碼里。AI生成腳本后我會(huì)先用ruff做靜態(tài)檢查再用pytest --collect-only確認(rèn)函數(shù)能被正確收集兩關(guān)都過才進(jìn)入下一環(huán)節(jié)。2.4 腳本自愈讓AI處理元素漂移和斷言失效端到端測(cè)試跑了一段時(shí)間后最煩人的就是“昨天還好好的今天掛了”。一部分是真實(shí)缺陷一部分是環(huán)境變化、頁面元素變化或時(shí)序抖動(dòng)。腳本自愈的思路是當(dāng)腳本執(zhí)行失敗時(shí)把失敗日志、截圖、響應(yīng)報(bào)文喂給一個(gè)專門的自愈Agent讓它分析失敗類別。如果判斷是元素定位失效則讓它嘗試用新的XPath或CSS定位器替換并重新執(zhí)行如果判斷是時(shí)序波動(dòng)則調(diào)整等待策略如果判斷是斷言過強(qiáng)則不自動(dòng)修改而是標(biāo)記為“需人工判斷”。自愈功能必須設(shè)防呆同一腳本連續(xù)失敗兩次就停止自愈轉(zhuǎn)入人工處理。否則AI會(huì)陷入“改一次跑一次越改越偏”的死循環(huán)把環(huán)境偶發(fā)問題當(dāng)成腳本問題處理反而引入更多噪聲。我建議自愈Agent每次修改后都生成一個(gè)diff摘要存到測(cè)試資產(chǎn)庫這樣你隨時(shí)能追溯AI到底改了什么。這個(gè)功能用下來真正能自動(dòng)修復(fù)成功的比例大約在40%左右但剩下60%的“成功闖入人工”會(huì)節(jié)省大量排查時(shí)間。3. 最小可復(fù)現(xiàn)方案用LLM API Python模板引擎跑通一條端到端鏈路3.1 設(shè)計(jì)一個(gè)“需求→腳本”的中間表示不要直接讓LLM從需求文本生成pytest文件否則很難控制質(zhì)量和可調(diào)試性。我建議中間加一層DSL——一個(gè)比JSON稍微寬松的“測(cè)試動(dòng)作序列”中間表示。用YAML描述因?yàn)閅AML能寫注釋便于人工審閱。示例testcase: name: 5G語音主叫流程 preconditions: - UE_A_ATTACH - UE_B_ATTACH actions: - step: SEND_INVITE from: UE_A to: SBC params: caller: $ENV.CALLER callee: $ENV.CALLEE media_profile: AMR-WB expect: - status_code: [183] timeout: 5 - step: WAIT_RING target: UE_B expect: - event: RING timeout: 10這個(gè)YAML是LLM和代碼生成之間的“黑匣子”接口。好處有三點(diǎn)第一人審YAML比審代碼快十分鐘能掃完二十條用例的動(dòng)作序列第二同一份YAML可以同時(shí)生成pytest和Robot腳本只要寫兩套模板第三YAML本身是需求基線需求變更時(shí)用git diff就能看出哪些步驟變了進(jìn)而定位需要重跑的用例。這個(gè)中間表示是整套方案里最值得先寫死的部分它的字段規(guī)范一旦定下來后續(xù)所有AI交互都圍繞它展開。3.2 腳本生成代碼示例與參數(shù)說明下面是我常用的一段生成代碼基于OpenAI兼容接口通過環(huán)境變量配置base_url和api_key方便對(duì)接企業(yè)內(nèi)網(wǎng)部署的LLM網(wǎng)關(guān)。核心邏輯是讀取YAML中間表示組裝生成提示詞調(diào)用LLM生成pytest代碼。import os import json import yaml from openai import OpenAI client OpenAI( api_keyos.environ.get(LLM_API_KEY), base_urlos.environ.get(LLM_BASE_URL, https://api.openai.com/v1) ) def generate_test_script(yaml_path: str) - str: with open(yaml_path, r, encodingutf-8) as f: test_spec yaml.safe_load(f) prompt build_prompt(test_spec) resp client.chat.completions.create( modelos.environ.get(LLM_MODEL, gpt-4o), messages[ {role: system, content: 你是通訊行業(yè)測(cè)試開發(fā)專家。}, {role: user, content: prompt} ], temperature0.2, max_tokens4096, response_format{type: json_object} ) result json.loads(resp.choices[0].message.content) return result[python_code] def build_prompt(spec: dict) - str: return f 根據(jù)以下測(cè)試規(guī)格生成一個(gè)pytest測(cè)試函數(shù)。 要求 1. 使用框架封裝好的 SIPClient / UE 類不要自己構(gòu)造底層socket。 2. 斷言必須包含業(yè)務(wù)級(jí)驗(yàn)證不能只驗(yàn)證狀態(tài)碼。 3. 禁止使用 time.sleep改用 wait_until。 4. 輸出JSON格式{{python_code: ...}} 測(cè)試規(guī)格 {json.dumps(spec, ensure_asciiFalse, indent2)} 參數(shù)說明temperature0.2是平衡穩(wěn)定性和少量靈活性——腳本生成要求確定性高太高容易產(chǎn)生隨機(jī)錯(cuò)誤max_tokens4096是為了防止長(zhǎng)腳本被截?cái)嗳绻麥y(cè)試步驟超過十五步我會(huì)把 max_tokens 提到 8192response_format強(qiáng)制 JSON 輸出但如果你的模型網(wǎng)關(guān)不支持這個(gè)參數(shù)就拆掉它改用正則從返回內(nèi)容里提取 python 代碼塊。另外base_url一定要支持切換通訊企業(yè)往往在自己的 AI 中臺(tái)上部署私有模型這里用環(huán)境變量可以避免寫死地址。3.3 生成腳本的質(zhì)量校驗(yàn)與人工確認(rèn)生成出來的腳本不能直接進(jìn)CI。第一步是靜態(tài)檢查用ruff check做語法和風(fēng)格檢查用pytest --collect-only確認(rèn)能被收集第二步是“需求追溯校驗(yàn)”把生成的腳本逆解析回動(dòng)作序列和原始YAML比對(duì)。這個(gè)逆向翻譯我會(huì)再調(diào)用一次LLM讓它“把pytest代碼轉(zhuǎn)回YAML”然后對(duì)比兩者的動(dòng)作數(shù)、接口名、斷言數(shù)量是否一致。如果逆向和正向不一致說明生成走了樣直接打回。人工確認(rèn)環(huán)節(jié)只需要看兩樣?xùn)|西動(dòng)作序列是否符合預(yù)期、斷言強(qiáng)度是否足夠。如果每條生成腳本都要人工逐行讀代碼那提效就失敗了。所以中間表示YAML存在的意義是把“審代碼”變成“審表格”。我這里還有一個(gè)習(xí)慣把人工確認(rèn)后的YAML打上“已審核”標(biāo)簽下次需求變更時(shí)只對(duì)比新舊YAML差異而不是重新審查整條代碼。這套流程跑下來單條用例的人工介入時(shí)間從原來的二十分鐘壓縮到兩分鐘。4. 通訊行業(yè)特有的五個(gè)調(diào)整點(diǎn)協(xié)議、時(shí)序、專網(wǎng)、合規(guī)、數(shù)據(jù)4.1 協(xié)議棧與編解碼不要讓AI自己猜報(bào)文通訊行業(yè)的端到端測(cè)試涉及SIP、Diameter、HTTP/2、MQTT、私有協(xié)議。AI模型對(duì)公共協(xié)議的理解不錯(cuò)但對(duì)私有編解碼一無所知。常見做法是所有報(bào)文編解碼函數(shù)都封裝在測(cè)試框架的工具庫里提示詞里只允許AI調(diào)用這些函數(shù)禁止自己構(gòu)造字節(jié)流。如果一定要讓AI生成報(bào)文則應(yīng)提供ASN.1或TLV模板讓它填字段而不是憑空創(chuàng)造。給提示詞里加一條硬規(guī)則“不得直接構(gòu)造字節(jié)流必須先調(diào)用 encode_XXX 方法。”這能避免大量字節(jié)錯(cuò)位問題。真實(shí)案例中AI曾把Diameter的AVP長(zhǎng)度字段計(jì)算錯(cuò)誤導(dǎo)致對(duì)端直接拒收消息。這類問題在腳本審查階段很難肉眼發(fā)現(xiàn)必須從源頭掐斷。我一般會(huì)把工具庫的函數(shù)列表直接塞進(jìn)系統(tǒng)提示詞并標(biāo)注每個(gè)函數(shù)的參數(shù)和返回類型AI能正確調(diào)用的概率會(huì)大幅提升。4.2 時(shí)序與異步把等待策略寫進(jìn)提示詞通信系統(tǒng)異步消息多很多測(cè)試腳本掛在“等待響應(yīng)”上。AI默認(rèn)生成time.sleep(3)這是最粗糙的做法。要在提示詞里明確所有等待必須調(diào)用wait_until(predicate, timeout)并給出超時(shí)閾值偏好比如默認(rèn)5秒信令流程最長(zhǎng)15秒。同時(shí)告訴AI不要在注冊(cè)流程里用“軟等待”替代“注冊(cè)成功確認(rèn)”否則后續(xù)流程全亂。這里有一個(gè)參數(shù)值得專門調(diào)超時(shí)閾值。不同網(wǎng)元差異很大。核心網(wǎng)網(wǎng)元響應(yīng)快計(jì)費(fèi)系統(tǒng)可能要等SSR回執(zhí)所以我會(huì)在YAML里給每個(gè)步驟配一個(gè)timeout字段生成時(shí)把它傳給wait_until。AI需要學(xué)會(huì)讀這個(gè)配置而不是自己拍腦袋。另外凡是消息重傳的場(chǎng)景要在提示詞里說明“最多重試三次、每次退避指數(shù)增長(zhǎng)”否則AI會(huì)把重傳邏輯寫成死循環(huán)。時(shí)序問題在通訊測(cè)試?yán)锸切W(xué)重災(zāi)區(qū)AI生成的腳本尤其容易在這里翻車。4.3 專網(wǎng)與版本碎片化模型需要看到“設(shè)備畫像”通訊廠商的產(chǎn)品線版本非常多同一流程在V1.2和V2.0上的交互過程可能不同。通用AI模型不知道你們專網(wǎng)的版本差異。所以方案里要為被測(cè)環(huán)境建一個(gè)“設(shè)備畫像”文件包含網(wǎng)元型號(hào)、版本、協(xié)議能力、已知缺陷列表。生成腳本時(shí)把這個(gè)畫像作為context塞進(jìn)提示詞AI才會(huì)寫出匹配版本的預(yù)期。例如某個(gè)舊版本SBC不支持SIP INFO方法AI如果不知道就會(huì)生成一個(gè)實(shí)際跑不通的流程。設(shè)備畫像的維護(hù)本身也可以交給AI變更單來了自動(dòng)對(duì)比新舊版本差異更新畫像文件。這相當(dāng)于讓AI維護(hù)它自己的“記憶力”是非常符合ai native研發(fā)范式的一步。注意設(shè)備畫像文件要按網(wǎng)元拆分不要放在一個(gè)大文件里否則提示詞太長(zhǎng)模型會(huì)丟失注意力。我通常給每個(gè)網(wǎng)元一個(gè)Markdown文件控制在五十行以內(nèi)只寫關(guān)鍵差異不寫手冊(cè)。4.4 合規(guī)與安全生成代碼必須先過靜態(tài)檢查通訊行業(yè)對(duì)測(cè)試代碼沒有太多合規(guī)要求但一旦AI生成代碼要進(jìn)生產(chǎn)CI或接入現(xiàn)網(wǎng)數(shù)據(jù)就必須做安全門禁。AI生成代碼常見的風(fēng)險(xiǎn)硬編碼口令、使用不安全的加密庫、把敏感數(shù)據(jù)打進(jìn)日志。我們會(huì)在生成后自動(dòng)跑一遍自定義規(guī)則和semgrep掃描。比如禁止出現(xiàn)用于連接現(xiàn)網(wǎng)的賬密、禁止把用戶號(hào)碼打印到測(cè)試報(bào)告里、禁止調(diào)用未脫敏的配置文件讀取接口。如果你用多AI協(xié)作的方式讓一個(gè)Agent專門生成測(cè)試數(shù)據(jù)另一個(gè)生成腳本那么還需控制Agent之間的上下文權(quán)限。不要讓數(shù)據(jù)生成Agent直接讀生產(chǎn)庫給它的應(yīng)該是脫敏的schema和字段約束。這個(gè)安全邊界要在系統(tǒng)設(shè)計(jì)階段就定好不要指望提示詞能約束住所有越權(quán)操作。我見過一個(gè)團(tuán)隊(duì)因?yàn)锳gent擅自調(diào)用了生產(chǎn)環(huán)境查詢接口差點(diǎn)把在線用戶的簽約數(shù)據(jù)卷入測(cè)試流量后來他們加了網(wǎng)關(guān)級(jí)權(quán)限校驗(yàn)才算攔住。4.5 測(cè)試數(shù)據(jù)用合成數(shù)據(jù)而不是生產(chǎn)數(shù)據(jù)端到端測(cè)試離不開真實(shí)號(hào)碼段、IMSI、SIP URI。生產(chǎn)數(shù)據(jù)涉及用戶隱私且環(huán)境里的數(shù)據(jù)狀態(tài)會(huì)隨線上變化不適合作為測(cè)試基線。我建議用合成數(shù)據(jù)生成器先定義號(hào)碼段規(guī)則、簽約模板、業(yè)務(wù)參數(shù)范圍然后讓AI按規(guī)則生成符合協(xié)議的測(cè)試數(shù)據(jù)。這里AI不是“創(chuàng)造”數(shù)據(jù)而是按你給的規(guī)則填充。例如“號(hào)碼段取139XXXX0001-1000APN為CMNETIMEI符合Luhn校驗(yàn)”。合成數(shù)據(jù)的最大坑是“生成得太假”——所有數(shù)據(jù)分布均勻沒有邊界值和壓力值。所以生成器里要摻入前綴碰撞、重復(fù)IMSI、超大字段值這類臟數(shù)據(jù)用它們專門做魯棒性測(cè)試。AI擅長(zhǎng)按模板批量生成但臟數(shù)據(jù)規(guī)則需要人來設(shè)置不要指望它自己悟出來。我一般會(huì)在YAML數(shù)據(jù)模板里加一個(gè)data_strategy字段可選值為normal、boundary、stress這樣每條測(cè)試數(shù)據(jù)都能說清楚它屬于哪類策略排查問題時(shí)一目了然。5. 避坑指南AI生成測(cè)試腳本的6個(gè)常見翻車現(xiàn)場(chǎng)5.1 現(xiàn)象AI生成的腳本“看起來對(duì)跑起來廢”第一輪跑AI生成腳本時(shí)經(jīng)常遇到語法沒問題、函數(shù)也都存在但就是跑不通的情況。原因往往是AI對(duì)被測(cè)系統(tǒng)的隱含狀態(tài)理解錯(cuò)誤例如它假設(shè)用戶已注冊(cè)但實(shí)際上注冊(cè)流程在另一個(gè)夾具里沒觸發(fā)導(dǎo)致調(diào)用SIP方法時(shí)直接報(bào)“用戶未注冊(cè)”。解決生成提示詞里強(qiáng)制要求“必須注明每個(gè)前置條件的建立方式”并且生成的腳本必須包含前置條件的setup代碼或引用已有夾具。如果AI不寫setup就判為不合格。我在模板引擎里加了一個(gè)校驗(yàn)器掃描生成的代碼里是否有env.ue.register這類前置調(diào)用沒有的話直接打回重生成。5.2 現(xiàn)象提示詞越加越長(zhǎng)效果反而變差很多人在提示詞里堆了三百行說明結(jié)果AI開始“取巧”——總是生成和示例一模一樣的模板喪失了對(duì)具體需求的適配能力。這是因?yàn)槟Ｐ妥⒁饬Ρ贿^多示例分散了。解決把提示詞分層。第一層是系統(tǒng)提示固定為業(yè)務(wù)規(guī)則第二層是用戶提示放入具體需求和環(huán)境信息第三層是少量示例每個(gè)示例對(duì)應(yīng)一種典型場(chǎng)景。示例不要超過5個(gè)并且要刻意覆蓋“正常、邊界、異?！比悺Ｈ绻龅教貏e復(fù)雜的協(xié)議不要試圖用提示詞講完所有細(xì)節(jié)而是把細(xì)節(jié)放進(jìn)一個(gè)參考文檔里讓AI“先讀取文檔再作答”。5.3 現(xiàn)象模型幻覺出根本不存在的接口字段有一次生成IMS注冊(cè)測(cè)試腳本AI調(diào)用了不存在的SIP頭字段P-Served-User還給它賦了一個(gè)不存在的值。這類問題的根源是模型訓(xùn)練數(shù)據(jù)里的“通用電信知識(shí)”和你們?cè)O(shè)備的實(shí)際實(shí)現(xiàn)不一致。解決給AI一個(gè)“接口字典”文件列出所有可用方法和字段名并在提示詞里聲明“只能使用字典里的接口”。同時(shí)生成后做一個(gè)字段校驗(yàn)用靜態(tài)腳本把生成的代碼里所有方法名、字段名和字典做匹配命不中的直接標(biāo)紅。相信我這一步必不可少能攔下80%的幻覺字段。接口字典需要隨版本更新建議放在版本控制里和代碼一起評(píng)審。5.4 現(xiàn)象多AI協(xié)作時(shí)一個(gè)Agent改壞了另一個(gè)的狀態(tài)我試過用兩個(gè)Agent一個(gè)負(fù)責(zé)生成測(cè)試步驟一個(gè)負(fù)責(zé)生成測(cè)試數(shù)據(jù)。數(shù)據(jù)Agent會(huì)自作聰明地修改“全局用戶狀態(tài)表”導(dǎo)致步驟Agent拿到的用戶狀態(tài)和預(yù)期不符。解決Agent之間不能直接共享可變狀態(tài)必須通過中間文件或消息隊(duì)列傳遞不可變數(shù)據(jù)結(jié)構(gòu)。更簡(jiǎn)單的方法是每個(gè)Agent只做“讀入輸入產(chǎn)出輸出”不做任何更新操作。狀態(tài)變更統(tǒng)一由主控流程處理。這個(gè)模式和函數(shù)式編程的思路很像雖然犧牲了一點(diǎn)“多AI協(xié)作”的靈活性但換來的是可調(diào)試性和確定性。在通訊行業(yè)里確定性比靈活性重要得多。5.5 現(xiàn)象生成速度很快但維護(hù)成本被轉(zhuǎn)移到“提示詞”上AI生成腳本后需求一變你不需要改代碼了但要改提示詞。這看起來進(jìn)步了實(shí)際上如果每個(gè)需求都改提示詞維護(hù)成本并沒有消失。解決把“業(yè)務(wù)規(guī)則”和“場(chǎng)景描述”分離。業(yè)務(wù)規(guī)則信令流程、協(xié)議約束放到系統(tǒng)提示詞里長(zhǎng)期不變場(chǎng)景描述本次要測(cè)什么放到用戶提示詞里按需求變化。這樣改動(dòng)點(diǎn)是壓縮的。另外每次提示詞變更都應(yīng)當(dāng)有版本記錄我用git管理prompt文件CI里跑一次回歸確保沒打破舊腳本。如果你的團(tuán)隊(duì)還沒有專門維護(hù)提示詞的倉庫建議盡快建一個(gè)否則半年后你會(huì)對(duì)著無人理解的舊提示詞發(fā)呆。5.6 現(xiàn)象測(cè)試報(bào)告里AI寫的斷言全是弱斷言AI傾向于生成“響應(yīng)碼200”“消息已發(fā)送”這類弱斷言因?yàn)樽钊菀淄ㄟ^。端到端測(cè)試的價(jià)值恰恰在于業(yè)務(wù)鏈路驗(yàn)證。解決在規(guī)則里定義“弱斷言清單”生成后自動(dòng)掃描檢查每條用例是否有至少一個(gè)業(yè)務(wù)斷言。例如業(yè)務(wù)斷言可以是“收到SDP且包含正確的媒體IP”“主被叫都進(jìn)入通話態(tài)”。沒有業(yè)務(wù)斷言的用例直接打回重生成。自動(dòng)掃描的實(shí)現(xiàn)很簡(jiǎn)單用正則匹配斷言語句剔除只包含status、return、success的斷言統(tǒng)計(jì)剩余斷言數(shù)。這個(gè)閾值根據(jù)用例復(fù)雜度調(diào)整但至少保證有一條真·業(yè)務(wù)斷言。6. 從試點(diǎn)到落地我建議這樣定邊界、做評(píng)估、逐步推廣6.1 先用“30個(gè)歷史需求”做基線回歸測(cè)試選這個(gè)方案時(shí)不要上來就拿新需求試點(diǎn)。更好的做法是選過去已完成的30個(gè)歷史需求這些需求有真實(shí)代碼和真實(shí)結(jié)果。讓AI重新生成一遍腳本和原腳本做對(duì)拍。對(duì)拍時(shí)看三點(diǎn)動(dòng)作序列是否覆蓋原腳本關(guān)鍵步驟、斷言強(qiáng)度是否不弱于原腳本、執(zhí)行通過率是否達(dá)到原腳本水平。30個(gè)需求足夠暴露80%的生成模式問題也足夠你估算出真實(shí)的提效倍率。我當(dāng)時(shí)跑完這30個(gè)需求發(fā)現(xiàn)AI在“需求理解”上的成功率只有七成但在“模板化腳本生成”上幾乎能到九成這直接決定了后續(xù)落地形態(tài)。6.2 評(píng)估指標(biāo)不要只看生成成功率生成成功率AI生成的腳本能直接運(yùn)行的占比是基礎(chǔ)指標(biāo)但不是核心指標(biāo)。核心指標(biāo)是“腳本交付后一周內(nèi)的人工修訂次數(shù)”和“腳本上線后因腳本錯(cuò)誤導(dǎo)致的誤報(bào)率”。我見過團(tuán)隊(duì)把生成成功率從60%優(yōu)化到90%但修訂成本仍然很高因?yàn)锳I把相同的錯(cuò)誤模式復(fù)制到了每個(gè)腳本里。所以要統(tǒng)計(jì)“缺陷模式重復(fù)率”同一個(gè)原因比如總是用錯(cuò)等待函數(shù)導(dǎo)致的失敗出現(xiàn)多少次。這個(gè)指標(biāo)才是AI提效的真相。建議用表格記錄每一條失敗的原因分類每周回顧一次把頻次最高的三類原因?qū)懟靥崾驹~規(guī)則里。6.3 讓AI生成“測(cè)試設(shè)計(jì)”而不是“測(cè)試代碼”的混合模式到最后你會(huì)發(fā)現(xiàn)完全由AI生成腳本在通訊行業(yè)里很難保證質(zhì)量。我目前的落地形態(tài)是“AI生成測(cè)試設(shè)計(jì)人工寫關(guān)鍵腳本”即AI負(fù)責(zé)輸出動(dòng)作序列、預(yù)期結(jié)果、測(cè)試數(shù)據(jù)、邊界場(chǎng)景表測(cè)試工程師只需把設(shè)計(jì)表格里高風(fēng)險(xiǎn)的20%動(dòng)作手動(dòng)寫腳本剩下的交給模板生成。這個(gè)混合模式的好處是人工介入減少而安全邊界清晰。AI在“設(shè)計(jì)”上比“寫代碼”更擅長(zhǎng)也更少產(chǎn)生幻覺。如果你預(yù)算有限優(yōu)先做需求解析和場(chǎng)景生成這兩段它們帶來的提效比是最高的。最后分享一個(gè)習(xí)慣每次跑完AI生成的腳本我會(huì)把失敗日志和最終修訂結(jié)果回喂給LLM讓它生成一份“修訂原因摘要”并存入測(cè)試資產(chǎn)庫。下次生成同類腳本時(shí)這些摘要會(huì)被自動(dòng)附加到提示詞里。這個(gè)做法讓AI的生成質(zhì)量隨著項(xiàng)目進(jìn)行緩慢上升而不是停留在同一個(gè)水平。這套方案和這些坑希望能在你落地AI測(cè)試開發(fā)時(shí)少走幾次彎路希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取