自動化測試框架的基礎是鉤子，也就是常說的hook機制。但這在實際的應用過程中可能會遇到一些問題。
一旦要做鉤子，那麼就必須獲取函式位址。由於我原先設計的鉤子的目標函式，都是delphi的內部函式，也就是說，這些函式在編譯之後，很難找到。
當然了，也是有幾種方式可以找到的：
將**植入到系統中，編譯的時候可以直接找到。
編譯的時候，帶上map檔案，可以通過map找到函式位址。測試框架以dll的方式遠端注入。
delphi中的包，可以公布這些函式的位址
前兩種方式，有乙個最大的缺點，在於必須為自動化測試，特別編譯乙個版本。雖然說可以接受，但顯然不是最好的方案。第三種方案雖然好，但是前提是系統必須構建在帶包編譯的基礎上。
幸好，我們目前的測試的系統就具備這樣的條件。
那麼，對於自動化測試框架來說，只需要隨意作為乙個dll，並注入到原系統中就可以了。如果原系統提供了注入的擴充套件，那是最好。因為這樣除錯起來很方便。否則就做成遠端注入，不過除錯的時候只能attach了，很麻煩。
這個時候，只需要將包含自動化測試框架**的測試用例**，對vcl的包，帶包編譯，就可以做到對包中函式的hook了。不過這裡面還是有一些細節需要注意的。原先我用的是fastcode的hook**，但是在代表編譯的時候就失效了。經過追查，發現代表編譯和非帶包編譯的**不一樣。由於vcl的**，編譯到了包中，那麼本dll在呼叫包中的方法的時候，加上了跳轉指令。簡單的就是乙個call操作。在包裝載的時候，call後的位址會更新。
經過一些探索，發現中國的cnpack(www.cnpack.org
)中早就針對這個問題有了解決方案。其實方法也很簡單，就是判斷一下是否存在位址跳轉，如果有的話，就取跳轉後的位址，否則取當前位址。
完成了鉤子後，我們就會發現，在我的測試用例的dll中，對bpl中的方法，進行了hook。請注意，這裡面有乙個選擇，就是在dll內部hook，還是在bpl內部hook。在dll內部hook，只需要修改跳轉位址即可，鉤子的方法很簡單。在bpl中hook，則需要修改函式**的前5個位元組，這種方法複雜，但是使得入口單一，一處修改，全面有效。
自動化測試框架，就是選用的後者的hook方法。這樣，我們在dll中，對bpl中的方法進行了hook，所有帶著此包編譯的dll或者exe，都會受到影響。而這也正是我們想要的。
解決了這個問題後，我們就可以針對已有的系統安裝程式進行測試，而不需要修改任何開發**（包括版本構造過程）。滿足這個特性非常好！
自動化測試框架
可設計為五層 一 測試用例層 主要存放用例的指令碼，分為主指令碼和子指令碼。主指令碼用來控制各個子指令碼，實現指令碼間的資料傳遞。子指令碼是實現各個功能點的指令碼，同時也會提取出一些共用的方法，一般放在提取層中。主指令碼中可使用資料驅動來控制指令碼實現各種場景的流程，如silktest的test s...
自動化測試框架 自動化測試呼喚開發
週末參加了testage 測試時代 組織的乙個專家討論會。主要討論測試自動化。說是專家討論會，我參加實在是慚愧，我對測試的理解實在是太淺薄了。只是因為在部落格上發表了一些謬論才收到邀請。想著可以幫助公司去接受一些新的思想，而自己也可以結識一些朋友，便去了。對於測試時代的會議組織，我以為定位和思路還是...
自動化測試框架指南
這 是我以前寫的一篇文章，用於整理自己對自動化測試的理解。當時寫這個文章的目的，是因為剛剛掌握qtp，又使用自動化測試參與公司乙個大專案的測試，結果 發現原來掌握qtp距離自動化測試還有很遙遠的路要走，原來一直以為掌握了qtp的指令碼編寫 可以寫出所有的測試方法指令碼則自動化測試就可以大功告成了。但...