QTP自動化測試陷阱

在項目啓動會議上,項目經理告訴大家說將在項目中採用自動化測試工具,然後指定你在下週的會議之前提交一份工具選型報告。你感到很驚訝,項目經理是從什麼地方瞭解到自動化測試的,爲什麼突然對自動化測試這麼着迷,你突然想起幾周前某個工具廠商的銷售人員曾經到公司拜訪……

  你憂心重重,難道項目經理已經掉入了所謂的自動化測試陷阱中?!

  陷阱1:自動化測試工具是萬能的!

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

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

  你的項目經理也許就在這時候開始一步步邁向自動化測試的陷阱。

  陷阱2:一個工具能適合所有項目

  到目前爲止,還麼有一款工具可以支持所有操作系統環境。

  你也許會被項目經理要求尋找一款可以支持所有實時嵌入式系統測試的測試工具,而你們的應用需要跑在各種操作系統環境上,包括VxWorks、Integrity、mainframe、LinuxWindows XP,編程語言包括Java和C++。

  陷阱3:引入自動化測試工具後,測試人員的負擔立即減輕

  引入自動化測試工具後,並不會馬上就減輕測試負擔,事實上一開始往往會增加負擔。

  項目經理往往希望通過引入自動化測試工具來減輕測試負擔。但是經驗表明,在一個新項目中嘗試實施並且有效地應用自動化測試,往往需要經過一條學習的曲線。測試的負擔並不會馬上減輕,但是項目經理卻希望馬上看到自動化測試發揮其威力,希望馬上看到效果。

  事實上,在一開始的時候,很大可能會增加測試的負擔,因爲測試工程師需要一段時間熟悉和掌握測試工具,而與此同時,手工測試一刻也不能停止,因此測試的負擔沒有減輕,反而加重了。

  另外,自動化測試需要仔細的分析被測試應用程序,哪些部分需要和能夠被自動化實現;並且需要仔細地設計和開發測試腳本。這些無疑都將加重測試的負擔,尤其是在初始階段。

  陷阱4:引入自動化測試工具後,進度可以馬上被壓縮

  上了自動化測試工具之後,整體測試進度不會馬上縮短,相反,在初始階段,往往會對進度造成一定的延誤。

  另外一個誤區是,自動化測試工具能馬上縮短測試時間表。但是由於測試的負擔在初始階段加重了,因此很自然地,我們不能期待進度縮短,相反,在引入自動化測試後,我們應該給初始階段的進度表預留一些時間。一旦整個自動化測試的流程建立起來之後,我們就可以期待自動化測試給我們的進度帶來積極的影響。

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

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

  通常很多工具廠商都會誇大自己產品的易用性,他們會否認所謂的"學習曲線"。工具銷售人員通常鼓吹所謂的"錄製/回放"可以簡單地記錄下測試工程師的鍵盤和鼠標動作,然後再簡單地回放出來。

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

  陷阱6:自動化測試是手工測試的增強。乞求項目中的測試百分百實現自動化是不合理的。在首次引入自動化測試時,最好先驗證一下,工具是否能識別出所有對象和第三方的控件。這對於基於GUI的測試工具來說非常重要,因爲這類工具往往在識別一些個性化控件方面有困難,例如一些calendar、spin、grid控件,而這些控件被廣泛應用在程序界面中,並且這些控件往往由第三方編寫,大部分測試工具廠商未能跟上他們的發展速度。

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

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

  至於哪些測試用例應該被自動化實現,可以參考下表決定:

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

  並非所有內容都可以被自動化地測試到。不可能覆蓋所有可能的輸入,所有可能的組合和路徑。

  自動化測試可以增加測試的廣度和深度,但是仍然無法達到100%的測試覆蓋率,因爲沒有足夠的時間或資源。

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

  即使我們可以每分鐘創建一個測試,也需要155年來完成全面的測試。因此,不可能窮盡所有可能的輸入的測試。

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

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

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

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

  自動化測試所需要的技巧與手工測試所需要的技巧是不一樣的。

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

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

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

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

  通常在自動化測試過程中,我們都忙着搭建自動化框架和編寫測試腳本,但是我們往往忘記了測試的本來目的:找bug。

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

  小結

  正在你憂心重重,擔心項目經理一步步邁向自動化測試的陷阱的時候,你看到了這篇文章,你決定拿給項目經理看看,希望他在看完這篇文章之後,對自動化測試有一個新的認識,從而把那隻即將踏入陷阱的腳抽回來!

轉自陳能計,版權歸原創作者所有. http://xqtesting.blog.51cto.com/4626073/808561

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章