您的位置:軟件測試 >> 測試技術 >> 測試精品文章
自動化功能測試的基本原則
作者:Łukasz Jasi?ski(澤眾軟件原創(chuàng)翻譯) 發(fā)布時間:[ 2014/2/20 9:23:31 ] 推薦標簽:自動化 功能測試 軟件測試
Lukasz Jasinski目前擔任波蘭弗羅茨瓦夫的BLStream質(zhì)量保證工程師。
Lukasz擁有弗羅茨瓦夫科技大學遠程信息學碩士學位和兩個ISTQB高級證書。
他是一個測試自動化專家,對各種編程語言掌握的很好。
Lukasz也對連續(xù)傳遞過程及各類散熱器的可視化質(zhì)量方面有興趣。

  介紹
  每個實行持續(xù)交付的項目,都有生產(chǎn)流水線的元素,如持續(xù)集成和自動化測試。這些測試是在不同層面進行的,從單元測試到冒煙測試再到功能測試。自動化功能測試的優(yōu)點之一是可重復性和可預測的執(zhí)行時間。出于這個原因,它應該作為軟件質(zhì)量的每一個構建之后的指標。功能測試自動化往往會成為一個瓶頸,所以你應該熟悉一下如何創(chuàng)建這樣的測試的基本原則。
  
  首先設計你的測試
  測試集合可以比作盆景樹。
  初的時候,我們照顧樹根和樹干。我們選擇會成長的主要分支,我們每天都細心照料這棵樹并等待它長出健康的葉子。
  我們可以以類似的方式繼續(xù)測試。
  我們建一個將負責應用程序主要功能(例如:開啟)的基類。
  根據(jù)說明,我們先明確將被測試覆蓋的應用程序的主要功能,然后每天我們在執(zhí)行測試的時候都添加更多平行測試。
  每一個支持測試(例如創(chuàng)建一個新的用戶)的方法都需要與測試分離——讓我們在單獨的類里面來實現(xiàn)。
  你應該在包括了應用程序主要功能的目錄里保持類。
  去建一個規(guī)定很多功能共有方法的抽象類是很好的做法。
  如果你正在測試Web應用程序,用頁面對象設計模式。該模式里,一個類及其方法對應了單個頁面的功能或一個大型網(wǎng)頁里單個頁面上的一個元素。
  
  
  無需事事自動化
  自動化花費很多,所以你應該主要測試應用程序的主要功能。
  某些測試可以快速輕松地手動完成,且潛在腳本可能難以實現(xiàn)。
  值得用到自動化的是那些繁瑣的需要被重復很多次的,和那些需要大量數(shù)據(jù)驗證的測試工作。
  
  寫短測試
  在一個或多個測試失敗的情況下,開發(fā)團隊的任何成員都應該能夠輕松地找到錯誤的原因。
  出于這個原因,每個測試方法里應該多有5個斷言,并且每個方法都必須提供的測試操作的完整記錄。
  明智的做法是使用BDD(行為驅動開發(fā))技術,但是當你沒有用一個特定的測試框架時,你應該把接下來的測試步驟放在comments //given //when //then下。
  
  創(chuàng)建獨立測試
  在測試類中的每個方法應該是一個獨立的實體,而不是依賴于其他測試。我們應該能夠在任何時間運行單個測試。否則,這樣的測試用例集將來維護起來會很貴——必須定期跟蹤和更新測試之間的聯(lián)系。
  很多時候,測試需要一定的前提條件來滿足。這些條件不應該用外部方法,應該在試驗開始時運行。如果這些條件和測試類的所有方法一樣,它們可以被放在一開始進行的方法里(例如:在JUnit中被標記為@ BeforeClass)。
   
  關注可讀性
  源代碼應該是自我記錄的,而寫下以下幾行代碼的每個利益相關者應該明白測試在做什么,為什么它被這么寫。盡量避免在源代碼注釋,因為它也必須被更新。這值得花比平常多一點的時間來命名方法,從而使你的代碼更易讀。
  再看看行為驅動開發(fā)技術,每個測試方法都應以單詞“應該”開始,而不是“測試”。
  根據(jù)這一慣例,我們馬上可以明白一個特定的方法測試什么內(nèi)容了,它在分析測試報告時特別有用。
  
  測試必須要快
  正如在本文開頭所提到的,自動化功能測試應該是應用程序質(zhì)量的一個指標。連續(xù)傳遞過程中的每一步都應指明長持續(xù)時間;并且根據(jù)這個概念,開發(fā)團隊應該盡快獲得有關軟件質(zhì)量的反饋。自動化功能測試的持續(xù)時間應不超過幾分鐘。
  對一個非常全面的測試集來說,有必要并行運行測試(經(jīng)常在不同的機器上)。虛擬化在這里可能是非常有幫助的。
  
  創(chuàng)建抗變測試
  常提及自動化功能測試的缺點是其對應用程序中變化的低抵抗性,尤其是在GUI中。
  在Web應用程序中,測試應該能抵抗網(wǎng)站的內(nèi)容的變化。測試應該只驗證功能,這使得它可以在不同的位置運行測試。這并不意味著我們不應該編寫自動化測試來檢查網(wǎng)頁的內(nèi)容。
   如果你已經(jīng)想創(chuàng)建這樣的測試,你應該遵循DDT(數(shù)據(jù)驅動測試)技術。這意味著,檢查內(nèi)容是與源代碼分離開的。
  Web應用程序的頁面布局變化非常頻繁,這已經(jīng)影響到了用戶界面。
  當你設計一個界面時,每個區(qū)段和每個頁面你都應該有一個你可以用來測試的標識符,即使一個網(wǎng)站的層次結構發(fā)生了變化。
  
  自動化測試無法取代人類
  功能自動化測試可以是項目中的主要測試技術,但絕不是的一個。
  自動化測試是可重復再生的,他們的覆蓋范圍總是相同的。
  另一方面,雖然探索性測試是低再生的,但是它們能夠覆蓋自動化測試未觸及的區(qū)域。
  你還應該記住,自動化測試的“綠色”狀態(tài)并不意味著你的應用程序是沒有錯誤的。
  這種情況往往會讓測試員分心,而且有可能會影響測試的準確性。

  版權聲明:本文出自 SPASVO澤眾軟件測試網(wǎng):http://dytjszp.cn/news/html/201422093452.html

  原創(chuàng)作品,轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明,否則將追究法律責任。
相關鏈接:
軟件測試工具 | 聯(lián)系我們 | 投訴建議 | 誠聘英才 | 申請使用列表 | 網(wǎng)站地圖
滬ICP備07036474 2003-2017 版權所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd