我現在很擔心維護一個網站。最常見的情況是在幾次更新之後最終破裂。該網站由我們團隊中的兩名開發人員啓動,然後傳遞給我。我在想,考慮到我已經完成了項目的一半,是否可以進行單元測試和驗收測試。在項目進行到一半時執行單元測試和驗收測試
現在寫測試需要很長時間嗎?這是否可行或者是否有其他測試方法?
我現在很擔心維護一個網站。最常見的情況是在幾次更新之後最終破裂。該網站由我們團隊中的兩名開發人員啓動,然後傳遞給我。我在想,考慮到我已經完成了項目的一半,是否可以進行單元測試和驗收測試。在項目進行到一半時執行單元測試和驗收測試
現在寫測試需要很長時間嗎?這是否可行或者是否有其他測試方法?
引入測試永遠不會太早,你越早開始發現錯誤就越快。
我會從兩個不同的觀點開始測試。首先,如果你有一些相當獨立的Java類用於商業邏輯和數據處理等事情,我會開始爲他們創建JUnit測試,以解決內部代碼問題。
其次,我希望爲業務指定的用例創建測試。這些很可能會在像Selenium這樣的東西中完成,因爲您希望測試遵循用例中指定的與Web站點的交互。在後臺留下本質的JUnit測試。這些是對功能的高級確認。
所有這些都需要時間,管理層不可能讓您除了測試幾個星期或更長時間以外什麼也不做。相反,處理它的最可能的方法就是在你去的時候去做。填寫您的時間報價修復和新功能,以便編寫測試。請記住,寫作測試可能需要50%或更多的時間,尤其是在您開始填寫時。一旦你擁有多種套件,時間會稍微減少一些,但即使如此,一些測試也比代碼更難編寫。但他們是值得的。
我同意德里克。不算太遲。爲您的測試創建框架。可能只有一個集成測試項目,一個用於單元測試。由於你一天比較晚,所以專注於集成測試,以便在部署之前完全測試解決方案。你會從中獲得快速的好處。隨着錯誤的增加,這也將爲您提供基礎架構以更輕鬆地重現它們,並更快地創建修復程序。
另外,甚至不試圖測試一切;相反,隨時建立你的測試套件。專注於現有的錯誤(編寫一個失敗的測試,然後通過測試)以及您懷疑的部分代碼。好的,EXTRA懷疑。 – 2010-09-23 22:26:14