軟體測試人員的華麗轉身——自動化測試之我見

　　軟體測試，是一件非常令人沮喪的事情。為什麼這麼講呢？從軟體測試的工作量而言，軟體測試是一件非常消耗人力和時間成本的工作；從測試人員的心理而言，重複的去做同一件看似毫無技術含量的工作，沒有成就感。大型軟體專案的測試尤甚。軟體測試的痛苦在於，軟體測試的目的在於發現軟體bug，從某種角度上講，發現的軟體bug越多，證明了軟體測試的有效性越強，但從另一角度而言，軟體的bug越多，也就說明軟體在設計和實現過程中的問題很多，該軟體專案就算是比較失敗的專案。有人可能會說，在軟體專案中，開發人員應該是最重要的，如果沒有開發人員的聰明才智，就不會有成功的軟體。沒錯，但是測試人員的努力工作換來了高質量的軟體。

　　既然測試人員工作非常辛苦，而且有了他們的工作才能保證高質量的軟體。那麼如何做才能夠幫助他們實現華麗的轉身，讓測試人員有時間回家陪老婆抱孩子，而不是整天面對一堆用例，面對眾多bug以及不停的迴歸迭代。

　　自動化測試是目前看似行之有效的方法（沒有之一）。自動化測試的概念就如同它的名字一樣清晰，就是通過使用自動化工具將測試人員部分的工作解放出來，使測試人員能夠專注於測試設計的本身，而不去考慮測試指令碼編寫、測試執行等實現問題。自動化的好處當然顯而易見，但是自動化的實施以及自動化實現的程度卻根據不同的公司、不同的專案而異。一般說來，自動化測試對於已經執行維護的系統進行迴歸測試的效果較為明顯，而對於新開發專案的實施成本較高且效果不夠顯著。這是因為對已執行的系統，其功能和特性已經較為熟悉，在迭代過程中，能夠通過自動化去替代人工對原有的功能進行測試。二新開發的軟體專案的功能可能並不清晰，在設計開發中的改動也比較大，如果使用自動化測試工具，需要根據被測物件的改變而不停的維護測試工具。因此代價和成本也較高。自動化測試可以從兩個方面來解放測試人員的工作，提高測試效率。一方面是自動化測試管理平臺的建立，另一方面是自動測試工具的建立。對於前者，可以採用開源軟體testLink來實現，主要進行用例的管理維護工作。本文先對後一型別進行說明。目前自動化測試工具用的比較多的有HP公司的QTP。QTP通過錄制/回放的功能，能夠自動的進行測試。而且QTP不僅支援物件庫，而且支援描述性程式設計，能夠適應不停改變的專案。

　　自動化測試的開展首先必須要考慮到自動化要達成什麼樣的目標？要達到多高的覆蓋率？是不是覆蓋率越高的話自動化就越好？其實，自動化的覆蓋率和自動化效率是一個拋物線的圖，對某一專案而言，在自動化覆蓋率達到一個閾值時效率最高，隨著覆蓋率的進一步加大，維護的成本就會加大，被測物件的一點改變都必須進行自動化測試工具相應的維護和改變。目前來看這個閾值只能是根據開發測試架構的測試開發人員的經驗去判斷。對於前臺UI的自動化，有一種說法是這個目標很難實現，因為在設計中UI是最容易變更的，這樣對自動化工具而言成本就非常大。一次有幸聽過google中國測試部門老大的講座，他提到沒有見到一例做UI自動化成功的。看來UI自動化還是任重道遠。對於後臺的自動化，因為功能部分比較穩定，因此這裡是實現自動化的主要方面。但是後臺自動化的問題是如何與前臺進行互動。有一種方法是在後臺和前臺之間放一層中間層，後臺所有測試的資料最後都放在中間層中，而前臺直接呼叫中間層的資料，避免了前後臺直接互動，而只採用了資料互動的方式。

　　發散的說了這麼多，還只是作為一個自動化測試菜鳥的一點學習總結和感悟，自動化測試的願景是美好的，道路是曲折的。曲折的道路不僅包括技術問題，更重要的是成本的計算、開發測試等專案組人員自動化測試意識的培養、以及整體專案的推進情況決定的。總之，自動化測試就類似於共產主義，測試人員都在期待那天的來臨，如果實在太遙遠，那就先進行社會主義初級階段，從可以推進的專案逐漸進行，將測試人員的部分工作逐漸自動化替代，實現測試人員華麗的轉身。

本文轉載自51Testing軟體測試網，檢視更多：http://www.51testing.com/html/news.html

[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1060339/，如需轉載，請註明出處，否則將追究法律責任。