以前聽過北京中軟的一個業內專家講一句話,覺得挺經典:凡是說既是科學又是藝術的學科,就是說明它是不成熟的學科!他將軟件工程和建筑行業做類比,讓我們深深體會到軟件工程走向成熟化的任重與道遠。而軟件測試,更是一個新興的領域,雖然近幾年得到了快速發展,也隨著該領域從業者數量的與日俱增,培養了一批高級的人才;但是依然有多少企業和個人工作在迷茫中:這種困惑是因為工程師們手中的測試工作與理想的測試模式造成的強烈反差,這種無奈是因為他們和開發人員一樣的努力卻有不同的待遇,這種迷茫是因為測試工作者不知道這個領域里是否還有自己的發展空間和人生價值的體現!筆者認為:如今的軟件測試行情,正處在群雄逐鹿的混戰歲月,每個人、每個有測試部門或從事測試業務的企業,都該發揚百花齊放、百家爭鳴的精神,多多借鑒國內外先進的測試經驗,參考業界流行的行業標準,找到適合自己團隊的測試方法和模式,創造更大的社會價值,發揮更大的人生價值。
實施軟件測試自動化的理由分析
首先,測試人員的工作比以往任何時候都更加困難,因為公司和組織希望以更快的速度和更低的成本開發出高質量的應用程序。
此外,在很多項目中,測試人員的所有任務實際上都是手動處理的,而實際上,有很大一部分重復性強的測試工作,是可以獨立開來自動實現的。
還有,在大型項目中測試團隊和其他的團隊之間沒有足夠的合作,無法促進彼此的工作。
最后,從個人角度來說,測試人員通常很難花費大量時間來學習新技能;這是目前國內測試從業者的現狀,太多的企業為了節約成本而將剛剛走出校門的畢業生作為測試工程師,他們每日做著繁忙的重復工作,又基于自身技能的不深,雖懷博覽群書的心愿卻不知從何出入手。所謂光陰似箭,因為一轉眼我們就說到未來的5年、10年后,我們這些技能不深的測試工程師能做什么呢?而軟件測試自動化,也是未來測試工程師或即將成為測試工程一項強有力的工作技能。
可以說,實施測試自動化是軟件行業一個不可逆轉的趨勢,如果在這個領域走在了前列,無論從企業的核心競爭力還是個人的工作技能來說,都有巨大的優越性,而國內眾多的軟件廠商也的確在紛至沓來的著手開展著這項工作。
國內軟件測試自動化實施現狀分析
隨著眾多具有了一定優秀實施自動化測試經驗的企業陸續出現,也伴隨著很多組織對這項工作依然是丈二的和尚-摸不著頭腦。對當前國內軟件企業實施或有意向實施測試自動化時面臨的主要問題,按實施的不同層次來說:
——干脆認為測試自動化是個遙不可及的事情,我們這樣的小公司不必實施,人員、資金、資源都不足,以后再說吧!
——熱血沸騰的實施測試自動化,購買了工具,推行了新的測試流程;幾個月后,工具放在那里成了共享資源,測試流程又濤聲依舊,回到原來的模式。
——公司實施了自動化測試;然而開發與測試之間,甚至與項目經理之間矛盾重重,出了事情不知如何追究責任;雖然還在勉強維持的自動化測試,但實施的成本比手工測試增加了,工作量比從前更大了,從而造成項目團隊人員怨聲載道,更懷念起那段手工測試的悠閑歲月,唉!那一場風花雪月的事,既然要結束又何必開始…
——自動化測試實施相對比較成功,但或多或少還有些問題,比如工具選擇不準確,培訓不到位,文檔不完備,人員分配不合理,腳本可維護度不高等等,造成一種表面上的自動化測試流程,是一幅空架子,如同山間竹筍,嘴尖皮厚腹中空。
國內軟件測試自動化實施不成功原因分析
——公司高層意識不到軟件測試自動化的重要性;殊不知,其他競爭對手們都大張旗鼓的開展這方面研究和策劃的時候,自己還對此持漠視態度,等到整個行業都提高到一個新的層次,那時再著手做,可能就是熱鍋上的螞蟻了。
——所謂凡事預則立,不預則廢。一個軟件企業實施測試自動化,絕對不是拍腦袋說干就能干好的,它不僅涉及測試工作本身流程上、組織結構上的調整與改進,甚至也包括需求、設計、開發、維護及配置管理等其他方面的配合。
——軟件開發是團隊工作,在這一領域要尤其注重以人為本;所以人員之間的配合、測試組織結構的設置非常重要,每個角色一定要將自己的責任完全擔負起來,這也是減少和解決前述團隊矛盾的必要手段。
——對開展自動化測試的監督和評估相當重要,也包括對工作產品的檢查和人員的考核。一定要將自動化測試全面深入的貫徹到測試工作中,不能敷衍了事,不能做表面工作。這項工作在CMM三級里規范的很好,只可惜我們的很多公司對CMM真的只是“過級”!
正確認識國內未實施軟件測試自動化的根源
目前國內的軟件公司,很多還是處于獲取資本的原始積累階段,我們不能說公司領導完全不重視測試,而是測試整體行業都沒有被重視起來,這是其一;其二是公司高層有更需要重視的環節,例如尋找客戶簽訂單,或者開發,這些是直接關系公司存亡的命脈性東西。
即便企業重視測試,如果公司做一番比較全面的評估(在后續的測試自動化引入入條件里,再詳細說明),也不一定非要實施自動化測試。筆者認為一些中小軟件公司在大刀闊斧推行自動化測試之前,在測試流程管理、測試缺陷流程、測試人員技能培訓等方面做工作,這樣可以用比較少的成本投入來獲取相對較大且長期的收益回報。
最后,針對普通測試工程師的一些建議,在這樣的公司里,其實有著很多意想不到的優越性:
。ㄒ唬┻@樣的公司測試如果不正規,那么你就有更大更多的發揮空間。
。ǘ┠憧梢詥为殞W習自動化測試技術,自己先試著應用到日常工作的軟件項目中。
。ㄈ┠憧梢灾苯雍烷_發人員溝通,甚至向他們學習開發技術,這對將來的自動化測試中開發腳本很有好處。
。ㄋ模┟總優秀測試工程師的成長都是個循序漸進的過程。我遇到很多測試界的新手向我發牢騷,很慚愧我沒有什么可以告誡他們的,只是希望這樣的新人克服浮躁情緒,穩扎穩打練好基本功,想成為優秀的測試專家,就要經歷這個階段。
軟件測試自動化的引入條件
如果你的測試部門有意向引入自動化測試,那么首先要從思想上統一認識。
一、 軟件測試自動化的正確認識
1) 自動化測試能大大降低手工測試工作,但決不能完全取代手工測試。完全的自動化測試只是一個理論上的目標,實際上想要達到 100% 的自動化測試,不僅代價相當昂貴,而且操作上也是幾乎不可能實現。一般來說,一個 40-60% 的利用自動化的程度已經是非常好的了,達到這個級別以上將過大的增加測試相關的維護成本。
2) 測試自動化的引入有一定的標準,要經過綜合的評估,絕對不能理解成測試工具簡單的錄制與回放過程。實際上,從實現成熟度來說,自動化測試分五個級別:
級別 | 說明 | 優點 | 缺點 | 用法 |
一級 | 錄制和回放 | 自動化的測試腳本能夠被自動的生成,而不需要有任何的編程知識 | 擁有大量的測試腳本,當需求和應用發生變化時相應的測試腳本也必須被重新錄制 | 當測試的系統不會發生變化時,實現小規模的自動化 |
二級 | 錄制、編輯和回放 | 減少腳本的數量和維護的工作 | 需要一定的編程知識;頻繁的變化難于維護 | 回歸測試時,用于被測試的應用有很小的變化 |
三級 | 編程和回放 | 確定了測試腳本的設計,在項目的早期就可以開始自動化的測試 | 要求測試人員具有很好的軟件技能,包括設計、開發 | 大規模的測試套件被開發、執行和維護的專業自動化測試 |
四級 | 數據驅動的測試 | 能夠維護和使用良好的并且有效的模擬真實生活中數據的測試數據 | 軟件開發的技能是基礎,并且需要訪問相關的測試數據 | 大規模的測試套件被開發、執行和維護的專業自動化測試 |
五級 | 使用動作詞的測試自動化 | 測試用例的設計被從測試工具中分離了出來 | 需要一個具有工具技能和開發技能的測試團隊 | 專業的測試自動化將技能的使用最優化的結合起來 |
3) 自動化測試能提高測試效率,快速定位測試軟件各版本中的功能與性能缺陷,但不會創造性的發現測試腳本里沒有設計的缺陷。測試工具不是人腦,要求測試設計者將測試中各種分支路徑的校驗點進行定制;沒有定制完整,即便事實上出錯的地方,測試工具也不會發覺。因此,制訂全面、系統的測試設計工作是相當重要的。
4) 自動化測試能提高測試效率,但對于周期短、時間緊迫的項目不宜采用自動化測試。推行自動化測試的前期工作相當龐大,將企業級自動化測試框架應用到一個項目中也要評估其合適性,因此決不能盲目的的應用到任何一個測試項目中,尤其不適合周期短的項目,因為很可能需要大量的測試框架的準備和實施而會被拖跨。
5) 實施測試自動化必須進行多方面的培訓,包括測試流程、缺陷管理、人員安排、測試工具使用等。如果測試過程是不合理的,引入自動化測試只會給軟件組織或者項目團隊帶來更大的混亂;如果我們允許組織或者項目團隊在沒有關于應該如何做的任何知識的情況下實施自動化測試,那將肯定會以失敗告終。
如果軟件企業有意向實施自動化測試,那么應該具備什么樣的條件才可以引入自動化測試呢,才可以最大可能的減少引入風險,并能夠可持續性的開展下去呢?
二、對企業自身現狀的評估分析
第一,從企業規模上來說,沒有嚴格限制。無論公司大小,都需要提高測試效率,希望測試工作標準化,測試流程正規化,測試代碼重用化。所以第一要做到的,就是企業從高層CTO開始,直到測試部門的任何一個普通工程師,都要樹立實施自動化測試的堅定決心,不能抱著試試看的態度。一般來說,一個這樣的軟件開發團隊可以優先開展自動化測試工作:測試-開發人員比例合適,比如1:1到1:1.5;開發團隊總人數不少于10個。當然,如果你的公司只有三五個測試人員,要實施自動化測試絕非易事;不過可以先讓一個、兩個測試帶頭人首先試著開展這個工作,不斷總結、不斷提高,并和層層上司經常匯報工作的開展情況,再最終決定是否全面推行此事。
第二,從公司的產品特征來說,一般開發產品的公司實施自動化測試要比開發項目的公司要優越些。原因很簡單,就是測試維護成本和風險都小。產品軟件開發周期長,需求相對穩定,測試人員可以有比較充裕的時間去設計測試方案和開發測試腳本;而項目軟件面向單客戶,需求難以一次性統一,變更頻繁,對開發、維護測試腳本危害很大,出現問題時一般都以開發代碼為主,很難照顧到測試代碼。但決不是說做項目軟件的公司不能實施自動化測試,當前國內做項目的軟件公司居多,有很多正在推行CMM等級標準,這是好事情;只要軟件的開發流程、測試流程、缺陷管理流程規范了,推行自動化測試自然水到渠成。
第三,說說標準化的開發和管理流程。不管是CMM還是ISO,不管是開發流程、測試流程還是缺陷管理流程,這里不能一一闡述,可以參考RUP(Rational Unified Process, Rational 統一過程),可以參考很多業界文獻,我只說明一點,也是我們IT從業人員甚至任何從業人員一個很好的工作原則:
a、 把你想做的寫下來(計劃管理)
b、 按照你寫下來的去做(行為管理)
c、 把做的事情記錄下來(報告管理)
d、 出現的問題要設法解決(跟蹤管理)
在測試流程里,這幾個要點都一一有所落實;如果你的軟件開發團隊據此開發軟件,那么完全具備實施自動化測試的條件。當然,也許一些公司的測試管理比較混亂,出了問題不知道誰負責,測試人員或開發人員整日礙
測試階段 | 描述 | 備注 |
單元測試/組件測試 | 這個測試工作通常是開發人員的職責,很多不同的方法能夠被使用,比如"測試先行",它是一個測試框架,開發人員在編寫代碼前編寫不同的單元測試,當測試通過時,代碼也被完成了。 | 通過使用正式的單元測試,不僅能夠幫助開發人員產出更加穩定的代碼,而且能夠是軟件的整體質量更加的好。 |
集成測試 | 這里的測試工作集中在驗證不同的組件之間的集成上。 | 這種類型的測試通常是被測試系統的更加復雜測試的基礎,大量的邊緣測試被合并以制造出不同的錯誤處理測試。 |
系統測試 | 這種測試是通過執行用戶場景模擬真實用戶使用系統,以證明系統具有被期望的功能。 | 這里不需要進行自動化的測試。安裝測試、安全性測試通常是有手工完成的,因為系統的環境是恒定不變的。 |
其它兩種非常重要的測試 | ||
回歸測試 |
回歸測試實際上是重復已經存在的測試,通常如果是手工完成的化,這種測試只在項目的結尾執行執行一到兩次。 | 這里完全有潛力應用自動化的測試,你能夠在每次構建完成后執行自動化的回歸測試,以驗證被測試系統的改變是否影響了系統的其他功能。 |
|
性能測試包括以下不同測試形式: - 負載測試 - 壓力測試 - 并發測試 -..... |
如果沒有自動化的測試工具,你將不能執行通過模擬用戶的負載實現的高密集度的性能測試。 |
其三是軟件自動化測試切入方式的風險。正如前面所言,一定要記住將自動化測試與手工測試結合起來使用,不合理的規劃會造成工作事倍功半。首先,對于自動化測試率的目標是 10/90 (10% 的自動化測試和 90% 的手工測試)。當這些目標都實現了,可以將自動化測試的使用率提高。對于何種測試情況下引入自動化測試,何時依然采用手工測試,我們分開闡述。
一般這樣的測試條件下使用自動化測試:
· 項目沒有嚴格的時間壓力
· 具有良好定義的測試策略和測試計劃(知道要測試什么 ,知道什么時候測試 )
· 對于自動化測試你擁有一個能夠被識別的測試框架和候選者
· 能夠確保多個測試運行的構建策略
· 多平臺環境需要被測試
· 擁有運行測試的硬件
· 擁有關注在自動化過程上的資源
· 被測試系統是可自動化測試的
如下條件是宜采用手工測試:
· 沒有標準的測試過程
· 沒有一個測試什么、什么時候測試的清晰的藍圖
· 在一個項目中,你是一個新人,并且還不是完全的理解方案的功能性和或者設計
· 你或者整個項目在時間的壓力下
· 在團隊中沒有資源或者具有自動化測試技能的人· 沒有硬件
其四是企業軟件的開發語言風險。當前業界流行的測試工具有幾十種,相同功能的測試工具所支持的環境和語言各不相同,這里筆者總結了當前國際上流行的幾個軟件測試工具生產廠商及一些主要IDE產品,讀者可根據參考網址去了解列舉工具和更多工具的詳細資料。
生產廠商 | 工具名稱 | 測試功能簡述 | 網址鏈接 |
Mercury |
Winruner |
|
http://www.Mercury.com/ |
Loadrunner |
性能測試 | ||
QuickTest Pro |
功能測試 | ||
Astra LoadTest |
性能測試 | ||
|
測試管理 | ||
IBM Rational |
Rational root |
功能測試和性能測試 |
http://www.900.ibm.com |
Rational XDE tester |
功能測試 | ||
Rational testmanager |
測試管理 | ||
Rational purifyplus |
| ||
Compuware |
|
功能測試 |
http://www.compuware.com/products |
QALoad | 性能測試 | ||
QADirector | 測試管理 | ||
DevPartner Studio Professional |
白盒測試 | ||
Seque software | Silk Test | 功能測試 | http://www.Seque.com/products/index.asp |
Silk | 性能測試 | ||
SilkCentral Test /Issue Manager |
測試管理 | ||
Empirix | e-Tester | 功能測試 | http://www.Empirix.com/Empirix/ /Web+Test+Monitoring/Testing+Solutions/ Integrated+Web+Testing.html |
e-Load | 性能測試 | ||
e-Monitor | 測試管理 | ||
parasoft | Jtest | Java白盒測試 | http://www.parasoft.com/jsp/ products.jsp?itemID=12 |
C++test | C/C++白盒測試 | ||
.NETtest | .NET白盒測試 | ||
RadView | WebLOAD | 性能測試 | http://www.radview.com/products |
WebFT | 性能測試 | ||
MicroSoft | Web Application Stress Tool |
性能測試 | http://www.microsoft.com/technet/archive/ itsolutions/downloads/webtutor.mspx |
Quest Software | benchmark Factory | 性能測試 | http://www.quest.com/benchmark_factory |
Minq Software | Pure | 功能測試 | http://www.minq.com/products/ |
Pure | 性能測試 | ||
Pure | 測試監控 | ||
Seapine Software | QA Wizard | 功能測試工具 | http://www.seapine.com/products |
TestTrack Pro | 缺陷管理工具 |
。c擊查看表格圖片-test tool summary.jpg)
其五還要做時間估算。在評估完前面幾項指標后,需要估算實施測試自動化的時間周期,以防止浪費不必要的時間,減少在人員、資金、資源投入上的無端消耗。雖然到測試自動化步入正軌以后,會起到事半功倍的效果,但前期的投入巨大,要全面考慮各種因素,明確實施計劃并按計劃嚴格執行,才能最大限度降低風險。
其六是工作流程變更風險。測試團隊乃至整個開發組織實施測試自動化,或多或少會因為適應測試工具的工作流程,帶來團隊的測試流程、開發流程的相應變更,而且,如果變更不善,會引起團隊成員的諸多抱怨情緒;所以應該盡量減少這種變更,并克服變更中可能存在的困難。
其七是人員培訓與變更風險。簡單而言,就是測試團隊人員的培訓具有風險性,例如每個角色的定位是否準確,各角色人員對培訓技能的掌握程度是否滿意,尤其實施途中如果發生人員變更等風險,都要事先做出預測和相應的處理方案。
一個企業或軟件團隊實施測試自動化,會有來自方方面面的壓力和風險,但是憑借團隊成員的聰明才智和公司高層的大力支持,事先做好評估,做好風險預測,那么可以告訴你一個激動人心的消息:你的團隊成功引入了測試自動化!有了測試自動化,我們即可享受它帶來的超凡價值和無窮魅力:我們的測試工作變得更簡單、更有效,我們工作在一個專家級的團隊里,因此我們每天都在享受這種成功的喜悅!
文章來源于領測軟件測試網 http://www.kjueaiud.com/