高家祺-大模型加速BDD工程化落地.pdf

《高家祺-大模型加速BDD工程化落地.pdf》由會員分享，可在線閱讀，更多相關《高家祺-大模型加速BDD工程化落地.pdf（39頁珍藏版）》請在三個皮匠報告上搜索。

1、大模型加速BDD工程化落地高家祺|杭州諧云科技有限公司演講嘉賓高家祺諧云科技-DevOps技術總監目前就職于諧云科技，主要負責DevOps產品研發、推廣、落地，擁有多年大規模微服務架構、軟件工程化、團隊敏捷化實踐經驗，主導過觀云臺、DevOps、項目管理、API網關、微服務治理平臺等產品孵化、架構升級建設，目前服務過的客戶主要覆蓋政府、銀、證券、能源業，包括：應急部、香港醫院管理局、杭州銀行、湘財證券、國元證券、中國電力科學研究院、上海汽車、東風汽車等。目 錄CONTENTS1.BDD開發模式2.BDD企業應用實踐3.大模型+BDD框架4.總結與展望BDD用戶行為驅動開發模式PART 01常見

2、的測試模式軟件需求軟件開發軟件測試軟件發布軟件需求軟件開發軟件發布傳統模式敏捷模式敏捷測試 傳統測試 敏捷測試傳統測試通常在軟件開發的后期階段進行，測試工作相對獨立，通常由專門的測試團隊負責，測試的重點在于驗證軟件是否符合需求設計。傳統測試往往在項目完成后才發現問題，反饋周期較長，導致修復成本高。同時，傳統測試的跨職能合作較少，開發和測試團隊之間的溝通不夠頻繁，可能影響軟件的質量和交付速度。敏捷測試則貫穿整個開發過程，強調早期和頻繁的測試，確保軟件在每個迭代周期都能快速交付可用功能。敏捷測試鼓勵開發和測試人員之間的密切合作，團隊成員共同參與需求討論和設計評審。敏捷測試關注更快的定位發現軟件中存

3、在的缺陷，建立快速反饋機制，持續改進，高效解決問題。此外，敏捷測試采用輕量級文檔，靈活應對變化，更加適應快速發展的軟件項目環境。敏捷其實是一系列方法如XP、Scrum、Lean等總稱的術語，目的是通過迭代和增量的開發，并且經常檢視和調整來提升項目的管理和交付。測試時間短文檔少，難以短時間理解需求開發質量差缺陷基數大測試環境不穩定存在問題敏捷測試宣言測試是一個活動 勝于 測試是一個階段Testing is an Activity Over Testing is a phase預防缺陷 勝于 發現缺陷Pervent Bugs Over Finding Bugs做測試者 勝于 做檢查者Be a te

4、ster Over Be a checker幫助構建最好的系統 勝于 破壞系統Helping to build the BEST system Over Breaking the system團隊為質量負責 勝于 測試為質量負責Whole team takes responsibility for quality OverTester is responsible for quality敏捷方法要求團隊能夠持續提供高質量的軟件，敏捷測試是確保這個目標實現的關鍵。Ken Schwaber在敏捷中，測試與開發是交替進行的，測試并不是在完成開發后才開始，而是隨時伴隨開發的進展。Mike Cohn 敏

5、捷測試不僅僅是在開發后做功能驗證，它應該貫穿整個開發過程，幫助我們更早地識別問題，并盡早修復。Martin FowlerTDD(測試驅動開發)測試驅動開發（TDD）是一個軟件開發過程，其中開發人員在實現代碼之前，首先構建并執行測試，從而確保代碼符合預期功能；TDD的意義在于提高代碼質量、確保功能符合需求、減少缺陷，并促使開發人員更清晰地理解需求，從而提升開發效率和維護性。測試驅動開發的工作模式u 首先創建測試用例，進行測試用例評審，達成一致約定。u 運行測試代碼，預期執行失敗u 編寫實現的代碼，不斷調試代碼，使測試腳本執行通過。u 重構將代碼調試到最佳(重構是在不改變其功能的情況下改進代碼結構

6、以提升質量）TDD存在的問題：u雖然測試驅動開發過程，但是更像測試單打獨斗，然而業務、開發都未能參與進去，無法拉齊整個團隊uTDD側重于單元測試，可能難以全面覆蓋復雜的業務邏輯或系統集成場景u隨著代碼的演變和重構，測試用例可能需要頻繁更新，維護成本高BDD(行為驅動開發)行為驅動開發(BDD)是一套軟件工程實踐來幫助團隊構建和交付更有價值、更高質量的軟件。它借鑒了敏捷和精益實踐，特別是測試驅動開發(TDD)和領域驅動設計(DDD)。但最重要的是，BDD提供了一個基于簡單的、結構的語言表達方式來描述需求，促進項目組與業務方之間的溝通。BDD(行為驅動開發)28需求具有明確的應用場景，避免脫離場景

7、的偽需求促進業務、開發、測試充分溝通，一致需求語言需求充分考慮用戶使用的異常情景需求邊界清晰，易于評估工作量統一溝通語言，減少浪費，節省溝通成本業務人員（產品經理）把軟件業務需求告訴需求分析人員1軟件需求分析人員和開發人員、測試人員一起分析軟件需求2研發人員使用用戶故事場景來開發軟件代碼3測試人員使用用戶故事場景形成測試驗證條件和編寫測試案例4BDD自動化測試案例及時驗證軟件功能是否符合用戶故事，并形成產品特征的描述文檔5軟件需求的分析結果是結構化的自然語言來描述的用戶故事場景BDD的優點BDD是測試驅動開發的延伸，通過用戶故事作為使業務、開發、測試溝通的語言創建任務條目，每個條目對應一個用戶

8、行為，天然具備可使用、可測試、可開發的特點。作為什么用戶角色(用戶畫像)想要完成什么活動(需求場景)，以便于（實現價值）通過如何的操作步驟，可以做到什么。(可驗證)預期驗收點：1、2、3、BDD的描述語言用戶故事對比BDD與TDD特性BDD（行為驅動開發）TDD（測試驅動開發）目的強調開發者、測試人員和業務相關者之間的協作，定義和測試軟件行為。通過共享理解，提升團隊的整體效率。側重于創建自動化測試，確保軟件代碼滿足指定的要求。主要目標為代碼驗證。語言使用自然語言描述軟件行為，通常通過用戶故事或場景進行描述，易于跨職能團隊理解，特別是非技術人員。使用編程語言編寫每個代碼單元的測試，通常需要開發人

9、員專門的技術能力。范圍涵蓋端到端測試，包括UI、API和數據庫測試，確保從用戶需求到技術實現的全方位覆蓋，增強產品的可用性。主要聚焦于單個代碼單元的測試，更側重于代碼級別的驗證。執行通常使用專門的BDD測試框架，如Cucumber或Behave。通過框架與自然語言結合，促進跨團隊協作，增強溝通效果。通常使用特定編程語言的測試框架，如Java的JUnit或PHP的PHPUnit，較少強調團隊間的溝通。結果在所有相關方之間達成共享的軟件行為理解，促進開發人員、測試人員與業務人員的持續合作，減少需求誤解和功能偏差。確保代碼經過徹底測試并滿足指定的要求，但可能不會總是促進軟件行為的共享理解，缺少對業務

10、需求的直接反饋。優勢1.跨職能協作：通過自然語言和示例驅動的測試，促進開發、測試和業務人員之間的緊密合作。2.需求驗證：能夠早期捕捉到需求誤解，并迅速反饋，降低開發過程中的偏差。3.共享理解：有助于所有團隊成員（包括非技術人員）理解軟件行為，提高開發的準確性和效率。1.代碼級驗證：聚焦單元級測試，確保代碼按需求工作。2.實現細節驗證：對于精確的代碼實現和邏輯驗證有優勢，但對于功能全局或用戶需求驗證較弱。BDD把需求和技術實現緊密結合，創造了一種能讓所有利益相關者都能理解的軟件開發方式。BDD使團隊能夠在一個共享的視角下進行工作，所有成員，包括非技術人員，都能清楚了解產品的行為和預期。BDD幫助

11、我們通過更具表達力的示例和場景來描述需求，讓每個團隊成員都能理解，并能在開發的每個階段進行有效驗證。BDD產品、開發、測試聯動產品/業務開發測試與業務溝通將業務需求轉換為用戶故事定義用戶故事與開發、測試溝通按用戶故事驗證需求根據用戶故事拆分Feature功能、Scenario場景根據 Feature 文件中的場景，編寫相應的代碼實現，確保功能的正確性和完整性維護功能點知識庫，包括接口和頁面元素審核用戶故事：確保用戶故事的完整性和準確性，確認需求清晰且可轉化為具體場景。編寫測試腳本：根據Scenario編寫Steps測試腳本事項對Scenario的功能性驗準備測試數據User StroyFeat

12、ureTest StepsBDD的三元素User Story-用戶故事n 定義：用戶故事是對用戶需求的簡潔描述，通常以“作為角色，我想要目標，以便收益”的格式書寫。n 角色：用戶故事是BDD的起點，幫助團隊理解用戶的需求和期望。Feature-特性n 定義：特性是一個或多個相關用戶故事的集合，代表軟件的一個功能或模塊。n 關系：每個特性應對應多個用戶故事，明確該功能的整體目標和價值。Scenario-場景n 定義：場景是對特性實現的具體描述，通常使用Gherkin語法編寫，具體展示用戶如何與系統交互。n 關系：每個場景是特性的具體實現示例，涵蓋特定的業務邏輯和預期結果，幫助團隊驗證特性是否符合

13、用戶需求。BDD的優勢保持測試用例盡可能的簡單，以驗證業務為首要目標簡化不需要另外單獨的文檔，而是在測試類中對每個測試方法對應的業務場景，輸入和期望的輸出進行詳細的描述注釋測試通過即可證明用戶使用通過口徑一致按用戶使用流程編排功能點根據用戶使用操作流程進行測試驗證貼合自然語言每一個測試類（Step）都可以被復用，不依賴于其它任何測試；同樣很多測試類也可以一起執行，而不會互相干擾原子針對每一個需要驗證的業務場景進行測試，而不是對代碼的每一個方法進行測試業務導向聚焦于最核心鏈路的測試聚焦2341765敏捷測試中通過BDD的模式描述測試場景，由測試驅動開發，提升研發質量和效率，聚焦業務目標。BDD測

14、試框架應用實踐PART 02BDD自動化測試框架Cucumber 是一個廣泛使用的行為驅動開發（BDD）工具，允許團隊使用自然語言（如 Gherkin 語法）編寫可讀的測試場景。它支持多種編程語言（如 Java、Ruby 和 JavaScript），促進了開發、測試和業務團隊之間的溝通。Cucumber 通過將用戶需求轉化為自動化測試，使團隊能夠在開發過程中快速驗證功能的實現。Selenium 是一個流行的開源自動化測試工具，專門用于Web應用程序的功能測試。它支持多種瀏覽器和操作系統，通過編寫測試腳本模擬用戶與網頁的交互。Selenium 提供了一整套API，允許開發人員和測試人員創建復雜的

15、測試用例，從而確保Web應用的穩定性和用戶體驗。Gherkin提供易懂的測試用例關鍵詞解釋feature描述要實現的功能或特性background每個場景執行之前都要執行的步驟scenario用來描述特定的測試場景scenarioOutline 場景大綱、劇本大綱given假如、假設、假定，表示測試場景的初始條件或前提when當，表示在某個場景下執行動作或行為then那么，表示期望結果或后果and而且、并且、同時，用于在 Given、When 或 Then 后補充更多條件或步驟but但是，用于表示額外的條件或情形參數化占位符 和密碼 多行文本姓名:張三地址:北京市海淀區ExampleExamp

16、les:|username|password|user1|pass1|user2|pass2|注釋#規則：檢查密碼規則標簽登錄功能Gherkin是Cucumber的描述語言，用于編寫符合業務需求的可讀測試用例。通過自然語言編寫的Gherkin文件（.feature文件），非技術人員（如產品經理、業務分析師）可以輕松理解測試場景和期望行為。Cucumber解析Gherkin文件，將行為規范轉化為自動化測試，幫助開發、測試和業務團隊保持一致理解。Gherkin的存在使測試流程更加透明，便于跨團隊協作，實現了需求與測試的無縫銜接。#功能描述：在線銀行系統的登錄和轉賬銀行功能Feature:在線銀行系

17、統#背景：在每個場景之前都要執行的步驟 Background:Given 用戶已在登錄頁面#規則：檢查密碼規則 Rule:密碼格式要求 Example:用戶必須輸入至少8位密碼 Given 用戶已輸入用戶名 When 用戶輸入少于8位的密碼 Then 系統提示“密碼必須至少8位”#場景：用戶成功登錄 登錄功能 Scenario:用戶使用有效憑證登錄 Given 用戶輸入正確的用戶名和密碼 When 用戶點擊“登錄”按鈕 Then 系統跳轉到用戶的賬戶主頁 And 顯示用戶賬戶余額測試用例案例/背景步驟 Given(用戶已在登錄頁面)public void 用戶已在登錄頁面()System.ou

18、t.println(用戶在登錄頁面);/實現登錄頁面初始化邏輯 可復用-測試腳本案例Selenium提供UI自動化能力方法功能描述示例代碼get(String url)打開指定的URLdriver.get(https:/);findElement(By by)查找頁面上第一個符合條件的元素WebElement element=driver.findElement(By.id(id);click()點擊元素element.click();getAttribute(String name)獲取元素的指定屬性值String value=element.getAttribute(value);send

19、Keys(keys)輸入文本至元素，如輸入框 element.sendKeys(text input);isDisplayed()檢查元素是否可見boolean visible=element.isDisplayed();isSelected()檢查元素是否已選中boolean selected=element.isSelected();getText()獲取元素的文本內容String text=element.getText();navigate().to(String url)導航至指定URLdriver.navigate().to(https:/);navigate().back()瀏覽

20、器后退driver.navigate().back();navigate().refresh()刷新當前頁面driver.navigate().refresh();switchTo().frame(int index)切換到指定索引的iframedriver.switchTo().frame(0);manage().window().setSize()最大化瀏覽器窗口driver.manage().window().setSize();wait.until()設置等待時間new WebDriverWait(driver,Duration.ofSeconds(10)close()關閉當前窗口dr

21、iver.close();quit()關閉窗口并退出瀏覽器driver.quit();Selenium通過WebDriver與瀏覽器進行交互，模擬用戶操作，如點擊、輸入、選擇等。它通過瀏覽器驅動程序發送命令，控制瀏覽器執行操作并獲取頁面信息，支持多種瀏覽器和編程語言，廣泛用于自動化測試。錄制式代碼式UI自動化測試的開展方式對比維度錄制式（Record&Playback）代碼式（Code-Based）操作方式用戶通過錄制工具錄制瀏覽器操作，生成測試腳本。開發者手動編寫測試代碼，控制瀏覽器行為。易用性對非程序員友好，易于上手，不需要編程經驗。需要編程知識，開發者需要編寫代碼來實現測試邏輯。靈活性靈

22、活性較差，錄制的腳本在復雜場景下可能不適用，難以修改擴展。非常靈活，可以根據需求自由編寫、調試和擴展測試代碼?？删S護性難以維護，錄制的腳本可能因頁面變化而頻繁失敗，需要重新錄制?？删S護性較好，隨著需求變化，開發者可以靈活修改代碼。適用場景適合簡單、靜態的頁面測試，快速創建測試腳本。適合復雜的測試場景，包括動態內容、數據驅動測試等。調試能力調試能力差，錯誤通常不容易發現，無法進行靈活的錯誤處理。提供豐富的調試功能，開發者可以使用 IDE 工具調試腳本。擴展性擴展性差，處理復雜場景時需要重新錄制或使用外部工具。高度可擴展，可以通過模塊化代碼、測試框架等方式進行擴展。執行效率通常較慢，因為錄制的操作

23、和腳本中可能包含冗余步驟。執行效率較高，可以進行優化，減少冗余操作。測試框架支持通常依賴于錄制工具自帶的功能，難以集成第三方測試框架。容易與常見的測試框架（如 TestNG、JUnit）集成。學習曲線學習曲線較低，非程序員也能快速上手。學習曲線較高，需要具備編程基礎和測試框架的使用經驗。適用人群適合測試人員、QA 和非技術人員使用。適合開發人員和具有編程經驗的測試人員使用。測試數據偏靜態測試場景，不易動態測試數據數據驅動測試，靈活支持動態加載測試數據。錄制式：適合簡單、重復性的測試場景，能夠快速生成測試腳本，適合非技術人員。但在處理復雜、動態的頁面時，維護性差且靈活性不足。代碼式：適合復雜的應

24、用程序，提供高度的靈活性、可維護性和調試能力，適合有編程經驗的開發人員和測試人員，能夠實現更精細的測試控制。搭建測試框架WebControllerUI控制TestReport測試報告TestDataTools測試數據GherkinFeatureParsercontroller.switchViewcontroller.waitForTestCaseParser測試用例解析FeatureTestData.xlsxDevOpscontroller.clickElementcontroller.getElementAttributecontroller.getTextFromElementcontr

25、oller.screenshotcontroller.writeTextToElementloadTestDataStepOptionsParser執行測試報告，并門禁測試結果TestReportTempleteTestContextDataTestReportFactory解析Feature用例加載測試數據執行測試Step步驟記錄測試結果輸出測試報告根據Git用戶獲取作為測試人員測試框架的核心特性測試報告：集成 Extent Reports 生成可視化的測試報告，包含測試步驟、截圖、執行結果等信息。錯誤截圖：在測試失敗時自動截取瀏覽器屏幕，作為測試作證材料。操作視頻：操作步驟錄制為視頻。開箱

26、即用，快速上手測試先行，報告權威GitOps：代碼即測試，版本控制，伴隨CICD測試左移測試通過即驗收通過可重復執行跨平臺測試Owner式開發者兼容性能測試封裝框架處理測試數據獲取FeatureName獲取FeatureData文件按Scenario加載測試數據TestContextData執行Step步驟導入step測試數據測試結果錄屏封裝框架處理測試報告填充FeatureContext填充ScenarioContext填充StepContext統計測試結果輸出Word報告選擇報告模版BDD模式的協作模式需求用戶故事CICD需求評審編寫測試腳本編寫開發代碼用例通過？用戶驗收代碼倉庫Featu

27、re用例測試報告BDD的模式會大大優化開發、測試的協作方式，首先需求質量會大大增加，從原先的需求評審轉變對用戶故事和故事對應功能場景、驗證方式的評審，需求評審能夠更加清晰地理解需求；測試驅動開發，首先根據Feature用例編寫測試腳本，接著編寫代碼文件，測試腳本與代碼文件同頻更新，在不斷的失敗-成功中，完成編碼工作；通過GitOps將開發代碼、測試腳本統一在代碼倉庫版本化管理起來，在CICD過程中自動執行測試腳本，測試用例的通過情況成為發布的必要門禁；在測試用例通過后，僅需要簡單的驗收測試即可結束需求生命周期。BDD自動化測試應用收益優化團隊結構n 改變責任模式，測試更加關注質量管理與測試規范

28、，由執行者轉變為支撐與協調者n 避免開發測試產品扯皮，誰開發誰負責n 適用與以開發為主，測試占比很小的公司或團隊，測試職責更專注與質量標準的質量提升開發質量n 往往缺陷是由于對業務邏輯理解不清晰而產生，BDD在開發與測試同步進行，缺陷開發過程中就被解決，質量更高、效率更高n 應用現代化架構的一個重要的評估原則就是可測試性，代碼天然具有可測試性避免測試腐化n GitOps版本控制n 測試腳本隨著開發代碼的演進而同步演進，避免開發、測試不同頻，自動化測試腐化問題n 測試腳本與需求文檔嚴格對應，避免文檔和測試的脫節降低測試成本n 測試腳本原子化到Step，多Scenario可復用n 減少測試問題分析

29、、復現帶來的時間開銷n 無需反復進行環境測試，節約環境維護成本、測試人力成本和時間成本，提升交付效率大模型+BDD框架PART 03代碼化的測試框架推廣存在的問題存在問題測試數據管理復雜代碼化測試中，測試數據的管理和隔離變得復雜，特別是數據驅動的測試需要多場景、多數據集，且要求數據的獨立性。缺乏數據管理策略可能導致測試數據冗余、污染，甚至干擾測試結果代碼化測試在早期階段的投入較大，需要時間編寫、調試和優化用例。因此，ROI（投資回報率）在初期可能不明顯，尤其是在快速迭代的項目中，回報周期較長回報周期較長學習曲線陡峭代碼化測試框架通常需要團隊成員具備編程技能，并且對復雜的框架（如Cucumber

30、、Selenium、Gherkin）有較深入掌握，需要理解自動化測試代碼結構、Gherkin語法和代碼庫的管理代碼化測試用例隨系統功能變化頻繁更新，如果沒有完善的測試管理流程，測試用例的維護將占據大量時間，影響團隊效率。此外，自動化測試代碼可能會變得冗長且難以維護，特別是在框架代碼與業務代碼緊密耦合的情況下維護成本高引入大語言模型應用到測試場景工具模型推理加速生成/評審用戶故事支持多功能支持多系統生成測試數據提取接口文檔代碼審查自然語言生成測試腳本WindowsMacOsLinux海量高質量代碼數據微調16K超大上下文窗口生成測試腳本開發者Testing根據自然語言進行用戶故事的描述，并補充自

31、然語言的功能描述，提取Scenario生成Feature更新功能點將原子功能提煉成Xpath的功能點，首先根據自然語言提取相關的功能點根據上下文自動生成清晰的代碼注釋，提高代碼可讀性和文檔質量。生成Steps腳本根據用戶需求，構造生成測試數據，輸出到測試數據中生成測試數據執行自動化測試腳本將自動化測試工程放在Git中進行管理，隨 著CICD執行測試腳本Deploy生成測試報告將測試腳本執行后，將每個測試場景截圖，并總結生產測試報告，推送到Pipeline中測試報告發布測試腳本AI+BDD測試流程業務需求用戶故事生成用戶故事Feature文件生成Feature文件產品知識庫Feature知識庫測

32、試腳本庫編寫操作步驟ScenarioScenarioScenarioScenario系統菜單平臺功能頁面功能表單功能根據自然語言檢索相關的功能操作步驟操作步驟操作步驟操作步驟操作步驟生成測試代碼測試代碼GivenWhenThen生成測試數據測試數據數據條目數據條目數據條目快速生成大量有意義的測試數據總之根據自身業務邏輯創建的有意義的測試數據才能讓測試結果更加可靠測試數據的要求n測試數據應當貼合業務場景n測試數據具有內部關聯關系n測試數據隨著功能變化而變化，應當具有可廢棄性n隨著自動化測試的反復執行，測試數據應具有不重復性，確保每次測試執行高效平臺內置規則：電話號碼、城市、國家、電子郵箱、姓名、

33、性別、地址、單位、部門、日期、圖片、數字、正則表達式、序列AI自定義生成數據規則：按照特定格式要求約束來生成符合不同業務場景的規則智能構造數據服務原子數據生成規則數據快照，數據恢復批量生成帶關聯關系的數據并插入數據庫將測試數據規則作為AI輸入參數批量生成測試執行過程的正常、異常數據數據準備測試數據數據反復可測，隨時清理，隨著生成一整塊業務測試數據，數據驅動針對性測試數據異常場景。生成用戶故事/Feature文件#角色你是一個專業的 Cucumber Feature 描述生成助手，可以根據用戶提供的信息，準確地生成 Cucumber 格式的描述。#技能#技能 1：生成功能描述1.引導用戶輸入功能

34、名稱，例如：“請提供功能名稱?！?.引導用戶輸入功能目標，例如：“請說明這個功能的目標是什么?！?.根據用戶輸入的功能名稱和目標，生成功能描述部分，格式為：“功能：作為一個用戶 我想要 以便我可以?！?技能 2：生成場景描述1.引導用戶輸入場景名稱，例如：“請提供場景名稱?！?.引導用戶輸入給定條件，例如：“請說明場景的給定條件?！?.引導用戶輸入操作，例如：“請詳細說明在這個場景中的操作步驟?！?.引導用戶輸入預期結果，例如：“請說明這個場景的預期結果?！?.根據用戶輸入的場景名稱、給定條件、操作和預期結果，生成場景描述部分，格式為：“場景：給定 當 并且 那么 并且?！?限制-只專注于生成

35、 Cucumber Feature 描述，拒絕回答與該任務無關的問題。-嚴格按照給定的格式生成描述，不能偏離要求。-引導用戶逐步提供完整的信息，確保生成的描述準確且全面。生成Feature Prompt#角色你是一個專業的 BDD 用戶故事生成助手，能夠高效地為 BDD 項目生成清晰、具體且有價值的用戶故事。#技能#技能 1：生成新用戶故事1.當收到具體的業務場景描述時，分析場景中的參與者、行為和目標結果，生成用戶故事。用戶可以通過描述參與者、行為和目標結果的方式進行輸入?；貜褪纠?-作為，我想要，以便。=#技能 2：優化現有用戶故事1.當用戶提供一個用戶故事時，檢查其是否清晰、完整，并提出

36、優化建議。優化時將檢查以下要點：-角色是否明確？-行為是否具體？-目標結果是否清晰，且與業務目標一致？回復示例：=-原始用戶故事：-優化建議：=#限制：-只生成與 BDD 方向相關的用戶故事。-輸出的內容必須按照給定的格式進行組織，不能偏離框架要求。生成用戶故事基于錄制方式并由AI轉換代碼SeleniumIDE腳本錄制方式：通過SeleniumIDE來執行錄制自動化腳本，具有上手門檻低，操作簡單，配置邊界的特點。利用大模型解決錄制腳本生成代碼與框架適配問題，以Step場景來錄制腳本，導出場景腳本代碼，在翻譯過程中解決腳本可讀性、腳本可維護性、靈活性問題、重用性問題。輸入腳本錄制存在的問題：脆弱

37、性：錄制的測試腳本往往對頁面的結構和元素定位非常敏感，如果網頁發生了輕微的變化（如元素之間管理發生變化），測試可能會失敗?？删S護性差：錄制的腳本缺少語義化的注釋來映射操作步驟，未實現測試數據與測試腳本的分離，不易于工程維護靈活性不足：錄制的腳本通常無法應對復雜的業務邏輯或動態內容，限制了測試的覆蓋范圍。缺乏可重用性：由于錄制的測試用例往往是特定于某一場景的，它們的重用性較低，不能輕易應用于其他測試場景。調試困難：在出現錯誤時，調試錄制的腳本可能比較困難，因為它們缺乏清晰的邏輯結構和錯誤處理機制。解析代碼增加注釋提取XpathStep語句生成代碼框架約束操作說明轉換Controller操作拆分測

38、試數據清理代碼Step代碼基于積木來搭建操作路徑 原子化頁面操作 積木式操作路徑 多角色協作 統一溝通 編排生成代碼利用Blockly實現拖拽積木編排頁面操作流程，記錄操作場景并導出未step腳本；支持通過將自然語言首先轉化為積木語言，進而轉化為測試腳本的智能生成轉換方式?；谧匀徽Z言交互生成代碼自然語言描述一個場景的操作步驟與驗證方式語義解析產品知識庫提取可能的功能點檢索功能點結構化操作步驟輸出結果提醒用戶補充功能點生成Step代碼框架約束用戶驗證持續優化總結與展望PART 04總結與展望提升效率AI賦能的測試框架能夠根據用戶輸入的業務描述自動生成測試腳本，顯著減少了手動編寫測試的時間，使測

39、試過程更加高效。01優化協作AI賦能的測試框架將多人協作流程簡化為單人操作，使開發者具備“特種兵”能力，在開發同時兼顧測試驗證、實現高質量的開發成果。03增強規范性通過自動化生成的測試腳本，確保了測試用例的一致性和規范性，降低了因人工操作導致的錯誤和不一致，提升了軟件質量。02未來發展潛力隨著AI技術的不斷進步，未來的測試框架將能夠更深入地理解業務邏輯，自動適應需求變化，提供更智能的測試建議和優化方案，推動持續集成和持續交付的進一步發展。04在AI的加持下，讓開發者成為特種兵式的超級個體，讓又快又好成為常態！AI不是替代人，而是輔助人，讓不可能成為可能，大大降低難度、提升質量與效率！利用AI技術深化計算機對現實世界的理解推動研發進入智能化時代