軟體自動化測試計劃

『壹』 軟體自動化測試要學哪些工具

qtp：強大的商業自動化工具
selenium：開源的web自動化測試
robotframework：開源的自動化測試框架
如果要選一個，selenium
如果學會了自動化的常用操作，想了解自動化框架：robotframework

『貳』 如何制定軟體測試計劃

制定計劃
1. 分析產品
分析什麼
用戶(他們是誰，他們做什麼的)
操作(這個操作是干什麼用的)
產品結構(代碼，文件，等)
產品功能(這些功能是干什麼用的)
產品數據(輸入的，輸出的，狀態，等)
平台(外部的硬體和軟體)
怎麼分析
走一下產品/原型的主要流程
評審產品和項目文檔
咨詢設計人員和用戶
與類似的產品做比較
可能的工作產出
產品的功能范圍概要
注釋性的文檔
產品的問題列表
執行狀態檢查
設計人員有沒有確認以及批准了產品的功能范圍概要?
設計人員有沒有認為你已經正確理解了這個產品?
你能不能將這個產品形象化並且預測正確的行為?
你能不能造出產品的測試數據(輸入和結果)?
你能不能配置和操作這個產品?
你有沒有理解這個產品是怎麼樣被使用的?
你有沒有注意到設計中的漏洞或不一致的地方?
關於這個產品你還有沒有未解決的問題?
2. 分析產品的風險
分析什麼
產品受到的威脅
產品的易受攻擊的地方
失敗的方式
失敗後的影響
怎麼分析
評審需求和規格說明書
評審出現問題的一些事件
咨詢設計人員和用戶
通過探索性風險分析和質量判據列表來評審產品
識別基本的錯誤/失敗方式
可能的工作產出
組件風險列表矩陣
失敗模型概要
執行狀態檢查
設計人員和用戶有沒有對風險分析達成一致?
你有沒有發現所有的重要的問題，而這些問題是否在測試過程出現呢?
你是否知道在哪些地方要集中測試精力並獲得最大的效率呢?
設計人員有沒有做一些事情使得重要的問題更容易的發現，或減少其發生的概率呢?
如果你的風險分析是正確的，你是怎麼發現的呢?
3. 設計測試策略
基本策略
Domain testing(包括邊界值)
用戶測試
壓力測試
回歸測試
Sequence testing
State testing
基於文檔的測試
結構化測試(單元測試等)
怎麼計劃
對於風險和產品功能匹配策略
將特殊的和實際的策略形象化
分析是否可用自動化的機會
使用原型去測試probes和harnesses
不要強加計劃，讓測試人員自己決定
可能的工作產出
各個類型的報告怎樣應用的測試策略文檔
風險/任務的matrix
已選擇的策略中存在的問題或挑戰列表
對產品覆蓋比較少的部分提供的建議
測試用例(如果是必須的)
執行狀態檢查
設計人員對這個測試策略達成一致了嗎?
這個策略對於項目每個參與人員以及協助人員都有用嗎?
這個測試策略是否很基本了?是否也容易的應用到這個產品中?
這個測試策略是否透露了所以的重要的問題
4. 計劃安排
安排的內容
測試時間的評估和計劃
易測性的工程分析
測試團隊人員(詳細的能力)
測試人員的培訓和監督
測試人員的任務的指定
產品開發信息的收集和管理
項目會議，溝通，協調的方式
與其他已存在的功能之間的關系，包括開發過程中
測試平台的認購和配置
測試工具盒自動化
需要用到的測試樁和mock
測試套的管理和維護
建立和輸出協議約定
測試周期管理
問題報告系統和約定
測試狀態報告的約定
代碼凍結和增量測試
測試後期的壓力管理
項目階段輸出協議約定
測試效率的預估
可能的工作產出
問題列表
項目風險分析
任務和責任matrix
測試時間表
與開發之間的約定和協議
執行狀態檢查
這個項目所列的安排是否支持測試策略?
是否存在一些問題會阻礙測試的執行?
在可見性的問題面前，這些安排和策略是否適合?
你現在是否開始測試還是以後整理剩下的問題?
5. 分享計劃
分享的方式
讓設計人員和股東都參與到整個測試計劃的制定過程中
更主動的獲取關於測試計劃的意見
盡最大可能幫助開發人員保持進度
幫助開發人員理解他們做什麼會影響測試
與技術支持和寫技術文檔的人分享產品質量信息
讓設計人員和開發人員評審並且批准所以相關的文檔
記錄並加強與開發之間的約定
讓參與人員評審測試計劃的細節
在測試計劃中盡量減少沒必要的信息以增加評審的效率

目標
對於測試過程達到一致的理解

來自：領測軟體測試網。我本人覺得挺贊的。

『叄』 軟體測試的工作計劃和目標

每天在忙忙碌碌的維持生計的工作中，甚至沒有好好想過我在這個階段應該做什麼？而不是被要求去做什麼。
經過這么幾年在軟體測試行業的折騰，也有好好的想過這個問題，在特殊的階段我們應該做好什麼？尤其在軟體測試行業。
大家都比較看好軟體測試行業，只是因為表面上看起來：錢多事少加班少。其實這個都是針對個人運氣好的童鞋才會有此待遇。在不同的階段做好不同階段的事情，才有可能離這個目標更近，作為一枚軟體測試人員，也許下面才是我們最真實的寫照。

{第一年}

當年也是一頭撞進了軟體測試行業。迫切的想要了解這個行業，它的升職模式，如何才能薪資更高。但是以過來人的經歷，告訴你：做好當前的事情。把上司交給你的每一份任務都仔細認真的去完成，體現你作為一個初入職場的新人的價值。新人進去，不奢望你能夠做多大的貢獻，只希望交代給你的事情，不用給你擦屁股就行。
第一年，如果你每天都很積極，迫切的想要完成更多的任務，那麼這一年的你將會進步最快。對功能業務邏輯的整體把握感，對測試用例的編寫能力，對功能測試進度把握，這些都將會成為你以後工作的堅實基礎。這一年，請打好你的基礎，暫時忘記自動化代碼工具這些，你沒有堅實的軟體測試行業內知識和接觸到的一些專業名詞，你拿著工具也都是徒然。

{第二年}

經過第一年的努力，你已經具有比較牢靠的軟體測試基礎，已經完成了一輪一輪的重復的手工測試，對，在這個階段我們應該做什麼？是每天上班等下班還是利用這段時間做點有意義的事情？毋庸置疑，如果你是積極向上的請你，那答案肯定是後者。
建議是：把你每天做的重復的功能測試，利用工具來做。
不建議大家過早的接觸代碼或者是性能這塊，如果你還是職場第二年，因為你還見識的太少，根本達不到寫代碼和性能的這個階段，要能夠寫腳本和做性能，需要你對整個測試框架和業務邏輯都有一個比較強的把握能力，否則，你做的事情，就會是無用功。就好比你學寫代碼，卻發現自己永遠停留在print（「hello world」）的水平；你學性能，缺發現自己永遠停留在錄制腳本的水平。
可以接觸的工具：QTP/Jmeter，這兩款工具都可以幫助你減少相對的勞動力，把一些重復的工作都利用工具來進行。學好了用活了，下次升職加薪或者是換工作，幸運之神都不會錯過你。

{第三年}

終於邁入了第三個年頭，恭喜恭喜，還能夠堅持說明你沒有被這個行業淘汰。經過兩年的基礎打底，如果你不是混混過日子，那麼你的基礎會讓你的工作效率大步提升，你也會有更多的時間來做的別的事情，毫無疑問還是：學習。
這個時候，我們可以嘗試著接觸一些代碼和一些框架，把你自己所學的知識融入到你自己的項目中去。能夠把自己的項目整理出一個測試框架，那麼你就是對這個公司的工作是有非常大的推進作用的！
建議：學習Python，selenium等。

{第四年}

有了代碼基礎後，發現你的工作量又被簡化&優化了。這個時候我們應該對網站的架構，代碼知識，資料庫知識，網路瓶頸，系統優化等各個方面都有了比較深入的了解，我們終於可以進一步來做性能測試了！這個時候，我們突然明白：做性能測試不僅僅是錄制腳本了！你需要去優化腳本，去設計場景，去獲取目標用戶量，去執行壓力測試，去分析壓力結果，做好這些之後，去綜合分析發生性能瓶頸的是資料庫優化問題，還是網路瓶頸問題還是本來的架構就存在問題？
推薦：LR/Jmeter

{第N年....}

未完待續.......
如果你能堅持到第五個年頭，我希望是對軟體測試行業而言是個有用的人；對軟體測試行業有點點推動的人；對公司軟體測試工作有建樹的人。

『肆』 如何使用TestLink管理軟體自動化測試過程

首先，創建項目-創建測試計劃-創建需求-在需求中創建測試用例（這樣需求就直接可以和用例關聯了）-創建套件-將測試用例與測試計劃關聯，接下來就可以執行測試用例了
這里可以你也可以將testlink和mantis集成

『伍』 軟體開發各個階段可以實施的自動化測試技術有哪些

1. 單元測試自動化, 包含: 用例代碼自動化生成, 測試數據生成, 被測代碼的靜態分析, 測試覆蓋率統計等
2. 介面自動化測試, 包含: 測試數據的生成, 調用參數並發起請求, 驗證請求返回的結果等
3. 基於頁面的GUI自動化測試, 包含: 根據不同平台和業務場景, 選擇合適的自動化框架和測試執行框架等
更多實戰小技巧可以到網路上找下黑馬程序員相關視頻。很高興我的回答能對您有所幫助，謝謝您的採納

『陸』 什麼是自動化測試

一般是指軟體測試的自動化，軟體測試就是在預設條件下運行系統或應用程序，評估運行結果，預先條件應包括正常條件和異常條件。自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。

基本信息

• 中文名稱

  自動化測試

• 外文名稱

  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或其他廠家的產品。這樣雖然需要支付一部分費用，但省去了工具維護所需要的大量工作。至於具體選擇哪個廠家的產品為好，筆者尚無結論性意見。相信讀者朋友都有一些見仁見智的看法，不妨來信交流。

『柒』 自動化測試基本流程是什麼

自動化測試基本流程

1、制定測試計劃

在展開自動化測試之前，最好做個測試計劃，明確測試對象、測試目的、測試的項目內容、測試的方法、測試的進度要求，並確保測試所需的人力、硬體、數據等資源都准備充分。制定好測試計劃後，下發給用例設計者。

2、分析測試需求

用例設計者根據測試計劃和需求說明書，分析測試需求，設計測試需求樹，以便用例設計時能夠覆蓋所有的需求點。一般來講，基於Web功能測試需要覆蓋一下幾個方面：

1）頁面鏈接測試，確保各個鏈接正常；

2）頁面控制項測試，確保各個控制項可靠；

3）頁面功能測試，確保各項操作正常；

4）數據處理測試，確保數據顯示准確、處理精確可靠；

5）模塊業務邏輯測試，確保各個業務流程暢通。

3、設計測試用例

通過分析測試需求，設計出能夠覆蓋所有需求點的測試用例，形成專門的測試用例文檔。由於不是所有的測試用例都能用自動化來執行，所以需要將能夠執行自動化測試的用例匯總成自動化測試用例。必要時，要將登陸系統的用戶、密碼、產品、客戶等參數信息獨立出來形成測試數據，便於腳本開發。

4、搭建測試環境

自動化測試人員在用例設計工作開展的同時即可著手搭建測試環境。因為自動化測試的腳本編寫需要錄制頁面控制項，添加對象。測試環境的搭建，包括被測系統的部署、測試硬體的調用、測試工具的安裝和設置、網路環境的布置等。

5、編寫測試腳本

根據自動化測試用例和問題的難易程度，採取適當的腳本開發方法編寫測試較薄。一般先通過錄制的方式獲取測試所需要的頁面控制項，然後再用結構化語句控制腳本的執行，插入檢查點和異常判定反饋語句，將公共普遍的功能獨立成共享腳本，必要時對數據驚醒參數化。當然還可以用其他高級功能編輯腳本。腳本編寫好了之後，需要反復執行，不斷調試，知道運行正常為止。腳本的編寫和命名要符合管理規范，以便統一管理和維護。

6、分析測試結果、記錄測試問題

應該及時分析自動化測試結果，建議測試人員每天抽出一定時間，對自動化測試結果進行分析，以便盡早地發現缺陷。如果採用開源自動化測試工具，建議對其進行二次開發，以便與測試部門選定的缺陷管理工具緊密結合。理想情況下，自動化測試案例運行失敗後，自動化測試平台就會自動上報一個缺陷。測試人員只需每天抽出一地你該時間，確認這些自動上報的缺陷，是否是真實的系統缺陷。如果是系統缺陷就提交開發人員修復，如果不是系統缺陷，就檢查自動化測試腳本或者測試環境。

7、跟蹤測試BUG

測試記錄的BUG要記錄到缺陷管理工具中去，以便定期跟蹤處理。開發人員修復後，需要對此問題執行回歸測試，就是重復執行一次該問題對應的較薄，執行通過則關閉，否則繼續修改。如果問題的修改方案與客戶達成一致，但與原來的需求有所偏離，那麼在回歸測試前，還需要對腳本進行必要的修改和調試。

8、自動化腳本的維護

如果系統發生變更時，對自動化測試腳本和相關文檔包括《自動化測試用例》、《自動化腳本設計說明書》進行維護，以適應變更後的系統。

『捌』 軟體自動化測試的意思是什麼具體價值體現在什麼方面能做些什麼事情

軟體測試是對創造力和智力非常有挑戰性的任務。測試一個大型軟體需要的智能要超過設計這個程序的智能。軟體在它發行之前應當通過徹底的測試，以保證它的可靠性和功能性，不幸的是，測試工程師要覆蓋一個大型程序的所有情況會感到太麻煩和太費時。確實，軟體的每個部分如能被分別測試到，同時一些指定的路徑也能被測試，這對總的軟體質量的保障是非常有效的。
一般的說，沒有測試覆蓋分析工具，軟體在發行前僅有50%的源程序被測試過。在差不多有一半源代碼沒有被測試的情況下，大量的故障（bug）隨軟體一道被發行出去。在這種情況下，軟體的質量、性能和功能不可能得到保障。此外，什麼時候測試結束？或是否要對該程序作進一步的測試？對於測試工程師和測試管理人員來說是不知道的，通過引進測試覆蓋的概念，問題就可以得到解決。
項目測試管理
1。幫助軟體管理者准確地測算開發組的效率的，通過提供多層分析,包括系統/文件/類/函數的能力。
2。提供管理人員測算工程開發進度與質量分析的能力，允許在被生成的類繼承圖和函數調用圖上，直接反顯所有在規定的日期或一個小組/單個員工完成的模塊，在這些圖上帶有覆蓋在每個類/函數框上以條形圖方式顯示的相關質量信息，比如大小、復雜性、數據性能、代碼測試覆蓋等。
3。 結合軟體系統質量分析能力和系統開發管理能力，提供給管理人員的帶有質量數據的有關開發效率和工程開發進度信息總是即時的和精確的，因為它們是直接從源代碼得來的第一
軟體測試是對創造力和智力非常有挑戰性的任務。測試一個大型軟體需要的智能要超過設計這個程序的智能。
軟體在它發行之前應當通過徹底的測試，以保證它的可靠性和功能性，不幸的是，測試工程師要覆蓋一個大型程序的所有情況會感到太麻煩和太費時。確實，軟體的每個部分如能被分別測試到，同時一些指定的路徑也能被測試，這對總的軟體質量的保障是非常有效的。
一般的說，沒有測試覆蓋分析工具，軟體在發行前僅有50%的源程序被測試過。
在差不多有一半源代碼沒有被測試的情況下，大量的故障（bug）隨軟體一道被發行出去。在這種情況下，軟體的質量、性能和功能不可能得到保障。此外，什麼時候測試結束？或是否要對該程序作進一步的測試？對於測試工程師和測試管理人員來說是不知道的，通過引進測試覆蓋的概念，問題就可以得到解決。
項目測試管理
1。幫助軟體管理者准確地測算開發組的效率的，通過提供多層分析,包括系統/文件/類/函數的能力。
2。提供管理人員測算工程開發進度與質量分析的能力，允許在被生成的類繼承圖和函數調用圖上，直接反顯所有在規定的日期或一個小組/單個員工完成的模塊，在這些圖上帶有覆蓋在每個類/函數框上以條形圖方式顯示的相關質量信息，比如大小、復雜性、數據性能、代碼測試覆蓋等。
3。 結合軟體系統質量分析能力和系統開發管理能力，提供給管理人員的帶有質量數據的有關開發效率和工程開發進度信息總是即時的和精確的，因為它們是直接從源代碼得來的第一手信息。
測試計劃
軟體系統不僅變得越來越龐大，但是也變得越來越復雜。復雜的代碼是很難閱讀、理解和修改的；必須化更多的精力去測試、維護和再測試。
測試復雜性分析能幫助軟體工程師容易並精確地去計劃他們的測試活動。 提供系統級復雜性分析和過程級復雜性分析去精確地測量復雜性，幫助工程師更好地計劃他們的測試活動。幫助工程師更好估計和使用測試復雜性度量，為滿足不同層次的測試覆蓋的要求，必需提供：塊測試復雜性、分支測試復雜性、段測試復雜性、條件-判定測試復雜性、條件-段測試復雜性。

『玖』 軟體測試自動化測試面試題

自動化測試面試題
1. 你比較熟悉那種自動化測試工具？
2. 你在你以前工作中是如何使用自動化測試工具的？
3. 介紹一下你在利用自動化測試工具的過程中遇到的一些問題
4. 你是如何計劃自動化測試的？
5. 自動化測試能提高測試效率嗎？
6. 什麼是data-driven automoation(數據啟動自動化)？
7. 測試自動化的主要特徵有哪些？
8. 自動化測試可以代替手工測試嗎？
9.自動化測試的好處是什麼？
10. 自動化測試容易出現的誤區有哪些？
11. 介紹一下測試自動化的常見問題？
12. 你知道哪些測試自動化的腳本技術？
13. 測試用例的設計可以自動化嗎？
自動化測試框架都有哪些?
答：自動化測試框架主要分為以下幾種，可以根據項目需要進行選擇
1.模塊化框架(test script molarity)。
2.函數庫結構框架(test library architecture)。
3.關鍵字驅動測試框架(keyword-driven/table-driven testing)。
4.數據驅動測試框架(data-driven testing)。
5.混合型框架(hybrid test automation)。
請列舉你曾經做過的自動化功能測試項目的相關經驗
你認為什麼情況下適合進行自動化功能測試?請解釋原因
請問自動化測試在實現過程中會遇到的難點有哪些?
請問：怎麼在自動測試中實現數據驅動?
你會計算自動測試工程的投入回報比嗎?怎麼計算?
請比較 Rational Robot 與 MI QTP 的優缺點
你認為 Robot 在數據參數化的時候有什麼不便之處嗎?
請問 QTP 中如何不用錄制的方法啟動 IE ，並對 IE 窗口進行操作
在用自動測試工具製作測試腳本的時候，當需要對某個界面上的對象進行操作時，如何保證操作成功?
請選擇一個自動功能測試工具並用該測試工具的腳本語言寫一個腳本：每天早上 9 點彈出對話框，提示「現在 9 點了」。說明在測試工具中使用你的腳本的方式