2025全球軟件質量&效能大會·深圳站基于需求上下文知識增強的LLM輔助測試設計實踐李賀松|華為云TSELeader、測試技術專家全球軟件質量&效能大會華為測試技術專家全球軟件質量&效能大會01研發團隊的心聲02實踐Al輔助測試設計面臨的挑戰我們的探索和實踐實踐對研發流程的改變全球軟件質量&效能大會測試：需求總是簡單幾句話、規格也不清晰。我的時間都浪費在與產品和開發溝通和扯皮上，關鍵時刻還找不到人。每次現網出問題，所有的人都問我測試為什么沒攔截到，我又變成背鍋俠!開發：產品的需求寫的不清不楚的，還經常改來改去。本來是架構該做的需求設計要讓我來做，我還得做自測試，這不是測試該做的嗎?留給我安靜寫代碼的時間都不到一半。架構：那么大一個產品，就我一個架構師，每個月那么多需求要設計、功能、性能、安全、可靠性、體驗都要考慮，我還要不要活了產品：幾百上千條需求等著我分析、我白天還要見客戶，這么簡單的需求，架構、開發、測試還讓我補這個補那個的，我要對產品競爭力和商業成功負責，我哪有那么多時間處理這么多細節的東西反串講，線下溝通和澄清)占測試設計時間占比超過35%以上；全球軟件質量&效能大會對于熟悉業務的研發人員(理解上下文)看來是顯而易見的需求，對于新員工和大模型確是巨大挑戰!基于以上原因，完全基于需求信息的AI輔助測試設計，平均采納率一直在40%左右。如何獲取高質量的上下文，成為AI輔助測試設計的關鍵突破路徑。全球軟件質量&效能大會關于需求上下文增強的路徑選擇思考2)消耗資源多2、直接將領域知識做成知識圖譜進行檢索?1)需投入領域專家定義本體模型(實體類型、關系約束)3)圖數據庫的成本較高3、直接將領域知識進行切片，以RAG的形式進行上下文知識檢索?2.資源變更管理3.實例配置管理4.資源釋放管理5.訂單變更管理用例用例1用例2缺陷缺陷1缺陷…需求需求1特性21、通過特性關聯的基線用例反向提取特性的功能點和功能模型2、需求與特性功能點的上下文關系分析4.扣減用戶賬號余額(包年包月)數據流：用戶請求→訂單系統→資源管理系V2或V3系統發送不同的請求(V2是創建委托、V3是創建委托系統增加新字段保存請求結果：APICTMRESOURCETENANT的F1、為什么不是需求?通過需求與特性的上下文關聯分析，顯著提升了大模型獲取需求上下文知識的效率和質量，測試點的平均采納率提升到70%以上特性1用例1缺陷缺陷1需求1需求…特性2需求②需求與特性上下文關聯分析1、實例訂購管理_函數服務不存在時創建實例_實例創建成2、實例訂購管理_函數服務存在時創建實例_實例創建成3、資源變更管理_函數服務不存在時執行變更操作_變更操作成5、實例配置管理_函數服務不存在時配置API返回錯誤信息且6、實例配置管理_函數服務存在時配置API配置操作成功且狀態記錄正確9、函數服務存在性檢查_網絡類型不為V2_返回常規處理結果10、實例創建流程_資源租戶為V2且函數服務不存在_實例創11、實例創建流程_資源租戶為V3且函13、API配置流程_網絡類型為V2且函數服務存在_配置操作成14、資源變更流程_資源租戶為V2且函數服務不存在_變更操作成功且記錄狀態15、資源變更流程_資源租戶為V3且函數服務不存在_變更操作成功且記錄狀態實踐過程遇到的關鍵問題：1、同一份用例，每次提取的功能點和功能模型個數和顆粒度可能不一致，功能模型也可能存在結構差異2、同一個需求和相同的上下文信息，提取的測試點個數和顆粒度可能不一致3、不同服務，功能點和功能模型的原子粒度定義和邊界不同，同一模型不能精準適配2、同一個需求連續多次生成測試點，然后去重取并集。關鍵術語標準化定義領域知識RAG產品手冊/案例經驗總結歸因分析提取方法特性概述：…輸入：交互規則：-狀態機：…->…>…數據流：….-….>..測試點1、測試點2、..測試點n從特性基線用例中提取測試點的TOPN相關用例測試點n+TOPN相關用例測試點n的測試用例[用例標題]API導入與管理_導入Swagger文件_函數服務存在時導入成功[用例詳細]前置步驟1.用戶登錄PaaS平臺2.創建一個函數服務，命名為test-func3.準備一個包含API定義的Swagger文件，命名為test-api.yaml測試步驟步驟1:上傳Swagger文件輸入：選擇文件test-api.yaml,點擊上傳按鈕預期結果1:文件上傳成功，顯示上傳完成提示步驟2:檢查導入狀態輸入：進入API導入頁面，查看導入狀態預期結果2:顯示導入成功，狀態為"成功",無錯誤提示步驟3:驗證API信息輸入：進入API列表頁面，查看導入的API預期結果3:顯示導入的API信息，包括路徑、方法、請求參數等，與Swagger文件定義一致后置步驟1.刪除創建的函數服務test-func2.刪除上傳的Swagger文件test-api.yaml1.本測試用例適用于驗證Swagger文件導入功能在函數服務存在時的正確性2.測試環境應確保網絡正常，平臺服務正常運行3.測試過程中如遇異常，需記錄具體錯誤信息并回滾測試環境1、需求的業務功能建模2、通過父特性的相關性用例輔助進行邏輯校驗基于需求上下文增強的Al輔助測試設計整體方案特性1特性1用例1立立用例…需求需求1需求2缺陷缺陷1缺陷2缺陷…特性21、基于需求上下文知識增強，測試點的平均采納率從不到40%左右提2、基于測試點的上下文知識增強(父特性的關聯用例),由測試點生成測試用例的采納率達到80%以上。需求上下文知識增強對測試點采納率的提升效果全球軟件質量&效能大會【存在的問題】1、當前測試人員在開展測試設計的時候往往需要與SE和開發反復澄清和溝通，溝通和澄清的時間占到測試設計時間的30%以上；2、當前需求的測試建議規格/建議往往寫的比較簡單，一個需求串講完成以后不同的人對需求的理解程度不一樣；3、當前的需求描述和設計文檔中對需求上下文的分析不足，主要依賴開發和測試對業務知識的掌握情況。需求分解產品串講需求上線測試反串講測試設計【AI輔助測試設計帶來的改變】1.在需求設計階段，SE可以通過Al輔助生成的測試點快速獲得需求設計質量的反饋，高效進行查漏補缺，提升設計質量的同時，可以高效生成高質量的測試建議；2.在需求串講階段：SE、DE、TSE通過對測試點的評審和補充，高效達成對需求理解的一致性，串講和反串講融合；3.在需求開發階段：DE可以基于串講環節明確的測試點進行需求自驗證，提升需求開發質量；4.在測試設計階段：TSE基于串講環節明確的測試點進行詳細的測試設計，可以顯著減少與產品和架構的澄清和溝通，提升需求設計的效率和質量。需求分解產品串講需求設計設計串講+測試反串講1、架構師(設計負責人)的評價@李賀松，感謝賀松下午2個多小時一直在線指導，今天fg串講了5個需求，覆蓋了下面三類場景：1、歷史上下文質量差，但需求文檔寫的質量很高，生成的用例質量很高2、歷史下文質量好，但需求文檔質量寫的差，生成的用例質量也高3、歷史上下文質量差，需求文檔質量寫的也差，生成的用例質量巨差個人感覺：以前衡量需求文檔寫的質量好不好，很難量化。現在AI用例生成直接量化了