久久国产成人av_抖音国产毛片_a片网站免费观看_A片无码播放手机在线观看,色五月在线观看,亚洲精品m在线观看,女人自慰的免费网址,悠悠在线观看精品视频,一级日本片免费的,亚洲精品久,国产精品成人久久久久久久

分享

你的組織為自動化測試做好準(zhǔn)備了嗎,?

 xiaohuan 2007-06-22

1. 簡介
本文關(guān)注于一個實施自動化測試框架的組織的主要方面和影響。本文的意圖是提供一些能夠成功的實施自動化測試的指導(dǎo)方針,。

2. 測試自動化的神話
有很多關(guān)于自動化測試的神話,。其中的一些是真實的,而其他的一些是不正確的設(shè)想,,這些不正確的設(shè)想會嚴重的威脅到實施自動化測試的成功,。本文將向大家介紹幾種我們面臨的主要幾種關(guān)于測試自動化的神話:

2.1. 我們在時間上是緊迫的 - 項目已經(jīng)落后了 - 讓我們使用自動化測試吧!
這種情況將不能成為現(xiàn)實,。實際上,,正確的思想應(yīng)該是 - 我們時間急迫 - 我們決不應(yīng)該使用自動化測試。

如果項目已經(jīng)陷入到了麻煩之中,,不建議實施自動化的功能測試,。項目很可能因為需要大量的測試框架的準(zhǔn)備和實施會被托跨。我餓建議將重點放在以下的事情上:

  • 優(yōu)化測試的過程。調(diào)查并建議在目前工作基礎(chǔ)上的測試方法和過程,。建議借鑒 RUP 的相關(guān)思想和過程,。
  • 引進或者使單元/組件測試正式化。這是我們能夠快速獲得受益的很好的方法,。如果正式的組件測試被使用,,我建議可以使用 Rational PurifyPlus 進行單元或者組件測試。根據(jù)我的經(jīng)驗盡早的使用 Rational PurifyPlus 是非常值得的,。在一個引入和 Rational PurifyPlus 的項目中,,通常會在組件的級別得到 百分之三十的性能提升。
  • 僅僅在項目團隊能夠?qū)?下列問題的回答是"Yes"時:
    • 項目能夠被適當(dāng)?shù)耐蒲印?
    • 存在能夠通過實施自動化測試被達到的精確的目標(biāo),。
    • 項目具備建立適當(dāng)?shù)臏y試框架的必要條件,。

    那么,你可以在一個時間緊迫的項目中適當(dāng)?shù)膶嵤y試自動化,。但是根據(jù)經(jīng)驗這種情況是很難發(fā)生的,。

總而言之,我只能說"對不起,,銀彈根本不存在",。

2.2. 測試自動化就是捕獲和回放
在過去的日子中,自動化的測試工具只是被看作是一種捕獲和回放的工具,。當(dāng)前這個神話仍然在很多測試人員的思想中,。而事實上自動化測試已經(jīng)遠不止捕獲和回放這么簡單了。按照成熟度自動化的測試可以被劃分為 5 個級別,。

2.2.1. 級別 1:捕獲和回放

這是使用自動化測試的最低的級別,,同時這并不是自動化測試最有用的使用方式。

好處  
  自動化的測試腳本能夠被自動的生成,,而不需要有任何的編程知識,。
缺點  
  你會擁有大量的測試腳本,同時當(dāng)需求胡子和應(yīng)用發(fā)生變化時相應(yīng)的測試腳本也必須被重新錄制,。
用法  
  當(dāng)測試的系統(tǒng)不會發(fā)生變化時 - 小規(guī)模的自動化。

2.2.2. 級別 2:捕獲,、編輯和回放

在這個級別中,,你使用自動化的測試工具來捕獲你想要測試的功能。將測試腳本中的任何寫死的測試數(shù)據(jù),,比如名字,、賬號等等,從測試腳本的代碼中完全刪除,,并將他們轉(zhuǎn)換成為變量,。

好處  
  測試腳本開始變得更加的完善和靈活,并且可以大大的減少腳本的數(shù)量和維護的工作。
缺點  
  需要一定的編知識,。頻繁的變化可能會引起"意大利面條式的代碼",,并且變更和維護幾乎是不可能的。
用法  
  當(dāng)進行回歸測試時,,被測試的應(yīng)用有很小的變化,,比如僅僅是針對計算的代碼變化,但是沒有關(guān)于 GUI 界面的變化,。

你能夠使用這種技術(shù)通過快速的編制一些測試腳本以檢驗?zāi)愕南敕▉硖剿髂愕念A(yù)定的測試設(shè)計,。當(dāng)我在沒有任何象需求或者設(shè)計模型這樣的文檔的情況下第一次操作一個產(chǎn)品時和我需要獲得一系列內(nèi)部構(gòu)建版本的穩(wěn)定性的第一印象時,我使用過這種技術(shù),。通常如果適當(dāng)?shù)能浖渲霉芾恚⊿CM)與良好的內(nèi)建設(shè)計相結(jié)合時,,使用級別 2 的技術(shù)已經(jīng)足夠了。

2.2.3. 級別 3:編程和回放

這個級別是面對多個構(gòu)建版本的有效使用測試自動化的第一個級別,。你需要在實際的投資開始顯現(xiàn)之前確保團隊和客戶對項目的安全感,。如果沒有對測試自動化工具的適當(dāng)?shù)呐嘤?xùn)測試人員將不具備到達這個級別的能力。在自動化測試工具中的所有測試功能都必須被很好的理解,,并且要掌握測試腳本語言的知識,。

好處  
  你確定了測試腳本的設(shè)計。適當(dāng)?shù)脑O(shè)計是必要的,。編碼的習(xí)慣必須是適當(dāng)?shù)?。使用與開發(fā)中相同的編碼習(xí)慣是非常好的。這將開始搭建起測試和開發(fā)之間的橋梁,。

在項目的早期就可以開始自動化的測試,。你能夠在項目的早期就開始進行測試腳本的設(shè)計。與開發(fā)人員交并調(diào)查他們認為可能會存在問題的區(qū)域,。確保了開發(fā)人員關(guān)注在獲得能夠被測試的方案上,。
缺點  
  要求測試人員具有很好的軟件技能,包括設(shè)計,、開發(fā)等,。
用法  
  大規(guī)模的測試套件被開發(fā)、執(zhí)行和維護的專業(yè)自動化測試,。

級別 3 使你能夠使用自動化測試并構(gòu)建不同的回歸測試(重用已有的自動化測試用例),。根據(jù)我的經(jīng)驗在看到更多切實的回報之前,為了達到這個級別,,有大量的工作和影響項目的活動必須被做,。因此快速的建立和證明自動化測試的價值是至關(guān)重要的。找到乏味的測試(例如,,邊緣測試和特定的功能測試用例是首先進行自動化測試的良好候選者),。首先創(chuàng)建少量的能夠測試一些基本功能(比如,,登陸和創(chuàng)建用戶等)的測自動化測試用例。

2.2.4. 級別 4:數(shù)據(jù)驅(qū)動的測試

對于自動化測試來說這是一個專業(yè)的測試級別,。你現(xiàn)在要利用測試工具提供的所有的測試功能,。你擁有一個強大的測試框架,這個測試框架是基于能夠使你根據(jù)被測試系統(tǒng)的變化快速創(chuàng)建一個測試腳本的測試功能庫的,。維護的成本相對是比較低的,。你在你的測試中會使用到大量真實的數(shù)據(jù)。

好處  
  你能夠維護和使用良好的并且有效的模擬真實生活中數(shù)據(jù)的測試數(shù)據(jù),。
缺點  
  軟件開發(fā)的技能是基礎(chǔ),,并且需要訪問相關(guān)的測試數(shù)據(jù)。
用法  
  大規(guī)模的測試套件被開發(fā),、執(zhí)行和維護的專業(yè)自動化測試,。

級別 4 要求一些非常良好的測試數(shù)據(jù)。一個測試人員必須要花費一些時間來識別在哪里收集數(shù)據(jù)和收集哪些數(shù)據(jù),。使用現(xiàn)實生活中的數(shù)據(jù)是最基本的以從測試中得到完全的回報,。使用適當(dāng)?shù)臄?shù)據(jù)將為你提供通常僅僅在項目的后期才會發(fā)現(xiàn)的或者是有客戶發(fā)現(xiàn)的錯誤的能力。現(xiàn)在你能夠通過使用現(xiàn)實的數(shù)據(jù)開運行大量的測試,。

2.2.5. 級別 5:使用動作詞的測試自動化

這是自動化測試的最高級別,。主要的思想是將測試用例從測試工具中分離出來。這個級別要求有一個具有高技能測試人員測小的團隊,,這些測試人員能夠?qū)y試工具的非常深層次的知識與他們具備的較深的編程能力結(jié)合起來,。這個團隊負責(zé)在測試工具中生成并維護測試的功能性,能夠使測試工具從外部的來源,,比如 excel 表或者數(shù)據(jù)庫中執(zhí)行測試用例,。這種測試概念最初是由 CMG 開發(fā)的。與 CMG 方案相比,,其他的可能的開放源碼的方案有被 Carl Nagle 和SAS Institute 開發(fā)的 DDE,。使用 DDE 的概念,關(guān)注點是當(dāng)在Excel表中創(chuàng)建測試用例的時候,,放置使用包括被使用的特定動作詞語的一些類型的模板,。執(zhí)行的過程是從 Excel 表中讀取測試用例,并將測試用例轉(zhuǎn)換成為測試工具能夠理解的形式,,然后使用不同的測試功能來執(zhí)行測試,。

這個概念變得越來越流,因為測試與用例一起使用是非常有用的,。

好處  
  測試用例的設(shè)計被從測試工具中分離了出來 - 關(guān)注在設(shè)計良好的測試用例上。允許快速的測試用例的執(zhí)行和基于用例的更好的估計,。
缺點  
  需要一個具有工具技能和開發(fā)技能的測試團隊,,以提供并維護測試工程(框架),。
用法  
  專業(yè)的測試自動化將技能的使用最優(yōu)化的結(jié)合起來

如果工具不具備使用內(nèi)建的對象映射的可能性,那么這個方案對于消除與 GUI 相關(guān)的大部分維護成本是優(yōu)秀的,。在一些組織中已經(jīng)創(chuàng)建了這種方案,,并且他們其中的一些已經(jīng)實現(xiàn)了高度的自動化(60%),并且他們都得到了巨大的回報,。如果測試框架是適當(dāng)?shù)?,我們能夠使?excel 來生成實際的測試用例。

這個級別對于那些按照正規(guī)基礎(chǔ)使用用例的組織或者項目來說是非常優(yōu)秀的,。有多少測試用的估計是被需要的,,并且當(dāng)用例適當(dāng)時需要做的工作也是非常簡單的。你可以集中時間來生成第一個包含被需要的"對象映射"的測試用例(主流程),。依靠被測試應(yīng)用的復(fù)雜程度,,通常這會花費大約半天到一天的時間。后續(xù)的被需要的每一個測試用例大概會花費 15 到 20 分鐘的時間,,因為通常多數(shù)的測試用例可以復(fù)制已有的測試用例,,并對其進行必要的修改,通常這種修改是有限的,。動作詞語框架能夠通過使用用例使緊密的并行測試用例的開發(fā)變得可能,。

2.3. 我們不需要培訓(xùn)!
我們所有的人都在某一些方面具有一定的經(jīng)驗,,我們沒有時間能夠花費在使用新工具的培訓(xùn)上,。當(dāng)一個對自動化工具還不是很熟悉的組織或者項目團隊開始實施自動化測試時,培訓(xùn)和指導(dǎo)是至關(guān)重要的,。如果我們允許組織或者項目團隊在沒有關(guān)于應(yīng)該如何做的任何知識的情況下實施自動化的測試,,那將肯定會以失敗告終。用于實施自動化測試方案的預(yù)算會被超出,,測試會被延誤并且更壞的情況是自動化測試將被放棄,。組織和項目團隊需要盡量避免一些認識上的缺陷,尤其是自動化測試的維護成本和當(dāng)測試人員嘗試和確認工具如何工作時產(chǎn)生的挫敗感,。你需要確保你的測試過程是適當(dāng)?shù)?- 如果測試過程是不合理的,,引入自動化測試只會給軟件組織或者項目團隊帶來更大的混亂。因此,,我建議希望實施自動化測試方案的組織或者項目團隊?wèi)?yīng)該在實施之前建立"訓(xùn)練營",,并將重點放在培訓(xùn)測試團隊能夠很好的利用一個原型的項目上。

為第一個原型項目制定一個實施計劃,,下面包括原型項目的最小化的描述:

  • 當(dāng)先狀態(tài)
  • 我們希望實現(xiàn)什么 - 建立成功的因素
  • 期待的回報(第一次自動化測試工作被期望驗證什么)
  • 找到一個"簡單的"測試的痛處并盡力的通過自動化測試解決它,,這可以被作為在同一時間上使測試運行在多個平臺上的樣例
  • 說明被需要的資源和時間
  • ......

一開始你就要大聲的說出成功的信心 - 讓人們了解你所展示的進展。這將吸引更多的關(guān)注和資源,。

2.4. 我們必須 100% 的自動化
從管理的角度來說,,100% 的自動化目標(biāo)只是一個從理論上可能達到的,,但是實際上達到 100% 的自動化的代價是十分昂貴的。

一個 40-60% 的利用自動化的程度已經(jīng)是非常好的了,。達到這個級別以上將增加測試相關(guān)的維護成本,。由于對每一個構(gòu)建版本的需求變化的復(fù)雜度,你將花費更多的時間在變更測試用例上以使他們能夠正確的運行,。在這種情況下,,通過告知管理層 100% 的自動化目標(biāo)是相當(dāng)昂貴的來確立一個合理的期望值才是明智之舉。對于決定自動化一個測試用例的一般規(guī)則是這個測試用例必須被運行 4 次以上,。這個數(shù)字是基于用戶對測試工具有良好的技能并且有一個良好的測試框架的,。如果情況不是這樣的化,整個數(shù)字能夠是 10-20次或者更高,。一個例子,,在一個項目中測試人員花費和兩周的時間將手工測試的 23天的任務(wù)轉(zhuǎn)換成了自動化測試的用例。在完成使,,項目能夠在 4 個小時在多個平臺上運行相同數(shù)量的測試用例,。

2.5. 測試框架
測試框架對于產(chǎn)生成功的測試自動化的適當(dāng)基礎(chǔ)是重要的。很多考慮必須被解決以使測試自動化更加有效地被使用,。重點必須在:

  • 維護成本
    維護成本是成功的使用自動化測試的最重要的問題之一,。維護成本直接聯(lián)系到前面已經(jīng)提到過的自動化測試的成熟度。組織或者項目必須至少要在成熟度的 3 級使用高度的測試庫才能使維護和更新測試功能變得容易,。
  • 測試數(shù)據(jù)
    什么樣類型的數(shù)據(jù)將被使用,?要為每一個測試用例生成測試數(shù)據(jù)還是使用在被測試應(yīng)用中已有的數(shù)據(jù)。在很多的情況下一個測試數(shù)據(jù)被創(chuàng)建了,,刪除他們是不可能的,。
  • 可測試性
    自動化測試方案能夠有效的測試嗎?例如,,被適當(dāng)命名的對象(不僅僅是索引 Id),。一個簡單的例子是所有的對話框都有相同的 #id 和相同的標(biāo)題,所不同的僅僅是顯示的文字信息,。當(dāng)測試應(yīng)該覆蓋多種語言的方案時,,對話框的測試就是一個挑戰(zhàn)。
  • 測試人員的技能
    被包括在自動化測試的創(chuàng)建中的人員應(yīng)該具有什么樣的技能呢,?如果他們具有良好的開發(fā)背景,,那么成熟度 3 級是足夠了。如果他們有很少的或者根本沒有開發(fā)的經(jīng)驗,,我們被迫使找到或者培訓(xùn)一個自動化測試專家的小組,,并直接到達成熟度 5 級,在成熟度 5 級測試的創(chuàng)建與實際的測試執(zhí)行被分離開,。
  • 一個好的構(gòu)建過程
    自動化測試的引入在"構(gòu)建團隊"上加入了一些約束,。為了實現(xiàn)自動化測試的高利用率(回歸測試),,要求具有一個高的構(gòu)建頻率。每周僅僅運行自動化的測試不是好的自動化測試的使用率,。將回歸測試增加到每天一次將幫助快速的發(fā)現(xiàn)新的問題并使開發(fā)人員更加容易的發(fā)現(xiàn)問題的根源,因為對測試的反饋時間是比較短的(開發(fā)人員能夠記住他們昨天做了什么),。
  • 所有權(quán)
    不同的測試庫的所有權(quán)的定義是重要的,。一個好的方案會將測試庫的組織劃分為三個級別:
    • 級別 1 - 全局的
      這個一個通常的級別。被存儲在這個級別的測試功能能夠被所有的項目訪問,。通用的和通常的功能象登陸,、創(chuàng)建一個用戶都是這個級別很好的候選者。
    • 級別 2 - 項目
      在這個級別的測試功能是與特定的測試項目相關(guān)的,,但是通常在項目中有用的比一定在項目外是有用的,。通常級別 2 是級別 1 的功能的提供者。
    • 級別 3 - 腳本
      功能被直接關(guān)聯(lián)到特定的測試腳本,。 I在這個級別中,,通常一個測試功能的第一個版本是被開發(fā)的。在新的測試腳本的創(chuàng)建期間已有測試功能的重用性被發(fā)現(xiàn),,并被移到了級別 2 中,。

    在這個級別上盡量最小化功能的數(shù)量,因為它將增加維護工作量,。

還有很多有關(guān)測試框架的問題,,但是這里所提及的是一些基本的要被解決的問題。

3. 在哪里使用自動化測試
有很多的情況下使用自動化的測試可以降低測試成本,。我將盡量的突出在自動化測試中的不同的測試技術(shù)

技術(shù) 描述 備注
單元測試/組件測試 這個測試工作通常是開發(fā)人員的職責(zé),,很多不同的方法能夠被使用,比如"測試先行",,它是一個測試框架,,開發(fā)人員在編寫代碼前編寫不同的單元測試。當(dāng)測試通過時,,代碼也被完成了,。 通過使用正式的單元測試,不僅能夠幫助開發(fā)人員產(chǎn)出更加穩(wěn)定的代碼而且能夠是軟件的整體質(zhì)量更加的好,。
冒煙測試 冒煙測試是一般驗證別測試系統(tǒng)的功能性測試用例的集合,。冒煙測試背后的思想是確保基礎(chǔ)是可以工作的,,以便"大的"測試工作能夠開始,。 在構(gòu)建過程能夠確保構(gòu)建已經(jīng)為測試準(zhǔn)備好時,冒煙測試通常是自動化的運行,。
功能/集成測試 這里測試的工作關(guān)注在驗證在不同的組件之間的集成上,。 這些類型的測試通常是被測試系統(tǒng)的更加復(fù)雜測試的基礎(chǔ),,大量的邊緣測試被合并以制造出不同的錯誤處理測試。
系統(tǒng)測試 - 用例測試 這種測試是通過執(zhí)行用戶場景模擬真實用戶使用系統(tǒng)以證明系統(tǒng)具有被期望的功能的測試,。 這里不需要進行自動化的測試,。安裝測試、安全性測試通常是有手工完成的,,因為系統(tǒng)的環(huán)境是恒定不變的,。
回歸測試 回歸測試實際上是重復(fù)已經(jīng)存在的測試。通常如果是手工完成的化,,這種測試只在項目的結(jié)尾執(zhí)行執(zhí)行一到兩次,。 這里完全有潛力應(yīng)用自動化的測試。你能夠在每次構(gòu)建完成后執(zhí)行自動化的回歸測試,,以驗證被測試系統(tǒng)的改變是否影響了系統(tǒng)的其他功能,。
性能測試 性能測試包括以下不同測試形式:
- 負載測試
- 壓力測試
- 并發(fā)測試
-.....
如果沒有自動化的測試工具,你將不能執(zhí)行通過模擬用戶的負載實現(xiàn)的高密集度的性能測試,。

4. 什么時候使用自動化測試
我對什么時候應(yīng)該使用自動化測試和什么時候應(yīng)該使用手工測試進行了一個概要的總結(jié):

使用自動化測試 使用手工測試
  • 項目沒有嚴格的時間壓力
  • 具有良好定義的測試策略和測試計劃
    • 你知道要測試什么
    • 你知道什么時候測試
  • 對于自動化測試你擁有一個能夠被識別的測試框架和候選者
  • 能夠確保多個測試運行的構(gòu)建策略
  • 多平臺環(huán)境需要被測試
  • 你擁有運行測試的硬件
  • 你擁有關(guān)注在自動化過程上的資源
  • 被測試系統(tǒng)是可自動化測試的
  • 沒有適當(dāng)?shù)臏y試過程
  • 沒有一個測試什么,,什么時候測試的清晰的藍圖
  • 在一個項目中,你是一個新人,,并且還不是完全的理解方案的功能性和或者設(shè)計
  • 你或者整個項目在時間的壓力下
  • 在團隊中沒有資源或者具有自動化測試技能的人
  • 沒有硬件

如果你正在從事自動化測試,,那么一定要記住要關(guān)注將自動化測試與手工測試結(jié)合起來使用。首先,,對于自動化測試率的目標(biāo)是 10/90 (10% 的自動化測試和 90% 的手工測試),。當(dāng)這些目標(biāo)都實現(xiàn)了,可以將自動化測試的使用率提高,。記住創(chuàng)建自動化測試的測試用例要比創(chuàng)建手工測試的測試用例花費更多的時間,。不要將你所有的測試時間都用在自動化的測試用例上。同時也要記住在測試期間對每一個被發(fā)現(xiàn)的錯誤都要花費一定的時間去處理,。

5. 自動化測試的好處
如果你正在你的組織中引入自動化測試,,記住有很多不同的方面被包含了進了。今天在測試工作如何被進行上有很多不同的視圖,。為了能夠成功的實施自動化測試你應(yīng)該提出這些問題:

  • 測試覆蓋什么,?- 我們沒有覆蓋什么?
  • 由于遺漏的測試我們沒有發(fā)現(xiàn)的"bug"會帶來什么樣的成本,?
  • 由于不好的測試,,破壞已有功能性的成本是多少?
  • 如果"瑣碎的"測試被每天的運行,,對于你的項目意味著什么,?
  • 如果我們能夠每天向開發(fā)人員提供他們最近代碼變更相關(guān)的反饋,對項目有怎樣的影響?

這些問題都能夠被自動化測試滿足,。你必須從自動化測試成熟度的級別 1 或者 級別 2 開始,,并開始測量結(jié)果。根據(jù)我的經(jīng)驗快速的向開發(fā)人員反饋并每天運行測試對于向自動化測試成熟度的級別 4或者 級別 5 是非常有好處的,。

自動化測試有以下的貢獻:

  • 降低風(fēng)險 - 你知道你測試了什么和沒測試什么
  • 測試能在項目的早期開始并隨著時間一直擴展
  • 快速的反饋 - 自動化測試用例能夠隨時的運行
  • 在多個平臺上的測試能夠同時進行
  • 更好的估計 - 你能夠?qū)y試進度和被使用的時間有更好的了解
  • 優(yōu)秀人員的集中 - 你能夠得到一個專家的團隊,,并將他們的知識傳播給其他的項目
  • 喜悅 -你和你的團隊正獲得著成功

參考資料

  1. Rational 培訓(xùn)課程 TST170: Principles of Software Testing for Testers
  2. Rational培訓(xùn)課程TST275: Essentials of Test Management with Rational TestManager
  3. Rational培訓(xùn)課程PRJ480 Mastering the Management of Iterative Development v2003.06.00
  4. 參考書:Software Test Automation by Fewster & Graham
  5. http://safsdev./FRAMESDataDrivenTestAutomationFrameworks.htm

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,,不代表本站觀點,。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,,謹防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,,請點擊一鍵舉報,。
    轉(zhuǎn)藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多