唯信產(chǎn)品分類Product Classification
4常見問題
您的位置:
首頁 ->
常見問題 -> 避開自動化測試的誤區(qū)
避開自動化測試的誤區(qū)
（1）必須信任自動化測試
自動化雖然已經(jīng)經(jīng)歷了10來年的發(fā)展歷史，但是很多同事潛意識里還是更愿意相信手工測試的真實可靠性。他們其中一部分認為自動化測試是不錯的方法和思想，但是相比來說機器永遠代替不了人的大腦，不夠靈活、不懂得變通；另外一部分從根本上就不信任自動化測試所做的測試執(zhí)行，認為執(zhí)行結(jié)果不可靠，根本無法節(jié)約成本，而且反而會降低測試質(zhì)量。 對自動化測試到底怎么看還是受站在什么角度想問題、考慮問題是否全面等因素的影響。這些不看好自動化的想法很可能是來自沒有自動化實踐經(jīng)歷的憑空想象或者是有過失敗的自動化經(jīng)歷；他們這種失敗的經(jīng)歷中自動化測試沒有選取合適的應(yīng)用范圍、方法不得當所占比重非常大，并且他們在失敗之后沒有進一步思考，沒有總結(jié)出這些導致失敗的誘因。比如，認為不夠靈活的往往是因為要求太高而技術(shù)實現(xiàn)又達不到預(yù)期；為什么想要變通呢？想必是因為需求沒有達到足夠細致的程度，測試設(shè)計太模糊從而導致執(zhí)行實際結(jié)果很容易產(chǎn)生一定的偏差：如果測試分析、設(shè)計上下了足夠的功夫，那么所謂的變通是完全不必要的。自動化測試腳本或者工具為什么要替代人的頭腦呢？換個角度思考一下，被測系統(tǒng)是否達到了替代人腦的功能呢？當然沒有！自動化測試只是在對被測系統(tǒng)進行操作，每一處驗證點的檢查都是針對系統(tǒng)的設(shè)計和實現(xiàn)進行的，從根本上說，如果被測系統(tǒng)無法替代人腦的存在，自動化測試也沒有這個必要去考慮這個問題。無法節(jié)約成本的看法是因為不懂得自動化的成本效益如何分析，一味的單從自動化開發(fā)投入時間和運行時長作比較；認為自動化會降低測試質(zhì)量的看法則是由于不懂自動化測試理論、不懂測試理論導致的。
對自動化測試作用的徹底信任是自動化測試開始的必要條件，抱著半信半疑的態(tài)度去嘗試只會帶來很多的困擾。猶猶豫豫地總是懷疑自動化測試是否值得很可能就會導致人力投入、其他設(shè)備資源支持上的問題，認識上的誤差——尤其是管理者的誤解會給自動化的策略和發(fā)展帶來很大的障礙。不要把自動化作為一種資本或者實力的體現(xiàn)，從項目管理的角度來說，它只是在測試過程中實現(xiàn)測試周期調(diào)控和測試質(zhì)量把控的手段而已，而在整個測試過程中是起到輔助手工測試的作用還是主導著測試主要是看自動化使用的水平和程度。
（2）了解測試開發(fā)的模式
前面也談到開發(fā)模式略有不同，測試自動化開發(fā)也隨著不一樣，一般說來自動化開發(fā)有下面幾種模式，我們來看下他們各自的特點。
1、超前式，在項目設(shè)計編碼的同時就開始了自動化腳本開發(fā)，依賴系統(tǒng)開發(fā)過程中的高度復用；是一種比較先進的自動化設(shè)計開發(fā)模式，能夠在系統(tǒng)移交初期就完成自動化開發(fā)，并且得到很好的應(yīng)用，但是極少有公司能達到這種水平。
2、尾隨式，在系統(tǒng)開發(fā)環(huán)境緊隨編碼進度去做自動化的開發(fā)，需要投入人力較多，開發(fā)進度稍滯后與系統(tǒng)編碼進度，但是總體來說測試開發(fā)、調(diào)試完成之后還是能夠得到較好的應(yīng)用。
3、基線式，在SIT或者FAT完成之后的某個較為穩(wěn)定的版本上進行自動化腳本、程序的開發(fā)。開發(fā)的時候需要有一套獨立的自動化開發(fā)環(huán)境（也可以是Staging環(huán)境），界面比較穩(wěn)定；但是在后期需要同步更新的地方較多，測試運行基本只能夠應(yīng)用在ST的冒煙測試和回歸測試。
這幾種只是幾種相比其它方式較為正常、普遍的模式，也有一些不為筆者所了解的方法，如果大家能夠補充一下就更好了。
在第一、第二種模式里，比較容易出現(xiàn)的問題是沒有滿足相應(yīng)的條件又去使用對應(yīng)的自動化開發(fā)方法；比如在第二種方式里人力投入較少，那么自動化開發(fā)進度可能嚴重滯后，并不能達到預(yù)期的效果，這在第一章已有闡述?；€式最常見的問題是在測試過程中不斷的更新項目版本，在不斷更新的項目版本上進行不斷地進行自動化更新。乍一看這種操作沒有什么問題，可實際上系統(tǒng)開發(fā)過程中有缺陷修復帶來的反反復復，UI變動也存在A-B-C-A的過程。由于測試腳本開發(fā)較晚，這種測試運行基本只能夠應(yīng)用在ST的冒煙測試和回歸測試，中途的更新并不能帶來什么實際的好處，不斷地隨項目版本的變更去進行自動化的更新反而會消耗更多的時間和人力。我們經(jīng)常聽到的是：“這個系統(tǒng)不適合做自動化測試”這種說法，究
其原因，卻是因為變更（需求）太多導致的。同時這種不適合做自動化的抱怨也是一種誤解，只要調(diào)整對應(yīng)的自動化開發(fā)策略，問題還是能夠得到一定程度上的緩解的。
那有些同事可能說“剛經(jīng)過SIT或者FAT的版本和經(jīng)過ST的版本有著天壤之別，后期的更新可能跟重新開發(fā)消耗一樣的時間和人力，那最初的自動化開發(fā)不是一種浪費嗎？！”很簡單，拿出需求規(guī)格來看看，為什么有這么多的變更呢？這些變更如果沒有對應(yīng)的流程記錄，那毫無疑問項目經(jīng)理或者你的直接主管要為這么多的人力浪費買單；如果有已經(jīng)明確知會的變更，那么請記得在自動化開發(fā)過程中要跟蹤每次變更，同步更新測試需求和自動化開發(fā)需求。軟件開發(fā)成熟度評估標準中有一項是對需求管理的指標，上文之所以強調(diào)軟件開發(fā)成熟度對自動化的影響，其中一部分原因就在這個地方了。
（3）莫為自動化而自動化
無論是項目測試還是運營測試中，自動化測試的目的是測試而不是自動化，自動化測試應(yīng)該是先進的測試手段，是提高測試質(zhì)量、測試速度的手段，而并不是單純?yōu)榱思夹g(shù)研究而做的事情。在這一點上犯形式主義錯誤的人和事屢見不鮮，筆者總結(jié)有以下三種情況：
1、主觀上崇拜技術(shù)，只是為了要證明自己有做自動化測試的實力，進行自動化的出發(fā)點錯誤。把自動化測試技術(shù)作為第一要義，不注重測試的需求內(nèi)容，盲目追求測試自動化實現(xiàn)的華麗程度，但事實上沒有給系統(tǒng)測試做太多的貢獻。費時費力并不可怕，可怕的是費時費力之后卻沒有得到應(yīng)該得的東西；你可以鼓吹自己的自動化平臺、技術(shù)多先進，但是卻沒有資格對別人說自己的自動化能來帶什么樣的收益。例如有很多人在有QC和QTP的情況下，喜歡舍近求遠，放棄QC的預(yù)留接口和它與QTP之間非常好的兼容性，另起爐灶去開發(fā)難度較大的測試框架。這樣技術(shù)投入上消耗了更多的資源，但是效果卻并不一定有已有的東西好。
2、偏離測試主旨，長期運作但是沒有實際產(chǎn)出物。試想一下，每天上萬的測試腳本反復運行，但是從未見有發(fā)現(xiàn)任何缺陷或者從來就沒有對“每日回歸”發(fā)現(xiàn)的缺陷進行統(tǒng)計分析，這是一種什么概念。按理說能進行每日回歸并且我們這種幾近無甄選的“每日回歸”是非常強大的，即便是大家津津樂道的持續(xù)集成中的高頻度構(gòu)建也是能支持的；但是我們這里缺失了一個重要的環(huán)節(jié)：對當前版本上運行結(jié)果的分析。其實高頻度的運行涵蓋兩個方面，一是冒煙測試，這是版本每次發(fā)布Staging之后的運行，另一個是回歸測試，也就是版本定版之前的運行。那么有可能哪個版本移交過來之后就沒有缺陷么？當然幾乎沒有！既然有缺陷，那么自動化運行失敗而置缺陷不理，一味追求測試腳本的修復、更新又是所謂何來呢？那只能理解為你只求把自動化的運行用在回歸測試上，但事實上回歸測試的時候版本基本已經(jīng)穩(wěn)定，一般自動化運行是很難發(fā)現(xiàn)什么問題的。最終自動化測試成了回歸測試時增加測試人員信心的手段，目的只是為了證明沒有缺陷，而不是爭取發(fā)現(xiàn)缺陷，這也就從根本上偏離了測試的主旨。如果能形成每次運行之后的報告分析機制，那么種情況或許能夠得到改善，缺陷提交是自動化運行失敗必須要做的，缺陷關(guān)閉是版本移交生產(chǎn)必須做的，這樣卡住過程的首尾，自動化測試方能起到它該起的作用。
技術(shù)咨詢