但是，你打算在哪裡進行所有這些測試呢？

QA團隊現在正經歷著一些有趣的事情。人工智慧代理和基於MCP的工具讓測試人員能夠以前所未有的速度編寫自動化腳本。過去需要一周才能完成的腳本編寫工作，現在只需一個下午就能粗略完成。曾經遙不可及的測試覆蓋率如今觸手可及。這確實令人興奮。然而，這也悄悄帶來了一個無人提及的問題。

當測試編寫速度加快時，討論幾乎總是停留在寫作本身：使用哪個工具、如何建立提示、如何獲得可靠的定位符。然而，沒有人停下來思考一個真正決定這些測試最終能否發布的問題。

具體來說，你們打算在哪裡進行所有這些測試？

人工智慧可以在過去編寫十個測試用例的時間內產生數百個新測試用例。這才是真正的槓桿效應。但槓桿效應會放大其底層的一切，包括那些原本設計無法承受如此大負荷的系統。現在發現這一點的團隊並非自動化失敗，而是自動化速度遠遠超過其執行層的處理能力。

樓宇自動化是一個里程碑。但如何可靠、大規模地實施樓宇自動化，則完全是另一個問題。

幾乎所有球隊都遵循的模式

一切通常都始於一些很簡單的事情。某人的辦公桌上擺著幾台安卓設備。兩位工程師共用一部iPhone。發布前，筆記型電腦上執行Appium腳本。這樣就能用。而且在一段時間內，這也足夠了。

然後，測試範圍擴大了。更多的設備型號、更多的作業系統版本、跨瀏覽器覆蓋、多個團隊需要並行運行測試。幾乎一夜之間，限制因素就改變了。問題不再是“我們能否實現自動化？”，而是“我們是否有足夠的執行能力來實際運行這些測試？”大多數團隊對此毫無準備，並非因為他們沒有預見到自動化，而是因為執行能力的問題悄然出現。

「規模」的實際樣子是什麼樣的

到了某個階段，測驗數量本身不再是難題。真正的挑戰在於測試以外的一切：裝置碎片化、作業系統組合多樣、瀏覽器版本差異、跨時區團隊同時使用同一批裝置等等。測試數量持續成長，而基礎架構卻無法應付這種情況。

這還沒算上更複雜的情況：在真實硬體上表現不同的輔助功能流程、僅支援 Wi-Fi 的模擬器上根本無法使用的營運商相關功能，以及無法在桌面端近似實現的 Android Auto 或 CarPlay 車載整合。這些並非邊緣案例，而是實際應用中大多數運作環境都會悄悄失效的組成部分。

這就是執行債務在實踐中的表現：QA團隊停止編寫測試，轉而管理作業系統更新、調試容量衝突，並處理關於測試結果不穩定的投訴——而這些投訴最終被證實是配置問題導致的。原本應該加速發布流程的自動化最終卻產生了新的開銷。

真正的問題不在於擁有設備，而是建構其上的底層架構。

許多團隊已經擁有了自己的設備，這沒問題。設備本身不是問題。問題在於圍繞這些設備構建的一切：編排、整合、存取控制，以及如何在作業系統版本更新和硬體老化的情況下確保所有系統可靠運作。這並非一勞永逸的設置，而是一項需要有人負責的持續性工作。

當團隊試圖自行建立管理層時，它悄悄地變成了第二個工程產品，沒有路線圖，沒有專人負責，而且總是在最糟糕的時刻崩潰。這是沒人願意付出的代價。

擁有設備本身沒問題。真正的成本在於從零開始建立自己的設備管理平台。

合適的平台真正能解決什麼問題

當品質保證負責人開始評估執行平台時，討論通常始於設備可用性和持續集成，也終於設備可用性和持續集成。這些固然重要，但它們只是基準。更重要的問題是，該平台是否能夠滿足應用程式實際測試的全部需求。

首先是部署。有些團隊希望按需使用設備，無需任何採購成本，雲端方案可以滿足這項需求。而有些團隊已經擁有設備實驗室，需要合適的軟體層來實現大規模部署，而本地部署方案則可以滿足這項需求。選擇方案時，不應在便利性和控制力之間做出取捨。一個值得評估的平台應該同時支援這兩種模式，並且無論採用哪種模式，都應具備相同的功能。

BPCE集團法國第二大銀行集團正是採取了這種做法。他們之前在多個地點進行不一致的手動測試，缺乏可追溯性，團隊需要集中執行測試，但又不想放棄自己的設備。透過本地部署，他們現在可以在 102 台設備和 32 個瀏覽器版本上運行 700 名用戶的測試，並且每 5 到 15 分鐘運行一次，全天候進行測試。 閱讀完整的案例研究。

但部署靈活性只是開始。更難評估的——也是大多數團隊直到為時已晚才考慮的——是覆蓋深度。

想想前面提到的那些場景。依賴 TalkBack 或 VoiceOver 的輔助功能流程必須在真機上執行，因為只有在真機上螢幕閱讀器才能準確運作。 CPU 負載、記憶體佔用和電池消耗等實際使用條件下的效能表現，只有在實體硬體上才能體現出來。音訊相關的功能、假定存在 SIM 卡的運營商流程、Android Auto 或 CarPlay 的車載整合：這些都是真實應用程式的重要組成部分，而大多數平台要么不支援它們，要么將它們視為小眾的附加功能。

因此，在評估一個平台時，不要僅限於“它能否運行我們的 Appium 測試”，還要問它能否處理你的團隊一直默默擱置的那些場景。它能否跨地域運行這些測試，而不需要你搭建區域實驗室？它是否能融入你的持續整合 (CI) 管線，使合併的 PR 能夠自動完成建置、上傳、執行和報告等流程，而無需任何人手動幹預？

能夠正確做到這一點的團隊，不僅消除了營運開銷，還實現了以前無法實現的測試覆蓋率，這並非因為編寫測試太難，而是因為沒有可靠的地方來運行這些測試。

現在值得提出的問題

在下次自動化規劃會議之前，在下次迭代評審會議（有人慶祝達到 80% 的覆蓋率）之前，提出一個更困難的問題。

“六個月後，我們將在哪裡進行所有這些測試？”

因為數學是無情的：

100 個測試幾乎可以在任何地方運行。 5,000 個測試需要編排。 50,000 個測試——涵蓋功能、可訪問性、效能、音訊、營運商和連網汽車等場景——需要架構。

最終採用何種形式——雲端、本地部署還是混合部署——取決於您。但所有能夠自信地大規模交付產品的團隊都有一個共同點：他們很早就提出了執行方面的問題，並且能夠給出令人滿意的答案。