干測(cè)試這些年我一直覺(jué)得最費(fèi)時(shí)間的事情就是寫(xiě)測(cè)試用例。需求一變幾十條用例就要陪著改線上環(huán)境不一樣邊界條件也得跟著調(diào)手工維護(hù)一條條用例本質(zhì)上是在打地鼠。直到我試了用Coze搭建自動(dòng)生成測(cè)試用例的工作流把一段需求描述丟進(jìn)去幾分鐘就能拿到一版結(jié)構(gòu)完整、覆蓋不錯(cuò)的測(cè)試用例實(shí)測(cè)下來(lái)這個(gè)方案是真的穩(wěn)。先說(shuō)我眼中的Coze是什么。它就是一個(gè)可視化的AI應(yīng)用搭建平臺(tái)國(guó)內(nèi)用起來(lái)很方便你可以在里面組裝一個(gè)工作流把大模型節(jié)點(diǎn)、代碼節(jié)點(diǎn)、條件判斷、知識(shí)庫(kù)、文檔插件像拼積木一樣串起來(lái)。也就是說(shuō)你不光能讓AI幫你寫(xiě)用例還能讓AI幫你把用例整理成固定格式、按字段校驗(yàn)完整性甚至轉(zhuǎn)成Word文檔或者生成自動(dòng)化腳本。這套組合拳打下來(lái)寫(xiě)用例這件事的自動(dòng)化程度比我預(yù)想的高很多。這篇文章就把我的搭建思路、核心細(xì)節(jié)、實(shí)操過(guò)程和踩坑記錄都攤開(kāi)講適合所有被重復(fù)性用例編寫(xiě)折磨的測(cè)試工程師也適合想用Coze做文本生成類工作流、但不知道怎么設(shè)計(jì)流程的人參考。1. 為什么建議用Coze搭測(cè)試用例生成工作流1.1 手動(dòng)寫(xiě)用例的同款痛點(diǎn)先啰嗦幾句痛點(diǎn)。很多人會(huì)說(shuō)寫(xiě)用例難道不是測(cè)試的基本功嗎是基本功沒(méi)錯(cuò)但基本功做久了重復(fù)勞動(dòng)的部分會(huì)讓人非常疲憊。一個(gè)功能模塊正常流程、異常流程、邊界條件、權(quán)限場(chǎng)景、數(shù)據(jù)關(guān)聯(lián)場(chǎng)景這些都是必寫(xiě)的少說(shuō)二三十條多的上百條。我以前寫(xiě)過(guò)一次活動(dòng)頁(yè)面的用例需求文檔只有兩頁(yè)A4紙最后用例寫(xiě)了兩百多條寫(xiě)了整整一個(gè)下午第二天產(chǎn)品經(jīng)理改了需求其中有三分之一直接作廢。這種重復(fù)勞動(dòng)有幾個(gè)典型問(wèn)題。第一是容易漏人不是機(jī)器寫(xiě)到最后幾條時(shí)注意力已經(jīng)下降了最容易漏掉的是那些看起來(lái)不常發(fā)生、但一發(fā)生就是事故的異常分支。第二是不穩(wěn)定不同測(cè)試人員寫(xiě)出來(lái)的用例風(fēng)格差異很大有人喜歡把前置條件和操作步驟寫(xiě)在一起有人喜歡分得很細(xì)評(píng)審的時(shí)候經(jīng)常因?yàn)楦袷匠称饋?lái)。第三是維護(hù)成本高需求一旦變更你得手動(dòng)逐條去過(guò)判斷哪些用例受影響了這個(gè)動(dòng)作非常消耗精力。我嘗試過(guò)用通用的大模型聊天窗口寫(xiě)用例效果是有的但體驗(yàn)很割裂。你得把提示詞復(fù)制來(lái)復(fù)制去生成的格式經(jīng)常變今天用表格明天用列表而且當(dāng)需求比較復(fù)雜的時(shí)候大模型容易寫(xiě)著寫(xiě)著就跑偏。后來(lái)我開(kāi)始研究Coze工作流因?yàn)樗馨炎孉I干活這件事拆成可復(fù)用的流程至少解決了流程化的核心問(wèn)題。1.2 Coze解決了我最頭疼的三個(gè)問(wèn)題用Coze搭完之后我復(fù)盤了一下它實(shí)際上解決了三個(gè)具體問(wèn)題。第一個(gè)是流程固定。工作流不是一錘子買賣的聊天它是把寫(xiě)用例這件事拆成一段可以反復(fù)執(zhí)行的pipeline。我只要把需求文本丟進(jìn)去后面的解析、生成、校驗(yàn)、格式化都是固定流程不會(huì)像聊天一樣每次輸出都不一樣。你甚至可以設(shè)置不同的入口處理功能測(cè)試用例和接口測(cè)試用例走不同的分支流程。第二個(gè)是格式可控。Coze里可以在工作流中加入代碼節(jié)點(diǎn)我能對(duì)LLM的輸出做二次處理比如強(qiáng)制轉(zhuǎn)成JSON、過(guò)濾掉多余的空格、按字段校驗(yàn)完整性再把結(jié)果拼成統(tǒng)一的Markdown模板。這個(gè)能力是最關(guān)鍵的因?yàn)锳I生成內(nèi)容最大的毛病不是寫(xiě)不好而是格式不穩(wěn)定格式一穩(wěn)定后續(xù)交給其他系統(tǒng)處理就很方便。第三個(gè)是生態(tài)銜接好。Coze有插件系統(tǒng)、知識(shí)庫(kù)、文件上傳這些能力。我可以把歷史用例文檔傳到知識(shí)庫(kù)讓AI參考過(guò)往的項(xiàng)目風(fēng)格生成用例也可以通過(guò)工作流的文件上傳能力直接讀取PRD文檔內(nèi)容省去手動(dòng)整理需求的時(shí)間。再加上文檔處理插件生成完的用例還能直接轉(zhuǎn)成Word交付整個(gè)鏈路都不用離開(kāi)平臺(tái)。1.3 工作流的輸入與輸出到底該怎么設(shè)計(jì)搭工作流之前第一件事不是急著去拖節(jié)點(diǎn)而是想清楚輸入和輸出。我見(jiàn)過(guò)很多人搭Coze工作流失敗就是因?yàn)橐婚_(kāi)始沒(méi)定義清楚搭到一半發(fā)現(xiàn)缺這少那。我的輸入設(shè)計(jì)分兩種場(chǎng)景。場(chǎng)景A是功能測(cè)試用例輸入是需求描述文本或者一個(gè)功能點(diǎn)列表。場(chǎng)景B是接口測(cè)試用例輸入是接口文檔的關(guān)鍵信息包括請(qǐng)求方法、URL、請(qǐng)求參數(shù)、必填校驗(yàn)、返回碼等等。這兩種場(chǎng)景對(duì)LLM的要求不一樣功能測(cè)試用例需要理解業(yè)務(wù)流程接口測(cè)試用例需要更結(jié)構(gòu)化的字段化推理所以我在工作流里做了兩個(gè)分支分別用不同的Prompt處理。輸出設(shè)計(jì)上我強(qiáng)制要求輸出JSON結(jié)構(gòu)再通過(guò)代碼節(jié)點(diǎn)轉(zhuǎn)成Markdown表格。字段我固定成以下幾列用例編號(hào)、所屬模塊、用例標(biāo)題、前置條件、測(cè)試步驟、預(yù)期結(jié)果、優(yōu)先級(jí)、設(shè)計(jì)方法。為什么用這八列因?yàn)檫@是我們?cè)趯?shí)際評(píng)審中最常用的維度優(yōu)先級(jí)方便排版本設(shè)計(jì)方法方便做覆蓋率審計(jì)前置條件和預(yù)期結(jié)果則是用例是否可執(zhí)行的關(guān)鍵。這里我做一個(gè)輸入到輸出的對(duì)應(yīng)關(guān)系表看起來(lái)更直觀一些輸入類型處理方式輸出結(jié)果需求描述文本LLM節(jié)點(diǎn)解析業(yè)務(wù)規(guī)則功能測(cè)試用例JSON數(shù)組功能點(diǎn)列表LLM節(jié)點(diǎn)逐項(xiàng)拆解每個(gè)功能點(diǎn)的多條用例接口文檔字段LLM節(jié)點(diǎn)字段級(jí)推理接口測(cè)試用例JSON數(shù)組歷史用例/規(guī)范文檔知識(shí)庫(kù)檢索輔助風(fēng)格統(tǒng)一的用例文案我在這個(gè)設(shè)計(jì)上最大的體會(huì)是,先把輸出結(jié)構(gòu)定下來(lái)再去搭節(jié)點(diǎn)成功率會(huì)高很多。因?yàn)楹竺娴拇a校驗(yàn)、模板拼裝、插件導(dǎo)出全都是圍繞這個(gè)輸出結(jié)構(gòu)來(lái)設(shè)計(jì)的。2. 讓Coze寫(xiě)出高質(zhì)量測(cè)試用例的核心細(xì)節(jié)節(jié)點(diǎn)、Prompt與參數(shù)2.1 節(jié)點(diǎn)選型與編排邏輯為什么這樣設(shè)計(jì)Coze工作流的節(jié)點(diǎn)看著很豐富但真正核心的就那幾個(gè)大模型節(jié)點(diǎn)、代碼節(jié)點(diǎn)、條件判斷節(jié)點(diǎn)、知識(shí)庫(kù)節(jié)點(diǎn)和插件節(jié)點(diǎn)。我在用例生成這個(gè)場(chǎng)景里用得最多的是前三個(gè)。大模型節(jié)點(diǎn)是主角。它的作用是完成需求理解、用例生成這些智力工作。這里要注意一個(gè)節(jié)點(diǎn)干一件事就夠了不要想著一個(gè)節(jié)點(diǎn)把所有活都干了。我早期的失敗經(jīng)驗(yàn)就是一個(gè)LLM節(jié)點(diǎn)既做需求解析又做用例生成還做格式整理結(jié)果輸出經(jīng)常出現(xiàn)你讓我總結(jié)需求又讓我出用例我該以哪個(gè)為主這種混亂。現(xiàn)在我的流程是第一個(gè)LLM節(jié)點(diǎn)只負(fù)責(zé)把用戶輸入的需求文本拆成功能點(diǎn)列表第二個(gè)LLM節(jié)點(diǎn)才負(fù)責(zé)根據(jù)功能點(diǎn)列表生成用例職責(zé)干脆效果也穩(wěn)定。代碼節(jié)點(diǎn)是配角但不可缺。它主要負(fù)責(zé)三件事校驗(yàn)大模型節(jié)點(diǎn)的輸出、處理字符串格式、組裝最終的Markdown。有人會(huì)問(wèn)校驗(yàn)格式為什么要用代碼節(jié)點(diǎn)因?yàn)長(zhǎng)LM的輸出不是百分百可靠偶爾會(huì)多出注釋文字、缺少字段、甚至直接輸出一段無(wú)關(guān)內(nèi)容代碼節(jié)點(diǎn)可以用程序邏輯兜底而不是靠提示詞求著它別出錯(cuò)。條件判斷節(jié)點(diǎn)用來(lái)做分支路由。比如判斷輸入里有沒(méi)有接口文檔字段如果有就走接口用例生成分支如果沒(méi)有就走功能用例分支。這個(gè)在復(fù)雜一點(diǎn)的工作流里很有用。節(jié)點(diǎn)編排的通用邏輯我覺(jué)得可以這樣理解開(kāi)頭節(jié)點(diǎn)收集輸入解析節(jié)點(diǎn)理解需求生成節(jié)點(diǎn)產(chǎn)出內(nèi)容校驗(yàn)節(jié)點(diǎn)確保質(zhì)量導(dǎo)出節(jié)點(diǎn)做結(jié)果落地。清晰的流水線比堆節(jié)點(diǎn)更重要。2.2 測(cè)試用例Prompt模板直接能抄的那種Prompt設(shè)計(jì)是整個(gè)工作流里核心中的核心。我調(diào)試了很多版最后沉淀下來(lái)兩個(gè)最穩(wěn)定的模板這里直接分享出來(lái)。第一個(gè)是功能測(cè)試用例生成模板我通常放在主LLM節(jié)點(diǎn)里你是一位資深測(cè)試工程師擅長(zhǎng)功能測(cè)試用例設(shè)計(jì)。請(qǐng)根據(jù)以下功能點(diǎn)列表為該功能生成完整的測(cè)試用例。要求覆蓋正常流程、異常流程、邊界值、權(quán)限場(chǎng)景、數(shù)據(jù)關(guān)聯(lián)場(chǎng)景。每個(gè)用例必須包含用例編號(hào)、所屬模塊、用例標(biāo)題、前置條件、測(cè)試步驟、預(yù)期結(jié)果、優(yōu)先級(jí)、設(shè)計(jì)方法。設(shè)計(jì)方法必須標(biāo)注采用的是等價(jià)類劃分、邊界值分析、場(chǎng)景法中的哪一種。請(qǐng)嚴(yán)格按照J(rèn)SON數(shù)組格式輸出不要輸出任何解釋性文字和Markdown代碼塊標(biāo)記。配合的輸入格式是{module: 登錄模塊, feature_list: [用戶名密碼登錄, 驗(yàn)證碼登錄, 記住密碼]}第二個(gè)是接口測(cè)試用例生成模板我會(huì)用在工作流的接口分支你是一位接口測(cè)試專家。請(qǐng)根據(jù)以下接口定義設(shè)計(jì)接口測(cè)試用例。重點(diǎn)關(guān)注參數(shù)必填、參數(shù)類型、參數(shù)邊界、業(yè)務(wù)約束、異常返回碼。輸出字段要求用例編號(hào)、接口名稱、請(qǐng)求方法、請(qǐng)求URL、請(qǐng)求參數(shù)、預(yù)期狀態(tài)碼、預(yù)期響應(yīng)內(nèi)容、設(shè)計(jì)方法。請(qǐng)嚴(yán)格按JSON數(shù)組輸出。接口定義的輸入我一般這樣組織{api_name: 創(chuàng)建訂單, method: POST, url: /api/order/create, params: {goods_id: string,必填, num: int,1~99, coupon_id: string,選填}}我為什么會(huì)反復(fù)強(qiáng)調(diào)嚴(yán)格按JSON數(shù)組輸出不要輸出解釋性文字因?yàn)榇竽Ｐ吞焐休敵龅膽T性它總想跟你解釋一句好的下面是生成的用例這多出來(lái)的話會(huì)讓代碼節(jié)點(diǎn)直接解析失敗。我甚至?xí)赑rompt最后加一句如果你理解了我的要求直接開(kāi)始輸出不要做任何額外說(shuō)明。2.3 讓輸出穩(wěn)定可控的三個(gè)小技巧除了Prompt本身還有三個(gè)參數(shù)和設(shè)置層面的小技巧對(duì)穩(wěn)定輸出幫助很大。第一個(gè)是模型選擇。不要無(wú)腦選最強(qiáng)最大的模型要看任務(wù)類型。用例生成這種任務(wù)邏輯推理占比高對(duì)發(fā)散創(chuàng)作要求低我實(shí)測(cè)下來(lái)選豆包或者通義千問(wèn)這類在國(guó)內(nèi)環(huán)境穩(wěn)定的模型配合適合文本生成的版本效果就很好。模型太大會(huì)導(dǎo)致輸出速度慢而且容易自由發(fā)揮過(guò)度生成一些根本不成立的用例步驟。模型太小又會(huì)出現(xiàn)字段遺漏、邏輯跳脫的問(wèn)題。我建議在多模型里各跑一遍同一條用例選那個(gè)在格式和內(nèi)容上最穩(wěn)定的。第二個(gè)是溫度參數(shù)。Coze的大模型節(jié)點(diǎn)里模型參數(shù)通常可以配置。溫度我一般設(shè)置在0.3左右。測(cè)試用例需要的是確定性輸出不是創(chuàng)意寫(xiě)作溫度太高會(huì)導(dǎo)致每次生成的用例內(nèi)容飄忽不定A/B版本完全對(duì)不上溫度太低又會(huì)顯得死板邊界條件的思考容易被壓掉。0.3是我試下來(lái)覆蓋率和穩(wěn)定性比較平衡的點(diǎn)。如果某個(gè)模型默認(rèn)不支持配置溫度那就依賴強(qiáng)約束的Prompt來(lái)兜底。第三個(gè)是二次校驗(yàn)。我在主LLM節(jié)點(diǎn)后面一定會(huì)掛一個(gè)校驗(yàn)LLM節(jié)點(diǎn)或者代碼節(jié)點(diǎn)專門檢查輸出是不是合法的JSON、字段有沒(méi)有少項(xiàng)。代碼節(jié)點(diǎn)做JSON解析解析失敗就把原始文本丟給一個(gè)專門的修復(fù)節(jié)點(diǎn)處理解析成功就繼續(xù)走。這套機(jī)制加上去之后流程成功率從大概80%提到了95%以上體驗(yàn)提升非常明顯。3. 從零到一搭建Coze測(cè)試用例工作流一步一步實(shí)操記錄3.1 前置準(zhǔn)備賬號(hào)、模板和一份真實(shí)需求開(kāi)始動(dòng)手之前需要的準(zhǔn)備工作并不多但每一樣都別省。首先是Coze賬號(hào)。國(guó)內(nèi)環(huán)境直接用扣子平臺(tái)就行注冊(cè)登錄后打開(kāi)工作臺(tái)可以看到項(xiàng)目列表。我個(gè)人習(xí)慣是先在個(gè)人空間里建一個(gè)項(xiàng)目把所有測(cè)試用例相關(guān)的資源放在一起。國(guó)際版的界面和信息架構(gòu)略有不同但國(guó)內(nèi)版對(duì)中文需求的解析更友好推薦先用國(guó)內(nèi)版。其次是準(zhǔn)備一份測(cè)試用例模板。這份模板不是給AI看的是給你自己定義輸出標(biāo)準(zhǔn)用的。我的辦法是把公司之前的優(yōu)秀用例脫敏后整理成幾份代表不同風(fēng)格的文檔后續(xù)上傳到知識(shí)庫(kù)讓AI在生成時(shí)參考句式和顆粒度。沒(méi)有歷史模板也沒(méi)關(guān)系可以先用我上節(jié)給的Prompt字?jǐn)?shù)生成一版再反向調(diào)整格式要求。最后是準(zhǔn)備一份真實(shí)的需求文本作為測(cè)試輸入。第一次搭工作流時(shí)我強(qiáng)烈建議不要直接拿一個(gè)大而全的PRD去測(cè)而是選一個(gè)功能點(diǎn)比較清晰的小模塊比如用戶注冊(cè)分享海報(bào)生成這類。目標(biāo)越小調(diào)試越容易定位問(wèn)題。我自己的第一份測(cè)試輸入選的是驗(yàn)證碼登錄功能一開(kāi)始就控制了變量。3.2 搭主流程需求解析節(jié)點(diǎn)到用例生成節(jié)點(diǎn)現(xiàn)在進(jìn)入實(shí)操。打開(kāi)Coze工作臺(tái)新建一個(gè)工作流命名可以叫測(cè)試用例自動(dòng)生成助手。第一步拖入開(kāi)始節(jié)點(diǎn)。這個(gè)節(jié)點(diǎn)負(fù)責(zé)接收用戶輸入。我設(shè)置了兩個(gè)輸入字段一個(gè)是requirement_text用來(lái)接收需求描述文本另一個(gè)是input_type用來(lái)標(biāo)記輸入類型是功能用例還是接口用例。input_type這個(gè)字段非常重要它是后面條件判斷節(jié)點(diǎn)做分支路由的依據(jù)。第二步拖入第一個(gè)大模型節(jié)點(diǎn)命名為需求解析器。在這個(gè)節(jié)點(diǎn)里我要做的是把用戶輸入的需求文本轉(zhuǎn)成結(jié)構(gòu)化的功能點(diǎn)列表。模型選我剛才說(shuō)過(guò)的通用文本模型溫度設(shè)0.3Prompt用這樣一段你是一個(gè)需求分析助手。請(qǐng)從用戶輸入的需求描述中提取功能點(diǎn)并以JSON數(shù)組輸出。每個(gè)功能點(diǎn)包含function_name功能名稱、description功能描述、rules業(yè)務(wù)規(guī)則列表。如果輸入內(nèi)容不完整請(qǐng)輸出空數(shù)組不要自行編造功能點(diǎn)。這個(gè)節(jié)點(diǎn)就干這么一件事不做別的。很多人會(huì)在這個(gè)節(jié)點(diǎn)忍不住讓AI順便把用例也寫(xiě)了真的是一個(gè)大坑一旦出問(wèn)題你根本分不清是解析問(wèn)題還是生成問(wèn)題排查起來(lái)非常痛苦。第三步拖入條件判斷節(jié)點(diǎn)判斷input_type。這一步的意義在于區(qū)分功能測(cè)試用例和接口測(cè)試用例兩條生成鏈路。功能鏈路走我上面給的功能用例Prompt接口鏈路走接口用例Prompt。兩個(gè)分支各自掛一個(gè)大模型節(jié)點(diǎn)我這里會(huì)分別命名為功能用例生成器和接口用例生成器。3.3 讓代碼節(jié)點(diǎn)做格式校驗(yàn)一次徹底的兜底主流程串起來(lái)之后下一步就是在每個(gè)用例生成節(jié)點(diǎn)后面掛代碼節(jié)點(diǎn)這個(gè)環(huán)節(jié)絕對(duì)不能漏。代碼節(jié)點(diǎn)的作用我前面提過(guò)主要是校驗(yàn)和規(guī)整。我實(shí)際使用的JavaScript邏輯大致如下// 輸入previous_output 是LLM輸出內(nèi)容 async function main({ previous_output }) { let raw previous_output.trim(); // 去掉可能出現(xiàn)的Markdown代碼塊標(biāo)記 raw raw.replace(/json/g, ).replace(//g, ); let arr; try { arr JSON.parse(raw); } catch (e) { return { is_valid: false, error: e.message, raw: previous_output }; } // 校驗(yàn)必備字段 const required [case_id, module, title, precondition, steps, expected, priority, method]; for (let item of arr) { for (let key of required) { if (!(key in item)) { return { is_valid: false, error: missing field: key, raw: previous_output }; } } } return { is_valid: true, cases: arr, count: arr.length }; }這段代碼解決了我三個(gè)實(shí)際問(wèn)題一是去掉LLM畫(huà)蛇添足加的代碼塊標(biāo)記二是把非法JSON攔截在流程中間而不是帶病往下走三是在字段缺失時(shí)報(bào)出具體字段名方便我回查Prompt哪里約束不到位。如果代碼節(jié)點(diǎn)返回的是is_valid: false工作流會(huì)進(jìn)入異常分支。我在異常分支里放了一個(gè)修復(fù)節(jié)點(diǎn)也是一個(gè)LLM節(jié)點(diǎn)它的Prompt是請(qǐng)修復(fù)以下JSON數(shù)據(jù)使其合法并補(bǔ)全缺失字段只輸出修復(fù)后的JSON然后修復(fù)節(jié)點(diǎn)的輸出再送回同一個(gè)代碼節(jié)點(diǎn)做二次校驗(yàn)。這個(gè)暴力重試修復(fù)的機(jī)制雖然看起來(lái)不夠優(yōu)雅但在實(shí)際運(yùn)行中非常管用流程穩(wěn)定率就是這樣一點(diǎn)點(diǎn)拉上來(lái)的。3.4 讓用例更貼合項(xiàng)目風(fēng)格知識(shí)庫(kù)和文件上傳的兩種玩法Coze里對(duì)測(cè)試用例生成最有幫助的兩個(gè)能力我認(rèn)為是知識(shí)庫(kù)和文件上傳。它們的場(chǎng)景完全不同但都能減少人工干預(yù)。知識(shí)庫(kù)的玩法是這樣的。我把歷史項(xiàng)目的用例文檔脫敏后做成一個(gè)知識(shí)庫(kù)文檔格式用Markdown或者Word都行Coze會(huì)自動(dòng)做索引。在工作流里加一個(gè)知識(shí)庫(kù)節(jié)點(diǎn)讓它檢索并返回與當(dāng)前功能點(diǎn)相關(guān)的歷史用例文本片段然后把這個(gè)片段作為上下文拼進(jìn)用例生成器的Prompt里。這樣生成的用例在語(yǔ)言風(fēng)格、顆粒度、步驟描述習(xí)慣上會(huì)和團(tuán)隊(duì)的歷史風(fēng)格高度一致。我甚至試過(guò)把團(tuán)隊(duì)內(nèi)部的用例評(píng)審規(guī)范也傳進(jìn)去Prompt里可以引用規(guī)范來(lái)判斷優(yōu)先級(jí)如何設(shè)置效果很不錯(cuò)。文件上傳的玩法更多用在入口優(yōu)化上。Coze工作流支持文件上傳節(jié)點(diǎn)用戶可以直接上傳需求文檔比如Word版本的產(chǎn)品需求文檔。節(jié)點(diǎn)會(huì)解析出文本內(nèi)容再交給需求解析器處理。這樣測(cè)試人員就不需要手動(dòng)從PRD里復(fù)制需求描述了。這個(gè)能力在對(duì)付大文檔時(shí)很省力尤其當(dāng)一個(gè)需求的描述分散在文檔多個(gè)章節(jié)的時(shí)候直接讓AI讀取全文比人眼去找要快得多。不過(guò)要注意文件上傳對(duì)超大文檔仍有長(zhǎng)度限制我一般建議超過(guò)一萬(wàn)字的文檔先做章節(jié)拆分或者只上傳核心需求描述章節(jié)。3.5 從Markdown到Word測(cè)試用例文檔的導(dǎo)出鏈路測(cè)試用例寫(xiě)出來(lái)不是終點(diǎn)交付才是。我們團(tuán)隊(duì)測(cè)試用例的呈現(xiàn)載體是Word文檔所以工作流的最后一步我做了從Markdown到Word的轉(zhuǎn)換。實(shí)現(xiàn)方式有兩種第一種是直接用Coze的文檔處理插件在插件市場(chǎng)搜文檔轉(zhuǎn)換或者Word生成相關(guān)的插件把前面代碼節(jié)點(diǎn)組裝好的Markdown內(nèi)容作為輸入插件輸出Word文件這個(gè)做法最簡(jiǎn)單但不同的插件對(duì)表格樣式的支持度不太一樣用之前要測(cè)一下生成的Word表格是否完整。第二種是自己在代碼節(jié)點(diǎn)里做。簡(jiǎn)單一點(diǎn)可以生成一個(gè).doc兼容的HTML文件內(nèi)容是標(biāo)準(zhǔn)的HTML表格把文件后綴改成Word可識(shí)別的格式WorkOS上大部分流程都能接受這種方式。Coze代碼節(jié)點(diǎn)里可以用JavaScript拼字符串把用例數(shù)組遍歷成HTML表格行最后組裝成一個(gè)帶table結(jié)構(gòu)的HTML文本。我在這個(gè)環(huán)節(jié)的踩坑經(jīng)驗(yàn)是不要過(guò)度依賴模板文件生成docx。docx本質(zhì)是一個(gè)壓縮包里面是多段XML要在代碼節(jié)點(diǎn)里手工生成docx實(shí)在是太復(fù)雜了而且稍有不慎文件就會(huì)損壞。用插件或者用HTML轉(zhuǎn)Word的方式穩(wěn)定性都要高得多。如果項(xiàng)目對(duì)格式要求極高還可以讓工作流輸出Markdown源碼再自己用本地工具批量轉(zhuǎn)換成Word雖然多了一步但可控性最強(qiáng)。3.6 往自動(dòng)化方向延伸與Playwright測(cè)試腳本的銜接測(cè)試用例生成之后還有一個(gè)讓人很興奮的方向就是把用例直接轉(zhuǎn)成自動(dòng)化測(cè)試腳本。這里我重點(diǎn)說(shuō)下Playwright。Playwright是微軟開(kāi)源的一套自動(dòng)化測(cè)試框架支持Chromium、Firefox、WebKit寫(xiě)腳本用的是JavaScript或Python。它是完全合規(guī)合法的開(kāi)源技術(shù)也是目前業(yè)界做端到端測(cè)試的主流選擇之一。Coze生成測(cè)試用例之后怎么和Playwright銜接呢我的思路不是在Coze里直接跑Playwright而是讓Coze生成可轉(zhuǎn)化成腳本的用例結(jié)構(gòu)。具體做法是在用例生成的Prompt里增加一項(xiàng)要求為每個(gè)用例提供playwright_code字段字段里是這條用例的可操作步驟描述比如點(diǎn)擊登錄按鈕、輸入用戶名、斷言元素可見(jiàn)。這些描述不是直接能運(yùn)行的代碼但它的操作序列已經(jīng)足夠明確。然后我再寫(xiě)一段轉(zhuǎn)換邏輯把用例的步驟描述映射成Playwright的API調(diào)用模板比如page.click(選擇器)、page.fill(選擇器, 值)、expect(page.locator(選擇器)).toBeVisible()。這里我不會(huì)讓AI直接生成完整可跑的腳本因?yàn)椴煌岸隧?xiàng)目的元素定位方式千差萬(wàn)別AI不了解你的頁(yè)面結(jié)構(gòu)生成的代碼大概率不能直接跑。更合理的做法是讓AI產(chǎn)出可理解的步驟和定位建議再由測(cè)試開(kāi)發(fā)人員或代碼生成工具去做最終映射。這個(gè)思路可以避免大量無(wú)效調(diào)試工作。我自己試過(guò)一次讓AI直接生成Playwright代碼結(jié)果因?yàn)樵囟ㄎ蝗渴_本基本沒(méi)法用后來(lái)改成先生成步驟描述再人工映射效率反而高了很多。4. 實(shí)測(cè)中踩過(guò)的坑Coze生成測(cè)試用例常見(jiàn)問(wèn)題與排查4.1 輸出格式飄忽不定最讓人頭疼如果你只用Coze做過(guò)簡(jiǎn)單對(duì)話可能體會(huì)不到格式問(wèn)題有多惡心。當(dāng)工作流里的下游節(jié)點(diǎn)依賴上游輸出的時(shí)候格式飄忽不定就是最大的流程殺手。我最早跑通流程的時(shí)候第一次生成出來(lái)的是JSON第二次竟然在JSON外面套了json代碼塊標(biāo)記第三次直接輸出了Markdown表格代碼節(jié)點(diǎn)解析直接崩掉。針對(duì)這個(gè)問(wèn)題的排查方法我的經(jīng)驗(yàn)有幾條。第一條是在Prompt里把輸出格式寫(xiě)成負(fù)面清單加正面示例的方式正面示例就是完整的一個(gè)JSON數(shù)組樣例負(fù)面清單就寫(xiě)不要輸出代碼塊標(biāo)記、不要輸出解釋文字、不要輸出Markdown標(biāo)題。負(fù)面約束對(duì)LLM的規(guī)范效果非常好。第二條是代碼節(jié)點(diǎn)做兼容處理就是我前面那段代碼先用正則把代碼塊標(biāo)記剝掉再解析。第三條是異常分支做修復(fù)重試讓修復(fù)節(jié)點(diǎn)把非JSON內(nèi)容改造成JSON再回來(lái)過(guò)一遍校驗(yàn)。4.2 用例覆蓋不足漏掉關(guān)鍵分支怎么辦AI寫(xiě)用例的另一個(gè)常見(jiàn)問(wèn)題是漏。它的漏和人一樣容易漏掉異常條件、權(quán)限場(chǎng)景、數(shù)據(jù)之間的相互影響這些冷門分支。針對(duì)覆蓋率問(wèn)題我的方法論是分層設(shè)防。第一層防在Prompt里面我要求用例設(shè)計(jì)必須顯式標(biāo)注設(shè)計(jì)方法比如等價(jià)類劃分、邊界值分析、場(chǎng)景法并且要求每個(gè)功能點(diǎn)至少覆蓋一條正常流、一條異常流、一條邊界值。這個(gè)要求看起來(lái)簡(jiǎn)單但對(duì)大模型有很明顯的強(qiáng)制定心丸作用它為了不丟面子會(huì)刻意補(bǔ)齊這幾類用例。第二層防在代碼節(jié)點(diǎn)里統(tǒng)計(jì)每一組用例中設(shè)計(jì)方法字段里是否包含邊界值和異常這兩個(gè)關(guān)鍵詞如果沒(méi)有就返回警告提醒我人工復(fù)核這個(gè)模塊。第三層靠人工評(píng)審兜底AI生成用例我從來(lái)不會(huì)直接提交一定會(huì)安排至少一輪快速評(píng)審重點(diǎn)就是看有沒(méi)有明顯漏掉的業(yè)務(wù)規(guī)則。4.3 長(zhǎng)文本截?cái)嗪妥侄蝸G失這個(gè)坑最隱蔽Coze大模型節(jié)點(diǎn)都有最大輸出token限制模型越便宜限制越嚴(yán)格。我遇到過(guò)最尷尬的情況是上下文很長(zhǎng)的時(shí)候輸出到一半戛然而止用例數(shù)組的最后幾條被切斷整個(gè)JSON變成非法格式。不仔細(xì)看根本看不出是截?cái)嗔艘驗(yàn)镴SON沒(méi)閉合報(bào)錯(cuò)也報(bào)得很隱晦。這個(gè)問(wèn)題的根治思路是分片。與其讓AI一次生成很多用例不如把功能點(diǎn)列表拆開(kāi)一個(gè)功能點(diǎn)或者兩個(gè)功能點(diǎn)一組分多次生成最后再把用例數(shù)組合并起來(lái)。合并這個(gè)工作也在代碼節(jié)點(diǎn)里做把多次生成的JSON數(shù)組合并成一個(gè)大的數(shù)組。分片雖然會(huì)增加調(diào)用次數(shù)但穩(wěn)定性提升立竿見(jiàn)影。另外一個(gè)問(wèn)題是上下文過(guò)長(zhǎng)導(dǎo)致模型遺忘某些字段這時(shí)需要精簡(jiǎn)Prompt。我把Prompt里的解釋性文字全部刪掉只留精確要求和示例實(shí)測(cè)字段丟失率下降很多。4.4 其他高頻問(wèn)題和處理辦法速查再列一個(gè)速查表把我在使用中遇到過(guò)的問(wèn)題、現(xiàn)象和解決辦法都整理在一起方便你對(duì)照排查問(wèn)題現(xiàn)象可能原因我的解決辦法輸出不是JSONPrompt約束不足增加正面示例和負(fù)面清單加修復(fù)節(jié)點(diǎn)JSON解析通過(guò)但字段少LLM遺漏字段代碼節(jié)點(diǎn)做字段校驗(yàn)缺字段走重新生成分支用例內(nèi)容雷同溫度參數(shù)太高或Prompt缺乏約束溫度降到0.3要求按設(shè)計(jì)方法分類生成用例步驟不夠具體功能點(diǎn)拆解太粗先解析生成更細(xì)的功能點(diǎn)列表再生成用例生成的用例脫離需求上下文被其他內(nèi)容干擾精簡(jiǎn)Prompt只保留必要的示例和輸入長(zhǎng)文檔上傳后處理失敗超出模型上下文限制上傳前做章節(jié)拆分或只上傳核心章節(jié)Word轉(zhuǎn)換后表格錯(cuò)亂插件對(duì)Markdown表格支持不完整改用HTML模板生成或用本地腳本批量轉(zhuǎn)換這個(gè)速查表基本覆蓋了我三個(gè)月中遇到的高頻問(wèn)題如果你后面踩到新坑大概率也能在里面找到類似的處理思路。5. 跑了三個(gè)月我用真實(shí)數(shù)據(jù)算了一筆賬5.1 時(shí)間成本對(duì)比從人工半天到工作流十分鐘先算最實(shí)在的時(shí)間賬。以一個(gè)中等復(fù)雜度的功能模塊為例包含十個(gè)功能點(diǎn)每個(gè)功能點(diǎn)平均需要十二條用例。在沒(méi)有使用Coze之前我手動(dòng)編寫(xiě)這大約一百二十條用例快的下午也要三四個(gè)小時(shí)而且中間要不停翻需求文檔、對(duì)照邊界值、思考命名規(guī)范。如果需求描述再模糊一點(diǎn)一整天耗在上面也不意外。用了Coze工作流之后我的操作流程變成把需求描述復(fù)制進(jìn)工作流設(shè)定模塊名和功能點(diǎn)點(diǎn)擊運(yùn)行整個(gè)流程大概需要兩到五分鐘。跑完之后我花十五到二十分鐘做一件事——人工評(píng)審。重點(diǎn)看漏掉的業(yè)務(wù)規(guī)則、異常的優(yōu)先級(jí)是否合理、步驟描述是否夠清晰?？傮w時(shí)間從三個(gè)小時(shí)縮短到了半小時(shí)以內(nèi)而且消耗的主要是評(píng)審時(shí)間不是編寫(xiě)時(shí)間。我自己的直觀感受是工作流替代的是機(jī)械書(shū)寫(xiě)的部分保留的是測(cè)試設(shè)計(jì)判斷的部分。5.2 覆蓋率和可維護(hù)性評(píng)估時(shí)間是看得見(jiàn)的收益另一個(gè)維度是質(zhì)量。我對(duì)照了同樣一個(gè)功能模塊的人工用例和Coze用例人工用例是兩百二十條Coze生成的是兩百四十六條。我第一反應(yīng)是AI比我還能寫(xiě)但仔細(xì)評(píng)審后發(fā)現(xiàn)AI多的那些用例里有一部分是窮舉參數(shù)組合產(chǎn)生的偽增量可用性不強(qiáng)。不過(guò)它在邊界值和異常場(chǎng)景上的覆蓋率確實(shí)比我習(xí)慣的那個(gè)版本要高尤其是權(quán)限場(chǎng)景、空值場(chǎng)景、超長(zhǎng)值場(chǎng)景幾乎都沒(méi)漏。所以我的結(jié)論是Coze不是用來(lái)替代測(cè)試人員思考的它是用來(lái)補(bǔ)齊人工盲區(qū)的。它最大的價(jià)值在于當(dāng)你已經(jīng)想清楚了這個(gè)功能應(yīng)該覆蓋哪些類型之后它可以快速幫你把每個(gè)類型下的具體用例鋪滿而鋪滿這個(gè)動(dòng)作在人工執(zhí)行時(shí)最容易偷懶或遺漏?？删S護(hù)性方面因?yàn)楣ぷ髁鬏敵龅氖墙Y(jié)構(gòu)化的JSON后續(xù)如果用例格式需要調(diào)整我只需要改Prompt和代碼節(jié)點(diǎn)的模板重新跑一遍工作流幾秒鐘就能全量更新。這比我以前手動(dòng)改幾十條用例要舒服太多了。5.3 最后再分享幾點(diǎn)我的實(shí)際體會(huì)這幾個(gè)月用下來(lái)我對(duì)Coze自動(dòng)生成測(cè)試用例這件事的認(rèn)知也在變化。最初我以為它是一個(gè)偷懶工具后來(lái)發(fā)現(xiàn)它更像一個(gè)提效底座。它不是讓你變成一個(gè)不寫(xiě)用例的人而是讓你把寫(xiě)用例的時(shí)間挪去做更值得做的事比如測(cè)試策略設(shè)計(jì)、自動(dòng)化腳本維護(hù)、現(xiàn)場(chǎng)問(wèn)題復(fù)盤。如果讓我給準(zhǔn)備入手的同學(xué)提三條建議這可能是最核心的實(shí)踐沉淀第一不要追求一個(gè)工作流解決所有用例類型。功能用例、接口用例、性能用例的邏輯差異很大各自獨(dú)立的工作流或者分支會(huì)更容易維護(hù)。第二把格式校驗(yàn)做扎實(shí)比把Prompt寫(xiě)漂亮更重要。穩(wěn)定的結(jié)構(gòu)是工作流能被信任的基礎(chǔ)。第三留一條人工評(píng)審的底線。AI生成用例之后責(zé)任還在測(cè)試工程師身上評(píng)審不過(guò)關(guān)的用例堅(jiān)決不能直接進(jìn)項(xiàng)目文檔。我在實(shí)際項(xiàng)目里已經(jīng)把這套工作流用到了三個(gè)模塊上穩(wěn)定運(yùn)行的體驗(yàn)給了我一個(gè)明確的方向以后新功能進(jìn)來(lái)先跑一版AI用例再人工評(píng)審打磨測(cè)試設(shè)計(jì)的效率確實(shí)可以再上一個(gè)臺(tái)階。這就是我最真實(shí)的感受希望這篇記錄能讓你少走一些彎路。