07年我參加了
軟件測試工程師培訓課程（課程中包含自動測試工具，功能：
QTP，性能：LR），QTP課程主要講解了QTP的關(guān)鍵字視圖相關(guān)的內(nèi)容（專家視圖部分沒有涉及），培訓完以后，我對QTP的認識是：QTP使用起來很簡單，就是一個錄制、回放（不通過就調(diào)試）、細化腳本、再回放（不通過就再調(diào)試）、出報告的過程，那時候?qū)TP的認識很膚淺，也和一些朋友一樣對QTP產(chǎn)生過類似的質(zhì)疑：QTP能滿足實際項目包羅萬象的需求嗎？當時感覺QTP只能應(yīng)用在主要流程的驗證上，而且沒有真正意義上做到測試的自動化（當然以上都是07年對QTP的認識）于是我停止了繼續(xù)深入學習QTP……
09年9月左右，由于項目人手少，測試時間又短，所以每次版本更新后，只對新增功能和相關(guān)模塊進行測試，而比較穩(wěn)定的模塊只走一個正常流程（甚至時間太緊連正常流程也來不及走了），另外由于我所在項目和另外一個項目都是一個大項目的子項目，所以另外一個項目的修改也可能導致本項目的一些功能不可用，下面有個實際項目中遇到的例子：有一次另外那個項目修改了
數(shù)據(jù)庫結(jié)構(gòu)，數(shù)據(jù)庫中刪除了一個字段，導致我這個項目的一些特別穩(wěn)定的功能中查詢該字段的所有地方都報“黃頁”（當然這些地方都做了安全處理，只拋了個自定義的頁面，沒有把代碼拋出來），當時嚇出了一身“冷汗”，還好每次更新我都會挑一些沒有修改模塊進行抽查，這次運氣好，剛好抽到了，俗話說：“吃一塹長一智”，就算完全沒有修改的模塊也應(yīng)該驗證一下，但是目前的時間和人力只夠?qū)π鹿δ艿臏y試，我又想到了QTP，于是我安裝了QTP，將老功能的業(yè)務(wù)流程錄制成腳本，每次更新后，跑一下流程，驗證一下老功能是否可用，成功案例：有一次QTP回放當中發(fā)現(xiàn)2個地方報“黃頁”，后來才知道是因為另外一個項目更新了WEBSERVICE，而我這個項目的那2個地方剛好要調(diào)用那個WEBSERVICE，所以會報錯，由于這一次的經(jīng)歷讓我忽然對QTP產(chǎn)生了興趣，對QTP腳本進行了更深入的
學習，從07年的完全自動錄制到現(xiàn)在的手動寫腳本，從腳本依賴對象庫到脫離對象庫，從求助別人到幫別人寫實際項目的
自動化測試腳本，從各個測試腳本相互獨立，到自己編寫自動化測試框架……2個月前自己寫了個測試框架，實現(xiàn)了運行一個VBS腳本，就可以打開QTP（脫離對象庫）并按照CASE優(yōu)先級從高到低運行所有需要運行的CASE，運行結(jié)束自動將結(jié)果寫入文件中……2個星期前重新設(shè)計框架提高腳本開發(fā)效率和簡單易用性。
下面寫下現(xiàn)在我對QTP的看法：在沒有接觸自動化測試框架之前，我所有的腳本都是都是相互獨立的，即：每個功能作為一個TESTCASE，這樣就導致每次都要手動把每個腳本運行一遍，然后看報告，感覺自動化一點也不自動化，而且腳本的可重用性也很不好。于是我就在想，怎樣才能做到真正意義上的自動化呢？可不可以通過運行一個驅(qū)動腳本打開QTP然后自動運行所有指定的腳本用例呢？后來在網(wǎng)上查了相關(guān)資料，開始自己搭建自動化測試框架：
我的第一個框架：由依賴對象庫到脫離對象庫，由自動錄制到手動編寫測試腳本。這個框架思想是學習于51
論壇中的《輕量級自動化測試框架》，只不過在此基礎(chǔ)添加了一些功能，比如用例執(zhí)行優(yōu)先級。當時覺得這個框架很好用，全部使用描述性編程這樣可以使用例不依賴對象庫運行，提高了腳本的可移植性，但是隨著對QTP認識的不斷的深入，漸漸的發(fā)現(xiàn)描述性編程的弊端：腳本開發(fā)效率太低，同樣開發(fā)一個測試腳本，完全使用描述性編程和自動錄制+手動增強腳本相比，錄制一個同樣的功能，需要的時間大約3-4倍，甚至更長，因為使用描述性編程需要對對象的各個屬性特別熟悉，另外完全使用描述性編程的調(diào)試效率也很低，使用哪些屬性作為識別該對象的依據(jù)又需要一個判斷過程，這樣都會降低測試腳本的開發(fā)效率，還有描述性編程對編程基礎(chǔ)有一定要求，所以我覺得腳本開發(fā)應(yīng)該以自動錄制+手動增強腳本為主，以描述性編程為輔。因為在有的項目中有些步驟可能通過自動錄制是錄制不到的，這時候描述性編程就起到很好的輔助作用。
我的第二個框架：由脫離對象庫到依賴對象庫，由手動編寫測試腳本到自動錄制+手動增強腳本（以描述性編程為輔）。由于第一個框架的弊端，所以我在想怎樣避免這個弊端，提高腳本開發(fā)效率，自動錄制是開發(fā)腳本最快的一種方式，而且對腳本開發(fā)人員的要求很低，于是我開始把目光回歸到QTP這一最簡單最基本的功能上。開始設(shè)計一個屬于我們“菜鳥”的測試框架。（其中借鑒了《QTP項目應(yīng)用與進階》中
測試用例模板）
這個框架（相對于第一個框架）的優(yōu)點：1、降低人員素質(zhì)的要求，使用例的腳本開發(fā)人員不需要懂得太多QTP方面的專業(yè)知識，只要掌握簡單的錄制回放過程和腳本增強就可以，這樣避免有些人整天忙有些人“沒事”做了，從而達到資源的充分利用。2、提高腳本開發(fā)效率。
這個框架（相對于第一個框架）的缺點：調(diào)用外部ACTION相對復雜一點，需要明確知道該ACTION所在腳本的位置，不過這一點可以通過文檔解決這個問題，制作一個 ACTION列表就可以了。2、對象+
由于這個框架寫在了“丫頭”的畢業(yè)論文中，目前她還沒答辯，為了避免不必要的麻煩，所以這里就不詳細寫了（大家看了附件的框架實例就應(yīng)該能明白我的思路了）本實例是使用QTP10.0錄制的，重點闡述的是一種思想，腳本中很多功能未加入。例如：自動加載插件的功能，不過大家可以自己加一下（QTP自動化對象模型參考中有加載插件的代碼），另外QTP版本比較低的朋友可以自己錄制下腳本替換掉Script文件夾下對應(yīng)的腳本試下。若要設(shè)置腳本運行時QTP可見，可以將函數(shù)driver（）中的qtapp.visible=False修改為qtapp.visible=True
最后，如果哪位朋友有什么好的建議或覺得哪里需要改進，可以給我留言，如果有時間我會試著改進一下，另外寫的不好的地方也請多多指正，謝謝！
向大家推薦2本QTP相關(guān)的很不錯書：
《QTP項目應(yīng)用與進階》 E測工作室（風過無息、斐明哲、黃先容、韓柳、俞戴龍 化學工業(yè)出版社
《QTP自動化測試實踐》 陳能技 電子工業(yè)出版社
第一本書我買了而且前段時間看了，感覺很不錯，思路很清晰，而且包含編碼規(guī)范等自動化以外的的知識，感覺寫的蠻好的。
第二本書最近才了解到這本書，不過沒看過，朋友說很不錯，正打算買呢，另外看了作者博客里的資料，感覺寫的很好，所以就推薦大家看看，希望能對大家有所幫助，謝謝！
版權(quán)聲明：本文由會員 feiyunkai 首發(fā)于51Testing軟件測試論壇 [軟件測試新手上路] 版塊。
原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
相關(guān)文章：