Ⅰ 自動化測試框架有哪幾種
冒昧的說一句，您這個問題問的可能比較大。
因為從自動化測試角度講的測試框架有很多種；而且並沒有什麼固定的條條框框。全部是根據測試需要及公司產品開發現狀進行搭建的。從通俗的 整體的角度講只要滿足：測試輸入（腳本編寫）-》測試執行-》結果輸出 這種模式的都可稱之為自動化測試框架。
而從不同的角度分析框架又可根據不同篩選條件分為多類：
如：1.腳本語言方面分析，很多種語言提供了多種自動化測試的基礎框架：
1)ruby的Watir開源自動化測試框架、Test::Unit單元測試框架、開源測試框架Ruby on Rails 等等
2)java的junit回歸測試框架、Mockito、TestNG、easyb等等等等
3)Perl的perl Mechanize、Test::Base數據驅動測試等等等等
4)Python的PyUnit、PAMIE等等等等
5)基於Tcl/Tk的swift 自動化測試框架,ATF/VTP自動化測試框架
以上僅列舉自動化測試常用的幾種腳本語言的測試框架，當然不僅僅是這些
2.從測試體系角度分又分為：
1)單元測試框架.
2)系統測試框架
3)集成測試框架
。。。。。
3.基於測試目的的劃分
1)GUI自動化測試框架
2)網路協議自動化測試框架
3)基於web的自動化測試框架
。。。。。
4.從實現深度和角度分類：
1)簡單的錄制回放測試框架（或工具）
2)關鍵字驅動的測試框架
3)關鍵字驅動及結果輸出分析的自動化測試框架
4)智能匹配功能及具備快速腳本生成功能的自動化測試框架
。。。。。。
5.從測試工具角度分：
有些測試工具是許多大型公司結合了很多測試經驗及數據後進行開發的自動化測試軟體或者稱之為測試管理軟體的自動化管理部分及自動化測試部分；也有人稱之為自動化測試框架或自動化測試工具。比如QTP;LoadRunner;Quality Center、selenium等等。都具有一定的自動化測試及管理功能。
所以總的來看，測試框架分為很多種；不知提問者問的是哪個具體方面的。
筆者水平有限，僅能做個基本介紹，希望能有所幫助。也祝願所有從事自動化測試相關工作的同志事業順利。歡迎溝通交流
Ⅱ 自動化測試框架的發展及開發
自動化測試框架是自動化測試的核心，在開展自動化測試工作前，需要相應的自動化測試框架。一個好的自動化測試框架不但影響自動化測試的進程，也決定自動化測試的成敗。
基於界面的軟體自動化測試框架經歷了四個發展階段： 無框架→數據驅動→關鍵字驅動→混合模型，如圖 17-2 所示。
（1）無框架階段（即簡單的錄制/回放）。
■ 在早期，自動化測試並沒有框架這一概念，只是簡單的錄制/回放，由工具錄制並記錄操作的過程和數據，並形成腳本，通過對腳本的回放重復人工操作的過程。這種模式腳本與數據混合在一起，導致一個測試用例對應著一個腳本，維護成本很高，並且當界面發生變化時，就得重新錄制腳本，導致腳本的使用率很低。
（2）數據驅動（Data Driven）框架階段。
■ 無框架階段最大的缺點就是腳本與數據混合在一起，為了解決這一問題，自動化測試框架發展到數據驅動框架階段，該框架從數據文件中讀取數據，通過參數化的方式將數據文件中的數據寫入腳本中，由於不同的數據對應著不同的測試用例，將腳本與數據徹底地分離，因此提高了腳本的使用率，大大降低了腳本的維護成本。雖然數據驅動框架解決了腳本與數據的問題，但並沒有將被測試對象與操作分離。
（3）關鍵字驅動（Keyword Driven）框架階段。
■ 關鍵字驅動測試是在數據驅動框架的基礎上改進的一種框架模型。它將測試邏輯按照關鍵字進行分解，形成數據文件與關鍵字對應封裝的業務邏輯。主要關鍵字包括三類：被測試對象（Item）、操作（Operation）和值（Value）。用面向對象形式將其表現為 Item.Operation（Value）。關鍵字驅動的主要思想是：腳本與數據分離、界面元素名與測試內部對象名分離、測試描述與具體實現細節分離。
（4）混合框架（Hybrid Framework）階段。
■ 關鍵字驅動框架將自動化測試框架帶入了一個新的階段，自動化測試工具 QuickTest 也很好地使用了這個理念。但在實際開展自動化測試的時候，發現測試工具所帶的關鍵字驅動方式還是無法很好地完成測試任務。該框架雖然將數據與腳本進行了分離，但是如果要更靈活地調用測試用例中的數據或輸出測試結果，該框架無法做到；並且需要讀取其他文件存儲格式中的數據時也是無法很好地解決，這樣在自動化測試開始的前期，工程師會開發一個符合實際測試的框架來支持後期的測試工作，這就是通常所說的混合模型自動化測試框架。
隨著自動化測試框架的不斷發展，自動化測試腳本類型也在不斷地發生變化。 自動化測試腳本類型的發展經歷了以下幾個階段：
（1）線性腳本。
▲ 通過錄制直接產生線性執行腳本。線性腳本無法對其邏輯或順序進行任何的調整，產生的線性腳本只能按順序一行一行地執行。該腳本類型對應著自動化測試框架發展中的無框架階段。
（2）結構化腳本。
▲ 很顯然線性腳本無法處理邏輯和業務關系。為了解決該問題，在原來的線性腳本中添加了順序、循環和分支等結構的腳本，形成結構化腳本。
（3）共享腳本。
▲ 在實際測試過程中，需要將調試的腳本進行共享，供其他工程師調用，這樣腳本類型就發展到了可共享的階段。
（4）數據驅動腳本。
▲ 數據驅動腳本將數據與流程式控制制進行分離，通過讀入數據文件來驅動流程。
（5）關鍵字腳本。
▲ 腳本、數據、業務分離，數據和關鍵字在不同的數據表中，通過關鍵字來驅動測試業務邏輯。
自動化測試框架是由假設、約束以及為自動化測試提供支持的工具的集合。自動化測試框架最大的優點是可以減少測試腳本實現和維護的成本，測試用例只需要修改測試用例文件，而不需要更新腳本驅動程序和引擎驅動程序。自動化測試框架的優劣直接影響到自動化測試的成功與否。
假設自動化測試框架是形成自動化測試策略的基礎，下面是常用的假設條件：
約束條件影響著自動化測試是否成功，如果不注意以下約束條件，自動化測試工作將很難成功：
一般自動化測試框架應該包括四部分內容：測試管理、數據驅動、結果分析和測試報告。
如圖 17-3 所示是一個混合測試框架模型樣例。
Ⅲ 自動化測試：為什麼需要框架
因為軟體系統發展到今天已經很復雜了，特別是伺服器端軟體，涉及到的知識，內容，問題太多。在某些方面使用別人成熟的框架，就相當於讓別人幫你完成一些基礎工作，你只需要集中精力完成系統的業務邏輯設計。而且框架一般是成熟，穩健的，他可以處理系統很多細節問題，比如，事物處理，安全性，數據流控制等問題。還有框架一般都經過很多人使用，所以結構很好，所以擴展性也很好，而且它是不斷升級的，你可以直接享受別人升級代碼帶來的好處。
Ⅳ 自動化框架工具有哪些
1．模塊化測試框架
在五種框架中，模塊化框架是最容易掌握和使用的。在一個組件上方建立一個抽象層使其在餘下的應用中隱藏起來，這是眾所周知的編程技巧。這樣應用同組件中的修改隔離開來，提供了程序設計的模塊化特性。模塊化測試腳本框架使用這一抽象或者封裝的原理來提高自動測試組合的可維護性和可升級性。
2．測試庫框架
測試庫框架（Test Library Architecture）與模塊化測試腳本框架很類似，並且具有同樣的優點。不同的是測試庫框架把待測應用程序分解為過程和函數而不是腳本。這個框架需要創建描述模塊、片斷以及待測應用程序的功能庫文件。
3．關鍵字驅動或表驅動的測試框架
對於一個獨立於應用的自動化框架，關鍵字驅動（KEYWORD Driven）I9LJJ試和表驅動（TABLE DRIVEN）測試是可以互換的術語。這個框架需要開發數據表和關鍵字。這些數據表和關鍵字獨立於執行它們的測試自動化工具，並可以用來「驅動＂待測應用程序和數據的測試腳本代碼，關鍵宇驅動測試看上去與手工測試用例很類似。在一個關鍵字驅動測試中，把待測應用程序的功能和每個測試的執行步驟一起寫到一個表中。
這個測試框架可以通過很少的代碼來產生大量的測試用例。同樣的代碼在用數據表來產生各個測試用例的同時被復用。
4．數據驅動測試框架
數據驅動（DATA Driven），LJ試是一個框架。在這里測試的輸入和輸出數據是從數據文件中讀取（數據池，ODBC源，CSV文件，EXCEL文件，ado對象等）並且通過捕獲工具生成或者手工生成的代碼腳本被載入到變數中。在這個框架中，變數不僅被用來存放輸入值還被用來存放輸出的驗證值。整個程序中，測試腳本來讀取數值文件，記載測試狀態和信息。這類似於表驅動測試，在表驅動測 試中，它的測試用例是包含在數據文件而不是在腳本中，對於數據而言，腳本僅僅是一個「驅動器」，或者是一個傳送機構。然而，數據驅動測試不同於表驅動測試，盡管導航數據並不包含在表結構中。
5．混合測試自動化（hybrid Test Automation）框架
最普遍的執行框架是上面介紹的所有技術的一個結合，取其長處，彌補其不足。這個混合測試框架是由大部分框架隨著時間並經過若干項目演化而來的。
Ⅳ 如何搭建自己的自動化測試框架
這段時間一直在為公司內部開發
自動化測試框架
，簡稱GTF，因為這個框架現在還屬於開發階段，很多事都是言之過早。我會持續將我在架構過程中的想法寫下來。供自己和大家一起分享。
這些想法，並不屬於我一個人，我工作中的同事們給了我很大的幫助。
今天這一篇主要說明架構方面的考慮。
在現有的提供自動化測試解決方案的產品很多，包括:Robot，TestComplete，WinRunner等等。我只接觸過這些，公司里也進行過很大的嘗試，但是結果往往總是不竟如人意。
這中間，排除那些人員方面的原因，也總結這些自動化工具
，在使用過程中的不方便的地方:
1. 定位控制項不方便。標准控制項還好，非標准控制項就只能靠很多非正常方法去獲取。而且，控制項的識別往往和界面布局相關。
3. 代碼維護不方便。由於在編寫過程中，大量的和界面相關的代碼，導致最後在需求變更的時候，代碼的維護，成為軟體測試人員的負擔。
針對這些情況，我們經過討論，何不自己做一個軟體測試框架。當然了，這是基於我們的豐富的知識積累的決策。大家不需要關心這個決策的情況。不過，可以多關注一些我們在做的過程中的分析結果。
通過分析流行的軟體測試框架，有多種方式:
第一、最典型的就是消息驅動，自動化工具通過腳本錄制和編寫，保存為測試腳本。在回放的過程中，將這些腳本轉換成為Windows消息，發送給我們應用程序的窗體和各種控制項。
這種方式的好處在於，自動化工具和應用程序之間能夠做到完全的隔離。但是，由於使用了Windows消息，它也擁有了一個非常致命的缺點。那就是消息隊列的非同步性與程序的順序性之間的矛盾。很多消息發送給了應用程序，但是應用程序的處理可能已經和消息隊列錯位了。有一些關於代碼的時間片等待，就是因為這個問題。
另外，就是由於完全的隔離，對於操縱控制項數據的能力大大降低。畢竟，擁有大量數據的控制項都不是標准控制項。
第二、嵌入式
。TestComplete就是這類工具。它有支持不同語言的版本。大概思路，就是在程序編譯的時候，注入自己的控制項代理。腳本的回放，直接可以通過代理，操縱到應用程序。
可惜的是，這類軟體開發的時候，更多的是考慮平台的兼容性。對於特有平台上的支持不是十分完美。特別是對自定義控制項(比如Delphi中，除了VCL的標准控制項)支持也沒有做到最好。不過，我這里必須承認，TC的內部實現機制可能十分強大，我不能窺探所有。如果有人清晰，可以指點一二。
針對上面的兩種，我們想到的第三種方式:一體式。這種方式中，通過給程序在打包的過程中，添加額外的框架代碼，使得程序自動提供控制項的訪問方式。自動化的模塊也會作為軟體測試程序的一部分運行。
應用程序在執行腳本的時候，自動通過腳本
，控制各控制項界面的顯示和關閉。它應該是第二種方式的變種。但是由於是自己實現的，所以在對各類自定義控制項支持的都非常好。
針對一開始提出的幾個自動化測試的難題，我們提出了，自動封裝窗體上所有控制項的概念(這些概念後面會詳細介紹)，對於軟體測試人員，只要關心真正的業務操作流程。而業務流程中涉及到的控制項，已經為他們自動提供好。這樣，腳本也自然只成了業務流程的腳本。其復雜度也就大大降下來了。
如果要推薦2個工具的話，我就推薦澤眾軟體公司的
自動化測試工具AutoRunner和測試管理工具Testcenter
，用這2個軟體合作可以很好的進行自動化測試與對測試用例進行管理。
Ⅵ web自動化測試框架有哪些
Web自動化測試在測試領域裡面用得比較多的工具或者框架有Selenium, robotframework, Cucumber等。
Selenium是一個開源的Web自動化測試框架，ujiuye主要用於做HTML頁面的UI自動化測試。
RobotFramework是一個基於Python語言的，可擴展的關鍵字驅動的自動化測試框架，使自動化測試腳本編寫變得更簡單
Cucumber是BDD(Behavior-driven development，行為驅動開發)的一個自動化測試的副產品。它使用自然語言來描述測試，使得非程序員可以理解他們。
Ⅶ web ui自動化測試框架有哪些
冒昧的說一句，您這個問題問的可能比較大。
因為從自動化測試角度講的測試框架有很多種；而且並沒有什麼固定的條條框框。全部是根據測試需要及公司產品開發現狀進行搭建的。從通俗的
整體的角度講只要滿足：測試輸入（腳本編寫）-》測試執行-》...