我的測試曆程—QTP之狹義的資料驅動模型

07年我參加了軟體測試工程師教育訓練課程（課程中包含自動測試工具，功能：qtp，性能：lr），qtp課程主要講解了qtp的關鍵字視圖相關的内容（專家視圖部分沒有涉及），教育訓練完以後，我對qtp的認識是：qtp使用起來很簡單，就是一個錄制、回放（不通過就調試）、細化腳本、再回放（不通過就再調試）、出報告的過程，那時候對qtp的認識很膚淺，也和一些朋友一樣對qtp産生過類似的質疑：qtp能滿足實際項目包羅萬象的需求嗎？當時感覺qtp隻能應用在主要流程的驗證上，而且沒有真正意義上做到測試的自動化（當然以上都是07年對qtp的認識）于是我停止了繼續深入學習qtp……

　　09年9月左右，由于項目人手少，測試時間又短，是以每次版本更新後，隻對新增功能和相關子產品進行測試，而比較穩定的子產品隻走一個正常流程（甚至時間太緊連正常流程也來不及走了），另外由于我所在項目和另外一個項目都是一個大項目的子項目，是以另外一個項目的修改也可能導緻本項目的一些功能不可用，下面有個實際項目中遇到的例子：有一次另外那個項目修改了資料庫結構，資料庫中删除了一個字段，導緻我這個項目的一些特别穩定的功能中查詢該字段的所有地方都報“黃頁”（當然這些地方都做了安全處理，隻抛了個自定義的頁面，沒有把代碼抛出來），當時吓出了一身“冷汗”，還好每次更新我都會挑一些沒有修改子產品進行抽查，這次運氣好，剛好抽到了，俗話說：“吃一塹長一智”，就算完全沒有修改的子產品也應該驗證一下，但是目前的時間和人力隻夠對新功能的測試，我又想到了qtp，于是我安裝了qtp，将老功能的業務流程錄制成腳本，每次更新後，跑一下流程，驗證一下老功能是否可用，成功案例：有一次qtp回放當中發現2個地方報“黃頁”，後來才知道是因為另外一個項目更新了webservice，而我這個項目的那2個地方剛好要調用那個webservice，是以會報錯，由于這一次的經曆讓我忽然對qtp産生了興趣，對qtp腳本進行了更深入的學習，從07年的完全自動錄制到現在的手動寫腳本，從腳本依賴對象庫到脫離對象庫，從求助别人到幫别人寫實際項目的自動化測試腳本，從各個測試腳本互相獨立，到自己編寫自動化測試架構……2個月前自己寫了個測試架構，實作了運作一個vbs腳本，就可以打開qtp（脫離對象庫）并按照case優先級從高到低運作所有需要運作的case，運作結束自動将結果寫入檔案中……2個星期前重新設計架構提高腳本開發效率和簡單易用性。

　　下面寫下現在我對qtp的看法：在沒有接觸自動化測試架構之前，我所有的腳本都是都是互相獨立的，即：每個功能作為一個testcase，這樣就導緻每次都要手動把每個腳本運作一遍，然後看報告，感覺自動化一點也不自動化，而且腳本的可重用性也很不好。于是我就在想，怎樣才能做到真正意義上的自動化呢？可不可以通過運作一個驅動腳本打開qtp然後自動運作所有指定的腳本用例呢？後來在網上查了相關資料，開始自己搭建自動化測試架構：

　　我的第一個架構：由依賴對象庫到脫離對象庫，由自動錄制到手動編寫測試腳本。這個架構思想是學習于51

　　論壇中的《輕量級自動化測試架構》，隻不過在此基礎添加了一些功能，比如用例執行優先級。當時覺得這個架構很好用，全部使用描述性程式設計這樣可以使用例不依賴對象庫運作，提高了腳本的可移植性，但是随着對qtp認識的不斷的深入，漸漸的發現描述性程式設計的弊端：腳本開發效率太低，同樣開發一個測試腳本，完全使用描述性程式設計和自動錄制+手動增強腳本相比，錄制一個同樣的功能，需要的時間大約3-4倍，甚至更長，因為使用描述性程式設計需要對對象的各個屬性特别熟悉，另外完全使用描述性程式設計的調試效率也很低，使用哪些屬性作為識别該對象的依據又需要一個判斷過程，這樣都會降低測試腳本的開發效率，還有描述性程式設計對程式設計基礎有一定要求，是以我覺得腳本開發應該以自動錄制+手動增強腳本為主，以描述性程式設計為輔。因為在有的項目中有些步驟可能通過自動錄制是錄制不到的，這時候描述性程式設計就起到很好的輔助作用。

　　我的第二個架構：由脫離對象庫到依賴對象庫，由手動編寫測試腳本到自動錄制+手動增強腳本（以描述性程式設計為輔）。由于第一個架構的弊端，是以我在想怎樣避免這個弊端，提高腳本開發效率，自動錄制是開發腳本最快的一種方式，而且對腳本開發人員的要求很低，于是我開始把目光回歸到qtp這一最簡單最基本的功能上。開始設計一個屬于我們“菜鳥”的測試架構。（其中借鑒了《qtp項目應用與進階》中測試用例模闆）

　　這個架構（相對于第一個架構）的優點：1、降低人員素質的要求，使用例的腳本開發人員不需要懂得太多qtp方面的專業知識，隻要掌握簡單的錄制回放過程和腳本增強就可以，這樣避免有些人整天忙有些人“沒事”做了，進而達到資源的充分利用。2、提高腳本開發效率。

　　這個架構（相對于第一個架構）的缺點：調用外部action相對複雜一點，需要明确知道該action所在腳本的位置，不過這一點可以通過文檔解決這個問題，制作一個 action清單就可以了。2、對象+

　由于這個架構寫在了“丫頭”的畢業論文中，目前她還沒答辯，為了避免不必要的麻煩，是以這裡就不詳細寫了（大家看了附件的架構執行個體就應該能明白我的思路了）本執行個體是使用qtp10.0錄制的，重點闡述的是一種思想，腳本中很多功能未加入。例如：自動加載插件的功能，不過大家可以自己加一下（qtp自動化對象模型參考中有加載插件的代碼），另外qtp版本比較低的朋友可以自己錄制下腳本替換掉script檔案夾下對應的腳本試下。若要設定腳本運作時qtp可見，可以将函數driver（）中的qtapp.visible=false修改為qtapp.visible=true

　　最後，如果哪位朋友有什麼好的建議或覺得哪裡需要改進，可以給我留言，如果有時間我會試着改進一下，另外寫的不好的地方也請多多指正，謝謝！

　　向大家推薦2本qtp相關的很不錯書：

　　《qtp項目應用與進階》 e測工作室（風過無息、斐明哲、黃先容、韓柳、俞戴龍 化學工業出版社

　　《qtp自動化測試實踐》 陳能技 電子工業出版社

　　第一本書我買了而且前段時間看了，感覺很不錯，思路很清晰，而且包含編碼規範等自動化以外的的知識，感覺寫的蠻好的。

　　第二本書最近才了解到這本書，不過沒看過，朋友說很不錯，正打算買呢，另外看了作者部落格裡的資料，感覺寫的很好，是以就推薦大家看看，希望能對大家有所幫助，謝謝！

版權聲明：本文由會員 feiyunkai 首發于51testing軟體測試論壇 [軟體測試新手上路] 版塊。

原創作品，轉載時請務必以超連結形式标明本文原始出處、作者資訊和本聲明，否則将追究法律責任。