摘要
當今的企業需要掌控其關鍵業務應用的所有功能測試，以確保所有業務流程工作符合預期。通過實施自動化的功能測試，企業可以極大提高測試速度和精度，從挼間項目中得到更高的投資回報並且顯著地降低風險。
本文簡要描述了自動化功能測試的優勢和挑戰，幫助企業考慮實施最佳測試自動化的方法。
1.介紹
毫無疑問，嚴格的功能測試是成功開發應用的關鍵。開發人員，測試小組和管理人員所面臨的挑戰是，如何加速測試流程和提高測試的精確性和完備性，同時還不能增加已然很緊張的預算。
通過將功能測試的關鍵環節自動化，可以滿足有挑戰性的發佈時間安排，測試得更加全面和可靠，檢驗業務過程功能的正確性，從而從上線的運營中，獲得極高的產值和客戶滿意度。然而，功能測試的自動化會產生一些新的顧慮：
- 測試過程自動化的成本是多少？其投資回報率（ROI）是什麼？
- 哪些應用/過程適合做自動化測試，哪些不合適？
- 是否需要新的培訓，這將對當前的開發計劃安排產生怎樣的影響？
- 自動化測試得正確地方法論是什麼？
- 自動化測試時涉及到哪些情況？
- 當比較自動化測試產品時，哪些功能最重要？
在自動化測試項目開始之前，以上和其他一些問題應該得到全面地調查和了解。
2.功能測試與單元測試
功能測試是指確保應用按期望運行，也就是按照用戶的期望運行。功能測試以一種有效的方式捕獲用戶的需求，讓用戶和開發人員對業務過程滿足需求充滿信心，同時使得QA團隊可以檢驗軟件已發佈就緒。
功能測試是單元測試的補充，但有很大不同。簡言之，單元測試說明了代碼執行是否正確；功能測試說明了完成的應用是否做正確的事情。單元測試往往是從代碼開發人員的角度來看，而功能測試是從最終用戶和業務過程角度來看。
3.爲什麼將功能測試過程的自動化？
現在，IT部門的壓力越來越大。管理部門希望IT部門通過軟件可以交付新功能，抓住新的商業機會和提供有競爭力的優勢。這就意味着需要完成更多的業務應用開發項目，而時間會很緊迫，並不是都有更多的預算或資源。
同時，管理部門越來越意識到軟件和銷售額的重要關係。Web Services，聯機事務處理和ERP應用不僅是非常關鍵的，而且，它們直接關係到公司的產值能力。現在企業非常依賴非常複雜的計算機基礎設施。如圖，一個典型的企業可能依靠多個應用，運行在不同的系統上，使用幾種不同的前端客戶端，涉及到大量的業務過程並且與很多種數據集交互。
可能的組合是高度複雜，需要成百上千的測試場景。
| 組件 | 數量 | 事例 |
| 平臺 | 1 | Intel |
| 操作系統 | 5 | Windows XP, ME, 2000, NT4, and 98 |
| 前端客戶端 | 4 | Internet Explorer 6, Netscape 7.1 Java, Visual C++ |
| 業務過程 | 5 | Login, Search, Order Entry, Order Confirmation, Order Fulfillment |
| 數據集 | 15 | usernames, passwords, search strings, order numbers, ship dates,等的組合 |
| 需求的測試數量 | 1x 5 x 4 x 15 | = 1,500 可能的測試場景!! |
當軟件出現故障時，其代價是非常大的，包括銷售額下降，員工的低效率，客戶的不滿和開發和QA人員的士氣低落。在軟件開發週期中，缺欠發現的越晚其代價越高。上線後發現的缺欠的改正成本可能比在設計階段發現的高出100倍。自動化是提高軟件測試過程的速度，精確度和靈活性的關鍵，使公司可以更早發現和改正缺欠。
4.手工功能測試的挑戰
手工功能測試過程本身存在很多挑戰：
- 時間過長。有限的IT資源和緊張的交付時間使得手工測試對於滿足業務目標來說過於耗時。採用手工測試，測試和開發人員不得不計劃冗長的每步測試過程，然後手工執行，再現問題，快速消耗了有價值的時間和資源。根據Aberdeen Group，一個獨立行業分析公司，90%的IT項目交付出現延遲，手工測試是其中一個因素。
- 覆蓋不完全。平臺，操作系統，客戶端設備，業務過程和數據集等的組合對於手工測試過程來說，工作量非常大。需要驗證功能的測試用例數量非常巨大。所以當修改完成後手工迴歸測試花費的時間過長，以至於不能做全面的迴歸測試。
- 風險更高。手工測試過程比計算機過程的錯誤和疏忽更多。人們會變得疲倦，輸入數據錯誤，不能總是正確執行測試，並不是總有時間測試所有應該測試的內容。
5.自動化測試的好處
自動化測試有很多好處，包括：
- 快速執行。計算機在執行功能測試腳本的時候比人快得多，因此在有限的時間裏能測試的更多，在給定的時間裏更多的應用可以被測試，可以按時完成更多的工程。並且和人不同，計算機一天工作24小時，還包括晚上，週末和假期；他們不會感到無聊或者疲倦；而且他們從不對該作的事情和不該作的事情自作主張。
- 提高測試覆蓋。自動測試產品支持在所有流行的瀏覽器，操作系統等上執行測試腳本，用自動化的工具對不斷變化的應用和環境做迴歸測試，要比手工測試容易得多。通過整合的數據驅動表單的功能，自動化測試產品允許開發和測試團隊執行計算，操作數據集，以及快速創建多種反覆的測試，使得擴大測試覆蓋範圍。使用自動測試工具可以仿效任何混合的事務和任意的用戶負載。
- 提高測試精確度並提早發現更多錯誤。自動化測試給開發人員提供了一種再現和記錄軟件缺陷的非常容易的方法。這將在所有環境，數據集和業務過程等之間確保功能的正確性，同時對開發過程起到加速作用。
- 提供規範化的過程。自動化測試鼓勵測試團隊規範化他們的過程，以得到更高的一致性和更好的文檔記錄。
- 提高測試的重用性。測試一旦腳本化，開發人員可以使用和重用這些腳本，可以將腳本添加到測試套件中，以適應應用的變化。沒有必要爲每個應用的相同功能而重新創建腳本。
- 支持ERP/CRM。現在越來越多的用戶使用ERP/CRM解決方案，對端到端的迴歸測試的需求正變得越來越頻繁和越來越重要。
6.在什麼情況下采用自動化測試？
一般來說，把自動化測試的工作集中在關鍵的業務過程，複雜應用，以及由這些組成的用例方面（相對於低級別任務，例如系統級的驗證）是很有意義的。
如果一個企業擁有衆多每天工作很多小時的軟件測試人員，但是產品仍然出現質量和功能問題，那麼這家企業肯定能從自動化測試中受益。是否決定實行自動化測試應當充分考慮到投資回報，但是一般情況下，如果一個應用需要多次構造/補丁/修改；需要在大量的硬件或軟件配置下進行測試；並且支持衆多併發用戶等，那麼將會是值得采用自動化測試。另外，如果涉及到重複性的工作，例如數據裝載和系統配置等，或者應用需要滿足特定的服務等級協議（SLA）,那麼自動化測試當然也會節約成本。
7.如何確定自動化測試的投資回報？
任何投資回報都可以從一個簡單的計算得出：
投資回報=投資的淨現值/總初始成本
當採用測試過程的自動化時，成本是切實可見的，但是淨現值仍舊包含許多無形的因素。最好的方法就是儘量精確計算直接成本，然後與自動化測試產生的直接和間接的效益進行對比。
在ROI計算中需要考慮的直接成本包括:
- 購買成本：購買自動化測試軟件產品的成本。
- 硬件成本：功能測試所必需的硬件成本。有代表性的是，功能測試不需要特殊的硬件，只需帶有以太網端口的標準臺式電腦或者工作站即可。
- 勞動力成本：培訓職員編寫測試用例腳本或進行手工測試的成本因素。確認要包括招聘，僱傭，支付工資，和保留熟練的QA工程師的成本。
- 培訓成本：依賴於所選擇的測試產品，培訓使用者精通編寫自動測試腳本是值得的。當然，公司可以選擇僱用專業的服務公司創建最初的自動化測試。
當衡量自動化的潛在益處時，考慮隱性效益是很重要的，例如測試人員高漲的士氣和對工作的滿意度，改進的客戶滿意度和忠實度，還有因爲最終用戶使用的可信賴的軟件而不斷提高的知名度。
8.如何評估自動化測試軟件？
很多商家提供自動化測試產品。每個解決方案都有自身的優勢和劣勢，獨特的功能，和市場環境。每個企業需求的特殊性決定了最適合的一種選擇。然而，任何自動化測試產品都應當包含一些關鍵的性能：
- 自動化測試的“Scriptless”表示法：產品應該提供一個可點擊的界面，在測試時與應用組件進行訪問和交互——而不是呈現出一行行的腳本。測試者應該可以可視化每一步的業務過程，並且直觀的觀察和編輯測試用例。這將減少測試者在學習上走彎路，並幫助測試團隊面對緊迫的最終期限。
- 集成的數據表：自動化功能測試的一個關鍵的好處就是可以使系統快速產生大量數據。還有一個重要的功能就是操作數據集，執行計算，並以最小的代價快速創建數以百計的重複測試和組合。企業應該尋找擁有提供強大計算能力的集成電子數據表單的產品。
- 清晰明確的報告：如果測試結果不容易理解或解釋，那麼即使運行大量測試數據也不會有什麼好處。測試產品應當自動的產生並顯示所有測試運行方面的報告，並用易讀的格式解釋結果。報告應當提供的細節包括：應用在什麼地方發生了失敗和使用了什麼樣的測試數據；爲應用的每一步提供高亮或有差別的屏幕顯示；並提供每個檢查點通過和失敗的詳細解釋。當然還應當能夠在不用修改的情況下，在測試和開發團隊之間共享報告。
9.要點列表：自動化測試成功的五個關鍵
即使已經證明了測試的自動化是經濟有效的，然而如何確定轉變到自動化測試過程上的最佳方法依然是困難的。這部分略述了執行自動化測試過程的五個基本原則。
- 1.完成一個測試計劃文檔。理解被測應用的目標是任何測試成功的基礎。這包括全面的預先計劃以確保測試需求被正確的實施。測試工具應提供爲所有被測應用管理測試用例和需求的能力。
- 2.將測試細分爲自動測試用例。一個組織自動執行一個測試計劃的所有方面是不可能的。自動化測試應該集中圍繞在需求設計的複雜應用上和急迫的業務過程功能上，許多組織發現他們使用自動化測試只佔總測試用例的60%，而餘下的40%爲手工測試。
- 3.創建自動化測試。測試工具極大簡化了準備測試數據和腳本的過程。這使得更多的完全測試可最佳地使用測試資源和結果。使用測試工具，使用者可以不必作任何實際腳本而創建測試。測試工具應能自動捕獲目標應用的業務過程，並允許使用者創建一個可以被保存的而且可以被管理的測試流程。
- 4.提高測試覆蓋的數據驅動測試。測試者就可以爲應用創建一個使用儲藏在Excel電子表格裏的特殊關鍵字的依賴於數據的測試。這就允許測試者通過應用驅動大量的測試數據。
- 5.給測試增加驗證。需要在測試中添加了“通過或失敗”的測試標準。這包括了應用的前端，中間層，或後端數據庫的驗證。內置的數據庫驗證使數據庫值的存儲得到確認，並確保處理的精確性和已更新、刪除或增加的數據記錄的完整性。
10.總結
功能測試可以不是耗時或高成本的問題。採用自動化功能測試，企業可以將重點放在改進自動業務過程方面。開發和QA組可以增加測試過程的速度和精確度。整個IT部門可以獲得更高的投資回報，而且降低了大量風險。
成熟的軟件測試是確保軟件質量的一種重要手段，自動化測試技術的出現，對於提高測試單位績效比起了重要作用，被廣泛應用於迴歸測試中，但是由於被測試系統的不確定性和複雜性，使得軟件自動化測試變得異常困難。本文基於商業工具結合實際項目，分析自動化測試實施期間出現的各種問題，以提高大家對自動化測試項目的真正認識與理解。
現在自動化測試工具很多，商業的或者開源的，以對象識別爲基礎的或者以語言特性爲基礎的等等。在挑選的時候，首先我們要明確被操作軟件的範疇和特性，可預知風險，培訓潛在成本及是否具備被虛擬化等一系列問題，這些問題可製成標準檢查列表，以便確定一個解決一個。在本次自動化測試實施中，首先可知的是被測試軟件屬於行業金融軟件，使用Borland C++Builder語言開發，測試範疇鎖定在軟件前臺需配對後臺數據驗證，前臺由RedHat Linux服務端、自研發中間件和Oracle數據庫支撐。一般來說，這種軟件應用架構比較清晰，但是GUI層使用了大量的非標準第三方控件，有可能會導致部分對象無法捕獲造成實施困難，所以在進入真正的實施前作充分、快速的實驗性評估是非常重要的。
職業化的自動化測試團隊，應當非常熟悉當前主流的商業或者開源測試工具，這種團隊的定義是：技術讓位與成本控制，快速實施且能快速遞交，精確控制每12周爲一週期，項目延時誤差小於2天。考慮到腳本會被移交給其他團隊執行，所以我們選擇了目前在國內應用範圍比較廣、相關技術資料比較豐富的HP Winrunner和HP QuickTestPro。第一個被評估的是QuickTestPro 9.5版本不帶任何插件，結果大量的GUI對象無法被捕捉，不能捕捉意味着不能被操作，所以團隊快速轉換到Winrunner 9.2版本不帶任何插件，實驗結果是基本可以正確識別和捕獲我們所要操作的GUI對象，滿足了對工具的需求。其實QuickTestPro 9.5版本帶Delphi插件也可大大增加捕獲率，但是使用插件違反了團隊定義的工具應用管理規範，也不符合“有對象即可操作”的強硬編程作風。
在工具定義後，需要立刻選擇2組典型業務進行試驗性測試，這時需要業務專家和腳本專家一起工作。帶GUI界面軟件測試用例的設計核心問題是：需要精確區分正常測試用例和異常測試用例，按照先異常後正常的實際執行方式，組織最終的測試數據存放關係，一般合適的比例控制在異常75%—正常25%範圍內。腳本專家需要快速處理對象識別庫，如果涉及到重定義則需要在指定文件中加以註明，因爲這部分工作可被複用到後續的項目實施中，避免造成人力成本重複投入。通常實驗性階段主要產生的問題是：
● 該階段是否會產生腳本框架?答案是否定的，首先自動化測試不一定要有框架，框架產生的唯一目的就是犧牲一部分腳本性能，而對測試數據進行高效、有序的管理。不過在試驗性階段可以考慮這個問題，如果框架是個平臺，那麼我們可以在這個平臺上放置一些我們需要的單位腳本性能監視器或者其他一些東西。由於 Winrunner的描述性編程機能不夠，那麼在後續正常項目實施中，框架更多被定位於爲可測量、可伸縮、可動態、可智能解析測試數據的執行管理。
● 該階段是否需要考慮測試數據存放問題?答案是否定的，沒有必要浪費太多的時間在這種地方，一個文本文件或者乾脆不要文件的數據存放形式都可以，關鍵是成本。
該階段對於人員的要求是什麼?答案是人員需要精幹，一個業務專家，一個腳本專家，一個統計專家足夠，自動化測試實施非常注重績效比，績效比不夠根本沒必要執行後續的項目，你必須通過實驗性測試得出一個準確的結論，就是重複執行多少次腳本，總績效纔可以由負轉正。
● 該階段是否需要考慮環境的問題?答案是的，在這之前就應該安裝好虛擬系統了，如果腳本專家的一邊開着即時通訊工具一邊錄製腳本，我們認爲這是非常不專業的。系統環境的清潔程度如同醫院的手術室，需要提前對各種必須的軟件(例如殺毒軟件，網管軟件等)做好適應性選擇，有干擾的，或者影響系統機能的堅決卸載掉。
● 該階段的硬件是怎麼規劃的?前端的測試主機需要有同時承受開2—3個虛擬系統的準備，不能產生明顯的切換和操作停頓甚至系統假死。雖然 32位的 Windows XP系統不支持4G物理內存，但是經驗告訴我們內存容量多多益善，至於CPU和顯卡處於正常水平即可。後端使用的硬件需要穩定，因爲不是性能測試所以不作太多要求，一切爲了成本。
● 該階段的管理模式和輸出是什麼?答案是沒有太複雜的管理模式，實驗性評估一般都會在1周內被關閉，唯一重要的就是實施評估報告，報告內容大致包含：週期定義、工具定型描述、應用軟件描述、系統框架描述、可能採用的框架描述、可能遞交工件描述、可加入業務列表、預測腳本規模、
可實施技術分析、評估人/時分析、預測實際人/時分析、評估腳本價值、預測實際腳本價值、可能遇到的問題警告等，這些條目都必須一一做出詳實而且準確的描述。
實驗性評估結束後，需要確定自動化測試實施項目的時間及週期里程碑，我們採用12周爲一個週期里程碑，快速發佈快速遞交的方式以確保整個測試項目的實施成功。在開始的1周內，管理專家需要快速定義對象控制表、項目跟蹤表、需求跟蹤表、周/發佈項目進度、日/問題跟蹤表、配置管理須知，腳本專家需要快速定義代碼規範、腳本設計維護手冊、數據作用說明及填寫規範，環境專家需要快速定義虛擬環境配置手冊、維護與複製手冊，培訓專家需要制定實施階段課程培訓體系等，專家都是角色可複用，工作都是實打實的，需要認真對待，缺一不可。
我們通常將項目在快要接近380個可操作對象或者腳本代碼接近25000行的時候稱之爲一個“混亂點”，之所以稱爲“混亂點”完全是這種項目執行過程中的必然現象，如同飛機速度超過音速時產生的音障一樣，正確的對待和處理有助於後續項目實施的健康成長，否則後果不堪設想。
● 經典問題一、文檔混亂了。這裏的文檔混亂並非指文檔丟失、殘缺或者缺少維護這些低級錯誤，事實上這裏的文檔混亂是多個文檔內產生了部分內容相同的冗餘數據，且這些冗餘數據在可控制範圍內。“冗餘即懶惰”，所以對應的解決方案就是將所有文檔轉交EPG團隊，由專人看管做日終處理，只要不增加本團隊的成本我們是非常樂於這麼做的。
● 經典問題二、培訓熱度過高。爲了確保腳本週遞交轉移速度，我們在每週末需要對接應團隊做一定培訓，很多人(非合作團隊)都想增加自己在這方面的知識，所以原來的2小時培訓時間被延長到4小時，原來一場25人小團隊培訓被擴展爲二場各180人的培訓，很累。直接造成的後果就是很多人要內部轉崗來我們團隊，這也違背了“簡單既是美”。
● 經典問題三、腳本的增加突出了性能的缺失。一旦對象突破380 個(不包含描述性對象)，腳本突破25000行(不包含註釋及空行)，不優化，那麼在一臺機器上的綜合運行時間超過了4個小時，所以對代碼優化的工作在後續幾周的實施中急待解決。對於腳本性能調優，需要綜合考慮語言特性、數據結構、外調和對象識別處理，這裏需要對TestPackage – TestSuite – TestCase的組合模式進行事務級的時間分析，精確到毫秒。調優的處理有多種，每個團隊的方法各不一樣，經過綜合處理，現在我們能做到35532行腳本、451個對象、37個虛擬對象，合計78個綜合處理包全部一臺機器上運行，時間可控制在2小時之內。繼續壓縮時間的資源投入大於產出，這不符合成本控制團隊的初衷，所以最終放棄。
● 經典問題四、原來工具的函數有BUG。實際上大規模的代碼運用對測試工具本身也是一種考驗，一切軟件皆有問題，隨着時間的推移會逐漸暴露出來。我們發現了測試工具部分函數的會在某些特定環境下出現問題，所以替換這些函數是非常必要的。替換的方法是，使用第三方開發工具(例如VC)開發出可被腳本直接調用的函數(例如各種動態庫技術)，以替換原自帶問題函數，這樣既增加了整體代碼的穩定性，又提升了團隊的研發能力。例如Winrunner偶爾出現的菜單丟失的問題，都可用自研發函數給予解決。
另外測試工具本身提供的語言也可能存在某些侷限性，所以測試團隊具備自我開發能力也關係着項目是否能被順利實施。
● 經典問題五、腳本不動了。實際上這是最讓人討厭的問題，可能涉及的方面非常多，例如系統交互、網絡環境、本機環境、軟件衝突等等，我們總結了一條處理該類型事件的方法，先排除系統本身，排除干擾軟件，再分析比和對卡死位置數據，最後分析腳本本身，例如我們發現部分問題跟字符處理函數有關，這對提高腳本本身的健壯，提出了很高的要求。
項目進行到距離里程碑最後一週，大部分的問題列表需要被提前被關閉，相關遞交工件需要被整理評審，腳本經過驗證被最終集成轉交，這裏都需要配置管理來提供良好的控制環境。必須指明的是，日腳本構建和測試是貫穿整個項目週期的，這種做法能使腳本的開發狀態得到頻繁的更新，以及儘早發現設計和集成的缺陷。爲了充分利用時間與設備資源，夜晚21點後，腳本的自動執行測試(這裏多數指的是系統測試或迴歸測試)是一個非常行之有效的方法。一切都順利的話，等到第二天上班時，測試結果就已經在相關人員的郵箱裏面了，通過這份報告，你可以知道那些腳本是必須修改的，如果不太清楚還有一份更詳細的截圖列表輔助定位，準確告訴你當時軟件究竟出現了什麼現象導致了問題的產生。
最終該項目第一階段在12周且延長6個小時後被準確的關閉，並且通過了嚴格的部門驗收，6人蔘與到這個項目中，合計2916個有效工作時。經過計算每行代碼價值爲1.77元，總的來說還算是成功的，那麼接下來第二個階段裏面，我們能否將每行代碼價值控制在1元以下，請各位拭目以待。
轉載：http://blog.csdn.net/zbyufei/article/details/3888909