Dustin在2008年10月的《Software Testing and Performance》雜志上發表文章,深入探討了為什么如此多的自自動化測試專家Elfriede 動化測試項目會最終失敗。
1、IDT的自動化測試調查
IDT(Innovative Defense Technologies)在2007年進行了一次軟件自動化測試的研究調查。調查研究表明:雖然很多公司都認為自動化測試是非常有用的,但是很少有公司真正成功地實施了自動化測試。在問及沒有很好地開展自動化測試的原因時,大部分人回答是由于缺乏資源,例如:時間、預算、技術等,其中:
37%認為缺乏時間。
17%認為缺乏足夠的預算。
11%認為缺乏合適的工具。
20%認為缺乏專家的技術指導。
研發領域的技術在過去20、30年間得到了高速的發展。然而我們對這些技術的測試能力并沒有跟上發展的速度?,F實告訴我們,測試變得越來越重要。IDT研究測試技術多年,發現一些有趣的東西:
以前,業務驅動著軟件和測試的技術發展?,F在,軟件和測試技術逐漸對業務起著驅動作用。業務部門可以有很好的業務idea,但是如果軟件開發和測試部門不能很好地交付產品,或者測試能力有所欠缺的話,業務的競爭力會很快地消失。搶占市場的先機很重要,但是應該給予產品開發和質量保證更多的關注。
(2)應該給予“感知質量”更多的測試
質量過程和標準往往過于關注數據,例如出現了多少個Bug、缺陷的密度等數據,而忽略了顧客的“感知質量”。例如,對于一個產品,頻繁出現的10個缺陷,并且會影響到關鍵的功能運行,這往往會被顧客認為是一個低質量的產品,即使相對于整個項目而言,缺陷密度是非常低的。
相反地,如果發布的產品中有100個缺陷,但是不經常出現,而且幾乎不影響正常的功能操作,顧客則會認為這是個高質量的產品,即便從數據看來,其缺陷率非常高。
到目前為止,并沒有太多“基于使用的測試”的研究。“基于使用的測試”探索感知質量的內涵,追求高的感知質量,從而獲得更高的顧客滿意度。在Elfriede Dustin看來,amazon.com相比起其他在線書店網站,擁有更高的顧客感知質量,因為amazon.com的用戶體驗非常友好。
我們的目標是提高產品的感知質量。提高的途徑是:讓測試專注在那些最常使用的功能上(確保正常工作,沒有任何缺陷),專注于測試那些最常用功能的可用性、可靠性。
(3)測試人員總是會受到責備
Deadline臨近,而在多種環境下的測試周期看起來是無止境的。測試人員通常會因為Deadline而受到責備,還會因為項目超出預算、沒有覆蓋產品的所有Bug、缺乏創新等,受到責備。
但是,通常造成這種結果的真正原因是因為缺乏系統工程的過程。例如,對于一個上百萬行代碼、包含大量功能模塊的產品,僅僅依靠測試組的黑盒測試,費盡九牛二虎之力才找到一些Bug。
從另外一個角度來看,測試對項目進度拖延的真正原因是:不良的開發習慣導致充滿Bug的代碼,需要很長的、重復的修改周期。
還有一個原因是:缺乏單元測試。調查分析表明:單元測試越充分、越有效,則系統測試會開展得越順利,系統測試的周期也會越短。
不能忽略的一個問題是產品構建。構建(Build)和發布(Release)的過程應該自動化。如果沒有實現構建的自動化,那么軟件構建的過程將會是非常浪費時間、并且容易出錯的一件事情。
另外,如果Deadline本身設置得就不合理,那么導致失敗的可能性就非常大。有些Deadline的設置沒有考慮清楚究竟需要多長的時間來開發和測試軟件。
(4)開發人員不做測試
雖然已經有不少的開發人員采用單元測試、測試驅動的開發方式,他們確實做得不錯。但是開發人員仍然缺少集成和系統方面的測試。開發人員往往傾向于關注自己編寫的功能模塊的問題,缺乏對整個系統的全局觀。
為什么開發人員不做一下系統測試呢?他們沒有時間,他們不是專業的測試人員,他們缺少測試的技巧,他們忙著開發新的代碼和功能,并且測試系統整合部分的代碼不是他們的職責。
開發人員疲于應付新功能的開發,以便滿足那些不合理的Deadline。畢竟,大部分人認為搶占市場是很關鍵的。然而,事實證明,我們不僅僅要關注R&D,還要關注R&D&T。
2、自動化測試的最佳實踐
很自然地,大家希望借助于自動化測試來縮短系統測試的周期,緩解測試的壓力。但是,如果在設計和代碼開發的過程中缺乏對自動化測試的考慮,例如提高應用程序的可測試性,我們可能會掉入自動化測試的陷阱中去。
為了避免掉入自動化測試的陷阱,Elfriede Dustin總結了幾個最佳實踐,其中包括:
(1)提高應用程序的可測試性。
軟件開發人員可以通過在程序中構建更多的可測試特性,來幫助測試人員開展自動化測試??梢杂卸喾N方式來提高可測試性,其中一種比較常見的方式是提供日志或跟蹤機制,從而提供關于程序正在做什么的信息,包括正在操作的數據,以及關于應用程序狀態、運行中的錯誤等方面的信息。測試工程師可以利用這些信息來判斷錯誤是否發生,跟蹤測試執行過程中的各種處理流程。
在應用程序執行過程中,所有模塊都會寫入關于方法、函數、當前處理對象等詳細的日志信息。通常日志會寫到文件或數據庫中,并且按一定的格式寫入,以便后期地分析和調試。
在某些復雜的C/S結構系統或Web系統中,日志文件可能會寫到多個機器上,因此日志中應該包含足夠的信息用于判斷在機器之間執行的順序和路徑。但是也不能包含太多的信息,否則將影響后期的分析過程。每個日志信息應該盡可能簡潔地包含一些關鍵的信息,例如:
類名和方法名。
機器名和進程ID。
時間戳(精確到毫秒級)。
執行信息或出錯信息。
灰盒測試方式可以充分利用這些日志信息,跟蹤到對象在測試執行過程中的各種信息。另外,還會帶來如下好處: