1. 項目概述為什么要在麒麟OS上搞QT自動化測試最近幾年國產化替代的浪潮席卷了各行各業尤其是在一些對自主可控要求極高的領域。作為國產操作系統的代表之一麒麟操作系統包括桌面版和服務器版的裝機量和使用場景正在快速增長。隨之而來的是大量基于QT框架開發的圖形界面應用需要適配和遷移到麒麟平臺上。我手頭就接手了好幾個這樣的項目從工業控制軟件到數據可視化大屏核心邏輯用C界面用QT最終都要在麒麟V10上穩定運行。這就引出了一個非常實際的問題如何保證這些移植或新開發的QT應用在麒麟系統上的質量靠人工點點點效率低、覆蓋不全、回歸測試更是噩夢。自動化測試是必由之路。但你會發現市面上關于Windows或Ubuntu下QT自動化測試的資料不少可一旦切換到麒麟尤其是ARM架構的版本坑就多了起來。環境依賴、庫版本、驅動兼容性每一步都可能讓你掉進坑里。這個項目就是我在多個實際項目中趟平了這些坑之后總結出的一套從環境搭建、工具選型到腳本編寫、持續集成的完整解決方案。它不是什么高深的理論而是一份能直接“抄作業”的實戰指南目標是讓你能在麒麟OS上快速構建起可靠、可維護的QT應用自動化測試能力。2. 整體方案設計與核心思路拆解面對“麒麟OS QT應用”這個組合自動化測試方案的設計需要同時考慮操作系統的特性和QT框架的特點。我的核心思路是分層解耦工具鏈適配持續集成驅動。2.1 分層測試策略不能指望用一個工具解決所有問題。我將測試分為三個層次單元測試針對QT應用中的核心C業務邏輯。這部分通常不涉及GUI目標是驗證函數、類的正確性。在麒麟OS上我們繼續使用經典的Google Test (gtest) 或 Catch2 框架。關鍵在于編譯環境的配置需要確保測試代碼和被測代碼使用相同的麒麟OS原生編譯工具鏈如g和QT庫進行編譯鏈接避免因庫版本不一致導致測試結果失真。GUI功能測試這是自動化測試的核心模擬用戶對圖形界面的操作點擊、輸入、拖拽等并驗證界面反饋。這是挑戰最大的部分因為需要與麒麟OS的桌面環境可能是UKUI或KDE和QT的窗口系統深度交互。集成與端到端測試驗證整個應用在麒麟OS環境下的啟動、運行、與其他系統服務如文件系統、網絡、數據庫的交互是否正常。這部分常結合一些系統級腳本和監控工具。2.2 工具鏈選型與考量工具選型直接決定了方案的可行性和效率。以下是針對各層的工具選擇及背后的原因GUI測試工具Squish 與 AutoIt 的取舍Squish這是功能測試的“專業選手”對QT的支持是原生級的。它能識別QT的內部控件類型如QPushButton、QLineEdit錄制回放穩定對象識別能力強支持多種腳本語言Python、JavaScript等。為什么首選它因為在麒麟OS上我們需要工具能穿透桌面環境直接與QT應用通信。Squish的“hook”機制在這方面做得相對成熟社區和商業支持中也逐漸有了對Linux ARM架構的適配案例。雖然商業軟件有成本但對于復雜、長期的QT項目其穩定性和維護成本優勢明顯。AutoIt在Windows上是神器但在Linux包括麒麟上它依賴于xdotool等模擬鍵盤鼠標的工具屬于“圖像識別”或“坐標點擊”的層面。為什么不作為核心這種方式極其脆弱界面布局一變、分辨率一調、甚至窗口位置挪動腳本就失效了。維護成本極高僅適合作為非常簡單的輔助或臨時方案。基于 accessibility (AT-SPI) 的工具如Linux下的pyatspi。理論上QT應用可以通過Qt Accessibility模塊暴露控件信息。實操難點麒麟OS的桌面環境對AT-SPI的支持完整度需要實測且控件樹的獲取和操作不如Squish直接和穩定開發調試復雜度高。持續集成/持續部署CI/CD工具Jenkins為什么是Jenkins成熟、穩定、插件生態豐富。在信創環境下Jenkins的Java技術棧兼容性好易于在麒麟服務器版上通過Docker或直接安裝部署。我們可以用它來調度自動化測試任務定時觸發、代碼提交后觸發、自動獲取測試報告并通知。關鍵集成點在Jenkins任務中需要調用在麒麟OS上編譯好的測試套件gtest單元測試可執行文件和Squish的測試腳本執行器squishrunner。同時配置好測試結果報告如JUnit格式的收集和展示。輔助工具鏈版本控制Git。無需多言代碼和測試腳本的管理基礎。依賴管理對于項目自身的庫依賴在麒麟OS上要特別注意。優先使用系統包管理器yum或apt取決于麒麟版本安裝的QT和開發庫。對于第三方C庫盡量采用源碼編譯確保與系統架構x86_64或aarch64兼容。虛擬化/容器化VMware或KVM用于創建標準化的麒麟OS測試鏡像。這是保證測試環境一致性的黃金法則。所有測試都在一個干凈的、配置好的虛擬機快照中執行避免因宿主機環境差異導致的問題。3. 環境搭建與核心配置實戰理論說再多不如動手搭一遍。這里以麒麟桌面操作系統V10SP1x86_64版本為例搭建一個基礎的QT5應用自動化測試環境。3.1 基礎開發與測試環境部署首先需要一個安裝了麒麟OS的實體機或虛擬機作為測試機。確保網絡通暢并更新系統。# 1. 更新系統包列表和已安裝的包 sudo yum update -y # 2. 安裝必要的開發工具和庫 # 包括GCC/G編譯工具鏈、CMake、Git等 sudo yum groupinstall -y Development Tools sudo yum install -y cmake git make gcc-c # 3. 安裝QT5開發環境 # 麒麟軟件倉庫通常提供了QT5的包 sudo yum install -y qt5-qtbase-devel qt5-qttools-devel qt5-qtmultimedia-devel qt5-qtscript-devel # 根據你的應用需要可能還需要安裝其他qt5模塊如qt5-qtcharts-devel, qt5-qtsvg-devel等 # 可以通過 yum search qt5- 來查找可用的包 # 4. 驗證QT安裝 qmake -v # 應輸出QT版本信息例如QMake version 3.1 # Using Qt version 5.12.5 in /usr/lib64/qt5/lib注意麒麟OS不同版本、不同架構ARM vs x86的軟件源和包名可能有細微差異。如果yum找不到某些QT5包可能需要檢查是否已正確配置官方的軟件源或者考慮從QT官網下載在線安裝器進行安裝但要注意處理可能的依賴問題。3.2 Squish for QT 在麒麟OS上的安裝與配置Squish的安裝是重中之重也是坑最多的地方。獲取安裝包從Squish官網下載對應Linux版本注意區分x86-64和ARM64的安裝包。通常是一個.run文件。如果你有商業許可確保下載的版本與許可證匹配。安裝前置依賴Squish運行可能需要一些額外的庫。# 安裝X11、OpenGL等相關庫這些是GUI測試的基礎 sudo yum install -y libX11-devel libXext-devel libXrender-devel libXtst-devel mesa-libGL-devel # 安裝字體庫避免測試時因字體缺失導致界面識別問題 sudo yum install -y dejavu-sans-fonts執行安裝# 賦予執行權限并運行安裝程序 chmod x squish-7.1.0-qt57x-linux64.run ./squish-7.1.0-qt57x-linux64.run跟隨圖形化安裝向導進行操作。建議安裝到用戶目錄下如/home/username/squish避免權限問題。關鍵配置 - 設置QT_PLUGIN_PATH這是解決“This application failed to start because no Qt platform plugin could be initialized”錯誤的核心。問題根源Squish的runner或server在啟動時需要加載QT的平臺插件如libqxcb.so來創建GUI環境。如果它找不到插件就會報此錯。解決方案明確告訴Squish QT插件在哪里。你需要找到麒麟系統上QT的插件目錄。# 查找qxcb平臺插件的位置 find /usr -name \*qxcb*\ 2/dev/null # 典型路徑可能是/usr/lib64/qt5/plugins/platforms/libqxcb.so # 或者 /usr/lib/qt5/plugins/platforms/libqxcb.so在啟動Squish IDE或Squishserver之前設置環境變量export QT_PLUGIN_PATH/usr/lib64/qt5/plugins # 然后啟動Squish IDE /home/username/squish/bin/squish 更穩妥的做法將這條export命令添加到你的用戶shell配置文件如~/.bashrc中并source ~/.bashrc使其生效。配置被測應用AUT在Squish IDE中創建新的測試套件。在“被測應用AUT”配置頁“Wrapper”選項至關重要。你需要創建一個簡單的啟動腳本wrapper在這個腳本里設置好所有必要的環境變量然后再啟動你的QT應用。例如創建一個myapp_wrapper.sh#!/bin/bash # 設置QT插件路徑 export QT_PLUGIN_PATH/usr/lib64/qt5/plugins # 設置QT庫路徑如果需要 export LD_LIBRARY_PATH/usr/lib64/qt5/lib:$LD_LIBRARY_PATH # 啟動你的QT應用 /path/to/your/qt/application/myapp在Squish IDE的AUT配置中“可執行文件”就指向這個myapp_wrapper.sh。3.3 單元測試框架集成Google Test對于C業務邏輯的單元測試我們集成Google Test。下載與編譯Google Testgit clone https://github.com/google/googletest.git cd googletest mkdir build cd build # 使用麒麟系統自帶的CMake和GCC cmake .. make -j$(nproc) sudo make install # 將gtest庫安裝到系統目錄通常是/usr/local/lib在CMakeLists.txt中集成gtestcmake_minimum_required(VERSION 3.10) project(MyQtAppTest) # 查找QT5庫 find_package(Qt5 COMPONENTS Core Widgets REQUIRED) # 根據你的需求添加組件 # 查找GTest find_package(GTest REQUIRED) # 你的主應用程序 add_executable(myapp main.cpp mywidget.cpp) target_link_libraries(myapp Qt5::Core Qt5::Widgets) # 你的單元測試可執行文件 add_executable(myapp_test test_business_logic.cpp) target_link_libraries(myapp_test GTest::gtest GTest::gtest_main) # 鏈接你的業務邏輯庫如果有的話 target_link_libraries(myapp_test my_business_logic)編譯與運行在麒麟OS上使用上述CMake配置在項目目錄中mkdir build cd build cmake -DCMAKE_PREFIX_PATH/usr/lib64/qt5/lib/cmake .. # 確保CMake能找到麒麟系統的QT make ./myapp_test # 運行單元測試4. 自動化測試腳本開發與Squish實戰環境搭好了接下來就是編寫真正的自動化測試腳本。這里以使用Squish的Python API為例。4.1 錄制與對象識別對于初學者或快速創建測試用例可以使用Squish IDE的錄制功能。啟動錄制在Squish IDE中連接到你的測試機如果Squish server運行在遠程選擇好測試套件和用例點擊錄制。操作應用在啟動的被測應用上執行一系列操作如點擊按鈕、在輸入框輸入文字、選擇菜單項等。Squish會將這些操作轉換為腳本語句并捕獲操作對象的真實名稱Real Name。理解對象映射錄制結束后查看“對象映射Object Map”。Squish并不是通過易變的文本或坐標來識別按鈕而是通過QT控件的底層屬性如objectName、type、windowTitle等生成一個唯一的標識符。最佳實踐是為你需要操作的QT控件設置唯一的objectName這樣對象識別最穩定。在QT設計師或代碼中pushButton-setObjectName(\loginButton\);在Squish腳本中你就可以用waitForObject(\:loginButton\)來獲取這個按鈕對象。4.2 編寫健壯的測試腳本錄制生成的腳本往往比較脆弱需要人工優化和增強。# 示例一個登錄功能的自動化測試腳本 (test_login.py) import names def main(): # 1. 啟動應用已在Squish IDE的AUT中配置 startApplication(\myapp_wrapper\) # 2. 使用對象真實名稱等待并獲取控件比直接使用文本更穩定 try: username_field waitForObject(names.login_username_Edit) password_field waitForObject(names.login_password_Edit) login_button waitForObject(names.login_login_Button) except LookupError as e: test.fatal(\Failed to find login UI elements\, str(e)) return # 3. 執行操作 mouseClick(username_field) # 點擊獲得焦點 type(username_field, \testuser\) # 輸入用戶名 type(password_field, \password123\) mouseClick(login_button) # 點擊登錄 # 4. 驗證結果 - 等待登錄后窗口出現或某個元素狀態變化 try: # 假設登錄成功后會顯示一個主窗口其objectName為\mainWindow\ main_window waitForObjectExists(names.main_MainWindow, 5000) # 等待5秒 test.passes(\Login successful. Main window appeared.\) # 或者驗證某個歡迎文本 welcome_label waitForObject(names.main_welcome_Label) test.compare(welcome_label.text, \Welcome, testuser!\, \Verify welcome message\) except Exception as e: test.fail(\Login failed or main window did not appear in time\, str(e)) # 可以在這里截圖便于后續分析 screenshot captureScreenshot() test.attach(screenshot, \Screenshot on login failure\)關鍵技巧與注意事項使用waitForObject和waitForObjectExists不要使用findObject。waitForObject會等待對象出現默認最多20秒避免了因界面加載慢導致的腳本失敗。waitForObjectExists同理。善用objectName這是最可靠的識別屬性。在開發QT應用時就與開發人員約定好為關鍵測試控件設置有意義的objectName。處理異步與等待QT應用常有異步操作如網絡請求、文件加載。在關鍵操作后一定要有明確的等待和驗證邏輯而不是簡單的snooze(幾秒)。錯誤處理與日志使用try...except捕獲異常并用test.fatal(),test.fail(),test.passes()等函數記錄詳細的測試結果。captureScreenshot()在失敗時截圖是極其寶貴的調試工具。數據驅動將測試數據如用戶名、密碼組合外置到CSV文件或數據庫使用Squish的數據驅動測試功能讓一個腳本覆蓋多組數據。5. 集成到Jenkins實現持續測試單次運行測試不是終點我們的目標是讓測試自動化地、持續地運行。這里將Squish測試集成到Jenkins流水線中。5.1 Jenkins環境準備在麒麟服務器或另一臺Linux服務器上安裝Jenkins。建議使用Docker方式最為簡單。# 拉取Jenkins LTS鏡像 docker pull jenkins/jenkins:lts # 運行Jenkins容器映射端口和數據卷 docker run -d --name jenkins -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts訪問http://your-server-ip:8080完成初始設置。5.2 配置Jenkins節點關鍵我們的測試需要在麒麟OS測試機上執行因此需要將該測試機配置為Jenkins的代理節點Agent。在Jenkins管理后臺“節點管理” - “新建節點”。選擇“Permanent Agent”命名如“kylin-qt-test-agent”。配置遠程工作目錄例如/home/tester/jenkins_workspace。啟動方式選擇“Launch agent via SSH”。這是最常用的方式。主機填寫麒麟測試機的IP地址。Credentials添加一個SSH用戶名/密碼或密鑰憑據用于Jenkins Master連接到該Agent。主機密鑰驗證策略選擇“Non verifying Verification Strategy”以簡化生產環境建議配置已知主機密鑰。保存后Jenkins會嘗試通過SSH連接到麒麟測試機并自動部署agent程序。確保麒麟測試機的sshd服務已開啟且防火墻允許Jenkins Master的SSH連接。5.3 創建Jenkins Pipeline任務我們使用Pipeline流水線任務因為它更靈活可以用代碼Jenkinsfile定義整個構建測試流程。在Jenkins中新建一個“Pipeline”類型的任務。在“Pipeline”配置部分選擇“Pipeline script from SCM”關聯到你的代碼倉庫包含QT應用代碼和Squish測試腳本。在項目根目錄創建Jenkinsfilepipeline { agent { label kylin-qt-test-agent // 指定在麒麟測試節點上運行 } environment { // 定義環境變量指向測試機上的Squish安裝目錄 SQUISH_PREFIX /home/tester/squish AUT_PATH /home/tester/jenkins_workspace/build/myapp // 被測應用路徑 TEST_SUITE_PATH /home/tester/jenkins_workspace/squish_tests/suite_myapp } stages { stage(Checkout) { steps { checkout scm // 拉取代碼 } } stage(Build QT Application) { steps { sh cd ${WORKSPACE} mkdir -p build cd build # 使用麒麟系統的QT進行編譯 /usr/lib64/qt5/bin/qmake ../MyApp.pro make -j4 # 將編譯好的應用和wrapper腳本復制到指定位置 cp myapp ${AUT_PATH} cp ../scripts/myapp_wrapper.sh ${AUT_PATH}/ chmod x ${AUT_PATH}/myapp_wrapper.sh } } stage(Run Unit Tests) { steps { sh cd ${WORKSPACE}/build # 運行之前集成的gtest單元測試 ./myapp_test --gtest_output\xml:unit_test_results.xml\ // 收集單元測試報告 junit build/unit_test_results.xml } } stage(Run GUI Tests with Squish) { steps { sh # 1. 確保Squish server已啟動如果未作為服務運行 # ${SQUISH_PREFIX}/bin/squishserver --daemon # 2. 設置必要的環境變量特別是QT_PLUGIN_PATH export QT_PLUGIN_PATH/usr/lib64/qt5/plugins export LD_LIBRARY_PATH${SQUISH_PREFIX}/lib:${LD_LIBRARY_PATH} # 3. 使用squishrunner執行測試套件 # --testsuite 指定測試套件路徑 # --reportgen 指定報告格式和路徑 ${SQUISH_PREFIX}/bin/squishrunner \ --testsuite ${TEST_SUITE_PATH} \ --reportgen junit,${WORKSPACE}/squish_results.xml \ --reportgen html,${WORKSPACE}/squish_report // 收集Squish生成的JUnit格式報告 junit squish_results.xml // 歸檔HTML報告便于在Jenkins中直接瀏覽 publishHTML(target: [ reportName: Squish GUI Test Report, reportDir: squish_report, reportFiles: index.html, keepAll: true ]) } } } post { always { // 無論成功失敗都清理可能殘留的進程 sh pkill -f myapp || true # ${SQUISH_PREFIX}/bin/squishserver --stop // 可以在這里添加郵件通知等 } } }這個流水線定義了完整的流程在麒麟測試節點上拉取代碼 - 編譯QT應用 - 運行單元測試 - 運行Squish GUI測試 - 收集并發布測試報告。6. 常見問題排查與實戰心得在實際部署和運行過程中我遇到了無數問題。這里把最典型、最棘手的幾個列出來并附上排查思路和解決方案。6.1 環境與依賴問題問題1Squish啟動被測應用時報錯 “This application failed to start because no Qt platform plugin could be initialized.”排查這是最經典的錯誤。根本原因是Squish或啟動環境找不到QT的平臺插件如libqxcb.so。解決確認插件路徑在麒麟終端執行find /usr -name \*qxcb*\找到確切路徑。設置環境變量在啟動Squish IDE、squishserver或squishrunner的shell中必須設置export QT_PLUGIN_PATH/path/to/your/qt/plugins。使用Wrapper腳本對于被測應用AUT務必使用一個wrapper腳本在其中設置好QT_PLUGIN_PATH和可能的LD_LIBRARY_PATH指向QT庫目錄再啟動你的應用。檢查架構確保Squish版本、QT庫、平臺插件的架構x86_64 vs aarch64一致。問題2Squish可以啟動應用但錄制/回放時無法識別任何控件對象探查器里一片空白。排查Squish的“注入”injection可能失敗了。Squish需要向被測進程注入代碼以獲取控件信息。解決檢查Squish版本兼容性確保你使用的Squish版本支持你QT應用所使用的QT版本如Squish for Qt 5.7-5.15。檢查應用啟動參數有些應用在啟動時帶有-platform參數如-platform xcb需要確保Squish的AUT配置中包含了這些參數。以非root用戶運行盡量避免使用root權限運行Squish和被測應用某些系統安全策略如AppArmor, SELinux可能會阻止注入。在麒麟OS上檢查SELinux狀態getenforce如果是Enforcing模式嘗試設置為Permissivesetenforce 0測試是否是它的問題。查看Squish日志Squish的server和runner會生成日志通常在~/.squish/目錄下。查看這些日志里面常有詳細的錯誤信息。6.2 測試腳本穩定性問題問題3腳本回放時有時成功有時失敗錯誤是找不到對象ObjectNotFound。排查界面加載時間不穩定或者對象屬性動態變化。解決強化等待邏輯將所有的findObject()替換為waitForObject()或waitForObjectExists()并合理設置超時時間。使用更穩定的對象屬性優先使用開發人員設置的objectName。如果只能用文本考慮使用正則表達式或子字符串匹配來應對微小的文本變化。同步點Sync Point在關鍵操作后如點擊一個會觸發長時間計算的按鈕插入一個同步點等待某個特定條件滿足如進度條消失、某個狀態文本出現后再繼續。避免絕對坐標絕對不要依賴mouseClick(x, y)這種基于坐標的操作。問題4測試過程中應用彈出意外對話框如錯誤提示、確認框導致后續腳本失敗。解決異常處理在可能出錯的操作周圍使用try...except捕獲ObjectNotFound等異常。對話框處理函數編寫一個通用的函數在腳本開始時設置setPopupHandler用于處理預期外的彈出框。例如自動點擊“確定”或“取消”并記錄日志。前置條件清理在測試用例開始前確保應用處于一個干凈的狀態。可以編寫一個setUp函數強制關閉可能殘留的應用進程清理臨時文件等。6.3 性能與架構問題問題5GUI自動化測試執行速度慢尤其是大量用例時。解決測試用例設計保持用例獨立但也要設計一些更長的“流程用例”減少不必要的應用重啟啟動耗時最長。使用無頭模式Headless或虛擬幀緩沖如果應用不需要真正的圖形顯示僅做功能驗證可以考慮在無圖形界面的服務器上使用Xvfb虛擬X服務器來運行測試。這可以節省大量GUI渲染資源并允許在無顯示器的環境下執行。# 安裝Xvfb sudo yum install -y xorg-x11-server-Xvfb # 在啟動測試前先啟動Xvfb Xvfb :99 -screen 0 1024x768x24 export DISPLAY:99 # 然后在此環境中啟動Squish runner和你的應用并行測試如果測試套件支持可以利用Squish的分布式測試功能或Jenkins的并行階段在多臺測試機上同時運行不同的測試集。問題6ARM架構如飛騰處理器的麒麟OS與x86環境有何不同核心差異指令集不同所有二進制軟件包包括QT庫、Squish、你的應用都必須使用ARM64aarch64版本重新編譯。實操要點Squish安裝包必須下載Linux ARM64版本的Squish。QT庫在ARM版麒麟OS上通過系統包管理器安裝的QT庫自然是ARM版本。如果你需要自定義QT版本必須從源碼在ARM機器上編譯。第三方庫項目依賴的所有第三方C/C庫都必須在ARM環境下重新編譯。編譯工具鏈使用系統自帶的g/gcc即可它們會生成ARM原生代碼。性能初期可能遇到一些庫的ARM優化不如x86導致應用或測試工具性能稍差需要關注。這套方案不是一成不變的需要根據具體的項目需求、團隊技能和基礎設施進行調整。但它的核心價值在于提供了一條經過驗證的、從零到一在麒麟操作系統上建立QT應用自動化測試能力的路徑。記住自動化測試是一個持續投入和優化的過程早期的環境搭建和腳本編寫投入會在后續無數次的回歸測試中帶來巨大的回報。尤其是在國產化替代這個長期而堅定的趨勢下擁有這樣一套穩定的質量保障體系無疑會讓你和你的團隊更加從容。