10個高頻自動化測試誤區

在自動化測試中，會有一些小白或者只是對自動化感興趣的人誤入自動化測試陷阱中，本篇文章就來總結那些讓人高頻去踩的自動化測試陷阱。

陷阱1：自動化測試工具是萬能的！

        到目前爲止，尚未一款商業測試工具能支持從測試計劃，到測試設計，再到測試執行的自動化。

　　你常常會在某些測試工具的產品推介會、演示會上看到演講者展現測試工具的種種好處、優勢，讓你爲自動化測試激動不已；可是他們每每不會告訴你自動化測試的難點所在，實施自動化測試的複雜度，以及所需的投入有多大。

陷阱2：一個工具能適合全部項目

      到目前爲止，尚未一款工具能夠支持全部操做系統環境。

      你也許會被項目經理要求尋找一款能夠支持全部實時嵌入式系統測試的測試工具，而大家的應用須要跑在各類操做系統環境上，包括VxWorks、Integrity、mainframe、Linux和WindowsXP，編程語言包括Java和C++。

 

陷阱3：引入自動化測試工具後，測試人員的負擔當即減輕

　　引入自動化測試工具後，並不會立刻就減輕測試負擔，事實上一開始每每會增長負擔。

        項目經理每每但願經過引入自動化測試工具來減輕測試負擔。可是經驗代表，在一個新項目中嘗試實施而且有效地應用自動化測試，每每須要通過一條學習的曲線。測試的負擔並不會立刻減輕，可是項目經理卻但願立刻看到自動化測試發揮其威力，但願立刻看到效果。

　　事實上，在一開始的時候，很大可能會增長測試的負擔，由於測試工程師須要一段時間熟悉和掌握測試工具，而與此同時，手工測試一刻也不能中止，所以測試的負擔沒有減輕，反而加劇了。

　　另外，自動化測試須要仔細的分析被測試應用程序，哪些部分須要和可以被自動化實現；而且須要仔細地設計和開發測試腳本。這些無疑都將加劇測試的負擔，尤爲是在初始階段。

陷阱4：引入自動化測試工具後，進度能夠立刻被壓縮

　　上了自動化測試工具以後，總體測試進度不會立刻縮短，相反，在初始階段，每每會對進度形成必定的延誤。

　　另一個誤區是，自動化測試工具能立刻縮短測試時間表。可是因爲測試的負擔在初始階段加劇了，所以很天然地，咱們不能期待進度縮短，相反，在引入自動化測試後，咱們應該給初始階段的進度表預留一些時間。一旦整個自動化測試的流程創建起來以後，咱們就能夠期待自動化測試給咱們的進度帶來積極的影響。

陷阱5：自動化工具是很容易使用的

　　自動化測試工具要求測試人員掌握新的技巧，一般須要額外的培訓。應該制定培訓計劃，投入時間和成本，度過學習的曲線。

　　一般不少工具廠商都會誇大本身產品的易用性，他們會否定所謂的"學習曲線"。工具銷售人員一般鼓吹所謂的"錄製/回放"能夠簡單地記錄下測試工程師的鍵盤和鼠標動做，而後再簡單地回放出來。

　　可是，有效的自動化測試遠遠不只僅是"錄製/回放"那麼簡單。錄製下來的腳本須要手工修改，以便讓其可重用性和可維護性更強一點、更靈活一點，而這些都須要語言和腳本知識。所以他們須要針對工具和內建的腳本語言接受培訓。

 

陷阱6：全部測試均可以被自動化

　　並不是全部的測試均可以被自動化。

　　自動化測試是手工測試的加強。乞求項目中的測試百分百實現自動化是不合理的。在首次引入自動化測試時，最好先驗證一下，工具是否能識別出全部對象和第三方的控件。這對於基於GUI的測試工具來講很是重要，由於這類工具每每在識別一些個性化控件方面有困難，例如一些calendar、spin、grid控件，而這些控件被普遍應用在程序界面中，而且這些控件每每由第三方編寫，大部分測試工具廠商未能跟上他們的發展速度。

　　測試工程師在碰到這種狀況時要麼放棄這部分應用了難以識別的控件的測試自動化，要麼找出一些解決的辦法。

　　另外，還有一些測試是基本上不可能被自動化實現的，例如，測試工程師能夠實現自動化地把文檔發送到打印機的過程，可是檢查打印的效果（是否被正確地打印出來，有沒有越過紙張打印線）這部分則必須人工進行。

若是對軟件測試、接口測試、自動化測試、面試經驗交流。感興趣能夠加軟件測試交流：1085991341，還會有同行一塊兒技術交流。

至於哪些測試用例應該被自動化實現，能夠參考下表決定：

YESNO

測試執行的次數：

測試會被執行屢次嗎？ 

測試會有規律地運行嗎？

例如常常被重用，做爲迴歸測試的一部分或每日構建測試？ 

測試的關鍵程度：

測試覆蓋了軟件功能的最關鍵部分的路徑嗎？ 

測試覆蓋了最複雜的部分嗎？（一般是最容易出錯的部分） 

測試的代價：

若是手工進行測試的話，是否不可能、很是難以執行，例如併發測試、持久性測試、性能測試、內存泄漏測試等。 

測試很是耗時嗎？例如須要檢查成百上千個測試結果輸出。 

測試的類型：

測試須要組合不少輸入，可是共用一個測試步驟嗎？例如同一個功能，用不少不一樣的輸入來驗證。 

測試須要在多種軟硬件配置環境下執行嗎？ 

被測試應用或系統：

測試是在一個穩定的應用程序上執行的嗎？例如功能特性已經基本完成。 

使用兼容的技術和開放的架構 

 

陷阱7：自動化能提供百分百的測試覆蓋率

　　並不是全部內容均可以被自動化地測試到。不可能覆蓋全部可能的輸入，全部可能的組合和路徑。

　　自動化測試能夠增長測試的廣度和深度，可是仍然沒法達到100%的測試覆蓋率，由於沒有足夠的時間或資源。

　　例如一個簡單的登陸界面的測試，假設咱們須要測試它的密碼驗證函數的正確性，密碼長度在6到8個字符之間，每一個字符能夠大寫或小寫，至少包含一個數字，那麼輸入的可能組合將達到2,684,483,063,360個。

　　即便咱們能夠每分鐘建立一個測試，也須要155年來完成全面的測試。所以，不可能窮盡全部可能的輸入的測試。

陷阱8：測試自動化就是錄製和回放

　　僅僅錄製獲得的不是有效的自動化腳本。

　　不少項目經理仍然把測試自動化等同於使用錄製回放工具。而事實上，錄製獲得的腳本一般是不可重用的腳本，腳本中充滿了硬編碼的值，這些值應該被參數化，不然腳本僅僅適用於一個測試狀況，腳本還應該加入條件判斷、循環等結構，以便加強測試腳本的靈活性。

陷阱9：自動化的軟件測試與手工的軟件測試過程同樣

　　自動化測試所須要的技巧與手工測試所須要的技巧是不同的。

　　一般，你的項目經理會被那些測試工具銷售們迷惑，認爲自動化的軟件測試就是簡單地按一個錄製的按鈕，產生測試腳本。而事實上並無那麼簡單。

區分自動化測試所須要的技巧與手工測試所須要的技巧是很是重要的。最重要的是，自動化測試工程師須要掌握軟件開發技巧，沒有接受任何培訓的手工測試人員，或者沒有編程背景的手工測試人員，在實施自動化測試時會碰到不少困難。

陷阱10：忘記了測試的最終目標：找到BUG

　　在自動化測試中，一樣要注意把邊界值分析、等價類分析、基於風險的測試方法、挑選最合適的測試用例等技術應用起來。

　　一般在自動化測試過程當中，咱們都忙着搭建自動化框架和編寫測試腳本，可是咱們每每忘記了測試的原本目的：找bug。

　　項目經理可能僱傭了最好的自動化開發人員來搭建框架，使用了最新最好的自動化開發技術，建立了成千上萬的自動化測試腳本。可是若是BUG仍然被遺漏了，那些本該被自動化測試腳本捕捉到的BUG，結果沒有被捕捉到，那麼你的自動化測試仍然會被認爲是失敗的。

以上內容但願對你有幫助，有被幫助到的朋友歡迎點贊，評論。