為什麼每次都要在八種 Linux 環境中測試

在 Linux 上，只說「可以用」並不足夠。

即使是相同的 Ubuntu，系統函式庫與工具套件也會隨版本而異。顯示畫面的方式分為 X11 與 Wayland，韓文輸入法則使用 ibus 或 fcitx5。再加上安裝方式後，需要確認的組合很快就會增加。

能在一台開發者電腦上執行，只代表確認了無數種組合中的其中一種。

所以我在儲存庫裡建立了一座小型實驗室。針對每種環境啟動真正的虛擬機器，並重複執行相同的檢查。結果會彙整到一張表中。

這張表確認的事情很簡單。

應用程式是否能啟動。是否能輸入韓文。

也就是由我們先體驗使用者安裝應用程式後會經歷的最初三十秒。

我把一個環境做成一個檔案

實驗室使用 KVM 虛擬機器，而不是容器。因為容器很難正確重現真實的桌面工作階段與輸入法常駐程式。

下載發行版的雲端映像檔，再透過 cloud-init 進行準備。磁碟會以原始映像檔為基礎建立成覆寫層。發生問題時，可以直接丟棄並重新開始。

一個環境會用一個檔案宣告。檔案中包含發行版、映像檔、工作階段、輸入法，以及要安裝的套件。想確認新的組合時，只要新增一個檔案即可。

輸入方式會因工作階段而異。在 X11 中使用 xdotool，在 Wayland 中則使用 ydotool。Wayland 沒有視窗清單，因此會用資訊站模式的合成器將應用程式以全螢幕顯示。這樣每次都能在相同的位置輸入。

應用程式只會在主機上建置一次。接著將同一個二進位檔原封不動地複製到所有虛擬機器中。

如果在每個環境中重新建置，不同的編譯器與函式庫就會混入結果。發生失敗時，也會更難找出原因。最重要的是，使用者收到的檔案必須與實驗室檢查的檔案相同。

虛擬機器負責檢查，主機負責記錄

在虛擬機器內會確認三件事。

檢查二進位檔是否能執行、視窗是否會出現，以及輸入 dkssud 時是否會顯示 안녕。

每項檢查都會留下一列 JSON。主機會彙整結果、儲存成檔案並製成表格。測得的結果會保留在儲存庫中，以便與下一次檢查比較。

韓文輸入的確認方式會依建置類型而異。在開發用建置中，可以直接確認正在組合的文字。實際發布用建置則沒有這項功能。取而代之的是按下 Enter 並儲存檔案後，再讀取寫入磁碟的內容。

我從這個過程中學到了一件事。決定檢查方法的不是安裝方式，而是應用程式的建置類型。

第一張表告訴了我兩件事

在 Ubuntu 22.04 中，使用系統工具套件建置的應用程式無法開啟。這是因為找不到只有最新版 libadwaita 才有的符號。

另一方面，我也首次確認了在 Wayland 與 ibus 的組合下，可以正常輸入韓文。

根據這項結果，我決定在所有安裝方式中納入相同的工具套件。目前這張八列的表，就是用來確認該決定沒有再次遭到破壞的安全機制。

也有一些問題只有在真實環境中才看得到。與桌面版 Ubuntu 不同，雲端映像檔中沒有 GTK4 輸入模組，也沒有初始輸入模式。因此必須在佈建過程中另外安裝。

ibus 模組必須與發行版中安裝的常駐程式版本相符。每個發行版使用輸入工具的方法也不一樣。因此必須依環境拆分檢查指令碼。

為了節省主機記憶體，同時最多只執行兩台虛擬機器。收到結果後，虛擬機器會立即關閉。

這些都是只閱讀程式碼很難發現的問題。因為即使是相同的程式碼，也會因環境而產生不同的結果。所以我需要這張表。

這張表不承諾效能

表中也會記錄第一個畫面出現前所需的時間與記憶體用量。但不會將它們當作效能指標。

虛擬機器沒有 GPU，會以軟體繪製畫面，而且只在開機後測量一次。每次執行時，數值都可能不同。效能標準會在配備實體 GPU 的主機上測量三次，再以其中位數決定。

在這張表中，該看的不是毫秒數，而是勾選標記。

無法確認的環境會保持空白。Fedora 與 Debian、真實的 GNOME 工作階段，以及檔案選擇等入口網站對話方塊，目前都還不在表中。

不會把尚未確認的欄位填成「大概可以」。

我們無法決定使用者會選擇哪種環境。我們能做的，就是先進入那個環境，試著啟動應用程式。