先放這備用
當我用一些簡單的功能開始錄製腳本時，發現保存ActiveXScreen的話，生成的腳本很中空間（因爲程序會保存每個不同的錄製頁面），多錄一些硬盤空間就滿了，而且回放過程會很慢。 但如果不保存活動頁（ActiveXScreen），對腳本的再改造/維護起來就相對困難一些。
於是我開始去了解“關鍵字”視圖裏的內容，嘗試瞭解代碼。慢慢的，我瞭解到“關鍵字”視圖顯示了整個操作步驟，第個組件相對於程序裏一個元素。同時還記錄了錄製過程對該元素的操作和結果。
然後我又開始在論壇在找些資料看看，從有點所謂的高級應用中，我發現腳本的維護並不一定要有“活動頁”。實際是QTP所有對象的識別，都存在腳本的一個對象庫裏了。QTP經常出現無法識別對象的問題，可以從這裏着頭修改。
爲了減少QTP腳本佔用空間大、錄製慢的問題。我查閱了一些資料，可以在設置中進行修改，讓腳本中不保存活動控件（ActiveX）或僅保存出錯時的錄製頁面。乾脆，我就從此錄製頁面了。所有的調試都從“關鍵字”視圖和“專家”視圖中進行修改。而且關於對象庫，QTP也有個選項，可以設置加載頁面上所有的對象，我修改成只保存頁面上錄製過程使用的對象。 這樣，腳本的容量問題就解決了，錄製後的腳本會比以前小很多，來了個徹底的瘦身。關於錄製速度的問題，和保存“活動頁”、動態腳本也有一定的關係，另外可以減小啓動的加載項（如：去掉VB插件、.net插件，不需要的就不加進來）。這樣的腳本上傳到TestDirector上，或從TestDirector上調用就不會太慢了。
然而真正的問題，棘手的問題就不是上面所述的那麼簡單了。不過都是有辦法解決了的，嘿嘿……
以下是我經常遇到的問題：
一、無法識別控件。
二、錯誤回放過程未知彈出窗口。
三、加載.net插件後和TD的關聯問題。
四、動態加載元素的識別問題。
五、調用外部dll的問題。
六、隨機驗證碼的問題。
問題一，解決辦法有三種：
1、更改QTP自身對某控件的識別方式，在 tools——Object Identification 中。在這裏列出了所有QTP能識別的控件，以及控件的識別方式。你可以給他添加X、Y座標進行識別。或更明顯的，列表中的信息，不按名稱識別，而是按ID識別。這個修改可以解決一些問題，具體的趕緊動手試試吧……
2、使用虛擬物件，來定義一個控件，在 tools——Virtual Object 中。在這裏可以自定義一個控件。例如在ASP的程序中，程序出錯，在客戶端的表現形式大部分是一樣的，你可以把整個錯誤頁面當成一個控件來識別（感覺不錯）。如果加一個判斷，出錯後你想做什麼就由你自己定了。
3、使用低級錄製或鼠標錄製。用 Test——LowLevelRecording/AnlogRecording 吧，用它錄製就不需要什麼設置了，他會記錄你的程序控件相對屏幕的位置。用LowLevelRecording還有代碼可改，用AnlogRecording動作就被封裝了（維護性極差）。兩者因實際環境更取其長吧……
問題二的解決過程：
關於彈出提示的問題，我當時需要情況是這樣的。一個信息錄入系統，由於數據量很大，查詢需要一段時間。QTP回放時動作比較快，點了保存，程序還沒反應過來它就進行了下一步操作。這時的操作就和錄製時不一樣了，程序給出一個提示，但這個提示是錄製過程沒有的。彈出框是一般都是POP形勢（至上）的，導致QTP無法繼續回放，結果就是回放失敗。
解決辦法有兩個：
1、進行判斷，當出現這個提示時，點是/否/取消按鈕。
2、通過 Tools——Recorvery Scenario Manager 設置默認操作。
我最初就是用的第一種方法。寫一個函數判斷是否出現這個提示，如果出現就點“取消”然後wait(2)。 每個可能出現彈出框的動作後都調用一次這個函數。雖然可以解決這個問題，但回放的效率就低了，而且需要你預知提示框的信息。
當我知道了第二種方法，顯然更科學^_^。它可以對所有預知甚至不知的提示進行指定的操作。
實際上，當程序出現了未預知的提示時，可能就是程序的BUG，所以使用上述辦法解決工具問題時，也要考慮是否會掩蓋程序的缺陷。
問題三的解決辦法：
用好QTP後，會不自覺的和TD關聯起來。但從TD直接啓動QTP時，程序只會加載QTP自帶的插件，如果你安裝了其它插件（如.net、java、etc.），默認是不加載的。這會導致上傳的腳本無法正確執行。解決辦法很簡單，去 Test——Setting裏進行Modify 吧。從本地打開的腳本，這裏不能進行Modify的。所以辦法很簡單，但如果不知道的話就很難了。當初爲這個問題我可是廢了八牛三虎之力呢……
問題四的解決過程：
當我開始改代碼時，定義一個動作，然後可以生成N個動作。假設N個動作產生了N個結果，你要對這結果進行處理時，你會發現這N個結果都不能被識別:
網頁上有個表格，是往數據庫里加數據的。
兩個表格顯示在同一個頁面上，左邊爲父表，右邊爲子表。
點擊左表，右表顯示其子項目。
結構如下：
A
├─1
├─2
├─3
└─4
B
├─1
├─2
├─3
└─4
……
思想很清晰：
添加一個父項A、選中此父項A、對其添加子項1、2、3、4
添加一個父項B、選中此父項B、對其添加子項1、2、3、4 ……
代碼也很簡單：
dim M '定義父項數
dim N '定義每個父項包含的子項數
For i=1 to M
Call 添加父項( i )
選中父項( i ) '問題就出在這裏
For j=1 to bwfl step 1
Call 添加子項( j )
Next
Next
現在問題出來了，思路應該沒有問題（除非這方法真的行不通），循環也是順着思想來的。
問題是，無法實現選中的父項（最多識別到一個）。
由於此循環可以在錄製過程進行，如果不改變變量名稱，循環可且只可以成功運行一次。問題是這個名稱都是從DataTable裏獲取的。
因爲，在運行過程中生成的項目沒有加到對象庫中，無法被識別。
這個問題最後是從思想上解決的。答案是我做的是功能測試，爲什麼不先加父項，檢查父項的功能是否正常，然後再去測子項的功能。不去改變名字，因爲那沒有必要。核心答案“功能測試、測試功能”。即對測試工具首先需要有正確的認識。
當然，這個問題可以用代碼去實現，但那需要有一定的編程功底且耗時，可維護性不一定好。有需要的朋友可以去試一下，然後把你的經驗也共享一下。
問題五，是對QTP很大的一個擴充。
對於QTP調用外部DLL的功能，由於我的編程功底不夠，沒有相關人士配合我，我只能望之垂涎了！
如果能調用外部DLL的話，QTP的功能就可以變得很強大。自己寫的程序，自己編一些過程用QTP進行測試，我想“後果很嚴重” 。真想有一次給我嘗試的機會……
1、測試的時候，讓程序員把這塊限制去掉，免去驗證這關。
2、讓程序員提供一個萬能驗證碼，測試可以繞過這一關。
3、請程序員提供識別的方法，從獲取的圖片讀出驗證數據，再傳給QTP。
4、進行位圖檢查，將驗證碼分段進行圖像驗證。
實際上，驗證碼的目的就是防止用程序灌水或機器錄入信息。所以有點爲難我們測試了。
方法1，如果程序已在發佈並有客戶使用，危險性是可想而知的。方法2雖然可以解決驗證這一關，但跳過了輸入碼與驗證碼一致性問題。方法3就需要程序員配合了，可能就需要調用DLL了。方法4卻將圖像分段，把獲取的圖像和已經的圖像進行比對，比對通過取對應的值；這個在數字驗證會好做一點，因爲最多就四個圖像的比對。
關於網上的漢字驗證碼，那塊的測試我就不知道他們是怎麼做的了。真想了解一下！