• 軟件測試技術
  • 軟件測試博客
  • 軟件測試視頻
  • 開源軟件測試技術
  • 軟件測試論壇
  • 軟件測試沙龍
  • 軟件測試資料下載
  • 軟件測試雜志
  • 軟件測試人才招聘
    暫時沒有公告

字號: | 推薦給好友 上一篇 | 下一篇

自動化軟件測試的步驟

發布: 2010-9-26 11:01 | 作者: 不詳 | 來源: 領測測試網采編 | 查看: 181次 | 進入軟件測試論壇討論

領測軟件測試網

  測試庫: 自動化測試的一個通用策略是開發可以在不同測試中應用的測試函數庫。我曾經看到過很多測試函數庫,自己也寫了一些。當要求測試不受被測試產品接口變動影響的時候,采用測試庫方法是非常有效的。不過,根據我的觀察測試庫已經使用的太多了,已經被濫用了,并且測試庫往往設計的不好,沒有相關的文檔支撐,因此,使用測試庫的測試往往很難開展。當發現問題的時候,往往不知道是測試庫自身的問題,還是測試庫的使用問題。由于測試庫往往很復雜,即便在發現測試庫存在問題,相關的維護人員也很不愿意去修改問題。通過前文中的論述,可以得出結論,在一開始就應該保證測試庫設計良好。但是,實際情況是測試自動化往往沒有花費更多的精力去保證一個優良設計的測試庫。我曾經看到有些測試庫中的功能根本不再使用了或僅僅使用一次。這與極限編程原則保持一致,即 " 你將不需要它 " 。這會導致在測試用例之間的代碼出現一些重復,我發現微小的變化可能仍然存在,很難與測試庫功能協調。你可能打算對測試用例作修改,采用源代碼的方式比采用庫的方式更容易修改。如果有幾個測試,他們有某些共同的操作,我使用剪切和粘貼的方式去復制代碼,有的人認為我采用的方法不可理喻。這允許我根據需要修改通用代碼,我不必一開始嘗試和猜測如何重用代碼。我認為我的測試是很容易讀懂的,因為閱讀者不必關心任何測試庫的語法。這種辦法的優勢是很容易理解測試,并且很方便擴展測試套。在開發軟件測試項目的時候,大多數程序員找到與他們打算實現功能類似的源代碼,并對源代碼做修改,而不是從頭開始寫代碼。同樣,在寫測試套的過程中可以采用上述方法,這也是代碼開發方式所鼓勵的方法。我比較喜歡寫一些規模比較小的測試庫,這些庫可以被反復的使用。測試庫的開發需要在概念階段充分定義,并且文檔化,從始至終都應該保持。我會對測試庫作充分的測試后,才在測試中使用這些測試庫。采用測試庫是對所有面臨的情況作權衡的。千萬不要打算寫一個大而全的測試庫,不要希望有朝一日測試人員會利用你的測試庫完成大量的測試,這一天恐怕永遠不會到來。

  數據驅動測試: 把測試數據寫入到簡單表格中,這種測試技術得到了越來越廣泛的應用,這種方法被稱為表驅動( table-driven ),數據驅動 (data-driven) 或者 “ 第三代 ” 自動化測試( "third generation" automation )。這需要寫一個解析器,用來解釋表格中的數據,并執行測試。該測試架構的最主要的好處是,它允許把測試內容寫在具有一定格式的表格中,這樣方便數據設計和數據的檢視。如果測試組中有缺少編程經驗的業務專家參與測試,采用數據驅動測試方法是很合適的。數據驅動測試的解析器主要是由測試庫和上層的少量開發語言寫成的代碼組成的,所以,上面關于測試庫的說明放在這里是同樣合適的。在針對上面提到的少量代碼的設計、開發、測試的工作,還存在各種困難。代碼所采用的編程語言是不斷發展的。也許,測試人員認為他們需要把第一部分測試的輸出作為第二部分測試的輸入,這樣,加入了新的變量。接下來,也許有人需要讓測試中的某個環節運行一百次,這樣加入一個循環。你可以采用其他語言,不過,如果你預料到會面臨上述情況的時候,那么做好采用一些能夠通過公開的渠道獲取的編程語言,比如 Perl,Python 或者 TCL ,這樣比設計你自己的語言要快的多。

  啟發式確認: 我曾經看到很多測試自動化沒有真正意義上的結果校驗,其原因有兩個,一個原因是做完全意義上的自動化測試結果確認從技術上講是很困難的,另外一個原因是通過測試設計規格很難找出自動化測試的預期結果。這很不幸。不過,采用手工校驗測試結果的方法是真正意義上的測試校驗。標準文件( Gold file )是另外一中校驗測試結果的方法。首先,捕獲被測試程序的輸出,并檢視程序的輸出,然后,把輸出信息文檔化,并歸檔,作為標準文件。以后,自動化測試結果與標準文件作比較,從而達到結果校驗的目的。采用標準文件的方法,也有弊端。當產品發生變化,自動化測試的環境配置發生變化,產品的輸出發生變化的時候,采用標準文方法,會上報大量的誤報告警。做好的測試結果校驗方法是,對輸出結果的特定內容作分析,并作合理的比較。有時候,很難知道正確的輸出結果是什么樣的,但是你應該知道錯誤的輸出結果是什么樣的。開展啟發式的結果校驗是很有幫助的。我猜想一些人在自動化測試中設計了大而全的測試結果校驗方法,是因為擔心如果結果校驗漏掉了任何信息,可能導致自動化測試自身出現錯誤。不過,我們在測試過程中往往采用折衷的做法,沒有采用大而全的測試結果校驗方法,這樣就不得不面對少量漏測情況的出現的風險。自動化測試不能改變這種情況的出現。如果自動化工程師不習慣采用這種折衷的方法,那么他必須找相關人員咨詢,尋找一種合適的測試結果校驗策略,這需要有很大的創造性。目前有很多技術可以保證在不產生誤報告警的情況下,找到被測試產品的缺陷。

  把注意力放在通過設計保證測試的可延續性上,選擇一個合適的測試體系架構,你將進一步邁向成功的自動化測試。

  步驟六:有計劃的部署

  在前面的故事中,當自動化工程師沒有提供打包后的自動化測試程序給測試執行人員,會影響到測試執行,測試執行人員不得不反過來求助自動化工程師指出如何使用自動化測試程序。

延伸閱讀

文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/


關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備10010545號-5
技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

国产97人人超碰caoprom_尤物国产在线一区手机播放_精品国产一区二区三_色天使久久综合给合久久97