在我看來FitNesse具有以下優點:爲什麼在測試高度技術性時使用FitNesse?
讓非技術人員定義的測試數據和預期的結果集(他們是如何定義成功)。非技術人員可能是用戶,產品經理,或可能是軟件質量專家,他們無法訪問源代碼和/或不知道如何使用源語言進行編程。
讓非技術人員運行測試並快速瞭解待測代碼的健康狀況。
我有一個代碼庫,其中「用戶界面」是在一個庫中的API時,所以它是可以理解的,只與誰知道的語言,並具有對API直接訪問其他專業技術人員。我需要選擇一種方法來執行集成測試。我對FitNesse很感興趣,但我不明白爲什麼我會打擾。這些是仍然適用在這種情況下的優點:
它強制標準樣式定義的測試,所以他們很容易被其他軟件專業人士誰需要使用相同的代碼工作理解。
它讓源代碼的作者和維護人員能夠快速查看測試失敗以及失敗的方式。
測試用與源代碼相同的語言編寫,因此不需要單獨的專業知識體系(即perl或python)。
但是,還有其他一些簡單的方法可以實現同樣的目標,而不必離開代碼編輯器。另外,爲了運行測試,我沒有看到將FitNesse測試與自動化系統綁定的方法,例如持續集成服務器使用新版本運行它們。我也沒有看到如何在除開發平臺以外的其他硬件平臺上運行FitNesse測試,因此他們不會發現計時問題。
因此,如果您在「用戶」與您一樣技術性的環境中使用FitNesse,爲什麼?如果您嘗試過並決定反對,您的理由是什麼?
如果您使用FitNesse測試專用於單獨專用硬件(嵌入式系統)的代碼,那麼這是如何工作的?
針對嵌入式系統的自動化測試本身就是一種蠕蟲,特別是當測試需要外部刺激時纔有意義。 (認爲安全氣囊邏輯可以驗證來自多個加速度計的輸入)。我親自通過在PC上測試嵌入式代碼進行單元測試,並且通過功能測試證實它通常在嵌入式系統中工作,運氣最好。但我的項目也沒有預算去購買實驗室的可編程信號發生器和數據記錄器來構建真正的測試單元。 – RBerteig 2010-09-18 01:08:35
在這個系統上自動化測試更容易,因爲沒有移動部件,而且它是linux,所以我可以將系統掛載到我的主機linux系統並運行(交叉編譯)的可執行文件,而無需通過RTOS或非RTOS下載週期-OS系統。不過,當涉及到它時,軟件將世界視爲可以模擬的特定輸入。模擬是否值得投資是項目特有的。在這種情況下,從設備驅動程序開始實現協議棧,測試注意事項與非嵌入式API開發類似。 – jasper77 2010-09-18 01:44:42
我完全同意你的說法,難以融入自動化構建系統是一個嚴重的缺陷 – ossandcad 2010-09-19 22:31:48