❶ 什麼是自動化測試
一般是指軟體測試的自動化，軟體測試就是在預設條件下運行系統或應用程序，評估運行結果，預先條件應包括正常條件和異常條件。自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。
基本信息
中文名稱
自動化測試
外文名稱
Test
定 義
人為驅動測試為轉為機器執行過程
應 用
軟體測試的自動化
工 具
QTP
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例並通過評審之後，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬體資源，提高測試效率，便引入了自動化測試的概念。
折疊編輯本段工具介紹
折疊QTP
全名HP QuickTest Professional software ，2012年12月6日發布11.5版本，並更名為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%。所以一味追求測試自動化只會給企業帶來運作成本的急劇上升。再次，實施測試自動化需要企業有相對規模的投入，對企業運作來說，投入回報率將是決定是否實施軟體測試自動化的最終指揮棒，筆者建議企業在決定實施軟體測試自動化之前，必須要做量化的投資回報分析。此外，實施軟體測試自動化並不意味著必須采購強大的自動化軟體測試工具或自動化管理平台，畢竟軟體質量的保證不是依靠產品或技術，更多的因素在於高素質的人員和合理有效的流程。
折疊編輯本段實戰模擬
折疊背景介紹
A公司是一家大型保險公司，擁有近20個城市的分公司，並在其中5個城市建立了IT支持中心。平均每年的上線應用數量在20個左右(新業務系統和原有業務系統的主要版本發布)。A公司的專職測試團隊人數不足30人而且測試團隊的測試人員技能參差不齊測試只是作為項目上線前的一道工序而已。在測試團隊內部也幾乎沒有自動化的手段，主要依靠手工測試。由於已上線應用系統的問題，開發團隊必須分出一部分資源去維護和修復上線應用，而同時測試團隊的測試成果和效率卻無法和這些應用質量掛鉤，也更無從談起對軟體質量的控制。所以，A公司決定在軟體質量和測試方面進行投入，他們考慮以下幾方面:
●引進軟體測試流程管理的自動化，提高軟體測試過程的管理水平，使軟體測試和軟體開發一樣可被評估、被衡量。
●實現性能測試自動化，所有應用上線之前必須有應用性能風險評估報告和相關部門的確認
●逐步實現功能測試的自動化，在目前人員配置的情況下，把部分手工測試變成自動化測試，提高測試可信度，降低人為錯誤。
●通過軟體測試自動化，管理軟體測試中的案例、缺陷、報告等資產，進一步提升軟體測試的效率並建立測試基礎庫。
●在規劃中，將來的2~3年內使所有的應用系統上線都必須有數字化的測試數據作為依據。
折疊系統的情況
由於保險公司的業務種類繁多，同時在經過了幾十年的經營後，公司內的應用系統從早期的終端方式到現代的J2EE和.NET等應有盡有，魚龍混雜。IT部門已經建立的3年規劃，即在未來的3年時間內將所有終端和C/S方式的應用轉換成B/S架構，但當前仍然需要對這些舊應用系統進行維護，以保證業務的順利進行。對於開發部門來說，新應用開發基本上已經以B/S架構為主，主要是基於J2EE架構的WebHTTP應用和部分Window.NETForm的應用。
折疊公司現狀
企業機構在做測試自動化選型時一定要考慮清楚企業內部哪些部分可以實施自動化、哪些部分暫不實施自動化、哪些部分僅在某幾個項目做自動化試點。切忌匆忙上馬或盲目否定，缺乏實事求是的理性思考。
測試部門僅負責系統測試和對用戶驗證測試進行管理，對於之前的單元測試和集成測試主要由開發團隊中劃分出的一部分臨時測試人員完成。由於缺乏監測手段，測試部門也無法收集和確定集成測試和單元測試的完成情況，在整個軟體測試過程中，業務需求是由開發部門通過RationalRequisitePro進行管理，但測試需求尚沒有提出要求，測試案例主要通過在公司公用的文件伺服器中的目錄管理方式管理，對測試中缺陷流程等管理主要依靠郵件的流轉進行處理90%以上的測試是通過Excel和Word等測試案例文檔來完成，測試人員對軟體測試自動化的認識僅停留在"記錄+回放"的認識上。
折疊方案
方案A:A公司可以採用美科利(Mercury)公司產品為主的軟體測試自動化方案。
●依照原先的郵件流轉過程配置TestDirector缺陷管理流程，為每個保險業務的開發小組和測試團隊分配相應的用戶許可證，取消原有郵件方式。
●部署MercuryQuickTestProfessional，以便完成應用程序相關功能測試。
●部署MercuryLoad-Runner。從測試團隊中分化出專職的性能測試自動化工程師和小組，和業務部門協調，建立A公司應用系統上線性能指標，通過LoadRunner給出測試指標。
●建議A公司成立專門的質量控制部門，對TestDirector中的數據定期進行分析，建立相關質量模型，以便於企業量化管理和過程改進。
方案B:A公司也可以採用IBMRational產品為主的軟體測試自動化方案。
●採用RationalTestmanager來進行整個測試流程的管理，為相關開發和測試小組成員分配相應許可權，改變以前通過郵件以及Word、Excel文檔管理測試的工作方式。
●部署RationalRobot，用它來完成功能相關的測試工作以及新版本發布時的冒煙測試。此外，RationalRobot也能較好地完成性能相關測試。統一的操作方式降低了工具的學習周期和培訓帶來的大筆開銷。
●部署RationalPurifyplus，使測試工作前移到開發階段。由於Purifyplus能較好地支持白盒測試，編程人員在編碼階段引入的錯誤能盡早被檢測到，這大幅降低了後期測試的開銷。
●建議A公司成立專門的質量控制部門，對Testmanager中的數據定期進行分析，建立相關質量模型，以便於企業量化管理和過程改進。
方案C:A公司也可以採用開源軟體為主的軟體測試自動化方案。
●採用Bugzilla來進行Bug跟蹤管理，採用BugzillaTestRunner進行測試用例管理，採用CVS進行測試資源的配置管理。
●採用MaxQ和WebInject對B/S結構的應用系統進行功能測試。
●採用DBMonster、Open-STA、LoadSim進行性能相關測試。
●可採用Xunit架構的開源工具對不同語言的程序單元進行單元測試。
●建議A公司成立專門的開源軟體維護小組，以解決可能會碰到的工具維護工作。
●建議A公司成立專門的質量控制部門，對Bugzilla、TestRunner、CVS中的數據定期進行分析，建立相關質量模型，以便於企業量化管理和過程改進。
折疊方案評價
由於不同客戶在組織架構、員工素質以及流程管理水平等方面的不同，我們很難用一個實例、一兩句話來說明不同解決方案的適用性。在上面的例子中，筆者給出了3種可行的方案，具體選擇哪一個，需要仔細權衡。這里筆者給出一般性的意見，對於不想受制於某個測試自動化廠家的企業，開源絕對是一個理想的選擇。此外，它不需要支付成本，工具的源代碼可以隨意修改，因而具有較好的靈活性。但開源工具的弊端也是明顯的:缺乏使用培訓和技術支持，工具的用戶界面一般也較為粗糙。而對於那些比較看重培訓和售後支持的企業，筆者建議選擇IBMRational或Mercury或其他廠家的產品。這樣雖然需要支付一部分費用，但省去了工具維護所需要的大量工作。至於具體選擇哪個廠家的產品為好，筆者尚無結論性意見。相信讀者朋友都有一些見仁見智的看法，不妨來信交流。
❷ 如何提高 GUI 測試的穩定性
GUI自動化測試穩定性，最典型的表現形式就是，同樣的測試用例在同樣的環境上，時而測試通過，時而測試失敗。
造成GUI測試不穩定的五種因素：
非預計的彈出對話框
頁面控制項屬性的細微變化
被測系統的A/B測試
隨記的頁面延遲造成控制項識別失敗
測試數據問題
對於這幾種因素的解決思路：
非預計的彈出對話框
非預計的彈出對話框一般包含兩種情況：
GUi自動化測試用例執行過程中，操作系統彈出的飛魚級對話框。
被測軟體本身也有可能在非預期的時間彈出預計的對話框。
解決方法：
當自動化腳本發現控制項無法正常定位，或者無法操作時，GUI自動化框架自動進入「異常場景恢復模式」。在「異常場景恢復模式」下，GUI自動化框架依次檢查各種可能出現的對話框，一旦確認了對話框的類型，立即執行定義的操作，比如單機「確認」按鈕關閉這個對話框，接著重試剛才失敗的步驟。
這種方式只能處理已知可能出現的對話框。而對於新類型的對話框，只能通過自動化的方式嘗試點擊上面的按鈕進行處理。每當發現一種潛在會彈出的對話框，我們就把它的詳細信息（包括對象定位信息等）更行到「異常場景恢復」庫中，下次再遇到相同類型的對話框時，系統就可以自動關閉了。
頁面控制項屬性的細微變化
解決方法：採用「組合屬性」定位控制項會更精準，而且成功率會更高，如果能在此基礎上加入「模糊匹配」技術，可能以進一步提高控制項的識別率。
「模糊匹配」是指，通過特定的相似度演算法，控制項屬性發生細微變化是，這個控制項依舊可以被准確定位。（通常需要二次開發）
北柵系統的A/B測試
A/B測試，是互聯網產品常用的一種測試方法。它為Web和App的界面或流程提供兩個不同的版本，然後讓用戶隨記訪問其中一個版本，並收集兩個版本的用戶體驗數據和業務數據，最後分析出最好的版本用於正式發布。
A/B測試通常會發布到實際生產環境，所以就會造成生產環境中GUI自動化測試不穩定。
解決方法：在測試腳本內部對不同的被測版本做分支處理，腳本需要能夠區分A和B兩個的不同版本，並作出相應的處理。
隨記的頁面延遲造成控制項識別失敗
解決方法：加入重試（retry）機制，重試機制是指，當某一步GUI操作失敗時，框架會自動發起重試，重試可以是步驟級別的，也可以是頁面級別的，甚至是業務流程級別的。需要自己二次開發來實現。
❸ 測試中如何使用自動化腳本
從畢業到現在，經歷了軟體開發，
軟體測試，
1）QTP工具。QTP是一個快速測試專業工具。它的優點是可以快速建立企業自動化框架，但不是一個全能的工具，因為利用QTP並不能幫助用戶找出更多的 BUG，只能提高執行測試用例的效率。 QTP的價格也較貴。 QTP主要應用於較穩定的測試項目的回歸測試，UI的變化不明顯，功能較穩定的項目。它可以節省回歸測試的成本，但相對手工測試來說，QTP對測試人員的要求較高，比如要掌握VB腳本，掌握函數調用等技術；另外，建立QTP框架前期需要投入較大的人力寫測試用例，加上調試的時間，是一筆不小的開銷，所以企業在選用QTP測試工具時一定要三思而後行。
2）Loadrunner是一個企業級性能測試工具，應用十分廣泛。對於WEB應用，Loadrunner的優勢十分明顯。但與QTP一樣，lr的 License十分昂貴，所以很多企業都使用破解版。並且真正掌握LR精髓的人員並不多，很多人都會使用這個工具，但能用這個工具找出系統瓶頸的人並不多，所以，會使用Loadrunner和會性能測試是兩碼事。懂腳本語言的性能測試人員當然最好。
3）Python和Tcl/tk腳本語言。在我之前的經驗中，我用到過PYTHON和TCL。他們都是腳本語言，不需要編譯。兩種語言的特點如下：Python開發JAVA方面的http介面比較方便；tcl/tk開發C++方面的介面更容易一些。PYTHON寫的程序可讀性強，TCL寫的程序的可讀性不好。
4）在需要產生一些大批量數據時，如一個表需要插入100萬條數據，然後這100萬條數據屬於100個不同的類別，如果是手工輸入的話，估計10個人一個月都輸不完，但如果利用腳本，如PB，VB或者Tcl/tk，可以通過產生批量SQL腳本的方式，來產生SQL腳本，這樣不到半小時就可以搞定全部的數據。看來腳本的威力不小！
5）另外，就是Linuxshell腳本了，我們通常說「事半功倍」，shell腳本的確可以幫助你實現這個目的。我們平時在LINUX部署一個應用會用到很多的命令如 Checkout，ps，vi，kill等等，如果能把這個操作流程寫成一個SHELL腳本讓機器自動執行，那該是省了多少事？另外，作為 UNIX/LINUX管理員，平時可以要監控較多的PC終端，他完全可以在UNIX/LINUX上定製各種任務（如備份，刪除臨時文件，檢查磁碟空間等等），所以，掌握Shell腳本（如Sed，awk，grep等）對一個測試人員來講是十分必要的！
6）另外一個就SQL腳本了，要能寫存儲過程（SP）和觸發器（Trigger），還有游標（Cursor）的使用，掌握這些的話對於測試資料庫方面的用例是相當有幫助的。SQL腳本對系統性能和功能都起著十分重要的作用。
作為一名有6年測試經驗的工程師，我堅定地認為腳本測試技術是以後的發展方向，包括白盒測試，也是將來的一個發展方向，對於測試人員來講，核心競爭力是能完整的測試開發人員的程序，盡可能找出更多的BUG。黑盒測試只能從系統的角度去完成功能測試，但作為軟體本身，應該作更深層次的測試。
❹ 如何提高測試用例編寫效率
1.盡早參與到項目中
測試盡早介入項目詳細了解項目的業務需求，做好測試的前期准備：目前來說，可能大家都有類似的感受，接觸到的大多數的項目，都是測試周期比較短，開發人員耽誤了時間，為了不拖延項目進度，留給測試人員做測試的時間都非常緊張。如果項目測試的前期了解業務需求、了解產品屬性和准備測試數據不充分，往往測試效率很低，測試時間變長，測試效率急劇下降。
2.合理的測試計劃
首先要有一個合理的詳細的測試計劃：沒有詳細的測試計劃，測試部的每個成員都在那兒盲無目的測試，何談提高測試效率？當然測試計劃也不能夠太細，太細了，編寫測試計劃同樣浪費時間，做到時可而止。最好是測試任務盡量能細化到測試的功能較為理想。
3.要做好測試文檔的評審
測試負責人認真做好測試文檔的評審：測試經理一定要認真做好測試用例的評審，盡量使用較少的測試用例，發現較多的Bug，無疑是最佳提高效率的一種方式。很多時候，經驗較少的測試人員在設計測試用例的時候，寫了很多的測試用例，測試時幾乎沒有發現缺陷。還有一種：比如說等價類的測試，只要具備代表性就可以了，如果寫了很多測試用例，執行了半天，臃腫的測試用例，未發現任何問題，也很不值。這些主要是靠測試用例評審的時候，測試Leader去把握了。盡量做到在滿足需求的情況下，精簡測試用例數量，提高測試覆蓋率。很多時候，測試人員寫好用例就自己測試，根本沒人評審，有些地方理解有偏差，測試點沒測試到，導致發給客戶版本被退回，給公司也會帶來巨大經濟損失。
4.提高測試接受的標准，減少測試版本送測次數：
大部分公司的開發人員都有一種惰性，一旦公司成了測試部，他們自己測試時，都不會那麼認真，以為有了測試人員，就自己就解放了。很多時候都是調試編譯通過，實際上開發人員沒有做完整的自測，就拿到測試部進行測試。如果測試部門有嚴格的測試接受標准，一旦發現有重大問題，立即拒絕測試，送回開發人員修改。可以減少很多次反復測試，重復測試，明顯提高了測試效率。
5.發揮主觀能動性，積極溝通
測試工作是一項溝通要求比較高的工作，一般需要同項目經理、產品經理、開發人員、業務人員、客戶溝通。很多時候，由於測試介入較晚，測試時間短，測試初期測試人員了解需求不及開發人員，為了迅速熟悉需求，需要項目組成員之間相互培訓和溝通。測試人員為了利於測試工作，平時也需要主動和開發團隊溝通項目的進度、項目存在的問題、項目的需求變更等等情況。與團隊成員溝通得越充分、對項目的信息收集和把握得越及時、越准確，我們的測試工作才可能做得越順利，才可能提高測試效率。我們絕不能消極等待或一味埋怨開發人員的不理解和不重視。我們首先需要正視自己、改進自己，通過自身的不斷努力讓開發人員，真正體會到測試的價值。同時，也需要理解並配合開發人員的工作。只有這樣，才能贏得開發人員的支持。互相配合、互相促進，項目成員之間形成良性循環，彼此感情加深了、配合默契了、工作效率和工作質量也就自然提高了。
6.按照項目的性質大小不同，引入自動化測試工具和自動化測試腳本
是否引入自動化的測試工具，主要取決於測試的時間長短和測試的輪次。一般來說，測試周期較長、版本升級平凡和回歸測試次數較多的項目，引用測試工具可以提高測試效率。如果測試周期較短，本來測試周期只有兩三個月，開發測試腳步就要花費大量時間，引入自動化測試工具，用的次數較少，結果得不喪失，勞民傷財！
7.對測試項目前景充滿信心，調整最佳心態，保持愉悅的工作心情：
一般來說，如果大家認為測試的項目沒什麼發展前景，當然測試也不會很賣命，測試效率不用說。如果某個測試人員碰到什麼不順心的事，當天的工作效率肯定比平常低。所以，要保證測試效率，測試負責人要察言觀色，及時找不開心的下屬談心，了解並幫忙消除部分員工的不良情緒，讓員工有更好的心情投入到測試工作中去。
8.提高測試人員的專業技能和工作能力：
由於測試技術的不斷成熟和完善，許多的新技術陳出不窮，作為測試人員需要不斷提高自己的專業技能和工作技能。不斷的給自己充電，補充測試理論知識，讓自己工作技能力去彌補專業技能的不足。這樣，你的工作同樣可以做到最棒，效率自然很高。一段時間過去，回過頭來一看，自己確實進步不少，沒有虛度光陰呀！
❺ 怎麼加強自動化測試腳本的穩定性
IBM® Rational® Functional Tester 是用於功能性和回歸線測試的高級測試自動化工具，它可以在一個基於圖形化用戶界面（GUI）的程序上錄制測試場景，並回放測試場景以實現測試自動化。在錄制期間，您可以插入確認點，這些確認點可以從您正在測試的程序中獲取特定的數據或者屬性。然後在回放期間，這些確認點用來將錄制的信息，與現場信息進行比較以確保穩定性。工具會搜索映射的對象，並在測試期間對其執行一系列的操作。 但是，由於對象不存在或者不適當的狀態，Playback 特性通常會遇到一些失敗情況，在回放期間，如果 GUI 響應時間或者 GUI 到達預期狀態所花費的時間，要遠遠高於錄制時間，那麼工具所執行的操作就不能在適當的位置找到適當的對象或者它們的狀態或屬性了，這樣腳本回放就會失敗。通過按照本文中所介紹的步驟進行操作，您將會學到怎樣利用 Rational Functional Tester 程序編程界面（API），來改進腳本以實現基於 Eclipse 程序地可靠測試自動化。 前提條件 如果您擁有下述的知識，那麼您就能從本文中學到更多的信息： 熟悉 Eclipse 環境以及為測試下程序配置 Rational Functional Tester 熟悉錄制和回放測試腳本，並理解測試腳本的內容 場景 注意： 對於這些範例，IBM® Rational® Software Architect（一種基於 Eclipse 的程序）用作測試下的程序。 本文將會涉及到測試自動化中以下的失敗場景，並解釋在 Eclipse 工作區中遇到它們時的方案。 場景 1：不匹配的 GUI 響應時間 在回放期間，如果 GUI 響應時間要比錄制期間的時間長，那麼自動化工具將不會找到需要執行操作的對象，而測試腳本也將會失敗。 場景 2：未預期的活動窗口 如果在自動化測試的回放期間，出現了一個未預期的活動窗口，那麼在錄制期間該窗口將不會出現，自動化腳本將會失敗。自動化會因為未處理的窗口而停止。 場景 3：不適當的對象狀態 當您在創建確認點時，如果對象沒有處於它所預期的狀態，那麼它會獲取所有需要的具體內容。同樣，在回放期間，如果並不能確保相同的對象狀態，那麼確認點將會失敗。 圖 1 中的圖表描述了處理這些場景的基本方法。 圖 1. 方案的基本方法 方案方法基本上可以改進使用 Rational Functional Tester API 的腳本。作出的選擇能夠處理描述的場景，該場景可能發生在測試自動化場景之中。 創建 Eclipse：准備 Rational Functional Tester 以測試基於 Eclipse 的程序 為了對基於 Eclipse 的程序使用 Rational Functional Tester 自動化測試特性，您必須首先按照下面的方法來創建測試的環境： 點擊 Configure > Enable environment for testing 以打開 Enable Environments 窗口（參見圖 2）。 選擇 Eclipse 實例，並點擊 Enable。如果 Eclipse 環境尚沒有列出，那您您可以點擊 Search。 點擊 Finish 以保存您所做的修改。 圖 2. 激活環境窗口 修改代碼：根據用例來更改自動生成的代碼 在這一步中，會獲得對自動生成代碼所做的更改，以處理前面所描述的一個或者多個失敗。每一個失敗場景的解決方案，都與下述描述的子部分不同。 場景 1：不匹配的 GUI 響應時間 對於該場景有兩個可能的解決方案： 方案 1a. 檢查進度條的狀態 當您在基於 Eclipse 的程序中創建一個項目時，項目構建和確認會在項目向導完成之後才啟動，其中基於 Eclipse 的程序例如 Rational Software Architect 或者 IBM® Rational® Application Developer。有時所花費的時間要比預期的長，腳本回放會失敗，因為項目構建沒有完成，但是腳本會試著進一步地操作。為了避免這種失敗情況的發生，您可以在 Eclipse 工作區右下角查看進度條的狀態 修改代碼：根據用例來更改自動生成的代碼 在這一步中，會獲得對自動生成代碼所做的更改，以處理前面所描述的一個或者多個失敗。每一個失敗場景的解決方案，都與下述描述的子部分不同。 場景 1：不匹配的 GUI 響應時間 對於該場景有兩個可能的解決方案： 方案 1a. 檢查進度條的狀態 當您在基於 Eclipse 的程序中創建一個項目時，項目構建和確認會在項目向導完成之後才啟動，其中基於 Eclipse 的程序例如 Rational Software Architect 或者 IBM® Rational® Application Developer。有時所花費的時間要比預期的長，腳本回放會失敗，因為項目構建沒有完成，但是腳本會試著進一步地操作。為了避免這種失敗情況的發生，您可以在 Eclipse 工作區右下角查看進度條的狀態
❻ selenium webdriver 執行測試常見問題
selenium中如何保證操作元素的成功率？
如何提高selenium腳本的執行速度？
用例在運行過程中經常會出現不穩定的情況，也就是說這次可以通過，下次就沒辦法通過了，如何去提升用例的穩定性？
你的自動化用例的執行策略是什麼？
❼ 自動化測試的前提條件
實施自動化測試之前需要對軟體開發過程進行分析，以觀察其是否適合使用自動化測試。通常需要同時滿足以下條件：
1) 需求變動不頻繁
測試腳本的穩定性決定了自動化測試的維護成本。如果軟體需求變動過於頻繁，測試人員需要根據變動的需求來更新測試用例以及相關的測試腳本，而腳本的維護本身就是一個代碼開發的過程，需要修改、調試，必要的時候還要修改自動化測試的框架，如果所花費的成本不低於利用其節省的測試成本，那麼自動化測試便是失敗的。
項目中的某些模塊相對穩定，而某些模塊需求變動性很大。我們便可對相對穩定的模塊進行自動化測試，而變動較大的仍是用手工測試。
2) 項目周期足夠長
自動化測試需求的確定、自動化測試框架的設計、測試腳本的編寫與調試均需要相當長的時間來完成，這樣的過程本身就是一個測試軟體的開發過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，那麼自動化測試便成為笑談。
3) 自動化測試腳本可重復使用
如果費盡心思開發了一套近乎完美的自動化測試腳本，但是腳本的重復使用率很低，致使其間所耗費的成本大於所創造的經濟價值，自動化測試便成為了測試人員的練手之作，而並非是真正可產生效益的測試手段了。
另外，在手工測試無法完成，需要投入大量時間與人力時也需要考慮引入自動化測試。比如性能測試、配置測試、大數據量輸入測試等。
❽ 測試用例穩定性是指什麼
穩定性測試的概念有2種，
一， 穩定性測試，對應於異常性測試，即發生異常情況時，系統如何反應的測試。包含：
1 交互性測試，被打擾的情況，如來電，簡訊，低電量等。這些其實在上章的功能測試中有提到。
2 異常性測試，斷網，斷電，伺服器異常等情況
二，穩定性測試指的是性能測試，壓力測試
1 基準性能測試，通過壓伺服器埠及客戶端在不同網路環境下響應速度
2 大數據測試，在特定環境下，客戶端一次性更新大量數據及人員列表
另有其它文章，提到性能測試，為評估APP的時間和空間特性（真是高深啊，時間和空間，再來個4維，5維？），包括：
1 極限測試：在各種邊界壓力情況下，如電池，存儲，網速等，驗證app是否能正確響應
--內存滿時安裝app
--運行app手機斷電
--運行app時斷掉網路
這幾點倒是與第一條的內容重復
2 響應能力測試：測試app中的各類操作是否滿足用戶響應時間要求
--app安裝 ，卸載的響應時間
--app各類功能性操作的影響時間
3 壓力測試：反復、長期操作下，系統資源是否佔用異常
--app反復進行安裝卸載，查看系統資源是否正常（弄個幾次就行吧，正常人，誰反復安裝卸載啊）
--其它功能反復進行操作，查看系統資源是否正常（這倒是應該的）
4 性能評估：評估典型用戶應用場景下，系統資源的使用情況
這里要定義，什麼是典型用戶應用場景
5 benchmark測試（基線測試），應該不是基準性能測試：與競爭產品的benchmarking，產品演變對比測試等（沒有多大意義）。
簡要步驟：adb devices---了解包名--adb shell monkey -p 包名 -v 運行次數（多個參數的組合形成不同的用例以求最大的覆蓋）--當崩潰或無響應時分析monkey日誌
常規monkey命令（可直接在項目里使用）:
adb shell monkey -p com.jiochat.jiochatapp --throttle 100 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 1000000>d:\b.log
重現bug：monkey日誌搜索關鍵詞ANR exception，將之前的事件重新操作，尤其是seed值要一模一樣，如monkey -p 包名 -v seed 0 500
日誌分析：查看是否有crash等關鍵字，找上下文，進行簡單分析將你所能定位的錯誤信息發給開發。
該工具用於進行壓力測試。 開發人員結合monkey 列印的日誌 和系統列印的日誌，修改測試中出現的問題。Monkey 是SDK中附帶的一個工具,所有的事件都是隨機產生的，不帶任何人的主觀性。
❾ 用例在運行過程中會出現不穩定的情況，不一定每次都可以通過。該去提升用例的穩定性
測試用例： 1、熟悉業務需求。 2、在熟悉需求的基礎上設計測試用例。 3、設計正常業務測試用例 4、設計異常情況測試用例。