史上最全,細數 AIGC 在測試領域落地的困難點

X4VIERLI發表於2023-07-10

一、引言 & 背景

自 2022 年由橫空出世的 ChatGPT 引發的各類 AIGC(Generative AI)爆發以來,人們對其在各個領域的應用潛力產生了極大的興趣。在研發領域,各種研究已經證明了 Github Copilot 在研發效能提高上的積極作用。
在測試領域,AIGC 的爆發引發了對其在軟體測試中的應用可能性的廣泛研究和探討。傳統的軟體測試方法往往需要大量的人力和時間投入,而 AIGC 技術的引入可能為測試領域帶來革命性的變化。AIGC 在測試中的優勢在於其高效的自動化能力、快速的學習能力以及對大規模資料的處理能力。本論文旨在探討 AIGC 在測試領域的應用,並深入研究投入 AIGC 的困難點。透過對 AIGC 在測試中的潛在應用進行分析和討論,我們將探討 AIGC 技術對測試流程和質量的影響,以及它在提高測試效率、減少測試成本和改善軟體質量方面的潛力。

二、AIGC 在測試領域的潛在應用

AIGC 技術在測試領域中有著廣泛的潛在應用,可以為測試流程和質量帶來許多好處。下面將重點介紹 AIGC 技術在測試領域的幾個關鍵應用場景,並與傳統測試行業進行比較,以突出 AIGC 技術的改進和提升之處。

2.1 AIGC 在測試領域的應用方向

2.1.1 自動化測試用例的生成和執行

傳統的測試方法中,測試人員需要手動編寫和執行測試用例,這需要大量的時間和資源。而 AIGC 技術可以透過學習和分析軟體系統的特徵和行為,自動生成測試用例,並自動執行這些用例。AIGC 可以透過大規模資料的學習和推理,發現潛在的測試場景和異常情況,從而提高測試的全面性和覆蓋率。與傳統測試方法相比,AIGC 在測試用例生成和執行方面具有高效性和自動化的優勢,可以大大減少測試時間和成本。

2.1.2 智慧缺陷檢測和自動化迴歸測試

AIGC 技術在缺陷檢測和自動化迴歸測試方面也具有巨大的潛力。傳統的缺陷檢測方法通常需要依賴人工的經驗和規則,但這種方式存在侷限性和主觀性。而 AIGC 可以透過學習軟體系統的正常行為和常見缺陷模式,自動識別和檢測潛在的缺陷。它可以分析測試資料、日誌和報告,快速定位和報告問題,並支援自動化迴歸測試,確保修復缺陷後系統的穩定性。AIGC 在智慧缺陷檢測和自動化迴歸測試方面的能力可以提高測試的效率和質量,減少人工的工作量和錯誤率。

2.1.3 智慧協作和知識庫

AIGC 技術還可以改善測試人員與開發人員、測試人員與使用者之間的協作和互動。在測試過程中,測試人員通常需要與其他團隊成員進行溝通、討論和解決問題。AIGC 可以作為一個智慧的對話系統,與測試人員進行實時互動,並提供即時的反饋和解決方案。測試人員可以與 AIGC 進行對話,提出問題、尋求建議,並從中獲得支援和指導。與傳統的協作方式相比,AIGC 的智慧協作和使用者互動能力可以提供更高效、快速和準確的資訊交流,促進測試團隊的合作和決策過程。

2.2 AIGC 在測試領域的優勢和潛力

1. 高效的自動化能力:

AIGC 具有強大的自動化能力,可以自動生成測試用例、執行測試任務和分析測試結果。相比傳統的手動測試方法,AIGC 可以大幅度減少人工的工作量和時間成本,提高測試的效率和生產力。

2. 快速的學習能力:

AIGC 可以透過機器學習和深度學習的技術,快速學習軟體系統的特徵和行為。它可以從大規模資料中提取模式和規律,並應用這些知識來生成測試用例、檢測缺陷和改進測試策略。這種快速的學習能力使得 AIGC 能夠在短時間內適應不斷變化的軟體系統,並持續提高測試的質量和準確性。

3. 處理大規模資料的能力:

隨著軟體系統規模的增大和複雜性的提高,測試資料的規模也呈指數級增長。AIGC 具備處理大規模資料的能力,可以有效地分析和挖掘測試資料中的潛在問題和模式。它可以從海量的資料中提取有用的資訊,輔助測試人員做出更準確的決策,並幫助發現潛在的缺陷和效能問題。

4. 全面性和覆蓋率的提升:

傳統的測試方法往往受限於測試人員的時間和資源,無法對軟體系統進行全面和完整的測試。而 AIGC 技術可以實現全面性和覆蓋率的提升,透過智慧生成測試用例和自動執行測試任務,發現更多的潛在問題和異常情況。它可以檢測到傳統測試方法可能會錯過的缺陷和漏洞,提高測試的全面性和質量。

5. 智慧協作與人類測試人員的協同工作:

AIGC 可以作為智慧的對話系統,與人類測試人員進行實時互動和協作。它可以提供即時的反饋和解決方案,幫助測試人員理解需求、驗證功能,並共同解決測試中的問題。這種智慧協作能力提高了測試團隊的協同效率和溝通質量,推動測試過程的最佳化和改進。
綜上所述,AIGC 技術在測試領域的應用具有許多優勢和潛力。它可以自動生成和執行測試用例,提供智慧的缺陷檢測和自動化迴歸測試,改善測試人員與團隊成員之間的協作和互動。與傳統測試方法相比,AIGC 技術可以提高測試的效率、準確性和全面性,從而提高軟體質量並滿足不斷增長的測試需求。然而,為了實現這些潛在的應用,我們需要克服一系列的困難點,這將在下一章節進行討論。

三、AIGC 測試領域應用的困難點

儘管 AIGC 在測試領域具有廣泛的潛力,但其投入實際應用也面臨一些困難和挑戰。在本章中,我們將重點討論 AIGC 投入測試領域各個階段所面臨的主要困難點。

3.1 資料需求和資料質量

AIGC 無論是基礎的底座模型還是微調、蒸餾後的小模型,均需要大量的資料來微調和訓練模型。然而,測試領域的測試資料、文件通常是零散的、不成體系的。此外,這些測試資料、文件的質量和準確性也可能存在問題。眾所周知,訓練資料的質量直接關係到底座模型的能力,同時也會影響到依託於大模型 embedding 而構建的知識庫能力,缺乏足夠的高質量資料可能會限制 AIGC 在測試領域的應用。

3.1.1 資料質量

在當今中國網際網路的研發模式下,包括需求分析、系統設計、測試分析、測試執行和釋出上線等階段,不同的階段產生不同的文件,文件的結構、撰寫者水平的高地都據定了這些文件的質量。同時,需求、設計、開發和測試之間錯綜複雜的文件、需求關係也給資料準備帶來了一些困難。

3.1.1.1 文件質量

各家公司針對研發模式下涉及的各個階段的文件均有一些標準化的模版要求,這些模板化的要求從一定程度上幫助提高了文件的結構化程度。但是在這個過程中,每個文件撰寫者針對所描述的內容的理解、清晰程度直接決定了這些文件所產出的訓練語料質量。
各種文件的質量直接影響訓練資料、語料的質量。以下是一些常見文件的高質量要求:

  • 需求文件:準確、清晰、可驗證和完整,以便開發和測試團隊理解和實施相應的需求。
  • 系統設計文件:詳細描述系統的設計邏輯、介面規範和資料結構等,以確保開發和測試團隊能夠準確地理解和實施設計方案。
  • 測試分析文件:需要清晰、全面地描述測試範圍、測試目標和測試方法,以確保測試覆蓋全面、有效性高。
  • 測試執行文件:需要準確記錄測試過程中的問題和結果,以便開發團隊能夠追蹤和修復缺陷。
  • 釋出上線文件:需要清晰、詳細地描述上線計劃、版本變更和使用者指南等,以確保釋出過程順利和使用者能夠正確使用系統。 而高質量的文件在 embedding 資料準備和訓練語料準備中發揮著重要的幫助作用。它們提供了豐富、準確和有代表性的語料庫,幫助模型學習和捕捉語義資訊、建模上下文和語境,並提高模型的效能和泛化能力。中國網際網路在過去的快速迭代中對公司的文件、知識庫質量產生了不可磨滅的負面影響。各類文件的準確性、完整性、時效性、一致性和可訪問性等方面存在問題。而這些問題,會真是且持續的影響 AIGC 訓練、微調、embedding 相關資料的質量,進而影響最終模型的整體能力表現。

3.1.1.2 文件內容關聯性

整理並高效地識別需求、設計、開發和測試文件之間的上下文以及擴散關係是關鍵,它帶來了以下困難和挑戰,特別是在 AI 模型訓練、微調和 embedding 資料準備方面:

  1. 上下文資訊的獲取和整合:不同文件之間的上下文資訊分散在各個文件中,獲取和整合這些資訊可能會面臨困難。需求文件可能包含了業務需求和功能描述,設計文件提供了系統結構和元件資訊,而開發和測試文件包含了具體的實現細節和測試用例。在進行 AI 模型訓練、微調和資料準備時,需要整合這些文件中的資訊,並理解其相互關係,以確保資料的正確性和一致性。
  2. 文件間的資訊不一致性:由於需求、設計、開發和測試文件之間的擴散關係,可能會導致資訊的不一致性。例如,需求文件中規定的功能要求在設計文件中可能有所調整,或者開發過程中的變更未及時更新相關文件。這種資訊不一致性會對 AI 模型訓練、微調和資料準備過程造成困擾,可能導致模型理解的偏差和錯誤的資料準備。
  3. 跨團隊協作和溝通的挑戰:需求、設計、開發和測試文件涉及到多個團隊和角色之間的協作。不同團隊的成員可能對文件的編寫和更新有不同的理解和偏好,導致文件之間存在風格和格式的差異
  4. 變更管理和版本控制:在需求、設計、開發和測試的過程中,可能會發生變更和調整。這些變更可能涉及文件內容的修改和更新,對 AI 模型訓練、微調和資料準備產生影響。
  5. 文件中各類圖內容:需求、設計、開發和測試文件中的各類關係圖、時序圖、流程圖等提供了對系統功能、元件和流程的圖形化表示,而在 AI 模型訓練、微調和資料準備過程中,需要將這些圖形轉換為可處理的文字或結構化資料。

3.1.1.3 中文大模型落後 & 多模態資料能力不足

日常工作中無論是需求、設計、系統分析、測試分析文件中,都不可避免的會引入各類圖表、影像、音訊影片等多模態資料進行資訊展示。往往這些多模態資料中的資訊含量的巨大的,處理這類多模態資料有如下困難點:

  1. 中文語言處理的挑戰:相比於英文,中文具有更為複雜的語言結構和特點,例如字詞的複雜性、語法的靈活性和歧義性等。這給中文文件的處理帶來了挑戰。對於測試領域 AIGC 模型而言,需要具備對中文的良好理解和處理能力,包括中文分詞、命名實體識別、語義解析等任務。
  2. 中文資料集的稀缺性:相比於英文資料集,中文資料集在規模和質量上相對較少。這可能是由於中文的語言複雜性和資料獲取的困難性所導致的。缺乏大規模且高質量的中文資料集限制了測試領域 AIGC 模型在中文文件處理方面的能力提升。
  3. 中文大模型的發展滯後性:相比較現今市面上諸多英文大模型,現在的各種開源、閉源中文大模型無論在語言理解力、模型綜合能力、各種擴充套件泛化能力等方面均存在較大的差距。而這種差距會影響到在測試領域 AIGC 模型的建設,並深刻影響模型的各種能力評分。
  4. 多模態資料處理的挑戰:測試領域的文件內容通常不僅包括文字,還可能包含圖片、音訊、影片等多模態資料。多模態資料的處理需要模型具備對多種資料型別的理解和處理能力,例如影像識別、語音識別、影片分析等。然而,測試領域 AIGC 模型在多模態資料處理方面的能力還不夠成熟,缺乏對多模態資料的綜合理解和處理能力。
  5. 資料標註和質量控制:中文和多模態資料的處理需要大量的標註工作,以構建訓練和評估所需的資料集。然而,中文和多模態資料的標註工作比較困難,需要專業的標註人員和相應的標註工具。同時,保證標註資料的質量也是一個挑戰,需要進行嚴格的質量控制和評估。

3.1.1.4 測試程式碼質量

測試人員編寫的各類 UI 和介面測試程式碼可能存在一些質量問題,而這類程式碼所帶來的質量問題也會影響到後續的質量領域 AIGC 模型的整體能力水平。以下是其中的一些常見問題:

  1. 缺乏可維護性:測試程式碼的可維護性是一個重要的質量指標。如果測試程式碼難以理解、修改或擴充套件,將會增加維護成本並降低測試效率。缺乏良好的程式碼結構、模組化和註釋等因素可能導致程式碼的可維護性問題。
  2. 重複程式碼和冗餘邏輯:重複的程式碼和冗餘的邏輯會增加測試程式碼的複雜性,使其難以維護和理解。測試人員應該避免複製貼上相似的程式碼,而是採用函式、類或其他複用機制來減少程式碼的冗餘性。
  3. 弱錯誤處理和異常處理:測試程式碼應該具備良好的錯誤處理和異常處理機制。如果測試程式碼無法正確處理錯誤和異常情況,可能導致測試失敗的原因難以定位,測試結果的準確性受到影響。
  4. 不充分的邊界測試和覆蓋率:測試人員需要編寫具有充分邊界測試和覆蓋率的測試程式碼。如果測試程式碼只針對典型場景進行測試,而未考慮邊界情況和異常情況,可能無法發現潛在的問題和錯誤。
  5. 缺乏靈活性和可配置性:測試程式碼應該具備靈活性和可配置性,以適應不同環境和需求的變化。如果測試程式碼過於死板,無法適應系統變化或不同配置的測試場景,將限制測試的覆蓋範圍和可擴充套件性。
  6. 缺乏清晰的註釋和文件:良好的註釋和文件可以提高測試程式碼的可讀性和可理解性。測試人員應該編寫清晰的註釋,解釋程式碼的意圖、測試目的和關鍵邏輯,以幫助他人理解和維護程式碼。
  7. 不足的效能和效率:測試程式碼應該具備良好的效能和效率,以便在合理的時間內執行測試。如果測試程式碼執行緩慢或資源佔用過高,將影響整體的測試速度和效率。

3.1.1.5 持續性資料需求

使用強化學習(RL)和高強度人類反饋(RLHF)來改善模型能力是一個有挑戰性的任務,它涉及到資料獲取、訓練和微調等方面的困難。以下是其中的一些困難:

  1. 資料獲取的成本和複雜性:RLHF 需要大量的高質量人類反饋資料來訓練和微調模型。但是,獲取高質量的人類反饋資料通常需要耗費大量的時間、人力和資源。人類評估者需要對模型的輸出進行評估、提供反饋或進行標註,這可能需要培訓和溝通,增加了資料獲取的成本和複雜性。
  2. 人類反饋的主觀性和不一致性:人類反饋的主觀性和不一致性是 RLHF 中的一個重要挑戰。不同的評估者可能有不同的意見和標準,導致反饋的差異。這可能會導致訓練和微調過程中的困惑和不穩定性。為了應對這個問題,需要設計合適的反饋機制和評估準則,以減少主觀性的影響。
  3. 探索與利用的平衡:在 RLHF 中,需要平衡探索和利用的權衡。模型需要在探索新的行為和利用已知的好的行為之間進行平衡,以提高模型的效能。確定合適的探索策略和探索空間是一個具有挑戰性的問題,需要在訓練和微調過程中進行精細調整。
  4. 高度複雜的狀態空間和動作空間:在某些領域和任務中,狀態空間和動作空間可能非常大和複雜。例如,在遊戲或機器人控制領域,狀態和動作可能有很多選擇。這增加了訓練和微調過程中的搜尋空間和計算複雜性。需要使用有效的演算法和技術來處理高維和複雜的狀態空間和動作空間。
  5. 收斂性和訓練的穩定性:RLHF 的訓練過程可能面臨收斂性和訓練的穩定性問題。由於複雜的任務和大規模的模型空間,訓練過程可能需要很長時間才能達到收斂,並且可能面臨不穩定性。需要使用適當的訓練演算法和技術來提高訓練的效率和穩定性,以獲得可靠的結果。

3.1.2 業務語義理解

理解被測業務的語義是一個關鍵的難點。這是因為被測業務通常涉及複雜的業務邏輯、行業規範和特定領域的知識,要準確地理解和表達這些語義對於生成有效的測試資料至關重要。以下是一些涉及被測業務語義理解的難點:

  1. 領域知識的獲取和應用:生成有效的測試資料需要對被測業務的領域知識有深入的理解。這涉及到對業務流程、規則和約束的熟悉,以及對業務術語和行業規範的掌握。獲取和應用領域知識對於準確地理解被測業務的語義至關重要。
  2. 多樣性和複雜性的處理:被測業務通常涉及到多種場景、多樣的輸入和複雜的邏輯。要生成具有廣泛覆蓋和多樣性的測試資料,需要考慮到不同的業務情況和可能的組合。處理多樣性和複雜性可能涉及到處理不同的業務規則和條件,並確保生成的測試資料能夠涵蓋各種業務情況。
  3. 語義的精確性和約束:被測業務中的語義通常需要精確地表達和理解。測試資料的生成需要考慮業務規則、約束條件和預期結果,以確保生成的資料符合業務要求。這包括對業務邏輯和語義的嚴格約束,以生成準確和有效的測試資料。
  4. 上下文和關聯關係的處理:在生成測試資料時,需要考慮上下文和相關的業務關聯關係。業務邏輯可能會依賴於前後步驟、資料的關聯和業務流程的連貫性。要生成具有上下文和關聯關係的測試資料,需要準確地理解業務的語義,並考慮業務資料的一致性和合理性。
  5. 業務變更和演進的適應:被測業務往往是動態的,會隨著時間的推移而發生變化和演進。生成測試資料時,需要及時適應業務的變更,並理解變更對於測試資料生成的影響。這可能涉及到對業務規則和邏輯的更新和調整,以確保生成的測試資料與業務的最新要求保持一致。

3.1.3 資料處理

為了將各領域的文件資料處理成可用於測試領域 AIGC 模型的微調、訓練和 embedding 所使用的資料時,還需要面臨以下的資料處理困難和挑戰:

  1. 資料格式和結構的不一致性:各領域的文件通常具有不同的格式和結構,包括需求文件、設計文件、測試用例等。這些文件可能來自不同的團隊、部門或專案,採用不同的格式和約定。因此,將這些資料進行統一和規範化,使其適用於 AIGC 模型的微調、訓練和 embedding,需要解決資料格式和結構的不一致性。
  2. 大規模資料的收集和清理:各領域涉及大量的文件和各種不同型別的資料。收集和清理這些大規模的資料是一個具有挑戰性的任務。資料收集可能涉及從不同來源和系統中提取資料,而資料清理可能需要處理缺失值、噪音和重複資料等問題。這些過程可能耗費大量的時間和資源。
  3. 資料標註和註釋的複雜性:測試領域的文件可能需要進行標註和註釋,以便用於模型的微調和訓練。例如,測試用例可能需要標註關鍵字、功能、預期結果等資訊。標註和註釋的複雜性取決於文件的型別和領域的特點,可能需要領域專業知識和人工操作,增加了資料處理的難度。
  4. 多樣性和異質性的資料來源:測試領域的資料可能來自不同的系統、平臺和工具,具有多樣性和異質性。將這些異構資料整合和處理成為可用於 AIGC 模型的統一資料表示,需要解決資料的相容性和一致性問題。這可能涉及資料轉換、對映和整合等複雜的資料處理任務。
  5. 資料質量和準確性的保障:測試領域的資料質量和準確性對於 AIGC 模型的微調、訓練和 embedding 至關重要。確保資料的質量和準確性可能需要進行資料驗證、去噪、糾錯和標註質量控制等步驟。這些步驟需要投入人力和資源,並需要領域專業知識來進行資料驗證和校準。
  6. 非結構化資料的處理:測試領域的文件資料通常是非結構化的,包含自然語言文字、圖形、表格等形式。對於 AIGC 模型的微調、訓練和 embedding,需要將這些非結構化資料轉換為結構化的、可供模型處理的形式。這可能涉及到自然語言處理、影像處理和資料解析等技術,增加了資料處理的複雜性。
  7. 多輪對話資料的處理:處理 AI 模型的多輪資料需要考慮上下文的理解和建模、對話的連貫性和一致性、資料標註和註釋的複雜性、資料稀疏性和資料量的要求、對話歷史的管理和建模以及評估和度量的困難性。

3.2 訓練、微調、embedding 所面臨的問題

本輪 AI 浪潮帶來的不僅是對於 AI 在各領域能力的展現,同時也是各類開源 AI 模型底座的百花齊放時刻。而領域模型對於模型底座的能力依賴,底座模型的選型是在推進訓練、微調前至關重要的步驟。目前,有許多開源模型可供選擇,例如 ChatGLM、Vicuna、BELLE 等。而大模型的能力擴充套件離不開各類的配套設施,最典型的例子就是 LangChain。以下將對這些模型以及相關配套設施之間的差距和麵臨的各類困難的闡述。

3.2.1 開源模型之間的差距

不同的開源模型在自然語言處理任務上具有不同的效能和能力。對於測試領域 AIGC 模型,需要依託於底座模型的自然語言理解能力,結合識圖、讀圖等能力,配合程式碼理解、生成的能力才能夠完整的組合出測試領域模型。下圖是各類模型在各項能力上的對比。

以上所示的這些開源模型在各項能力中各有優劣,而擺在大家面前的問題即是如何從這些模型中挑選出能夠作為底座模型進而開展訓練、微調等後續工作。

3.2.2 配套設施之間的差距

除了底座模型的能力差距之外,還有一些相關配套設施和工具可以提供更全面和高效的支援。而這類配套設施、工具的之間的差異,也決定了最終的測試領域 AIGC 模型的落地效果。

  • LangChain:LangChain 是一個用於開發由大語言模型(Large Language Model)驅動的應用程式的框架。 在各項試用、調研中可以發現,對於 LangChain 模板化的 Prompt 要求,適配能力最好的是 ChatGPT,而各類開源模型對於 Prompt 的理解、生成能力均無法趕上 ChatGPT。如果需要進行適配則又增加了另一層的開發、訓練成本,而這個差別將決定了最終模型的應用效果。

  • 各類外掛:ChatGPT 外掛的推出帶來了各類多模態資訊的理解能力,以及對於實時資訊的獲取能力。而各類外掛的差距又將制約最終測試領域 AIGC 模型的落地效果。

3.2.3 訓練、微調面臨的困難

當我們跨過了重重門檻,將資料收集、清洗完成後。在使用這些資料進行質量領域 AIGC 模型訓練、微調、embedding 時,接下來會面臨如下困難:

  1. 計算資源需求:大模型的訓練和微調通常需要大量的計算資源,包括高效能的硬體裝置和大規模的資料集。眾所周知現在 A100 一卡難求,各大公司均在瘋狂採購。而各類大模型底座訓練所面臨的視訊記憶體牆又真實的攔在大家的面前。
  2. 模型調優和引數設定:對於大模型的訓練和微調,調優和引數設定變得更加困難。由於模型規模和複雜性的增加,需要更多的實驗和除錯來找到最佳的引數配置和調優策略。這需要專業的知識和經驗來確保模型的效能和魯棒性。
  3. 遷移學習和領域適應:在使用大模型進行微調時,遷移學習和領域適應是一個重要的問題。大模型在不同領域或任務上的表現可能有所不同,需要進行適當的微調和調整,以提高模型在特定領域或任務中的效能和效果。

3.3 模型能力的評估

目前市面上針對模型底座的各項能力均有較為完善的評估方案,諸如: MMLU (英文)、C-Eval(中文)、GSM8K(數學)、BBH(英文)等。目前市面上還未出現針對測試領域 AIGC 模型能力評估的通用方案,而完成模型訓練後,準確的評估模型的能力,進而判斷是否能夠真實的投入使用是一項新的挑戰。構建模型能力評估體系將面臨一系列的困難和挑戰:

  1. 多樣性的測試場景:測試領域涵蓋了各種各樣的測試場景,包括功能測試、效能測試、安全測試等。評估模型的整體能力需要考慮到這些不同場景的需求和特點。確保評估覆蓋多樣性的測試場景是一個挑戰,需要選擇適當的測試用例和評估指標,並設計合理的評估流程。
  2. 大規模資料的處理:評估測試領域 AIGC 模型的整體能力通常需要使用大規模的測試資料集。收集、處理和標註大規模的測試資料集是一項耗時且資源密集的任務。同時,資料的質量和準確性對評估結果的可靠性至關重要。因此,處理大規模資料和保證資料質量是評估的困難之一。
  3. 評估指標的選擇:選擇適當的評估指標對於評估模型的整體能力至關重要。測試領域的特殊需求可能需要特定的評估指標,如覆蓋率、準確率、召回率、誤報率等。確定合適的評估指標需要綜合考慮測試領域的特點和模型的應用場景,確保評估結果對模型效能有意義。
  4. 人工評估的主觀性:評估測試領域 AIGC 模型的整體能力通常需要進行人工評估。然而,人工評估往往存在主觀性和主觀偏差的問題。不同的評估者可能有不同的判斷和標準,導致評估結果的不一致性。因此,為了減少主觀性的影響,需要建立評估的標準化流程和明確的評估準則。
  5. 模型的可解釋性和信任度:測試領域的 AIGC 模型通常需要具備可解釋性和可信任度。評估模型的整體能力需要理解和解釋模型的決策過程,並確定其是否與測試領域的規則和標準一致。評估過程中需要開發相應的方法和工具,以增強模型的可解釋性和信任度。
  6. 模型的泛化能力:評估測試領域 AIGC 模型的整體能力還需要考慮模型的泛化能力。模型在訓練資料之外的資料上的效能是評估的重要指標。確保模型能夠在新領域、新測試場景或未知資料上具備良好的效能,需要進行額外的評估和驗證。 評估訓練和微調出來的測試領域 AIGC 模型的整體能力面臨多樣性的測試場景、大規模資料的處理、評估指標的選擇、人工評估的主觀性、模型的可解釋性和信任度,以及模型的泛化能力等困難。解決這些困難需要綜合運用資料處理技術、合適的評估指標和方法,並保證評估過程的客觀性和可靠性。

3.4 Model2Test 所面臨的困難

AIGC 在測試領域的一個關鍵應用是自動生成和執行測試用例。然而,自動生成測試用例是一個複雜的任務,需要考慮到不同的測試需求、系統約束和功能覆蓋等因素。此外,自動執行測試用例時還需要解決自動化環境配置和管理的問題。確保 AIGC 能夠生成合理、有效且具有高覆蓋率的測試用例,以及能夠自動執行這些用例,是一個具有挑戰性的任務。在測試領域,測試用例生成是一個重要的任務,而目前比較現實的兩個用例生成方向是 Code2Test 和 Text2Test。以下是對這兩個方向所面臨的困難進一步闡述:

3.4.1 Code2Test

Code2Test 是一種測試用例生成的方法,它透過分析原始碼來自動生成相應的測試用例。該方法主要針對軟體系統的原始碼進行分析,以識別潛在的測試需求和覆蓋範圍。透過深入分析程式碼的結構、邏輯和約束,Code2Test 可以生成符合特定測試目標的測試用例。
Code2Test 的核心思想是將原始碼中的程式碼塊、函式和方法等轉化為測試用例。它可以自動抽取程式碼中的關鍵路徑、邊界條件、異常情況等,以生成具有高覆蓋率和有效性的測試用例。該方法可以大大減少測試人員手動編寫測試用例的工作量,並提高測試的全面性和準確性。
儘管 Code2Test 作為一種測試用例生成方法具有很大的潛力,但在實際應用中仍然存在一些潛在的困難點。以下是對 Code2Test 中可能遇到的困難的闡述:

  1. 程式碼複雜性和多樣性:軟體系統中的原始碼通常是複雜的,涉及到不同的程式語言、框架和庫。這種複雜性和多樣性增加了分析和理解程式碼的難度,從而影響了 Code2Test 的效能和準確性。不同程式語言和框架的語法和語義差異可能需要特殊處理和定製化的分析技術。
  2. 動態程式碼和執行時行為:某些軟體系統可能包含動態生成的程式碼、反射、外掛等機制,這增加了對程式碼分析的複雜性。在這種情況下,靜態程式碼分析可能無法完全捕獲程式碼的行為和路徑。Code2Test 可能需要結合動態分析和執行時監測等技術來處理這些情況。
  3. 隱式邏輯和難以捕獲的約束:程式碼中存在一些隱式的邏輯和難以捕獲的約束,這可能會導致 Code2Test 無法完全捕捉到測試需求和覆蓋範圍。例如,一些約束可能在執行時才能被觸發,或者依賴於外部環境和資料。對於這些情況,Code2Test 需要引入更復雜的分析技術來檢測和處理這些隱含的約束。
  4. 錯誤處理和異常情況:程式碼中的錯誤處理和異常情況是測試中重要的覆蓋範圍,但這些情況往往比較複雜且多變。Code2Test 需要能夠有效地捕獲和處理程式碼中的錯誤路徑和異常情況,以生成具有高覆蓋率和有效性的測試用例。這需要對程式碼中的錯誤處理機制和異常情況進行深入的分析和建模。
  5. 資料依賴和環境依賴:測試用例的生成可能受到資料依賴和環境依賴的影響。某些測試用例可能需要特定的資料輸入或特定的執行環境才能被執行。Code2Test 需要解決資料和環境的相關性,確保生成的測試用例能夠在正確的環境中執行併產生期望的結果。

3.4.2 Text2Test

Text2Test 是另一種測試用例生成的方法,它透過分析文字文件(如需求文件、規範文件、使用者故事等)來生成相應的測試用例。該方法主要關注文字中的語義、關鍵詞和業務邏輯,以從中提取測試需求並生成相應的測試用例。
Text2Test 的關鍵在於將自然語言文字轉化為可執行的測試用例。它使用自然語言處理和文字分析技術,識別和提取文字中的關鍵資訊,然後將其轉化為測試用例的輸入、操作和預期輸出。這種方法使測試人員能夠以自然語言的形式描述測試需求,而不需要編寫繁瑣的程式碼。
雖然 Text2Test 作為一種測試用例生成方法具有很大的潛力,但在實際應用中仍然存在一些潛在的困難點。以下是對 Text2Test 可能遇到的困難的闡述:

  1. 自然語言的歧義性:自然語言文字中存在歧義性,同樣的描述可能有不同的解釋和理解。這使得將自然語言文字準確轉化為可執行的測試用例具有挑戰性。測試用例生成過程中需要解決文字中的歧義性問題,並確保生成的測試用例符合預期和準確反映文字的含義。
  2. 資訊缺失和不完整性:自然語言文字可能存在資訊缺失或不完整的情況,特別是在需求文件或使用者故事中。這會影響測試用例的生成過程,因為缺失的資訊可能導致生成的測試用例不完備或不準確。因此,需要考慮如何處理缺失的資訊,填補資訊的空白,並確保生成的測試用例具有完整性和可靠性。
  3. 大規模文字處理的複雜性:處理大規模的自然語言文字是一項複雜的任務。大規模文字可能包含大量的需求或故事,需要高效的文字分析和處理技術。為了進行高效的測試用例生成,需要採用有效的文字處理演算法和技術,以處理大規模文字並提取其中的測試需求。
  4. 領域特定語言和行業術語:不同的領域和行業可能有其特定的語言和術語,測試用例的生成需要理解和適應這些特定的語言和術語。對於領域特定語言和行業術語的識別和理解是一項挑戰,需要建立專業知識和語料庫,以便正確地轉化為測試用例。
  5. 文字噪聲和冗餘資訊:自然語言文字中常常包含噪聲和冗餘的資訊,如修飾詞、重複詞、不必要的細節等。這些噪聲和冗餘資訊可能會干擾測試用例生成過程,導致生成的測試用例不準確或冗長。在生成測試用例之前,需要進行文字清洗和預處理,以消除噪聲和冗餘資訊,提高測試用例的質量和可讀性。

3.5 與人類測試人員的協作和互動

在 AIGC 生成測試資料的過程中,與人類測試人員的協作和互動是至關重要的。然而,這種協作和互動可能面臨一些困難點。以下是與人類測試人員的協作和互動中可能遇到的困難點:

  1. 語言和溝通障礙:人類測試人員和 AIGC 之間存在語言和溝通的差異。AIGC 可能是基於自然語言的模型,但它仍然受限於語義理解和表達的能力。這可能導致測試人員與 AIGC 之間的溝通困難,理解測試需求、提出問題或解釋決策時存在歧義或誤解。
  2. 誤導性和誤解的風險:AIGC 生成的測試資料可能會引導人類測試人員朝錯誤的方向進行測試,或者產生誤導性的結果。這可能是因為 AIGC 的訓練資料、模型偏差或不完備的測試需求造成的。人類測試人員需要對 AIGC 生成的測試資料進行驗證和評估,並及時糾正可能的誤導或誤解。
  3. 對模型信任的挑戰:人類測試人員可能對 AIGC 的可靠性和準確性存在懷疑和不確定性。這是因為 AIGC 是一個自動化的系統,其決策和預測過程對測試人員來說可能是不可解釋的黑盒子。測試人員需要逐漸建立對 AIGC 的信任,並在需要時進行驗證和審查。
  4. 人機互動的複雜性:人類測試人員與 AIGC 進行實時的人機互動和對話時,可能會面臨複雜的互動過程和反饋機制。測試人員可能需要提供明確的指導、詢問和解釋,以確保 AIGC 能夠生成滿足測試需求的測試資料。這需要測試人員具備良好的溝通和解釋能力,並理解 AIGC 的工作原理和限制。
  5. 人類測試經驗的重要性:雖然 AIGC 具有強大的自動化和智慧化能力,但人類測試人員的經驗和專業知識仍然是寶貴的資源。測試人員的專業判斷、領域知識和質量意識對於測試過程的有效性和準確性至關重要。測試人員需要能夠正確地評估 AIGC 生成的測試資料,並結合自身的經驗進行補充和調整。

3.6 產品形態的困擾

上述所有的困難均集中在了模型這個關鍵能力點上,而假設我們擁有了能力突出的模型後,所需要面臨的下一個困難將是依託於模型,如何構建產品形態來改變當前的業務質量保障工作流、滿足各型別的質量、效能、風險平臺需求。
依託 Embedding 所帶來的知識庫、對話能力構建產品形態是一件顯然意見的事情,目前測試領域 AIGC 模型的最快落地 MVP 即為對話機器人/知識庫應用。這一類應用產品形態所帶來的困擾並不會成為整個投產過程中的重點。
而基於測試領域 AIGC 模型構建各類測試產品時,可能會面臨產品形態選擇困難。這是因為測試領域的需求多樣,涵蓋了各種不同的測試型別和場景。以下是一些可能的困難:

  1. 廣泛的測試需求:測試領域涉及到功能測試、效能測試、安全測試、自動化測試等各種測試型別和子領域。不同型別的測試可能需要不同的功能和特性。
  2. 定製化和靈活性:不同的業務有著不同的測試需求、工作流程以及質量重點。測試產品需要具備一定的定製化和靈活性,以適應不同使用者的特定需求。
  3. 資料和模型整合:測試領域的 AIGC 模型通常需要與各種測試資料和模型進行整合。這可能涉及到資料預處理、特徵工程、模型選擇等方面的問題。產品形態的選擇需要考慮如何與現有的測試資料和模型整合,並提供高效的資料處理和模型整合能力。
  4. 使用者介面和互動設計:測試產品需要提供易於使用的使用者介面和良好的使用者體驗。使用者介面的設計應該符合測試人員的工作習慣和需求,並提供直觀、簡潔的操作介面。
  5. 效果驗證和可信度:測試領域的 AIGC 模型的效果驗證和可信度是關鍵問題。使用者對於測試產品的效果和可靠性有較高的期望。因此,在產品形態的選擇中,需要考慮如何驗證模型的效能、如何提供可解釋性和可靠性,並保證測試結果的準確性和可信度。 產品形態選擇與基於測試領域 AIGC 模型的商業化密切相關。正確選擇產品形態可以為商業化打下基礎,影響商業化策略、推廣活動和盈利模式。產品形態需要與商業化策略相匹配,與推廣活動一體化,以提高產品的市場認知度和盈利能力。正確的產品形態選擇是實現模型商業化成功的關鍵。

3.7 測試工具 SaaS 化的資料可用不可見問題

當測試領域 AIGC 模型構建為 SaaS 服務後,為保護使用者的資料隱私和安全,常常會採用隱私計算技術。這種技術允許使用者在不暴露原始資料的情況下,利用大模型的能力進行處理和分析。而因隱私計算帶來的資料可用不可見問題,以下是對該問題的闡述:

  1. 資料不可見導致模型理解障礙:對於大模型來說,無法直接訪問和觀察原始資料可能導致模型理解障礙。大型模型通常透過學習和分析資料中的模式和特徵來進行訓練和調優。如果資料對模型不可見,模型將無法直接觀察和理解資料的特徵和分佈,從而限制了模型的學習和最佳化能力。
  2. 資料不可見限制模型最佳化和調優:在測試領域 AIGC 模型構建成 SaaS 服務的情況下,使用者上傳的資料經過隱私計算技術的保護,使得原始資料對於大模型不可見。這可能導致模型在進一步最佳化和調優過程中受限。模型無法直接觀察和分析資料的細節,從而限制了模型對資料特徵的挖掘和最佳化。
  3. 缺乏針對性和個性化的調優:大模型的調優通常需要根據資料的特點和分佈進行針對性的調整。然而,當資料對於大模型不可見時,模型可能無法針對性地調整和最佳化。無法直接觀察和理解資料的特徵,可能導致模型在調優過程中缺乏個性化和精細化的調整,從而影響模型的效能和適應性。
  4. 資料取樣和噪聲問題:為了保護資料隱私,經過隱私計算技術處理後的資料可能會被取樣或新增噪聲。這可能導致資料分佈的改變和資訊的丟失,進而影響模型的訓練和調優結果。模型可能受到資料取樣和噪聲引入的影響,無法準確地建模和最佳化資料的真實分佈。

四、寫在最後

本文旨在探討在測試領域投入 AIGC 技術的困難點,並透過對不同方面的討論引發進一步的討論和推動,以推動測試領域 AIGC 模型的廣泛應用和建設。
儘管在測試領域投入 AIGC 技術面臨一些困難和挑戰,但我們堅信 AIGC 大模型在未來將主導測試領域。透過不斷探索和創新,解決資料質量、模型可解釋性、資料處理和模型訓練、評估等等問題,我們可以進一步推動 AIGC 技術在測試領域的廣泛討論和應用。
本文的目的是拋磚引玉,鼓勵更多的討論和研究,促進測試領域 AIGC 技術的發展和應用。我們希望透過共享知識和經驗,推動 AIGC 技術在測試領域的建設,為測試工作提供更高效、準確和創新的解決方案。

相關文章