自動測試檢視原始碼討論檢視歷史
 |
一般是指軟件測試的自動化，軟件測試就是在預設條件下運行系統或應用程序，評估運行結果，預先條件應包括正常條件和異常條件。自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例並通過評審之後，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。
摺疊編輯本段工具介紹
摺疊QTP
全名HP QuickTest Professional software ，並更名為Unified Functional Testing
QTP是quicktest Professional的簡稱，是一種自動測試工具。使用QTP的目的是想用它來執行重複的手動測試，主要是用於回歸測試和測試同一軟件的新版本。因此你在測試前要考慮好如何對應用程序進行測試，例如要測試那些功能、操作步驟、輸入數據和期望的輸出數據等
QuickTest針對的是GUI應用程序，包括傳統的Windows應用程序，以越來越流行的Web應用。它可以覆蓋絕大多數的軟件開發技術，簡單高效，並具備測試用例可重用的特點。其中包括:創建測試、插入檢查點、檢驗數據、增強測試、運行測試、分析結果和維護測試等方面。
摺疊WinRunner
Mercury Interactive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄製、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對複雜的企業級應用的不同發布版進行測試，提高測試人員的工作效率和質量，確保跨平台的、複雜的企業級應用無故障發布及長期穩定運行。
企業級應用可能包括Web應用系統，ERP系統，CRM系統等等。這些系統在發布之前，升級之後都要經過測試，確保所有功能都能正常運行，沒有任何錯誤。如何有效地測試不斷升級更新且不同環境的應用系統，是每個公司都會面臨的問題。
摺疊RationalRobot
是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。它集成在測試人員的桌面IBM Rational Test Manager上，在這裡測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。這種測試和管理的雙重功能是自動化測試的理想開始。
摺疊AdventNetQEngine
AdventNet QEngine是一個應用廣泛且獨立於平台的自動化軟件測試工具，可用於Web功能測試、web性能測試、Java應用功能測試、Java API測試、SOAP測試、回歸測試和Java應用性能測試。支持對於使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、傳統客戶端/服務器等開發的應用程序進行測試。此工具以Java開發，因此便於移植和提供多平台支持。
摺疊SilkTest
是業界領先的、用於對企業級應用進行功能測試的產品，可用於測試Web、Java或是傳統的C/S結構。SilkTest提供了許多功能，使用戶能夠高效率地進行軟件自動化測試。這些功能包括:測試的計劃和管理;直接的數據庫訪問及校驗;靈活、強大的4Test腳本語言，內置的恢復系統(Recovery System);以及具有使用同一套腳本進行跨平台、跨瀏覽器和技術進行測試的能力。
摺疊QARun
QARun的測試實現方式是通過鼠標移動、鍵盤點擊操作被測應用，即而得到相應的測試腳本，對該腳本可以進行編輯和調試。在記錄的過程中可針對被測應用中所包含的功能點進行基線值的建立，換句話說就是在插入檢查點的同時建立期望值。在這裡檢查點是目標系統的一個特殊方面在一特定點的期望狀態。通常，檢查點在QARun提示目標系統執行一系列事件之後被執行。檢查點用於確定實際結果與期望結果是否相同
摺疊TestPartner
是一個自動化的功能測試工具，它專為測試基於微軟、Java和Web技術的複雜應用而設計。它使測試人員和開發人員都可以使用可視的腳本編制和自動嚮導來生成可重複的測試，用戶可以調用VBA的所有功能，並進行任何水平層次和細節的測試。TestPartner的腳本開發採用通用的、分層的方式來進行。沒有編程知識的測試人員也可以通過TestPartner的可視化導航器來快速創建測試並執行。通過可視的導航器錄製並回放測試，每一個測試都將被展示為樹狀結構，以清楚地顯現測試通過應用的路徑。
摺疊Holodeck
-強大的故障植入軟件測試工具
Holodeck is an advanced fault-injection tool that gives you the power to attack an application while it monitors and logs everything your application does - every function call, registry entry, piece of data read or written.
摺疊TelelogicTAU
TAU第二代包含三個最新的、最強大的技術用來加速大規模軟件開發和測試:統一建模語言(UML)及它的許多最新修訂版本中的特性，UML2.0;功能強大的測試語言TTCN-3和新的構造系統的方法:Model Driven Architecture(模型驅動構架)。這三個新的業界標準結合成TAU的已經過認可的軟件開發平台，形成了一個系統，一個一流的穩定可靠的工具解決方案。TAU第二代是系統與軟件開發解決方案的一個突破，它把業界從使用了太長時間的手工、易出錯、以代碼為中心的方法中釋放出來，自然而然地邁向下一步，一個更加可視化、自動化及可靠的開發方法。Telelogic TAU/Tester是基於通用測試語言TTCN-3,用於自動化的系統和集成測試的強大工具。TAU/Tester以現代化的開發工具為基礎，提供高層測試功能，支持整個測試生命周期，加速自動化測試。TAU/Tester可使用戶特別關注於測試的開發，因為TTCN-3語言是獨立於開發語言或測試設備的，且是抽象和可移植的。
摺疊AutoRunner
AutoRunner是黑盒測試工具，可以用來完成功能測試、回歸測試，可以提高測試效率，降低測試人工成本。
產品可以對以下類型對象進行GUI功能性測試:
1 Windows類型對象，一般為用C++/Delphi/VB/VFP/PB/.NetForm等技術開發的桌面程序。
2 IE網頁對象，一般性的網站，比如大的門戶類網站。
3 Java對象，一般為用AWT/Swing/SWT等技術開發的桌面程序。
4 Flex對象，網頁的內容是用Flex開發的。
5 Silverlight對象，網頁的內容是用Silverlight開發的。
6 WPF對象，一般為用WPF技術開發的桌面程序。
7 QT對象，一般為用QT技術開發的桌面程序。
摺疊PhoenixFramework
Phoenix Framework是一款基於 Selenium，Webdriver，autoIt研發的一款集資源管理和測試於一體的Web自動化測試工具。最新版本是1.1.8，該工具支持無腳本執行模式，無人值守執行模式，自由定製模式。不僅執行模式可以定製，功能模塊也支持定製。使用該工具的界面創建用例，組裝腳本，啟動執行。使用該工具其他開放的接口，可手動創建腳本，組裝並執行。它支持兩種部署模式，第一種是Server-Client方式，Server與Client均為EXE程序，通信協議是Socket;另一種是WEB版部署，方便與現有系統集成，支持Linux，將Server與Client放到Tomcat或Weblogic服務器下部署，通信協議為Http，通過WEB頁面控制並監控Client端的執行。
摺疊編輯本段前提條件
實施自動化測試之前需要對軟件開發過程進行分析，以觀察其是否適合使用自動化測試。通常需要同時滿足以下條件:
1) 需求變動不頻繁
測試腳本的穩定性決定了自動化測試的維護成本。如果軟件需求變動過於頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試腳本，而腳本的維護本身就是一個代碼開發的過程，需要修改、調試，必要的時候還要修改自動化測試的框架，如果所花費的成本不低於利用其節省的測試成本，那麼自動化測試便是失敗的。
項目中的某些模塊相對穩定，而某些模塊需求變動性很大。我們便可對相對穩定的模塊進行自動化測試，而變動較大的仍是用手工測試。
2) 項目周期足夠長
自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成，這樣的過程本身就是一個測試軟件的開發過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，那麼自動化測試便成為笑談。
3) 自動化測試腳本可重複使用
如果費盡心思開發了一套近乎完美的自動化測試腳本，但是腳本的重複使用率很低，致使其間所耗費的成本大於所創造的經濟價值，自動化測試便成為了測試人員的練手之作，而並非是真正可產生效益的測試手段了。
另外，在手工測試無法完成，需要投入大量時間與人力時也需要考慮引入自動化測試。比如性能測試、配置測試、大數據量輸入測試等。
摺疊編輯本段適用場合
通常適合於軟件測試自動化的場合:
(1)回歸測試，重複單一的數據錄入或是擊鍵等測試操作造成了不必要的時間浪費和人力浪費;
(2)此外測試人員對程序的理解和對設計文檔的驗證通常也要藉助於測試自動化工具;
(3)採用自動化測試工具有利於測試報告文檔的生成和版本的連貫性;
(4)自動化工具能夠確定測試用例的覆蓋路徑，確定測試用例集對程序邏輯流程和控制流程的覆蓋。
隨着測試流程的不斷規範以及軟件測試技術的進一步細化，軟件測試自動化已經日益成為一支不可忽視的力量。能否藉助於這支外在力量以及如何藉助於這支力量來規範企業測試流程、提高特定測試活動的效率，正是本期所要討論的話題。
軟件測試自動化的研究領域主要集中在軟件測試流程的自動化管理以及動態測試的自動化(如單元測試、功能測試以及性能方面)。在這兩個領域，與手工測試相比，測試自動化的優勢是明顯的。首先自動化測試可以提高測試效率，使測試人員更加專注於新的測試模塊的建立和開發，從而提高測試覆蓋率;其次，自動化測試更便於測試資產的數字化管理，使得測試資產在整個測試生命周期內可以得到復用，這個特點在功能測試和回歸測試中尤其具有意義;此外，測試流程自動化管理可以使機構的測試活動開展更加過程化，這很符合CMMI過程改進的思想。根據OppenheimerFunds的調查，在2001年前後的3年中，全球範圍內由於採用了測試自動化手段所實現的投資回報率高達1500%。
摺疊編輯本段選型原則
然而存在優勢是否就一定意味着選擇自動化測試方案都能為企業帶來效益回報呢?也不盡然，任何一種產品化的測試自動化工具，都可能存在與某具體項目不甚貼切的地方。再加上，在企業內部通常存在許多不同種類的應用平台，應用開發技術也不盡相同，甚至在一個應用中可能就跨越了多種平台;或同一應用的不同版本之間存在技術差異。所以選擇軟件測試自動化方案必須深刻理解這一選擇可能帶來的變動、來自諸多方面的風險和成本開銷。
以下筆者給出企業用戶進行軟件測試自動化方案選型的參考性原則，這些原則是從筆者實際工作中凝練而成的，它包括以下六個方面的建議:
●選擇儘可能少的自動化產品覆蓋儘可能多的平台，以降低產品投資和團隊的學習成本;
●測試流程管理自動化通常應該優先考慮，以滿足為企業測試團隊提供流程管理支持的需求;
●在投資有限的情況下，性能測試自動化產品將優先於功能測試自動化被考慮;
●在考慮產品性價比的同時，應充分關注產品的支持服務和售後服務的完善性;
●儘量選擇趨於主流的產品，以便通過行業間交流甚至網絡等方式獲得更為廣泛的經驗和支持;
●應對測試自動化方案的可擴展性提出要求，以滿足企業不斷發展的技術和業務需求。
摺疊編輯本段過程
自動化測試與軟件開發過程從本質上來講是一樣的，無非是利用自動化測試工具(相當於軟件開發工具)，經過對測試需求的分析(軟件過程中的需求分析)，設計出自動化測試用例(軟件過程中的需求規格)，從而搭建自動化測試的框架(軟件過程中的概要設計)，設計與編寫自動化腳本(詳細設計與編碼)，測試腳本的正確性，從而完成該套測試腳本(即主要功能為測試的應用軟件)。
1) 自動化測試需求分析。
當測試項目滿足了自動化的前提條件，並確定在該項目中需要使用自動化測試時，我們便開始進行自動化測試需求分析。此過程需要確定自動化測試的範圍以及相應的測試用例、測試數據，並形成詳細的文檔，以便於自動化測試框架的建立。
2)自動化測試框架的搭建。
所謂自動化測試框架便是像軟件架構一般，定義了在使用該套腳本時需要調用哪些文件、結構，調用的過程，以及文件結構如何劃分。
而根據自動化測試用例，我們很容易能夠定位出自動化測試框架的典型要素:
a. 公用的對象。
不同的測試用例會有一些相同的對象被重複使用，比如窗口、按鈕、頁面等。這些公用的對象可被抽取出來，在編寫腳本時隨時調用。當這些對象的屬性因為需求的變更而改變時，只需要修改該對象屬性即可，而無需修改所有相關的測試腳本。
b. 公用的環境。
各測試用例也會用到相同的測試環境，將該測試環境獨立封裝，在各個測試用例中靈活調用，也能增強腳本的可維護性。
c. 公用的方法。
當測試工具沒有需要的方法時，而該方法又會被經常使用，我們便需要自己編寫該方法，以方便腳本的調用。
d. 測試數據。
也許一個測試用例需要執行很多個測試數據，我們便可將測試數據放在一個獨立的文件中，由測試腳本執行到該用例時讀取數據文件，從而達到數據覆蓋的目的。
在該框架中需要將這些典型要素考慮進去，在測試用例中抽取出公用的元素放入已定義的文件，設定好調用的過程。
摺疊編輯本段腳本編寫
該編寫過程便是具體的測試用例的腳本轉化。初學的自動化測試人員均會使用錄製腳本到修改腳本的過程。但專業化的建議是以錄製為參考,以編寫腳本為主要行為，以避免錄製腳本帶來的冗餘、公用元素的不可調用、腳本的調試複雜等問題。
摺疊編輯本段測試運行
事實上，當每一個測試用例所形成的腳本通過測試後，並不意味着執行多個甚至所有的測試用例就不會出錯。輸入數據以及測試環境的改變，都會導致測試結果受到影響甚至失敗。而如果只是一個個執行測試用例，也僅能被稱作是半自動化測試，這會極大的影響自動化測試的效率，甚至不能滿足夜間自動執行的特殊要求。
因此，腳本的測試與試運行極為重要，它需要詳查多個腳本不能依計劃執行的原因，並保證其得到修復。同時他也需要經過多輪的腳本試運行，以保證測試結果得一致性與精確性。
自動化測試引入的原因是就把軟件測試人員從枯燥乏味的機械性手工測試勞動中解放出來，以自動化測試工具取而代之，使測試人員的精力真正花在提高軟件產品質量本身。
摺疊編輯本段注意事項
首先，一個企業實施測試自動化，絕對不是拍腦袋說干就能幹好的，它不僅涉及測試工作本身流程上、組織結構上的調整與改進，甚至也包括需求、設計、開發、維護及配置管理等其他方面的配合。如果對這些必要的因素沒有考慮周全的話，必然在實施過程中處處碰壁，既定的實施方案也無法開展。其次，儘管自動化測試可以降低人工測試的工作量，但並不能完全取代手工測試。100%的自動化測試只是一個理想目標，根據筆者的經驗，即便一些如SAP、OracleERP等測試庫規劃十分完善的套件，其測試自動化率也不會超過70%。所以一味追求測試自動化只會給企業帶來運作成本的急劇上升。再次，實施測試自動化需要企業有相對規模的投入，對企業運作來說，投入回報率將是決定是否實施軟件測試自動化的最終指揮棒，筆者建議企業在決定實施軟件測試自動化之前，必須要做量化的投資回報分析。此外，實施軟件測試自動化並不意味着必須採購強大的自動化軟件測試工具或自動化管理平台，畢竟軟件質量的保證不是依靠產品或技術，更多的因素在於高素質的人員和合理有效的流程。
定 義
人為驅動測試為轉為機器執行過程
視頻
自動化測試成敗的關鍵:自動化測試思維,你具備嗎?自動化測試到底有用沒用?