北京
轉載來源 | 快手技術
概 況
在《采納率從 7.9% 到 54%：快手智能 Code Review 的三階進化》中，快手研發效能團隊重點分享了智能代碼審查系統如何通過質量過濾與知識沉淀，將 AI 能力嵌入研發交付鏈路，使其從個人輔助工具升級為團隊級的協作生產力。但要真正實現從“個人提效”到“組織效能”的閉環，僅優化代碼合并前的質量關口仍然不夠，AI 能力還需要進一步向研發流程的前后環節延展。
在全面推進「AI 研發范式升級」的進程中，如何將個人 AI 工具的零散提效沉淀為組織級的交付能力，是當前效能升級的核心命題。在需求評審之后、測試執行之前，用例設計這一關鍵環節，正是影響交付質量與效率的另一瓶頸。圍繞這一問題，我們構建了智能用例生成系統，實現從手動編寫到審核校驗的模式轉變，這種轉變不僅釋放了測試人員的構思壓力，更讓 AI 升級為流程中穩定、可信的生產力環節。
以往寫用例全靠人工硬磨，效率低且難保全。為此，快手研發效能團隊復盤了智能用例生成系統的演進路徑，總結了快手智能用例生成系統從「Prompt 工程探索」到「Multi-Agent 人機協作」，再到「知識增強策略」，最終走向「自檢測 & 自進化」的四階架構演進。
針對生成質量不穩、業務理解淺、維護成本高這三大難題，我們通過「人機協作」兜底質量、「知識工程」對齊業務場景、「自檢測 & 自進化」降低人工維護負擔。這套思路直接將用例生成率從 8% 拉升至 60%+，累計生成測試用例逾 120 萬條；該系統已經成為全公司測試人員日常使用的標準化生產力工具，真正跑通了從個人 AI 提效到組織交付效能提升的閉環路徑。
背 景
在快手持續推進研發效能提升的過程中，我們對測試階段各環節的耗時進行了深入分析，測試用例設計階段（即測試用例編寫階段）在整個測試周期中占據了 13.69% 的時間成本，與用例執行、回歸測試并列為耗時最高的三大環節；這一數據揭示了傳統測試模式下的瓶頸：測試人員將大量精力投入在重復性的用例撰寫工作中，而非聚焦于更具價值的測試策略設計和缺陷挖掘。
在用例設計提效方面，快手此前主要通過 KCase 平臺的用例編寫在線化能力進行優化。該方案實現了用例模板的規范化與標準化、多人協作編輯與版本管理、用例資產的結構化沉淀。
然而，這種模式本質上仍依賴人工逐條編寫，效率提升存在明顯天花板。面對快手業務的高速迭代和海量的功能需求，測試團隊面臨以下挑戰：
2023 年以來，以 GPT 系列為代表的大語言模型（LLM）在代碼理解、邏輯推理和文本生成方面實現了質的飛躍。快手質量工程團隊敏銳捕捉到這一技術拐點，從 2024 年正式開始啟動 AI 生成手工測試用例的探索項目，目標是將「人工編寫」升級為「AI 生成 + 人工審核」的全新模式，釋放測試人員的生產力。
效 果
快手智能用例生成系統從 V1.0 到 V4.0 的演進歷程，涵蓋從初期的 Prompt 工程探索（生成率 8%），到 Multi-Agent 人機協作模式（生成率 12%），再到知識增強策略（生成率 35%），最終通過自檢測與自進化實現突破性提升（生成率超 60%）。目前，該系統已在快手實現公司級 60% 以上的用例生成率，累計生成測試用例逾 120 萬條。
從 8% 到 60%+ 的生成率躍升，體現了快手技術理念的持續演進：
V1.0：驗證了“AI 能夠生成測試用例”的可行性
V2.0：確立了“人機協作生成優于純自動化生成”的實踐路徑
V3.0：揭示了“知識比算法更關鍵”的本質規律
V4.0：實現了“AI 自我進化”的能力突破
我們不再糾結于 AI 是否能夠替代人類，而是為“AI 如何賦能人類更高效工作”尋求解法。
實踐 1：從 V1.0 到 V4.0 的技術架構演進實踐
3.1 V1.0 版本：Prompt 工程探索階段
3.1.1 初版設計思路
核心假設：大模型已具備足夠的“測試常識”，只需通過精心設計的 Prompt 引導，即可生成高質量測試用例。
技術方案：V1.0 單體生成流程
3.1.2 核心技術實現
技術架構
Prompt 結構設計
初版 Prompt 架構
存在的問題
第一輪優化：Few-shot Learning
問題分析：生成的用例質量仍參差不齊，主要原因是模型對“高質量用例”的標準理解不足。
解決方案：引入來自業務真實場景的高質量測試用例作為樣本，提升模型輸出的一致性和專業性。
Few-shot Prompt 架構：
關鍵發現：
提供 3 個樣例為性價比最優選擇（邊際收益趨于平緩）
樣例質量遠重于數量（1 個高質量樣例 > 5 個低質量樣例）
實際生成效果對比：
第二輪優化：場景化 Prompt 模板
問題分析：不同類型的需求文檔（如 PRD、技術方案 等）需要匹配差異化的測試策略，通用 Prompt 難以覆蓋多樣化測試目標與表達要求。
解決方案：構建多場景路由機制，依據輸入文檔的類型自動匹配最優的 Prompt 模板，實現精準化、專業化測試用例生成。
3.1.3 效果測評
為了驗證 Prompt 優化策略的有效性，我們針對多個關鍵動作開展了系統性測評。測評基于真實業務場景中的 PRD 和技術方案文檔，采用統一測試集進行對比評估。
測評一：Few-shot Learning 效果驗證
測試場景： 基于 PRD 生成功能測試用例（禮物貼紙玩法模塊）
對比組：
對照組： 無 Few-shot 的初始版本 Prompt
實驗組：引入 3 個高質量樣例的 Few-shot Prompt
測評結果：
關鍵發現：
測評二：場景化 Prompt 模板效果驗證
測試場景： 基于不同類型文檔生成測試用例
對比組：
對照組：通用 Prompt（不區分文檔類型）
實驗組： 場景化 Prompt（根據文檔類型自動匹配專用模板）
場景 1：PRD 功能用例生成
典型改進案例：
場景 2：技術方案用例生成
典型改進案例：
3.1.4 核心問題
盡管經過多輪優化，V1.0 仍面臨三大難以突破的瓶頸：
問題 1：長文檔理解能力不足
問題 2：缺乏業務背景知識
問題 3：生成過程“黑盒”
3.1.5 階段總結
結論：需要從系統架構層面重新設計解決方案
3.2 V2.0 版本：Multi-Agent 協作與人機交互階段
3.2.1 設計理念轉變
QA 編寫測試用例的真實思維過程并非“一步到位”，而是分階段逐步推進的，具體如下：
QA 會先“拆解測試點（模塊）”再“細化為具體用例”
每個階段都存在 Review 環節，便于及時糾偏
若前期階段出現偏差，后續將越走越偏
基于此，我們對于 V2.0 采用了新的設計思路，即模擬人類思維方式，引入 Multi-Agent 協作機制，并在關鍵節點支持人工介入。
3.2.2 Multi-Agent 架構設計
業務流程
技術架構
3.2.3 核心 Agent
文檔解析 Agent
這一 Agent 的職責是，對多種格式的輸入文檔進行標準化處理，提取其中的有效信息。
文檔解析流程：
實際案例：
效果示例：
模塊生成 Agent
這一 Agent 的職責是從清洗后的文檔中提取測試點，生成結構化的測試模塊樹。
用例生成 Agent
這一 Agent 的職責是，基于用戶確認的測試模塊，生成詳細的測試用例。
3.2.4 效果測評
為驗證 Multi-Agent 架構與人機協作機制的有效性，我們針對 V2.0 版本的關鍵動作開展了基于真實業務場景的系統性測評，從多個維度對比 V1.0 與 V2.0 的表現差異。
測評指標說明
測評一：文檔解析 Agent 效果驗證
測試場景： 處理不同長度和復雜度的 PRD 文檔
對比組：
對照組：V1.0 直接輸入完整文檔
實驗組：V2.0 經文檔解析 Agent 預處理后輸入
測評結果：
關鍵發現：
測評二：模塊生成 Agent 效果驗證
測試場景： 基于預處理后的文檔生成測試模塊樹
測評結果：
關鍵發現：
測評三：人機協作機制效果驗證
測試場景： 對比 V1.0（黑盒模式）與 V2.0（分階段 Review）的用戶體驗與效率
測評結果：
關鍵發現：
3.2.5 階段總結
3.3 V3.0 版本：知識工程階段
3.3.1 設計動機
我們發現，V2.0 遺留著一個核心問題，即生成的用例缺乏“業務深度”。
基于此，我們調整了 V3.0 的設計目標，即構建體系化的知識引入機制，使 AI 具備“懂業務”的能力。
3.3.2 架構設計
技術架構
知識引入的四個維度
3.3.3 RAG 檢索增強生成
RAG 整體架構
召回結果的價值：
提供了詳細的步驟參考（如“URL 參數攜帶 need_amount”）
補充了業務規則（如“充值后自動返回”）
最重要：帶入了歷史缺陷經驗（并發重復扣款、支付超時重復訂單）
基于 RAG 增強的用例生成
3.3.4 效果測評
為驗證體系化知識引入機制的有效性，我們針對 V3.0 的關鍵功能進行了基于真實業務場景的系統性測評，從多個維度對比 V2.0 與 V3.0 的表現差異。
測評指標說明
測評一：RAG 檢索增強生成效果驗證
測試場景： 基于 PRD 生成測試用例，對比有無 RAG 增強的效果
對比組：
對照組：V2.0 僅基于 PRD + Few-shot 樣例生成用例
實驗組：V3.0 基于 PRD + RAG 檢索的歷史用例和業務知識生成用例
測評結果：
關鍵發現：
測評二：知識引入綜合效果驗證
測試場景： 對比 V2.0 和 V3.0 在整體用例生成質量上的差異
測評結果：
典型改進案例：【直播禮物需求】
3.3.5 階段總結
3.4 V4.0 版本：自主性 & 自進化階段
3.4.1 技術架構
3.4.2 核心突破一：自主評審，Review-Critique 生成模式
設計動機
傳統的 AI 生成采用“單次直出”模式，類似于只會答題而不會檢查的學生。為提升生成質量，需賦予 AI “自我反思”能力，構建“生成 - 評審 - 優化”的自主評審閉環機制。
關鍵設計理念：
Critic（判別）：AI 扮演“評審員”角色，對生成結果進行系統性審查并給出專業指導建議
Generator（生成）：根據評審意見自動調整與優化輸出內容
離線異步：因多輪迭代耗時較長，采用后臺處理結合通知機制，保障效率與響應性
完整技術流程
整體架構
階段一：模塊級評審 ->優化閉環（結構治理）
自主評審 Agent —— 模塊審查維度詳解：
輸出示例（未通過）：
階段二：用例級評審 ->優化閉環（細節打磨）
自主評審 Agent
用例審查策略：全局 Review + 逐條細節檢查
用例審查維度：
輸出示例（未通過）：
質量指標與效果
對比傳統模式的提升：
3.4.3 核心突破二：基于測試計劃的自進化場景規則模板
問題背景：知識維護的困境
在 V3.0 階段，為了讓 AI 理解業務，需人工編寫大量團隊業務模板（業務已維護 170+ 套業務定制的團隊模板），但該模式存在三大痛點：
維護成本高：每個新業務場景均需人工梳理規則
知識更新慢：歷史缺陷經驗無法及時同步至模板
專家依賴強：需資深 QA 才能總結高質量模板
因此，我們的核心設計理念是讓系統從歷史數據中自動學習，實現隱性知識顯性化。
技術方案：雙層模板體系
我們構建了兩種層級的自進化模板：
單一場景知識：精準規則提取
定位：針對特定微場景（如“直播間送禮”、“評論輸入框”）的精確規則
作用：作為 RAG 鏈路中的上下文參考；自動補齊測試點，降低遺漏率
場景模版生成流程
RAG 召回流程
通用場景模板：聚類與抽象
定位：多個相似場景聚合而成的通用規范（如“消費端評論發布通用模板”）
作用：支持手動召回的 RAG 鏈路；作為明確的生成規則，提升精度
生成策略：
AI 聚合核心邏輯：
提取共性：保留出現在兩個及以上場景中的規則
去除個性：過濾僅屬于特定需求的特殊邏輯
保留具體細節：避免籠統表述如“參考歷史模板”，必須明確列出具體的驗證點
核心價值與成效
降低知識維護成本
提升生成質量
3.4.4 階段總結
實踐 2: 四層架構驅動的方法論實踐
圖片
AI 測試用例生成系統的成功，往往依賴于一套分層遞進的架構體系。基于此，我們在實踐中提煉出“四層架構”模型：場景分層 → 用戶運營 → 知識運營 → Agentic 架構，自上而下指導決策方向，自下向上提供能力支撐。
4.1 四層架構全景
4.2 場景分層 —— 選對戰場
我們的核心原則是不追求“全覆蓋”，而是基于價值 x 復雜度矩陣進行精準突破。
4.3 用戶運營 —— Badcase 驅動閉環
Badcase 是最好的老師，通過系統化收集與分析用戶反饋，驅動持續迭代優化。
Badcase 分類與解決路徑
閉環運營流程
關鍵指標演進：
4.4 四層協同：從 Badcase 到系統進化
我們以一個 Badcase 如何驅動四層協同進化來示例。
【觸發】用戶反饋：直播送禮場景缺少“并發送禮”測試點
【第一層 - 場景分層】
判定：直播送禮屬于“高價值”場景，值得深入優化
【第二層 - 用戶運營】
Badcase 分類：覆蓋類問題
根因分析：知識庫缺少并發場景的歷史缺陷數據
【第三層 - 知識運營】
補充缺陷庫：新增“并發送禮重復扣款”歷史 Bug 記錄
更新規則庫：提取“支付場景必須驗證并發”規則
自動更新模板：直播送禮模板中新增并發測試點
【第四層 - Agentic 架構】
RAG 檢索：后續生成自動召回并發相關知識
Critique Agent：自動檢查是否覆蓋并發場景
【結果】同類 Badcase 不再出現，場景覆蓋率提升至 92%
4.5 方法論總結
核心啟示：
自頂向下做決策：通過場景分層明確資源投入方向，確保戰略聚焦
自底向上建能力：以 Agentic 架構支撐知識運營，推動能力持續沉淀與復用
Badcase 是進化燃料：每個問題都是優化契機，形成“反饋→改進→提升”的持續進化飛輪
展 望
經過從 V1.0 到 V4.0 的持續演進，快手智能測試用例生成系統已完成了從「實驗性工具」到「標準化生產力工具」的跨越。
然而，我們也認識到，測試效率提升空間遠不止于「生成」環節，測試人員仍需投入大量時間在手工用例執行上，這是下一階段的核心突破方向。未來，我們將核心突破聚焦于「AI 智能執行用例」場景，構建從用例生成到用例執行的全鏈路智能化能力。
具體包含如下三個方向：
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
