基于Fuzzing和ChatGPT結合的AI自動化測試實踐一、前言有贊目前，結合insight接口自動化平臺、horizons用例管理平臺、引流回放平臺、頁面比對工具、數據工廠等，在研發全流程中，已經沉淀了對應的質量保障的實踐經驗，并在逐漸的進化中。在AI能力大幅進步的背景下，筆者嘗試將業務場景給到ChatGPT，進行了文本用例生成的測試，觀察到其輸出測試用例的邏輯和測試人員編寫用例的邏輯有較大的相似之處。在對ChatGPT的輸出結果進行簡單的調整和修改后，就可以用于業務測試中了。筆者發現AI設計的測試用例場景既能包括正向場景，也能包括逆向的異常場景，并能較為準確的給出測試用例描述和預期結果。在自動化測試中，測試工程師需要花費較多的時間去設計、實現和維護用例，對于該場景，我們是否可以應用ChatGPT的內容生成能力，來提升自動化測試腳本的編寫效率呢？如果結合Fuzzing的測試思路，借助大量的生成用例來執行是否能挖掘潛在的代碼問題呢？下面將介紹目前在做的基于Fuzzing（模糊測試）和ChatGPT結合的探索實踐。二、調研過程2.1什么是Fuzzing模糊測試（Fuzzing）的核心思想是通過系統自動生成隨機數據作為輸入，來驗證被測程序的可靠性。在測試領域中，Fuzzing經常作為一種補充接口測試手段，來覆蓋/探索接口中潛在的異常/臨界值場景。簡單來說，系統通過給定種子用例，隨機生成大批量用例，調用被測接口，嘗試發現問題（挖掘bug）。模糊測試的難點在于如何基于種子用例生成隨機有效的用例數據，從業界的經驗來看，測試人員通過對生成內容進行建模、設計相應算法來匹配被測對象，才能取得比較好的生成效果。隨著ChatGPT的發布，其AIGC的能力令人驚艷，如果借助ChatGPT的優勢，能否降低生成隨機數據的成本呢？于是，筆者圍繞ChatGPT生成用例的可行性進行了嘗試。2.2ChatGPT生成用例的可行性為了驗證ChatGPT生成數據的能力，筆者隨機找了一份公司的PRD，摘取了一部分需求（已脫敏）來測試ChatGPT生成用例的質量，以下是調研過程中的部分結果展示。摘取需求：商品設置了會員價-會員等級-打折，則群團團下單享受會員折扣。前置條件為當前店鋪A，消費者P是店鋪的會員，店鋪A筆記內的商品M售價100元，運費0元，店鋪設置了該商品M會員打8折。部分問答內容：可以從上述的圖片中發現，在給定較為完善的背景情況下，ChatGPT生成的測試用例還算那么回事。筆者和相關業務同學確認，如果在ChatGPT給出的用例上再做一些調整，就可以直接用于功能測試了，所以在ChatGPT生成用例這件事上，是有可行性的，值得進一步探索。而自動化測試，無外乎將生成內容和規則變更，讓ChatGPT產出可行的入參內容即可。2.3結合Fuzzing與ChatGPT可以做什么經過上述的調研，模糊測試（Fuzzing）的思路是

基于種子用例生成隨機用例->執行用例->發現問題（bug挖掘），但其難點在于如何生成高質量的隨機用例，而ChatGPT的內容生成能力，似乎可以解決這一問題。筆者將兩者嘗試結合，模糊測試作為核心思想，ChatGPT作為用例生成服務，目標是通過大量ChatGPT生成的用例，來挖掘被測對象潛在的問題。在自動化測試中，如果僅依賴模糊測試和ChatGPT生成的用例還不夠，因為我們無法判斷ChatGPT生成的用例是否有效，筆者嘗試引入了自動化測試覆蓋率的概念，將整體流程給串聯起來：以模糊測試為基石，讓ChatGPT來充當規則變異器，自動生成接口測試用例，覆蓋率作為檢驗生成用例的有效性，目的是發現問題和提高自動化測試的效率。下面，筆者將以ChatGPT用例生成、bug挖掘、代碼覆蓋率作為主線，來進行AI自動化測試實踐。三、設計與實現前言提到，有贊已經有幾個成熟的平臺可以使用，為了降低實現的成本，筆者將盡可能基于現有平臺的能力，來做設計與實現。3.1

整體思路有贊目前已有成熟的接口測試平臺insight、流量回放平臺zan-hunter，來承接日常接口測試、線上巡檢、引流回放等測試活動。基于調研結果，筆者經過整理，核心思路可概括為拾取用例->生成用例->執行結果判別->覆蓋率條件循環。具象的說，就是（1）insight/zan-hunter獲取用例生成模版數據->（2）根據模版數據生成ChatGPT的輸入（prompt）->（3）調用ChatGPT，根據要求生成用例（JSON輸出）->(4)執行用例，調用java應用的接口進行測試，輸出測試結果（bug挖掘）->（5）獲取接口對應的行覆蓋率，并根據判斷是否要繼續執行->（6）循環往復，直到覆蓋率摸高到天花板（可能是70%~80%）->（9）End。在現有資源限制、功能實現復雜度較高的背景下，筆者將其拆解為2個階段來完成，同時本期將優先實現第一階段的功能：第一階段：完成基于ChatGPT用例推薦，結合insight用例創建與執行來實現測試環境與基準環境的結果比對，驗證ChatGPT用例推薦有效性和被測代碼穩定性，目標是能夠挖掘出有效問題。第二階段：接入自動化覆蓋率采集能力。目的是通過接口執行覆蓋率是否提升的判斷，來優化測試用例生成的有效性，使其達到目標自動化覆蓋率。3.2功能設計筆者根據實際情況，將實現內容做了拆解。第一階段需要實現的功能分成3塊：1.搭建自動生成推薦用例前端展示、后端增刪改查的框架；2.后端用例生成核心邏輯部分；3.后端用例執行結束bug挖掘部分。第二階段的功能做了簡單的設計規劃，主要是覆蓋率的收集、比對判別、有效用例篩選標記、循環生成用例四大塊。以下主要是自動生成推薦用例的后端服務部分的流程圖。3.3實現情況目前，第一階段的開發和驗證已經結束，包括基于ChatGPT的推薦用例生成服務、用例執行、斷言回寫、結果輸出等。實踐結果證明基于ChatGPT創建的推薦用例，已經能夠正確執行并感知到代碼異常錯誤。第二階段做了初步調研，暫未實現功能。基于ChatGPT的推薦用例生成服務：前端頁面輸入提供生成規則，系統推薦參數模版；后端基于GPT-3.5模型，設計prompt來生成準確可靠的隨機內容入參，結合insight已有能力，創建測試用例與執行集。用例創建執行：基于ChatGPT生成的隨機內容入參構建測試用例和創建執行集，insight執行并獲得測試報告。（左：執行集詳情；右：執行集結果）斷言回寫：由于執行結果的不確定性，我們將每一條用例第一次執行的結果作為用例基準斷言。結果輸出：insight平臺還沒有合適的聚合結果展示能力，我們將每一條用例第一次執行的結果、后續執行的失敗結果，系統進行規則過濾后，將潛在風險問題均輸出到飛書文檔，方便測試人員可視化觀察。（左：平臺單條錯誤展示；右：飛書表格聚合展示）bug挖掘:由于輸出的結果經過系統的第一次過濾，產生報告量數據適中，可以通過人為檢查結果的方式來判斷在當次執行的結果中，是否存在有效問題。3.4現階段使用效果由于資源分配、時間的關系，目前只完成第一階段功能的開發驗證。這里也將只基于第一階段已經實現的能力做下使用總結，主要從生成速率、生成質量上來闡述使用效果。3.4.1

用例生成速率通過ChatGPT生成千條用例并執行完畢產出報告的速率在8分鐘左右（測試條件：推薦用例生成的入參字段個數<10個），相較于原先的手工測試，使用用例生成服務，可以節省大量參數構造以及用例執行所需的時間。3.4.2用例生成質量（bug挖掘情況）用例生成質量可以通過能否發現有效問題，或者接口能夠正常攔截異常輸入的角度來判定生成質量好壞。筆者在測試過程中，主要對分銷員業務接口（包含少量美業、群團團接口）進行bug挖掘驗證，篩選驗證接口共25（21+1+3）個接口，通過ChatGPT共生成了3400余條推薦用例，共發現4個有效問題，剩余21個接口能正常攔截異常錯誤。其中，發現的有效問題主要是SQL注入類異常報錯（涉及代碼安全問題）、業務代碼NPE處理不健全2類；正常攔截錯誤的接口，說明其接口相對健壯，能夠合法處理異常輸入且不影響業務使用。從測試的結果來看，用例生成質量符合預期（能發現問題）。3.4.3

結論分析結合目前第一階段計劃中已經實現的功能和使用效果，筆者對其有了更加深刻的認知，主要從工具定位、工具承擔的使命、工具和現有測試手段的關系做了簡短的總結。當然，現有的結論下，并不會影響到先前第二階段的初步設計，在解決了第一階段發現的問題后，繼續推進。工具定位掃描接口，利用隨機入參帶來的不確定性，來驗證接口的穩定性。比如：用作新接口的異常測試入參驗證新接口的異常測試入參校驗在沒有經過測試驗證前，校驗項是容易存在遺漏缺失，通過隨機生成的入參內容，可以用來驗證校驗邏輯的完備性在不同代碼版本中，回歸接口的穩定性。比如用作新老代碼在異常入參測試領域用作回歸測試生成的推薦用例可以用來驗證同一接口在不同代碼版本下響應，理論上針對推薦用例的響應，預期是一致的它能做什么、不能做什么可以做創建并執行隨機參數輸入的模糊測試批量測試用例生成（非業務語義）基于創建的執行集，在每個代碼版本中用作回歸測試驗證（不同代碼版本對同一份測試用例的結果校驗）；暫時不能做替代手工測試/場景化測試，原因是ChatGPT還不能很好的生成具有業務語義內容的數據（詳見4.1）。與現有自動化/功能測試之間的關系原有自動化/功能測試不會針對異常入參場景做詳盡的參數輸入測試，而自動推薦用例服務，可以在數量上彌補這一場景。從替代性上來說，目前無法替代現有的自動化/功能測試，只能用作輔助測試。最大的問題還是自動推薦用例服務還不具備完善的業務語義（真實）數據生成的能力。四、未來的計劃通過這段時間的實踐，筆者認為結合Fuzzing&ChatGPT的自動生成用例服務是可行的，但也存在著一些問題需要優化改進，比如具有業務語義推薦入參的生成策略、如何提高生成內容的準確性和穩定性等。當然，筆者會繼續嘗試prompt微調、數據集訓練模型等方式，來優化業務語義生成的準確性；通過工程架構優化、接入公司AI基建能力，來提高生成服務的穩定性。在Q4解決了這些問題后，后續將按照第二階段的計劃，結合接口測試代碼覆蓋率來推進ChatGPT生成用例的有效性。在實踐的過程中，筆者也看到很多測試同行在結合AI大模型做著各種各樣協助測試提效、為團隊賦能的事情，振奮人心。測試和AI的結合，不僅限于自動化測試，在CI/CD、測試環境治理上都能有AI輔助的身影，只要有想法且付諸實踐，都會發現AI神奇的魅力。隨著時間的發展各種國產大模型的崛起，LLM的能力被進一步挖掘，筆者相信，各種各樣的測試活動都有可能通過AI來提效，也由衷地希望AI可以給測試行業帶來新鮮的變化，甚至顛覆行業。其他：碰到的問題與解決方案筆者在實際開發、測試自動生成用例服務的過程中，也踩了不少坑，在這里分享幾個比較典型的問題。1.1入參推薦準確度（具有業務語義）使用推薦用例生成服務，需要提供關鍵的參數格式、生成數量和規則給到ChatGPT。如果不對生成規則在生成的時候，總是會生成錯誤的、不符合預期的數據，這樣的用例在實際執行的過程中，大概率是不能走到對應的業務邏輯代碼中去，導致無效用例生成數量在執行集中的占比偏高，執行效果不理想。如果需要解決該問題，有2種比較合適的方案：一是創建私有模型數據來訓練ChatGPT，通過微調的方式來優化ChatGPT的業務語義數據生成準確性；二是通過人為指定參數生成方式，來保障預期字段數據的準確性，從而達到獲得目標業務語義數據的結果。受限于ChatGPT使用資源、私有模型數據集整理收集的高昂成本問題，筆者退而求其次嘗試了第二種方法，盡可能的將生成結果靠近預期內的數據。這里嘗試借鑒使用了MVEL模版語言的規則，經過驗證，ChatGPT是能夠自主理解MVEL模版語言和如何使用該語言的，即使結果不太符合預期，也可以通過

提示

使ChatGPT更加理解我們的需求，并生成準確數據。當然，標準的MVEL語言有自己的編寫規范，我們要做的是設定自己的編寫方式，目的是降低使用者在撰寫推薦入參時的理解成本。為了讓ChatGPT理解什么時候要通過MVEL模版語言進行生成數據，我們通過MVEL()來標記字段，并結合prompt來傳達生成規則。我們現在可以通過自定義MVEL表達式編寫方式，來解決具有業務語義參數的指向性生成，比如在接口參數中需要指定"kdtId"字段的取值范圍在某幾個特定的店鋪范圍內，可以在入參中寫為{"kdtId":"MVEL(1||55||160)"}，ChatGPT在處理字段數據生成時，就會按照自定義規則在[1,55,160]數組中選取任意一個數字作為"kdtId"的值。但是，在方案二的實現中，我們仍然不能要求ChatGPT自主生成期望的“隨機”業務語義數據，這也是其帶來的一個弊端。1.2prompt設計1.2.1中文prompt剛開始接觸ChatGPT時，如何準確的向ChatGPT傳達我的需求，成為了最大的問題。最開始都是將它作為搜索工具來使用的，類似于百度、谷歌，用來解決代碼問題時特別好用。但當我需要解決一個復雜問題的時候，如果直接通過人類語言描述的方式，ChatGPT理解起來有一定難度，經常答非所問。并且，ChatGPT說到底還是LLM，本質還是在根據提供的上下文，預測下一個最優解。所以如何構建ChatGPT能夠理解的上下文，成為了破局的關鍵。在這次實踐中，我需要拆解我的需求，以及構建盡可能簡短精煉的prompt（應對token上限）。在prompt設計中，我首先選擇中文來編寫我的prompt，畢竟是母語，能夠直白快速的撰寫我所理解的需求。實際使用體驗下來，基本上能夠滿足我的要求。但也發現了幾個問題：prompt編寫受限于token數，所以在prompt需要設計的盡可能簡短，筆者僅使用規則形式來限制生成邏輯。當入參格式、入參模版字段個數、單次生成用例條數，都會影響到生成的效果。通過純中文方式描述的字段生成規則，在實際ChatGPT解析過程中，還是會出現誤差。在查閱相關資料、多次和ChatGPT深入溝通后，筆者嘗試優化了中文的prompt。基于問題1，筆者從工程層面做了生成規則上的限制，使其保持在相對穩定的生成狀態下。基于問題2，在了解到ChatGPT理解結構化的語言能力比理解自然語言的能力更強，筆者將純中文描述的生成規則改成了json格式的生成規則（未全部去除中文描述），在改造后的版本使用情況上看，ChatGPT給到的回答更加準確了。同時，筆者在翻閱資料的過程中，也發現ChatGPT的訓練模型中大多數據都是英文數據集，使用中文prompt自然會增加其轉換損耗，逐漸有了使用英文重構prompt的想法。###中文版本

"""用戶會提供一份接口信息，你將按照規則，依據接口信息生成測試數據。以下是規則：1.接口信息數據格式：{\"paramTemplate\":{},\"generateCasesNum\":0},字段依次是種子參數模版，生成的測試用例數量。2.依據paramTemplate提供的內容作為種子參數，按照內容進行生成測試數據。依據generateCasesNum作為生成測試數據的條數。3.生成規則，按照條件順序作為生成數據的規則優先級：3.1在生成的所有數據中，將要生成的用例總數為{generateNum}個，計算單個字段的值重復率，閾值為50%，超過閾值則丟棄當前導致超過閾值的該條數據，并重新生成。3.2如果字段內容不是MVEL表達式3.2.1生成規則：a.{\"type\":String,\"rule\":[\"rule1.長度不超過15位\",\"rule2.如果字符串中只有數字，生成任意可以表示為純數字的字符串\",\"rule3.不符合rule2的，可以生成任意包含數字、字母、字符組合的字符串\"]}(...）3.2.2兜底生成規則：(...)3.3如果字段內容是MVEL表達式3.3.1如果存在字段格式為\"value\":\"MVEL(*expression*)\",則認為value取值范圍為符合表達式*expression*的所有值4.測試數據輸出格式：{generatedParams:[param:{},param:{}]}；5.測試數據輸出要求：生成的測試數據存儲在數組generatedParams；只輸出minifiedjson，noexplainword；只輸出minifiedjson，noexplainword；只輸出minifiedjson，noexplainword。理解上述要求后不需要回復，用戶將提供接口信息:${paramTemplate}，請根據要求數據結果。"""1.2.2英文prompt在今年6月份，OpenAI發布了GPT-3.5新的訓練模型版本，同時GPT-3.5也支持了16K的模型，筆者開始著手英文prompt版本的設計。即使是在prompt中使用了Chinglish（中式英語），英文版本的執行效果還是略好于中文版本。筆者在使用英文prompt和ChatGPT進行交互時，發現其回答的響應速度有明顯的提升，不過其回答的準確度似乎有所降低，可能原因在于我去掉了中文prompt中的詳細規則描述。回答準確度降低的表現形式，包括但不限于1.輸出格式不為json格式；2.生成內容重復率高；3.不同結構的入參格式在生成過程中的解析能力差導致生成錯誤等。得益于"gpt-3.5-turbo-16k-0613"新版本，prompt的編寫可以不再考慮token的限制了（目前需求達不到16Ktokens上限），同時還能使用到functioncalling的新特性，筆者嘗試在英文prompt中增加了問答案例（讓ChatGPT學習生成規則、方式）、函數調用的能力（結合問答案例，方便輸入固定格式內容進行問答，便于工程化管理），優化了輸出格式的規則要求等其他措施，基本解決了生成內容不穩定的問題。當然，現有版本還有很大的優化空間，包括如何保障json格式的穩定輸入輸出（引入DSL）、paramTemplate的解析穩定性、ChatGPT生成數據的準確性、通過案例數據集微調私有模型等，在未來的規劃中，會嘗試逐一去解決這些問題。###英文版本

"""**Prompts**:\nBaseonfuzzingtestand{{MvelExpression}},generate{{generateNum}}random{{generateParam}}bygiven{{paramTemplate}}.\n[Introduction]:\n-{{MvelExpression}},alanguagelikejava/groovy.\n[GenerateRule]:\n-priority1:ifthereisakey/aelementinarraycontains{{MvelExpression}}ingiven{{paramTemplate}},baseon{{MvelExpression}}togenerate.\n-priority2:basedonkey/elementinarraysemanticstogenerate.\n-priority3:basedonkey/elementinarraytypetogenerate.\n-priority4:basedon[GoodExample]casesin[Examples]togenerate.\n-priority5:Ensureallkeys'value/allelementsinarraywillgeneratenewdata.\n-priority6:ifthegiven{{paramTemplate}}isaarray,generate{{generateNum}}arraysinsamegivenarraysize,andeveryelementinarraywillgenerateanewvalue,setarraysinaMulti-dimensionalArray.\n[OutputRule]:\n-onlyminifyjson.\n-setresultsin{{generatedParams}}byJsonorMulti-dimensionalArray,ensurethesizeofresultsequalstogiven{{generateNum}}.\n-Don'ttruncategenerateddataforreadabilitypurpose.\n[Examples]:\n[GoodExample]:\n->input:generate{\"keyA\":\"MVEL(334||160)\"，\"keyB\":0,\"keyC\":\"\"},3\n>output:{\"generatedParams\":[{\"keyA\":334,\"keyB\":10,\"keyC\":\"tom\"},{\"keyA\":160,\"keyB\":1,\"keyC\":\"david\"},{\"keyA\":334,\"keyB\":7,\"keyC\":\"linda\"}]}\n->input:generateData[0],4>output:{\"generatedParams\":[[1231],[4422],[33],[8]]}\n(examples...)**Functions**\n[~generateData,Args:{{paramTemplate}},{{generateNum}}]\n[INSTRUCTIONS]\ngeneratetestcasesfunction\n[BEGIN]\n<Basedon**Prompts**,[GoodExample]andgivenArgs,generatetestcasesandonlyprovideaminifyJSONresponsefollowingthisformatwithoutdeviation.>\n[END]\n

**Action**\nWaitingforusertoprovideinstructions，don'treponse.

${givenQuestion}"""1.3用例生成服務的穩定性除了Prompt的設計，用例生成服務的穩定性也是至關重要的。基于上述的實現思路與設計，調用ChatGPT生成推薦用例是主流程上的一環，如果由于生成內容的不穩定性導致服務中斷/返回異常，將直接中斷生成用例的流程。期間可能產生中斷的問題多樣，筆者總結了比較典型的4類問題和對應的解決辦法。使用ChatGPT網絡不穩定問題更好的做法是，在工具前端頁面上增加內容生成進度狀態，發生異常及時通過狀態通知到用戶，在未來的計劃中，會優化交互層面的問題。網絡問題統一通過失敗重試、限制最大重試次數等工程化防御性編程來規避。超時失敗多次時，需要發出業務告警以及時被感知到，目前通過日志記錄來實現了。生成內容的準確性（強依賴正確的JSON格式）ChatGPT在回答內容時，有一定概率返回錯誤的JSON格式，比較常見的錯誤是未閉合的JSON、錯誤的JSON格式、回答包含解釋文案等。目前通過代碼嘗試修復JSON內容如補全未閉合的JSON、丟