qileilove

　　軟件自動化測試

　　自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例并通過評審之后，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。

　　前提條件

　　實施自動化測試之前需要對軟件開發過程進行分析，以觀察其是否適合使用自動化測試。通常需要同時滿足以下條件：

　　1）軟件需求變動不頻繁

　 　測試腳本的穩定性決定了自動化測試的維護成本。如果軟件需求變動過于頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試腳本，而腳本的維護 本身就是一個代碼開發的過程，需要修改、調試，必要的時候還要修改自動化測試的框架，如果所花費的成本不低于利用其節省的測試成本，那么自動化測試便是失 敗的。

　　項目中的某些模塊相對穩定，而某些模塊需求變動性很大。我們便可對相對穩定的模塊進行自動化測試，而變動較大的仍是用手工測試。

　　2）項目周期足夠長

　　自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成，這樣的過程本身就是一個測試軟件的開發過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，那么自動化測試便成為笑談。

　　3）自動化測試腳本可重復使用

　　如果費盡心思開發了一套近乎完美的自動化測試腳本，但是腳本的重復使用率很低，致使其間所耗費的成本大于所創造的經濟價值，自動化測試便成為了測試人員的練手之作，而并非是真正可產生效益的測試手段了。

　　另外，在手工測試無法完成，需要投入大量時間與人力時也需要考慮引入自動化測試。比如性能測試、配置測試、大數據量輸入測試等。

　　適用場合

　　通常適合于軟件測試自動化的場合：

　?。?）回歸測試，重復單一的數據錄入或是擊鍵等測試操作造成了不必要的時間浪費和人力浪費；

　?。?）此外測試人員對程序的理解和對設計文檔的驗證通常也要借助于測試自動化工具；

　　（3）采用自動化測試工具有利于測試報告文檔的生成和版本的連貫性；

　?。?）自動化工具能夠確定測試用例的覆蓋路徑，確定測試用例集對程序邏輯流程和控制流程的覆蓋；

　　隨著測試流程的不斷規范以及軟件測試技術的進一步細化，軟件測試自動化已經日益成為一支不可忽視的力量。能否借助于這支外在力量以及如何借助于這支力量來規范企業測試流程、提高特定測試活動的效率，正是本期所要討論的話題。

　　目前，軟件測試自動化的研究領域主要集中在軟件測試流程的自動化管理以及動態測試的自動化（如單元測試、功能測試以 及性能測試方面）。在這兩個領域，與手工測試相比，測試自動化的優勢是明顯的。首先自動化測試可以提高測試效率，使測試人員更加專注于新的測試模塊的建立 和開發，從而提高測試覆蓋率；其次，自動化測試更便于測試資產的數字化管理，使得測試資產在整個測試生命周期內可以得到復用，這個特點在功能測試和回歸測 試中尤其具有意義；此外，測試流程自動化管理可以使機構的測試活動開展更加過程化，這很符合CMMI過程改進的思想。根據OppenheimerFunds的調查，在2001年前后的3年中，全球范圍內由于采用了測試自動化手段所實現的投資回報率高達1500%。

　　方案選型六大原則

　 　然而存在優勢是否就一定意味著選擇自動化測試方案都能為企業帶來效益回報呢？也不盡然，任何一種產品化的測試自動化工具，都可能存在與某具體項目不甚貼 切的地方。再加上，在企業內部通常存在許多不同種類的應用平臺，應用開發技術也不盡相同，甚至在一個應用中可能就跨越了多種平臺；或同一應用的不同版本之 間存在技術差異。所以選擇軟件測試自動化方案必須深刻理解這一選擇可能帶來的變動、來自諸多方面的風險和成本開銷。

　　以下筆者給出企業用戶進行軟件測試自動化方案選型的參考性原則，這些原則是從筆者實際工作中凝練而成的，它包括以下六個方面的建議：

　　●選擇盡可能少的自動化產品覆蓋盡可能多的平臺，以降低產品投資和團隊的學習成本；

　　●測試流程管理自動化通常應該優先考慮，以滿足為企業測試團隊提供流程管理支持的需求；

　　●在投資有限的情況下，性能測試自動化產品將優先于功能測試自動化被考慮；

　　●在考慮產品性價比的同時，應充分關注產品的支持服務和售后服務的完善性；

　　●盡量選擇趨于主流的產品，以便通過行業間交流甚至網絡等方式獲得更為廣泛的經驗和支持；

　　●應對測試自動化方案的可擴展性提出要求，以滿足企業不斷發展的技術和業務需求。

　　過程

　　自動化測試與軟件開發過程從本質上來講是一樣的，無非是利用自動化測試工具（相當于軟件開發工具），經過對測試需求的分析（軟件過程中的需求分 析），設計出自動化測試用例（軟件過程中的需求規格），從而搭建自動化測試的框架（軟件過程中的概要設計），設計與編寫自動化腳本（詳細設計與編碼），測 試腳本的正確性，從而完成該套測試腳本（即主要功能為測試的應用軟件）。

　　1）自動化測試需求分析。

　　當測試項目滿足了自動化的前提條件，并確定在該項目中需要使用自動化測試時，我們便開始進行自動化測試需求分析。此過程需要確定自動化測試的范圍以及相應的測試用例、測試數據，并形成詳細的文檔，以便于自動化測試框架的建立。

　　2）自動化測試框架的搭建。

　　所謂自動化測試框架便是像軟件架構一般，定義了在使用該套腳本時需要調用哪些文件、結構，調用的過程，以及文件結構如何劃分。

　　而根據自動化測試用例，我們很容易能夠定位出自動化測試框架的典型要素：

　?。╝）公用的對象。

　　不同的測試用例會有一些相同的對象被重復使用，比如窗口、按鈕、頁面等。這些公用的對象可被抽取出來，在編寫腳本時隨時調用。當這些對象的屬性因為需求的變更而改變時，只需要修改該對象屬性即可，而無需修改所有相關的測試腳本。

　?。╞）公用的環境。

　　各測試用例也會用到相同的測試環境，將該測試環境獨立封裝，在各個測試用例中靈活調用，也能增強腳本的可維護性。

　?。╟）公用的方法。

　　當測試工具沒有需要的方法時，而該方法又會被經常使用，我們便需要自己編寫該方法，以方便腳本的調用。

　?。╠）測試數據。

　　也許一個測試用例需要執行很多個測試數據，我們便可將測試數據放在一個獨立的文件中，由測試腳本執行到該用例時讀取數據文件，從而達到數據覆蓋的目的。

　　在該框架中需要將這些典型要素考慮進去，在測試用例中抽取出公用的元素放入已定義的文件，設定好調用的過程。

　　探索性測試可以說是一種測試思維技術。它沒有很多實際的測試方法、技術和工具，但是卻是所有測試人員都應該掌握的一種測試思維方式。探索性強調測試人員的主觀能動性，拋棄繁雜的測試計劃和測試用例設計過程，強調在碰到問題時及時改變測試策略。

　　對探索性測試最直白的定義是：同時設計測試和執行測試。探索性測試有時候會與即興測試（ad hoc testing）混淆。即興測試通常是指臨時準備的、即興的Bug搜索測試過程。從定義可以看出，誰都可以做即興測試。由Cem Kaner提出的探索性測試，相比即興測試是一種精致的、有思想的過程。

　　在對測試對象進行測試的同時學習測試對象并設計測試，在測試過程中運用獲得的關于測試對象的信息設計新的更好的測試。

　　探索性測試

　　探索性測試強調測試設計和測試執行的同時性，這是相對于傳統軟件測試過程中嚴格的“先設計，后執行”來說的。測試人員通過測試來不斷學習被測系統，同時把學習到的關于軟件系統的更多信息通過綜合的整理和分析，創造出更多的關于測試的主意。

　　探索性測試的基本過程

　　探索性測試識別軟件系統的目的；

　　識別軟件系統提供的功能；

　　識別軟件系統潛在的不穩定的區域；

　　在探索軟件系統的過程中記錄關于軟件的信息和問題；

　　探索式軟件測試一共分為自由式探索式測試、基于場景的探索式測試、基于策略的探索式測試和基于反饋的探索式測試。下面將詳細介紹4種類型的應用場景。

　　一：自由式探索式測試

　　自由式探索式測試指的是對一個應用程序的所有功能，以任意次序、使用任何如數進行隨機探測，而不考慮哪些功能是否必須包括在內。自由式測試沒有 任何規則和模式、只是不停的去做。很不幸，很多人認為所有的探索式測試都是自由式的，從長遠的觀點來看，這種看法低估了探索式測試技術的能力，我們在隨后 將看到這類測試的一些變種。

　　一個自由測試用例可能會被選中成為一個快速的冒煙測試，用它來檢查是否會找到重大的崩潰或者嚴重的軟件缺陷，或是在采用先進的技術之前通過它來 熟悉一個應用程序。顯然，自由式探索式測試無需也不應該進行大量的準備規則。事實上，它更像是“探索”而不是“測試”，所以我們應當相應的調整對它的期望 值。

　　自由式測試不需要多少經驗或者信息。但是，同以下提到的探索式技術相結合后，它將成為一個非常強大的測試工具。

　　二：基于場景的探索式測試

　　基于場景的探索式測試和傳統的基于場景的測試有類似之處。兩者都涉及到一個開商店，就是用戶故事或者是文檔化得端到端場景的開始之處，那也是我 們所期望的最終用戶開始執行應用程序的地方。這些場景可以來自用戶研究、應用程序、以前版本的數據等，并作為腳本用于測試軟件。探索式測試對傳統場景測試 的補充吧腳本的應用范圍擴大到了更改、調查和改變用戶執行路徑的范疇。

　　使用場景作為指導的探索式測試人員經常會修改他感興趣的輸入或者是追尋一些并沒有包括在腳本中的潛在副作用。不過，由于最終的不表是完成給出的場景，這些測試上的彎路、最終總是會回到腳本文件記載的用戶主要執行路徑。

　　三：基于策略的探索式測試

　　將自由式測試探索式與具有測試老手的經驗、技能和感知融合在一起，就成為基于策略的探索式測試。它屬于自由式的探索，只是他是在現有的錯誤搜索 技術下引導完成的。基于策略的探索式測試應用所有的已知技術（如邊界值分析或組合測試）和未知的本能（如異常處理往往容易出現軟件缺陷），來指導測試人員 進行測試。

　　這些已知的策略是基于策略的探索式測試成功的關鍵，存儲的測試知識越豐富，測試就會更有效率。這些策略緣于積累下來的知識，它們指導軟件缺陷隱藏在哪里，如何綜合人工輸入數據，那些代碼路徑常常出現故障。

　　基于策略的探索式測試結合了測試老手的經驗和探索型測試人員的隨機性。

　　四：基于反饋的探索式測試

　　基于反饋的探索式測試緣于自由式測試，但是隨著測試歷史的形成，測試人員們就會利用反饋來指導今后的探索。“覆蓋”就是典型的例子。一名測試人 員通過咨詢那些覆蓋指標（代碼覆蓋、用戶界面覆蓋、特性覆蓋、輸入覆蓋或者其中的某一些組合）來選中新的測試用例，以使這些覆蓋指標得以提高。覆蓋指標只 是收錄反饋信息的標志之一。我們也會看其他標志，如代碼改動數量和軟件缺陷密集程度等。

　　基于反饋的探索式測試時一種“上一次測試”：在上一次我根據應用程序的最后狀態選了每某一個輸入之后、下一次我就會選中另外一個輸入。或者是，在上一次遇到這個界面時我用A屬性，這一次我就會用B屬性。

　　基于反饋的探索式測試工具是非常有價值的，它可以是測試人員保存、搜索測試歷史并據此采取實時行動。不幸的是這樣的工具很少。

　　自動化測試（AT）與探索性測試（ET）

　　自動化測試在目前得到了越來越普遍的應用，自動化測試的優勢也越來越明顯。對于需求比較固定的功能，使用自動化測試工具通過編寫自動化測試代 碼。可以在以后得到多次的使用。這給回歸測試帶來了極大的方便性。也為持續集成（CI）的提供了很好的基礎。看來自動化測試是軟件測試領域中一項重大的革 命。

　　然而，自動化測試畢竟考慮時間有限，并且受到了一定的測試思想的制約，不可能在一次的測試設計中就能夠就能夠設計得很全面。另外自動測試對于測 試正常流程往往考慮的比較周全，而對于異常流程往往考慮得不是十分的充分。而對于一個有經驗的測試工程師來說，bug往往在處理異常流程的時候被經常發 現，另外好些缺陷往往在一些怪異的，不確定的操作后出現。所以有了自動化測試腳本作為支撐，探索性測試（ET）的作用不可忽略。保證一個產品好的質量，既 要依賴自動化測試工具，另外人工為主的探索性測試也不可以遺漏，這樣軟件的質量才可真正得到保障。

版權聲明：本文出自 jerrygu625 的51Testing軟件測試博客：http://www.51testing.com/?162585

原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。