搖擺UI測試庫比較：FEST，WindowTester臨等

Question

我並不想重複的問題，比如這一個：

Unit testing framework for a Swing UI

我想知道的是什麼，有沒有人有什麼好的對於各種擺動單元的比較測試庫，如：

• WindowTester Pro
• FEST
• etc ...

我們從來沒有做過任何GUI測試，所以我們並不熟悉可能存在的問題。

在此先感謝。

Answer 1

我曾與住持和一些比較好的經驗FEST，爲Swing UI測試兩個開源庫。

方丈似乎不再支持;這很難進入，因爲錄音機沒有生成足夠好的腳本。實際上，我用記錄器來「學習」腳本語言（XML標籤），最後我用一個簡單的文本編輯器直接編寫腳本。這工作得很好。

FEST採取另一種方法，您必須在Java中編寫您的UI測試。這使它成爲Java開發人員的工具，而Abbot可以被其他人使用（例如QA Team測試人員）。

與這兩個工具的主要問題，並可能與任何UI測試工具，主要有：

• 找到一種方法來唯一標識組件而不使用其位置或文本內容（這可以從一個改變修改爲另一個或難以測試相同的應用程序在不同的Locale
• 到在腳本中使用正確的時間：這些測試工具可以比人類用戶運行你的用戶界面快得多，因此你的用戶界面可能不快對他們來說足夠了（例如，它可能需要幾次zens ms打開一個對話框，甚至更多以從數據庫中填充表格）

對於這兩個問題，儘管存在一個解決方案。

對於組件識別，我強烈建議到名的所有Swing組件的UI（使用Component.setName()）並使用命名策略的是，它可以保證有永遠不會具有相同的名稱可見在2個組件同一時間。在guts-gui庫中，我甚至開發了a strategy that automatically names Swing components，它們作爲字段存儲在面板中，這有助於在應用程序編碼後添加組件名稱。

對於腳本計時，兩個框架在等待對話框出現時接受超時值;考慮到您的測試可能會在不同種類的機器上運行，且功率或多或少的可用功率，您可以選擇最佳的價值。您應該使用足夠大的超時以確保腳本不會報告錯誤否定（例如1秒後出現的對話框，而腳本僅等待500毫秒），但也不會太長，以便在出現真實錯誤（例如，從不出現預期的對話框）。我建議使用2到5秒的超時，這應該適合大多數測試平臺和大多數應用程序。

希望這會有所幫助。

Answer 2

有許多因素需要考慮。記錄/重放，單元測試支持，代碼更改性質，許可，成本，多平臺支持，多種外觀和感覺的測試，支持國際化測試...您的列表是什麼樣的？

關於我們使用的工具的一些評論。

IBM Rational Functional Tester的：

這有記錄腳本和回放能力。它支持驗證點。最重要的一點是不需要更改代碼。 RFT修改JVM並使用java可訪問性擴展來記錄和測試。我們主要用於Java（swing和awt包含大量的2D和對話操作）。它也適用於瀏覽器。

RFT公開了兩種識別GUI元素的機制。一個使用對象映射。這非常薄弱，並且在長期可維護性方面存在困難。使用「查找」API更適合程序員，儘管它需要更改代碼。擁有所有具有正確名稱的對象也有幫助。

完全不適合單元測試。

適用於Windows和Linux。

非常昂貴浮動許可證是12000USD的範圍內，固定許可證將成本的一半。所有節點（記錄測試和運行測試）都需要許可證。定價是近似和舊的，但它會給出一個想法。

在Windows上需要真正的GUI會話。 （這可能是在Linux上與VNC確定）

Jemmy： 我們轉移到jemmy進行新的測試。支持windows，linux。它曾經是免費的，不確定Oracle的計劃是什麼。我們在jemmy之上添加了我們的測試層 - 用於斷言和其他驗證機制。這個'jemmy testing toolkit'的演示文稿有更多關於jemmy的細節。

Answer 3

Jemmy爲UI測試提供了相當不錯的功能。雖然，它不會是JUnit測試的盒子解決方案，它可以很容易地擴展到適合您的目的。

我不確定其他UI測試工具，但與RFT相比，它爲您提供了實際UI對象的句柄（RFT返回代理對象）。根據我的經驗，這可能很方便。

這是一個開源項目（根據CDDL許可），正在積極開發中。

我覺得其他流行（或曾經是??）是jfcUnit。雖然我認爲這不是積極的發展。

Answer 4

在2012 @AlexRuiz，背後FEST的主要開發者決定stop development of FEST

巨星的代碼庫，後來分叉成AssertJ-Swing。

跳過FEST並從AssertJ-Swing開始。