在軟件測試領域，“猴子測試”一直是一種廣受歡迎的方法，但其也存在著動作隨機的局限性。如果引入大模型，創造一只更聰明的猴子，它可以真正理解應用并像人類一樣與之互動，將會怎樣？

此前，微軟內部團隊打造并開源了下一代跨平臺軟件測試基礎設施 Hydra Lab（ https://github.com/microsoft/hydralab），目前在微軟內部由 Hydra Lab 支持的云測試系統服務與微軟 Phone Link，Link to Windows，Teams，Outlook，Edge 等多個產品線。為創造一只更聰明的猴子，今年 Hydra Lab 接入了 LLM（Azure OpenAI Service），以提高在測試結果分析、探索性測試和測試用例生成方面的能力。

在今年 9 月 3-5 日舉辦的 QCon 全球軟件開發大會·北京站 中，微軟中國高級研發經理步紹鵬將分享 Hydra Lab 的技術思路，以及其對軟件測試智能化的理解與實踐經驗。在大會開始前，InfoQ 對步紹鵬、微軟測試平臺后端技術專家周樂進行了專訪。以下為對話實錄，經編輯。

InfoQ：步老師在今年 9 月舉辦的 QCon 全球軟件開發大會·北京站上的演講主題是《利用大模型打造更聰明的猴子：下一代跨平臺軟件測試基礎設施 Hydra Lab》，為什么會選擇這一主題？

步紹鵬：Hydra Lab 是一個在微軟內打磨了兩年左右的項目，團隊規模約為 10 人，隨著項目不斷發展，更多的小伙伴也參與了該項目，大家在一起踩了很多坑，也得到了領導層的各種支持，非常不容易，在此先對團隊表示衷心感謝。眼下軟件測試已經進入了自動化的時代，但仍存在大量的手工測試。近些年，隨著 AI 技術的不斷發展，我們可以看到軟件測試從自動化向智能化進階的可行性。有一次團隊內部閑聊中，小伙伴們聊到強化學習在游戲領域的應用（當時 flappy bird 還很火），很有意思，我們順勢想到是否可以將這種像人一樣玩游戲的感覺移植到軟件測試中。通過將被測軟件視為一個強化學習中“環境”的概念，如同玩游戲一樣進行交互反饋，不斷增強智能體的探索能力，最終實現智能探索。

在這個過程中，我們參考了很多相關的學術論文，也借助微軟亞洲研究院和 DKI 團隊同事的支持，發現學術研究界也有類似的想法和探索。同時，借鑒軟件測試經典理論中提到的 Monkey Test 概念（即對被測應用輸入一系列的隨機輸入，如同讓猴子隨機敲擊鍵盤或者胡亂點擊手機屏幕，然后觀察軟件在該情形下的表現），我們也進一步探索了 Smart Monkey 的實現，請更聰明的猴子去測試軟件。其中，如何讓“猴子”能“理解”被測應用，是一個關鍵問題。隨著大語言模型技術在工業界的普及，利用該技術賦能這個“猴子”也是我們目前探索實踐的重心。

總的來說，不同于一般的測試框架，Hydra Lab 旨在提供一套測試工程化解決方案，或者說是一套開源云測平臺，我們希望它方便地能夠與 DevOps 系統、編譯系統或 GitHub 等開發工具或平臺結合，給開發團隊帶來低成本的測試全流程方案。同時，我們將智能化引入其中，大家可以在這個項目中看到一些自動化生成測試用例的模塊、方案以及 prompt。工程化和智能化是 Hydra Lab 的關鍵詞，而工程化是智能化賦能的基礎。此次分享中我也會圍繞這兩個問題展開一些案例探討。

InfoQ：對于這波大模型結合軟件開發應用熱潮，您觀察到哪些有趣的趨勢？

步紹鵬：我最近做了很多分享，也參加了不少活動，發現大家在探討大模型與各個領域的融合，比如各種 copilot 產品體驗。目前，雖然大模型的能力令人激動，但還沒有到達 AGI 對一切賦能的階段，我們需要了解它的長處和短處，揚長避短的去應用，而且需要人的配合參與，所以我們更多在講 copilot，而不是 autopilot。目前大模型在內容生成和信息摘要展現出了很好的前景，但如果打算解決一個容錯度低、上下文龐大的問題，可能在關鍵技術產生突破之前，還沒有成熟的方案。

這次的不同之處在于，創新的驅動力大量來源于工業界，而不僅只有學術界，可以從軟件行業的一線開發工程師和實際產品實戰中看到越來越多的創新。這與 AI 模型達到一定規模后產生的能力涌現，能夠執行多目標任務和解決一些通用問題分不開關系。

周樂：從我自身的開發體驗來看主要有兩方面，首先是隨著 GPT、BERT、DALL-E 等預訓練模型的出現，開發人員可以很方便的調用 API 接口去使用這些模型的能力，應用于不同的領域。其次是代碼生成和優化，例如 GitHub Copilot 可以根據代碼上下文給出代碼補全建議，GitHub Copilot Chat 甚至可以通過對話的方式幫忙定位問題、幫助修復 Bug。

Hydra Lab 的技術設計與構建思路

InfoQ：軟件測試的自動化已經極大地改善了測試效率和質量，但隨著軟件系統越來越復雜，測試環境的多樣性增加，傳統的自動化測試面臨不少挑戰，具體主要體現在哪些方面？

步紹鵬：首先，我們的團隊是一個全球協作的團隊，我們的產品 Phone Link 也是一個跨平臺互聯的產品，這從“人”和“事”的層面都增加了我們在測試自動化合作推進的復雜性。我們希望自動化測試能真的全自動，減輕大家寫測試維護測試的負擔，同時可以真的發現問題。此外，我們也想把手機放到云上，建立云測試設備集群，全球共享。現在有 Hydra Lab，只要我們搭建好這個平臺，并配置好相應的編組和權限，真機的地理位置就不再是一個障礙。各地團隊可以突破物理的邊界，在測試上更有效地合作。

其次，UI 自動化測試任務可能會出現一些不穩定的情況，比如突然找不到某個元素，或者出現一些意外遮擋情況。這種情況下的測試任務失敗可能沒有反映真實的質量問題。而有了 Hydra Lab 這樣的平臺級方案，我們可以對這類 flakiness 做識別，重新運行任務，從而提高穩定性。這同時也相當于我們把識別和處理測試不穩定因素的經驗沉淀到了 Hydra Lab 開源工程中，一人貢獻，全社區受益。

另外，從安全和隱私合規性方面考慮，開發團隊如果使用外部第三方云測服務對持續集成系統構建的應用進行測試，由于這個階段構建的應用一般包含大量的 Debug 信息，也可能涉及未公開的新特性甚至商業機密，上傳給外部第三方多少有些顧慮，所以一個開源和可定制的系統在這種場景下非常有價值，換言之，有了 Hydra Lab，開發團隊可以直接利用已經采購的測試設備，搭建一套內部的持續測試的工程化系統，成本上十分劃算，數據流也能完全掌控。

周樂：對于定制化需求方面，再額外補充一點，由于我們的產品 Phone Link、Link to Windows 同時具備 PC 端和手機端，所以需要跨平臺即在 Windows 和手機上同時測試驗證。這個特性需要我們研發內部先實踐支持，這也是 Hydra Lab“與生俱來”的能力。

InfoQ：您帶領團隊推動了云測試平臺 Hydra Lab 的構建和完善，當初構建 Hydra Lab 的契機和思路是什么？

步紹鵬：Hydra Lab 目前剛剛開源幾個月，我覺得構建 Hydra Lab 的契機和微軟的工程師驅動的文化有很大關系。另外我們也借鑒了很多測試領域的經典著作，如：

《軟件測試藝術》：這本書談到了很多測試的名詞和概念，以及如何對測試進行分類和認識。這本書對我們平臺的一些架構和類的關系有很大的影響。

《探索式軟件測試》和《微軟測試之道》：這兩本書都是由微軟員工在 2010 年之前編寫的。它們提出了一些有趣的概念和方法，如“Money Tuor”賣點測試法。這種方法選擇用戶興趣點的串聯路徑進行測試，有利于提高軟件核心功能的覆蓋率。《微軟之道》這本書主要介紹了微軟在軟件質量非常重要的年代所采用的大規模測試方法和嚴格的標準，尤其是生命周期的定義，對云測平臺框架和架構的設計非常有指導性。此外，在智能化的探索上，我們與微軟亞洲研究院 MSRA 和微軟 DKI 團隊也有非常多的合作共創，也共同推進了一些該領域的專利，因此真的非常感謝他們的幫忙。在構建 Hydra Lab 平臺的過程中，我們先解決來自團隊內部和微軟兄弟團隊的實際需求、測試痛點。服務好他們的同時，也伴隨著我們平臺穩定性和功能性的提高。在穩定性問題基本解決之后，我們開始考慮如何結合智能化，將 AI 引入進來。前段時間的開源是一個重要的時間點，同時大語言模型的到來也帶來了新的變革。

InfoQ：Hydra Lab 能夠解決您剛才提到的自動化測試痛點嗎？Hydra Lab 在安全性上有哪些設計？

周樂：對，其實這幾個問題相對容易解決。舉例說明，有了云平臺之后，跨地區的協作就變得容易多了。美國有五臺手機，中國也有五臺手機，我們可以把它們都接入到 Hydra Lab 這個平臺上。而且，中國這邊的團隊可以在美國的五臺手機上部署測試并驗證新的改動，美國那邊的團隊也可以在中國這臺手機上進行驗證。這樣，跨地區的問題就得到了很好的解決。

此外，我們還實現了一些規則和配置性的約定，可以在測試任務中進行配置。在每個測試任務的定義描述中，我們可以配置一些執行規則、前置后置腳本等。我們還基于 OAuth 2.0 實現了簡單的用戶權限系統，可以比較方便地對接用戶服務器，并支持粗粒度的權限管控。

針對跨平臺測試場景，大家在項目里可以找到一個叫 AppiumCrossRunner 的存在，就是通過 Appium 實現跨平臺測試的測試執行器 （Test Runner），在 Hydra Lab 里大家可以找到各類不同平臺的 Runner，也反映了我們對測試執行過程的抽象。

黑盒測試領域的智能化測試探索

InfoQ：和其他同類型平臺相比，Hydra Lab 有哪些技術特性以及差異化優勢？

步紹鵬：我們的項目剛開源幾個月的時間，目前我個人在開源社區里面還沒有找到跟 Hydra Lab 定位相同的項目。在 GitHub 上，Hydra Lab 的核心分類標簽標簽是 Cloud Testing，也就是云測試系統，在這個標簽下 Hydra Lab 是 top 1，在當前比較火的 platform engineering 這個概念下 Hydra Lab 也躋身前五。這也側面說明，當下開源云測平臺同類競品方案很少。

Hydra Lab 提供了 RESTful API 和 Azure DevOps 平臺的集成插件；為了方便安卓開發者集成，也提供了 Gradle 插件。此外，Hydra Lab 還支持安卓和 Windows 平臺應用的性能測試，目前可以提取被測應用的電量和內存消耗數據，并在測試報告中可視化呈現。

最后，智能化測試方面，我們在 Hydra Lab 中已經可以看到很多大語言模型的應用案例，我們近期也合入了很多相關 PR。這樣的開源項目可能目前是僅此一家。

周樂：關于測試生成智能化，最近我們團隊的 Dexter 同學在寫工程化單測生成的方案，已經在 Hydra Lab 里進行 PR code review，歡迎大家參與吐槽拍磚，一起共創。

InfoQ：您提到團隊率先探索了黑盒測試領域的智能化測試用例生成，能具體介紹一下嗎？主要采用了哪些方法？

周樂：我這邊先簡單介紹一下應用的探索過程吧。在探索應用期間，我們會先用屏幕理解模型對當前頁面進行特征提取、UI 分類，然后借助大語言模型做出判斷，對特定頁面元素操作，以求覆蓋盡可能多的頁面或完成特定的用戶場景。

步紹鵬：是的，周樂提到的是基于 UI 探索的智能測試方案，更多是從黑盒視角出發的。而目前大語言模型帶來的測試智能化，尤其是測試生成，大多基于白盒測試的視角，相當于把代碼發給大語言模型，要求它能夠寫出提升代碼測試覆蓋率的單元測試用例。而黑盒測試下的測試遠比白盒復雜，目前還屬于比較前沿的探索。對于黑盒測試，代碼就像一個黑盒，內部邏輯是不可見的，而且應用界面或可執行程序的包體內包括豐富的信息，“上下文”龐大，多模態，很難直接轉換成 prompt。這種情況下，我們怎么讓大語言模型發揮作用呢？

這里 Hydra Lab 團隊 brainstorm 出來的、目前所采用的核心思路是：先探索，再利用。先通過一些策略探索和漫游一個軟件，然后轉換理解，形成數據結構，最后再利用這些數據，作為后續探索和用例生成的基礎。這就相當于通過探索，對黑盒內部邏輯進行了總結提煉，完成了一次“有損壓縮”。這個思路也很像一個測試人員第一次用一個軟件，一定會先探索理解，同時在旁邊整理一個信息圖，這在測試領域被稱為“功能圖”或“狀態圖”，然后再設計用例；這非常自然和接近人的操作。如果我們能用計算機做這件事情，就能自動化地完成探索，繪制狀態圖，并生成測試用例。

“工程師的價值仍非常重要， 未來大有可為”

InfoQ：大模型技術的發展為軟件測試帶來了更多可能性，對于那些于希望在項目中應用大模型做軟件測試的團隊，您會給他們提供哪些建議？

步紹鵬：第一，揮劍訣浮云，面對大模型，我們需要冷靜思考，它有優勢，但目前并不是萬能的。我們需要學習和理解它的特性，跟進它的進展，了解它的“稟賦”，并結合自己遇到的問題找切入點，讓它為己所用；一定避免生搬硬套，有些問題用普通的算法或者經驗規則可能就能夠解決。第二，他山之石可以攻玉，多關注開源方案和數據集，可以多去 Hugging Face 和 GitHub 這類寶藏平臺上逛逛；接下來可能多模態的開源模型是值得持續關注的。第三，重視數據的價值，高能的模型都是優質數據喂出來的，Hydra Lab 項目團隊目前也在探索各場景下用于軟件測試數據集的構建。

InfoQ：您認為大模型在軟件研發工作流中最大的價值是什么？大模型對軟件研發工作流的改變，將會如何影響軟件開發行業的未來發展趨勢？

步紹鵬：近期大模型之所以如此火熱，很大程度上因為它成為了打通工業界和學術界的一個契機。工業界能直接使用大模型涌現出的新能力，并可以大范圍投入應用到用戶場景，而這些應用又可能很容易成為媒體話題，仿佛“叫好又叫座”，給大家新的曙光。AI 架構從 Seq2Seq、Self-Attention、Transformer、GPT 一路走來，實現了模型規模突破后的質變，語言、代碼和圖像的生成都產生了突破。而突破發生后，我們發現很多任務都可以轉化為自然語言，這樣我們就可以將測試用例轉換成語言描述，從而使得大模型可以應用于這些場景。一個需求點，只要能夠用有限的語言描述清楚，大模型就可以成為一個實際的解決方案。

周樂：大模型在軟件研發工作流中的最大價值是可以提高軟件開發的效率和質量。通過使用大模型，軟件開發者可以自動生成代碼，優化代碼，測試代碼，快速生成文檔。

一方面，大模型將使軟件開發變得更加普及和便捷，讓更多人可以參與到軟件創造中來，從而促進軟件創新和多樣化。另一方面，大模型也將給軟件開發帶來一些挑戰和風險，例如如何保證大模型生成的代碼的正確性和安全性，如何處理大模型可能存在的偏見和誤導，如何保護大模型使用的數據的隱私和版權等。

總之，大模型是一種強有力的工具，可以為軟件開發帶來巨大的價值和影響。但是，我們也需要注意其潛在的問題和限制，并合理地使用它。

InfoQ：您在實際的研發過程中是否應用過大模型，使用體驗如何？

步紹鵬：我個人幾乎每天都頻繁使用大模型，也是 GitHub Copilot X 忠實用戶，有一些涉及敏感數據的問題我會用 Azure OpenAI Service 或者 Bing Chat Enterprise，這些 AI 工具能幫助開發者寫郵件、寫代碼，的確可以大幅度地提高生產力；也存在一定的局限性，比如有時會無中生有地調用不存在的 API 等。團隊層面，我們在探索應用 Copilot for Pull Request，工程化的單元測試生成方案等，有一定的成效，生成了一些內容，方便了大家的工作；也有一些挑戰和難點（解決大模型幻覺和不穩定的問題）在攻克。

InfoQ：軟件工程師需要具備哪些素質，才能在大模型的沖擊下仍具備核心競爭力？

步紹鵬：非常好的熱門問題。首先，自信非常重要，不要把自己僅僅看作一個“螺絲釘”或者為自己設限，要跳出初級角色的定位；關注到 AIGC 這個話題的各位已經走在時代的前沿了，未來是跨領域、跨學科創新的時代，擁有復合學科背景的、有獨立思考能力的軟件工程師人才，駕馭了 Copilot 之后必能創造更多的價值，大有可為；同時，嘗試提高自己解決問題的能力和范圍，以解決問題為導向，提升自己的綜合能力，構建自己的跨領域優勢；此外，拆解復雜問題的能力和溝通表達的能力也非常重要：拆解和處理一個項目中的復雜問題往往需要具備很多的領域內知識，并結合環境和形勢，調動邏輯思維進行換位思考，這是大模型不太可能具備的。表達和溝通能力與一個人的同理心相連。有了大語言模型之后，我們可能不僅要和人有同理心，和 AI 對話也要有“同理心”，有必要知其然和知其所以然。而 Prompt Engineering 仿佛就是在探索和構建我們和 AI 的同理心。

周樂：非常認同紹鵬的觀點，有道無術，術尚可求也，有術無道，止于術。在我看來，我們提升的重點不應該局限于某個技術或框架，如何快速學習新的知識，如何在復雜環境下定位解決問題，如何與團隊成員、客戶有效溝通，才是我們應該思考和提升的。