讓我們看看要交付的Aur構建版本的數目和復雜度。如果你只是要得到一個普通規模和復雜度的項目的一個構建版本，進行測試自動化可能就沒什么好處。實際上如果只在維護期重用一次(這樣情況很少見)，測試自動化就根本不合理。即使項目本身相對復雜點，如果重構建版本的數目和測試的交付物只限于修補，也不值得花時間進行自動化。
如果該項目將重復地被交付測試，而新的特征集將在多個測試間隔交付．且特征集很復雜，自動化測試可能會有很大益處。普遍接受的看法是自動化測試要花費執行手工測試的3～4倍的時間。如果你能在項目早期預先判定會有超過3～4個重要的可測試構建版本交付給你，那么你的項目就可選擇自動化測試。
沒有奇跡的組合或精確的公式能決定何時應該和不應該執行自動化。以下幾點可供考慮。
·AuT中的特征集本身是簡單還是復雜?
·AuT中的特征集在開發過程和階段中是否會改變很大?
·AuT中的特征集當前是否按需求所述工作?
·AuT中的特征集是否需要大量的數據組合來確認所有業務規則?
·自動化測試使用的測試工具是否能與用于測試目的的特征的所有必要屬性交互?(例如，它是否能像用戶一樣交互?我們是否能從GUI和 子對象獲得所有必要數據?)
如你所見，這些問題很復雜且難判斷�？偟膩碚f，這里有一些實踐準則，可用來決定是否進行自動化測試。
1)如果AUT不復雜且不太大．不要自動化。
2)如果你只將接收幾個(3個或更少)構建版本，不要自動化。
3)如果一個特征不是100％·有效，不要對它執行自動化測試，不管該Aur的規�；驈碗s度如何(你可以為它制定計劃．但不要創建真的自動化測試腳本，除非該特征能夠完成并100％有效)。
4)如果開發周期的時間表很緊，每次交付間隔時間很短，你就沒有時阿自動化。
5)如果一個特征不能通過自動化測試達到100％準確測試，就不要進行自動化了，除非它能節省大量的手工測試時間。這并不意味著特征必須要100％的測試。注意軟件測試幾乎不可能覆蓋到AuT的每個特征。不要妄圖達到這個目標。你執行的測試不應該是主觀的。結果應是可預見的，而且應該能指出通過或失敗的條件。
文章來源于領測軟件測試網 http://www.kjueaiud.com/