很高興今天有機會和大家討論一下軟件測試自動化的實踐，今天的話題分為兩個部分 ：一是軟件自動化功能測試；還有一部分會介紹一下軟件自動化性能測試。實踐主要包含兩個部分：一部分是介紹HP在軟件的功能和性能自動化測試的理念，以及產品和技術在這方面的支持。另一部分是一些實踐案例，包括在國內外哪些用戶使用我們的測試工具，他們是如何去做的。

首先是自動化功能測試，我們討論一下他的適用范圍，或使用時機是何時。對于一個新的項目，比如項目周期很緊的功能測試項目，如果臨時分配30個人，按測試方案進行手工測試的效率可能要比自動化測試工具錄制腳本在測試的效率好的多。那么自動化測試工具的價值在什么地方？我們可以看一下，很多客戶如果想增加一些新的功能，或者是修復bug，經常會推出產品新的版本，在推出的過程中，我們也知道，除了測試修改過的模塊外，每次都要重復測試有關聯的模塊，這樣很多時候會做大量的重復工作，人員很疲憊也達不到測試效果，自動化功能測試工具就可以創建整個測試生命周期的可重用模塊，同時還能覆蓋大部分的系統測試，更主要的是錄制好腳本以后，自動去執行，機器去操作，減少了人為主觀的錯誤，同時使測試人員解脫出來，專注新的模塊。自動化測試最大的價值在于回歸測試。在產品提交過來之后要執行“冒煙測試”，自動化測試工具能夠節省時間和金錢。圖中是國際上某金融機構的統計，在過去三年內使用使用自動化測試工具的投資回報率達到1500%。下面我們看一下自動化測試的原理是什么。自動化測試發展到現在，很多廠商走的技術路線都是類似的，一是通過錄制生成腳本，業務人員或測試人員按正常的業務執行流程，同時自動化工具錄制并生成腳本，要注意的是，它錄制的不是鼠標和鍵盤的操作，而是對象的操作，如某個button被click了一下，或某個文本框輸入了數據，這樣的好處是當button位置發生了變化，腳本會根據對象的屬性精確定位到對象，然后進行腳本回放，可以不需要反復修改，來執行自動化測試。當錄制好腳本后，可能要執行測試數據的參數化。錄制的可能是一套數據，如錄制登錄操作，可能錄制的是正確的用戶名和密碼，但實際執行測試的時候可能需要很多的組合，比如正確的用戶名、錯誤的密碼，空用戶名、空密碼等等，這時候你需要對輸入的數據進行參數化。那么需要這種參數表對參數進行定義。接下來第三點是自動化測試以功能測試是否正確作為結果來判斷的，它需要定義正確的檢查點，就是說我能夠通過對象的屬性或界面的文字去判斷我的功能執行是不是正確的。還有一個比較重要的，也是很多朋友容易忽略的，就是最后的測試報告。測試運行完以后，我需要根據我的檢查點去判斷我的運行結果怎樣，有的產品的報告可能是文字型的，但實際上對于很多測試需要圖形化的報告，可以看到我的檢查點是什么，執行的時候是什么情況，為什么會出現錯誤?；谝陨线@些，我們可以看到當使用軟件測試自動化工具的時候需要考慮什么問題：1．工具要有對對象很好的識別和維護的能力，支持各種傳統和新的技術，象今天上午的調研報告里反映的，很多朋友也都關心自動化測試工具是否支持一些新的技術，另外，還需要統一的對象庫，腳本可以基于對象庫統一管理對象，當對象庫的某一對象發生變化時，如中文版的button上是“確定”，英文版可能就是“ｏｋ”，可以更改對象庫中對象的屬性，就不需要打開每個腳本進行修改，還有一個比較重要的是對象庫的圖形化操作，可能會有些對象庫的合并、分拆等等。２．就是腳本要易于修改和維護，不僅僅是腳本的語言，更主要的是要提供腳本圖形化的編輯。雖然測試人員很多是從開發人員轉換過來的，但測試人員不等于開發人員，那么工具的使用是要易于理解和掌握，像有的用戶甚至是業務人員和開發人員一起錄制腳本，這時候工具對于業務人員要易于理解和掌握，要能夠知道工具是如何用的。還有就是離線編輯，不用起應用也能夠進行腳本編輯。３．測試數據的驅動，數據表要易于編輯和維護，數據參數化操作。４．檢查點，支持多種檢查點，如對象、文本、位圖。５．結果報告，剛才我們也提到，結果報告的圖形化也是很有必要的，而且要易于瀏覽。下面我們看看惠普提供的相關功能測試套件，上午的調研報告中我很高興的看到，對自動化測試工具在企業中應用的調查結果，WinRunner是排在第一位的，但實際上HP同時還有另外一個自動化測試工具產品，就是Quit Test Professional，即QTP。目前，HP是把WinRunner和QTP作為整體的功能測試套件提供。WinRunner比較關注傳統的應用，如早期的Delphi、PowerBuilder；QTP關注新興技術，如.NET、新的WebService、無線、VMWare桌面支持的測試，QTP都可以支持。同時這兩個產品又有通用的覆蓋面，包括像Web、VB、Activex等等，但我們向用戶推薦QTP，因為它具有靈活、易用、簡單的特性。它不僅提供腳本語言的編輯，同時還提供關鍵字視圖界面。在界面中它對每一個對象進行梳理、提取，同時下面又提供數據表和實時的捕捉，這樣用戶可以很方便的編輯。同時也可以把對象選擇進來，離線編輯腳本。另外還提供ActiveScreen技術，可以界面快照，然后對快照添加驗證點、測試步驟，甚至離線編輯。下面是我們在長期的工作過程中總結的自動化功能測試的原則：1．就是選擇合適的被測應用；2.就是要選擇合適的案例；3．設計自動化功能測試框架；4．自動化測試實際上是這種規模效應，覆蓋率達到一定規模，他的效果才能體現出來，同時也是要不斷積累和完善的。

1．選擇合適的被測應用：

• 工具對應用界面開發技術的支持程度

• 生命周期長，但是經常變更和升級

• 界面變化相對不大

• 開發已經基本完成

• 回歸測試階段

− 檢查已知錯誤是否重現

− 發現修改造成的新錯誤

2.選擇合適的案例

• 高業務風險

• 手工測試復雜度高

• 實現自動化測試難度低

• 前期測試發現缺陷比較多

案例評估方法

這個片子是介紹如何評估業務的風險。主要從業務風險評估和技術風險評估兩方面來說。從不同的維度來評估你的業務是不是具有高風險。

3．規模效應，不斷完善積累

• 設計先行

• 覆蓋率越高，價值越明顯

• 覆蓋率和投入成正比

• 不要一開始就期望高覆蓋率

• 逐步使用，逐步發展，逐步完善

另外一方面，對于自動化功能測試僅僅錄制回放是不夠的：

• 設計自動化功能測試框架

• 業務人員和技術人員的協同工作

• 大批量腳本的調度

• 重用需要實現腳本調度

• 數據驅動的要求

• 界面一旦變化的維護要求

4．自動化功能測試設計框架

這里我們提出的自動化功能測試設計框架應該包含的內容，首先最關鍵的是中心管理，我們首先應該有自己的庫（Central Management），去集中管理所有的自動化測試腳本；上面一層是功能庫（Functional Lib），是一些可以提取的函數；再上面一層是業務組件（Logic Components），把被測系統可重用的組件提取出來；再上面一層是控制器（Controller），可以控制、組織業務組件，形成一個個業務流程；再上面是調用的腳本（Load Scripting），實現腳本的調度。下面我們來看一下，傳統的自動化功能測試是序列化的，從登錄、創建訂單、查看訂單到退出，是一步步做的，數據往往和腳本是捆綁在一起的，對腳本的調用還是需要用寫代碼的方式來維護。而HP的業務流程測試（Business Process Testing）—基于Web的無測試腳本的功能測試，它與傳統的自動化功能測試的區別是：

• 使業務人員參與自動化功能測試的設計和使用，及早進行測試規劃

• 業務人員使用自然語言定義組件；測試人員腳本實現

• 使用應用界面流和數據創建測試案例

• 大量減少自動化測試案例維護時間

• QTP/WR與TD for QC集成實現

外面的展廳中，我的同事會有一些實時的demo展示，大家如果感興趣可以在間歇的時候去看一下，業務流程測試怎么樣方便的幫助用戶實現自動化功能測試的框架。這個圖是HP的質量中心的框架圖，在軟件質量管理講演中會對它詳細介紹，這里我就不詳細介紹了。

第二部分給大家介紹軟件自動化性能測試。講解之前，我首先問大家一個問題，有多少人用過LoadRunner？好，我本來想如果用的人多的話我就著重介紹一些新的特性，現在看來大家用的不多，我還是詳細介紹一下。前面我們介紹的是功能測試，主要是在功能上看產品和業務的對應情況，能不能滿足業務需求。但同時我們也知道產品的使用往往不是一兩個人，少則幾十，多則上千，那么產品上線以后是不是能夠支撐這么多用戶，因此要做性能測試，他與功能測試還有個區別是，功能測試還是可以靠人力去做，但性能測試往往無法靠人力做的，因為沒有辦法做到這么多人同時做一個操作，并計算響應時間。作為性能測試，我們往往面臨一些問題：1．性能測試目標不明確；2．業務部門和測試團隊缺乏通用語言；3．腳本能否錄制和回放；4．場景如何接近真實地模擬；5．瓶頸定位。

HP LoadRunner作為業界領先的自動化壓力測試工具，它具有很多功能：1．使用成百上千的虛擬用戶代替真實用戶；2．從單一控制點對系統產生精確的，可測量和可重復的負載，并且提供無代理的監控；3．強大的分析器，協助查明系統瓶頸。

然后我們可以看一下LoadRunner如何工作?

• 將業務流程錄制為自動化腳本，例如股票交易應用中的 “買入”；

• 添加事務, 參數化輸入數據, 添加驗證點；

• 模擬用戶行為，例如網絡連接類型，頻率等…