模板
教程
環境
性能
功能
管理
軟件自動化測試陷阱
在項目啟動會議上，項目經理告訴大家說將在項目中采用自動化測試工具，然后指定你在下周的會議之前提交一份工具選型報告。你感到很驚訝，項目經理是從什么地方了解到自動化測試的，為什么突然對自動化測試這么著迷，你突然想起幾周前某個工具廠商的銷售人員曾經到公司拜訪……
你憂心重重，難道項目經理已經掉入了所謂的自動化測試陷阱中?!
陷阱1：自動化測試工具是萬能的!
到目前為止，還沒有一款商業測試工具能支持從測試計劃，到測試設計，再到測試執行的自動化。
你經常會在某些測試工具的產品推介會、演示會上看到演講者展示測試工具的種種好處、優點，讓你為自動化測試激動不已;但是他們往往不會告訴你自動化測試的難點所在，實施自動化測試的復雜度，以及所需的投入有多大。
你的項目經理也許就在這時候開始一步步邁向自動化測試的陷阱。
陷阱2：一個工具能適合所有項目
到目前為止，還么有一款工具可以支持所有操作系統環境。
你也許會被項目經理要求尋找一款可以支持所有實時嵌入式系統測試的測試工具，而你們的應用需要跑在各種操作系統環境上，包括VxWorks、Integrity、mainframe、Linux 和 Windows XP，編程語言包括Java和C++。
陷阱3：引入自動化測試工具后，測試人員的負擔立即減輕
引入自動化測試工具后，并不會馬上就減輕測試負擔，事實上一開始往往會增加負擔。
項目經理往往希望通過引入自動化測試工具來減輕測試負擔。但是經驗表明，在一個新項目中嘗試實施并且有效地應用自動化測試，往往需要經過一條學習的曲線。測試的負擔并不會馬上減輕，但是項目經理卻希望馬上看到自動化測試發揮其威力，希望馬上看到效果。
事實上，在一開始的時候，很大可能會增加測試的負擔，因為測試工程師需要一段時間熟悉和掌握測試工具，而與此同時，手工測試一刻也不能停止，因此測試的負擔沒有減輕，反而加重了。
另外，自動化測試需要仔細的分析被測試應用程序，哪些部分需要和能夠被自動化實現;并且需要仔細地設計和開發測試腳本。這些無疑都將加重測試的負擔，尤其是在初始階段。
陷阱4：引入自動化測試工具后，進度可以馬上被壓縮
上了自動化測試工具之后，整體測試進度不會馬上縮短，相反，在初始階段，往往會對進度造成一定的延誤。
另外一個誤區是，自動化測試工具能馬上縮短測試時間表。但是由于測試的負擔在初始階段加重了，因此很自然地，我們不能期待進度縮短，相反，在引入自動化測試后，我們應該給初始階段的進度表預留一些時間。一旦整個自動化測試的流程建立起來之后，我們就可以期待自動化測試給我們的進度帶來積極的影響。
陷阱5：自動化工具是很容易使用的
自動化測試工具要求測試人員掌握新的技巧，通常需要額外的培訓。應該制定培訓計劃，投入時間和成本，度過學習的曲線。
通常很多工具廠商都會夸大自己產品的易用性，他們會否認所謂的"學習曲線"。工具銷售人員通常鼓吹所謂的"錄制/回放"可以簡單地記錄下測試工程師的鍵盤和鼠標動作，然后再簡單地回放出來。
但是，有效的自動化測試遠遠不僅僅是"錄制/回放"那么簡單。錄制下來的腳本需要手工修改，以便讓其可重用性和可維護性更強一點、更靈活一點，而這些都需要語言和腳本知識。因此他們需要針對工具和內建的腳本語言接受培訓。
陷阱6：所有測試都可以被自動化
并非所有的測試都可以被自動化。
自動化測試是手工測試的增強。乞求項目中的測試百分百實現自動化是不合理的。在首次引入自動化測試時，最好先驗證一下，工具是否能識別出所有對象和第三方的控件。這對于基于GUI的測試工具來說非常重要，因為這類工具往往在識別一些個性化控件方面有困難，例如一些calendar、spin、grid控件，而這些控件被廣泛應用在程序界面中，并且這些控件往往由第三方編寫，大部分測試工具廠商未能跟上他們的發展速度。
測試工程師在碰到這種情況時要么放棄這部分應用了難以識別的控件的測試自動化，要么找出一些解決的辦法。
另外，還有一些測試是基本上不可能被自動化實現的，例如，測試工程師可以實現自動化地把文檔發送到打印機的過程，但是檢查打印的效果(是否被正確地打印出來，有沒有越過紙張打印線)這部分則必須人工進行。
至于哪些測試用例應該被自動化實現，可以參考下表決定：
|
|
|
|
