這部分主要介紹如何基於當前框架創建一個全新的自動化項目，我們約定項目路徑在F盤下，項目名稱爲AutoProject。
1.1. 目錄創建
在路徑：“F:\自動化測試管理\框架使用說明\項目初始化模板”下雙擊“雙擊生成新項目.vbs”文件，輸入【AutoProject自動化測試】點確定。
執行初始化後，可以在路徑：“F:\自動化測試管理\自動化測試項目”查看到新增的項目。
1.2. 報告數據庫配置
目前報告服務器的地址爲10.35.60.1。賬號：hyholine 密碼：Aa123456。在數據表【list_project】中添加一條項目的信息。
注：如果在此處添加記錄，則執行報告結果插入到數據庫時會失敗。
1.3. 新建測試用例腳本
在充分閱讀需要和測試用例的基礎上，安裝TD中用例組織的結構，在目錄【F:\自動化測試管理\自動化測試項目\AutoProject自動化測試\AutoProject】下創建測試集和測試用例。
1.4. 配置腳本環境
1.4.1. 加載公共函數文件
1) 在QTP工具打開菜單項Tools-Options，找到Folder項：在此處添加存在函數庫或對象庫的文件夾路徑。目的是其他配置的文件路徑可以使用相對路徑，相對路徑會在此處配置的絕對路徑下搜索匹配的文件。
2) 在QTP工具打開菜單項File-Settings，找到Resources項：在此處添加公共函數文件，默認存放在目錄【公共函數庫】下，如（F:\自動化測試管理\自動化測試項目\AutoProject自動化測試\公共函數庫）。注：全局函數文件GlobalFunction.vbs存放在目錄【Global】下，如（F:\自動化測試管理\自動化測試項目\Global）。
1.4.2. 加載公共對象庫文件
1) 在QTP工具打開菜單項Resources-Associate Repositories，在面板上添加公共對象庫文件，並把相應的Action腳本從左側列表添加到右側列表中。默認存放在目錄【共享對象庫】下，如（F:\自動化測試管理\自動化測試項目\AutoProject自動化測試\共享對象庫）。
1.5. 編寫腳本
根據需求文檔和測試用例的要求設計腳本。原則上，在編寫腳本之前務必詳細閱讀需求，在瞭解需求的基礎上，再分析測試用例的設計結構，充分考慮測試的設計結構是否滿足腳本的可實現條件。正常情況下，在分析完需求和用例後，腳本的設計雛形在腦海中應該就完成了。
1.5.1. 分析需求和用例需要考慮如下5點：
1) 需求的描述和用例是否一致，是否有遺漏，矛盾，衝突等情況。
2) 腳本的設計是否可以使用用例設計的結構（一般是可以的），如果不行，就要自己設計用例的腳本實現模式。
3) 正常一個功能點會有多個用例來覆蓋，因此需要考慮多個用例是否可以整合成爲一個腳本來覆蓋。
4) 腳本的結構要優先考慮通過數據驅動模式，當然，腳本設計的原則是以最少的成本完成最大的用例覆蓋。這裏的成本包括當前的設計、編寫、調試腳本的時間，也包括後期需要維護的時間。基於這個原則，如果數據驅動模式不容易實現，則採用逐個對應來覆蓋。
5) 在閱讀需求和用例過程中，要充分考慮每一個步驟和檢查點在腳本實現上是否可行。因爲如果某些步驟無法實現，則應該及時做出判斷，不行就放棄實現。如果待到腳本編寫了一半，才發現關鍵的功能點無法實現，那麼就等着自我反省吧。另外，爲了防止上述的問題，對於比較複雜的用例，最好是自己手工執行一遍，磨刀不誤砍柴工！
1.5.2. 編寫腳本時需要考慮如下7點
1) 腳本設計要考慮結構的合理性，例如：重複的業務邏輯，採用循環語句來遍歷覆蓋；對於可複用的業務動作或檢查點要封裝成函數；
2) 函數封裝的原則，先查找現有函數庫，存在已實現的用已實現，沒有就考慮是否有可以擴展的函數，如果也沒有就自己新建一個函數。
3) 新建函數的原則，不要僅僅考慮目前需求，也要考慮可擴展性。多多考慮你設計的這個函數在將來可能會用到的地方，涉及其他功能的調用，在不同場景下的調用。
4) 執行測試用例強調思維的發散，即在按照用例設計執行的基礎上，發揮自己的想象力，結合需求上功能點進行交叉測試。那麼在設計腳本上，也是可以借鑑，在保證基礎功能點檢查覆蓋外，也可以加入自己認爲有必要檢查點。另外，對於用例中非重要檢查點，腳本實現困難時可以選擇不覆蓋，但是，需要在對於的用例上加以說明。
5) 檢查自己編寫的腳本排版是否美觀。
6) 對於複雜的步驟需要加以註釋說明。
7) 創建函數的命名是否符合規則，是否達到見其名知其義。
1.5.3. Vbs編寫命名規則
1) 常數命名規則
全部字母大寫，多個單詞用下劃線 (_) 分隔。
例如： USER_LIST_MAX 、NEW_LINE
2) 變量命名規則
駝峯命名法。
例如：UserName、Passwd
3) 形參命名規則
全部字母小寫，多個單詞用下劃線 (_) 分隔。
例如：user_name, passwd
4) 函數命名默認規則
動作函數、使用首字母小寫駝峯命名法
例如：getEmailName、setNewUserEditValue
檢查函數、使用check開頭的駝峯命名法
例如：checkMailListBySubject、checkWriteMailMessage
5) 對象命名規則
如果是qtp對象，使用以objqtp開頭的駝峯命名法
例如：objqtp_LoginPage、objqtp_WriteMail
如果是dom對象，使用以objdom開頭的駝峯命名法
例如: objdom_SettingPage、objdom_PopMenu
6) 業務大模塊函數命名規則
參考使用mod開頭的駝峯命名法(根據業務的不同，可以採用不同的標示)
例如：mod_SendCommonMailBase、 mod_EditSettingValue_PageStyle
1.6. 腳本調試
代碼調試是每個開發人員的基本功，良好對調試習慣和排錯方法可以大大提高開發的速度。在實際生產過程中，需要針對實際情況選擇最有效的排錯方式，因此，針對VBS的代碼調試排錯，個人提出如下總結：
1) 在調試時需要在Setting窗口將錯誤處理選擇彈窗模式，另外如果有on error resume next的語句，可能包含錯誤語句，可以先註釋掉。
2) 在QTP中，首先需要排除語法錯誤，可以通過保存腳本或執行語法檢查（快捷鍵：Ctrl+F7）判斷腳本VBS語法是否正確，在底部對Information窗口可以查看到相應對錯誤信息，雙擊錯誤信息，可以定位到錯誤的腳本位置。
3) 認真分析執行中報錯對信息，新手往往看到報錯很緊張，沒有認真閱讀錯誤提示信息就關閉窗口進行調試，這是錯的。錯誤提示信息是分析錯誤對第一手資料，同時也判斷出錯誤對位置。
4) 設置斷點、單步調試、輸出變量、查看變量、執行調試動作等，這些都是常規對調試方法，可以有選擇的使用。在QTP中，調試的功能還是比較不錯的，基本滿足調試任務對需要，相關的功能可以認真閱讀分析Debug菜單項和Debug Viewer視窗。
5) 調試過程中，有些函數或業務模塊過於複雜，可以將通過拆分，將認爲可能存在問題對代碼行拷貝出來單獨調試。這樣處理方式更有針對性，排除外部的干擾，降低調試對複雜度。
1.7. 設計數據驅動
1.7.1. 概念說明：
數據驅動是自動化測試框架中的一個重要思想，其目的是要讓測試業務邏輯和測試業務數據剝離開，進行分別管理，所帶來的最大好處是結構更清晰，維護更便捷。目前框架的數據驅動支持Excel和Mysql數據庫的驅動模式，默認是Excel模式，Mysql模式需要另行配置。
1.7.2. 邏輯說明：
Excel驅動模式，通過函數方法【addExcelData】或【addExcelData_Action】執行數據加載，函數根據測試集名稱和測試用例名稱在Excel數據表【測試驅動數據表.xlsm】中搜索，判斷存在相應字段信息則會加載到QTP的數據池中。
Mysql驅動模式，不建議使用，主要原因是從維護上到數據庫編輯沒有Excel方便。
1.7.3. 使用方法：
在腳本可以通過QTP提供的方法訪問數據池中的數據，也可以使用框架封裝的方法來訪問（框架提供如下數據池操作方法）
1) 判斷datatable表中是否存在指定的表
2) existDatasheet(Byval sheetname)
3) 判斷datatable指定表中是否存在指定的列
4) existDataParameter(Byval sheetname, Byval parametername)
5) 往QTP數據表中加載Excel數據主體函數，適用於默認加載Action
6) addExcelData()
7) 往QTP數據表中加載指定的Excel數據
8) addSpecifyExcelData(setname,casename)
9) 通過封裝，獲取數據表中的值 GetData(Row,ParamaterID,SheetID)
10) 返回特定的數據表中的某一列有效行數 getParemeterRowCount(Byval paremetername, Byval sheetname)
11) 通過封裝，獲取特點字段對應的數據表中的值 GetSpecialData(Byval reField,Byval reValue,Byval geField,Byval SheetID)
1.7.4. Excel數據表約定：
用例腳本的測試集名稱 對應於 Excel表中的表名【測試集名稱】
用例腳本的測試用例名稱 對應於 Excel表中字段【★測試用例名稱】
舉例：假設，新建測試集的名稱(測試用例的父文件夾名稱)爲“MyTestSet”,測試用例名稱爲“MyTestCase1”。那麼你需要在測試驅動數據表【測試驅動數據表.xlsm】中新建一張sheet表，命名爲MyTestSet。在表中添加數據表，表的格式如上圖，獨立一行命名測試用例名稱，在名稱前加上小星星圖標，表示該值爲用例名稱，中間部分根據腳本需要添加相應的數據，在末尾獨立一行填入結束標示符【◆◆◆◆】，表示當前的用例數據加載到此爲止。
1.8. 設計公共函數庫
1.8.1. 概念說明：
爲什麼要寫函數？爲什麼要定義函數庫？函數封裝本質是體現分工協作的關係，寫的人關心函數的內部實現過程，保證功能的實現正確和健壯性。而使用的人僅僅需要函數提供的接口和返回值。這好比你想有輛車，不需要了解內部構造，但是要懂得如何駕駛它。從計算機科學上，函數的封裝也體現了開發語言的美，不想讓自己成爲搬碼工的最好方法，就是學會創造、激發自己的靈感，讓自己封裝出的函數足夠靈活強大。
1.8.2. 使用說明：
函數庫分兩類：
一類是用來支撐自動化測試框架和輔助腳本開發，命名爲【GlobalFunction.vbs】；
一類是針對項目開發的功能函數集合，僅僅爲當前的項目腳本開發服務，如：
動作函數集合（XXX_ActionFunction.vbs）
檢查函數集合(XXX_CheckFunction.vbs)
對象函數集合(XXX_Object.vbs)
業務函數集合（XXX_Module.vbs）
配置函數文件（XXX_Config.vbs）
目前函數庫文件的管理採用頭部說明的方式，即在每份函數文件的頭部編寫函數的目錄信息，方便搜索和查閱，在函數設計上需要檢查如下10點：
1) 函數的編寫風格是否美觀，代碼相應的縮進是否排布清晰。
2) 函數是否可以在現有函數的基礎上擴展，如果可以儘量在現有函數的基礎上擴展實現。
3) 函數命名是否符合規則，是否見其名知其義。
4) 函數中的內部變量是否有定義。
5) 函數中是否存在冗餘的代碼，即存在可以通過調用現有的功能函數來實現。
6) 函數是否充分考慮到功能的擴展和不同場景的使用。
7) 函數的功能是否正確，是否經過嚴格的調試和檢查。
8) 函數定義爲Function，是否有正確的返回值，對於不同的調用場景下是否有準確的數據返回。
9) 函數執行過程中，對於特殊情況是否有處理，例如，對象不存在或取值錯誤的情況下。即，函數的代碼是否足夠健壯。
10) 函數名是否會存在重名，如果存在重名會導致調用失敗。
1.9. 設計公共對象庫
1.9.1. 概念說明
對象庫顧名思義即用來管理測試對象。自動化測試最爲核心的技術即對象的識別技術，不管哪個自動化測試工具，對象識別越厲害，吸引的使用羣體就越多，市場佔有率也就越大。所以說，對象識別既是自動化測試的基礎，也是難點。QTP中對象庫採用了樹狀文件式的管理方法，分爲本地對象和公共對象。本地對象只提供給當前依附的腳本使用，不提供給外部的腳本使用，反之，公共對象，即一個獨立的庫文件，腳本需要就加載它使用，與之帶來的好處，即全部的腳本對象管理僅需要維護一份對象庫文件。
1.9.2. 論對象識別機制
QTP工具在管理對象庫方面是成功的，對象管理的結構很清晰，也很簡單，對於開發人員來講易於管理和使用，例如：對象的關聯方法、對象的定義、對象的識別處理機制。個人覺得這些都是QTP工具上的亮點。以前，網上論壇常有人在爭論描述性識別對象方法和對象庫識別對象方法的優劣之分，其實，在我看來，二者本無優劣之分，僅有在特定的情況下，那種方法更適用，更方便腳本的開發。此處，我總結下我的看法：
1) 描述性對象識別方法：使用簡單、體現直觀、易於理解、處理靈活，在小規模項目和簡單的對象識別上可以考慮使用，但是前提是對象在後期不會變更，否則隨之帶來的是大量的維護任務。
2) 對象庫識別方法，科學管理、識別機制更強大、適用於大型的自動化項目開發，多人協作模式，以及項目對象頻繁變更的場景下。一般是推薦使用對象庫來管理識別對象，更有利於整個項目的管理。
上述二者之關係，好比一個是摩托車（描述性方法），一個是轎車（對象庫管理），都可以用來處理對象識別，因爲他們都是用發動機引擎，不過發動機的引擎規格不同，決定了它們的性能不同。摩托車固然靈活輕巧，容易駕駛上手，但是安全性不足，上了高速容易出事故，拋頭顱，灑熱血！而轎車呢，成本高，得先考駕照吧，即掌握使用方法，然而，相比摩托車，其速度更快、安全性更高（安全氣囊）、行程更遠。
另外，引用上述比喻，轎車也非萬能，跑高速路上很優秀，但是走山路呢？這裏想說明一個問題，對於產品的web對象可識別度不高、開發人員無法給與支持配合的情況下，對象庫的使用也容易出現不靈光的現象，畢竟QTP對象庫提供的識別技術有限。解決辦法？請挽起袖子自己造輪子吧！這也是定義對象庫文件【XXX_Object.vbs】的目的之一，對於識別難的對象（包括識別不到和識別速度慢），可以採用DOM方法封裝函數對象的方式處理。這個方法目前在多個項目中被使用，效果比較好，因爲這樣即利用了對象庫的優點，也提高了對象識別的靈活度。
1.9.3. 公共對象庫的管理方法
對於新手，往往對對象庫管理比較不感冒，使用過程也常頭疼，覺得寫個腳本中間還隔着個對象庫，不論編寫或維護腳本都比較麻煩。但是隨着學習的深入以及經驗的積累，對於QTP對象庫會更爲準確的認識。
本人在這三年來積累的一些相關認識記錄下來供大家參考：
1) 使用對象庫，必須先掌握對象識別機制，否則一定管理不好對象庫。例如測試對象中的Web控件類別、每一類對象常用到幾種定位屬性、對象識別的優先順序和策略等。
2) 對象庫的目錄樹需要合理規劃，正常情況下可以按照頁面的功能排布來劃分，如果存在特殊的對象，如上傳彈窗，頁面彈窗等，也可以根據對象的類別獨立出來管理。良好的對象庫目錄樹分類有助於腳本的編寫和對象庫的維護。
3) 對象命名的方式也需要統一準確，避免和其他模塊的對象名稱相混淆。對於集合類的對象需要做出特徵標示，標示該對象屬於集合對象、可以通過定義屬性來定義對象。其次，良好的命名風格，可以使對象在目錄樹中分門別類清晰排布，如果隨意命名，對象顯示會呈現散亂不易管理。
4) 對象添加到對象庫後，需要對特徵屬性進行重新確認並編輯，因爲QTP默認識別到的對象屬性不一定是最優方案，需要根據項目的對象特點採用最爲穩定的特徵屬性。另外，對於使用定位屬性（Index、Location、CreateTime）這類的對象，一定要慎重！多考慮在不同場景下，對象的定位是否準確。
5) 對象庫中的定位屬性，並不是越多越好，也不是越少也好，而是應該從穩定和識別速度上來取捨。
6) 通過對象庫工具添加對象不一定能定位到屬性，此時，可以使用FireBug這類工具來查看對象代碼，通過分析代碼抓取有效的特徵值。
7) 靈活運用對象定位屬性值的正則匹配方法，對於某些特徵值，雖然不固定，但是有一定的規律，此時可以使用正則表達式來匹配，往往會有驚喜！
1.10. 設計腳本批量執行
1.10.1. 概念說明：
腳本批量執行就是根據給定對配置，調用執行工具對多個腳本進行遍歷執行，並將執行對結果保存到指定對位置以供分析。
1.10.2. 批量執行方法
我們對執行工具是QTP，自然是要調用QTP的對象接口，通過定義對象接口，加載執行信息，讓QTP按照我們的指示執行腳本，目前，我們對執行平臺爲Excel，基本可以滿足批量執行對要求。基本的原理是通過VBA函數調用驅動文件【Action驅動.vbs】，驅動文件再加載Excel中的腳本執行路徑信息和配置信息，通過調用QTP對象實現執行批量。
添加執行腳本的方法如下圖，中對應的列【二級路徑】和【Action】添加路徑和腳本名，然後中【執行】列選擇打鉤。這樣就成功添加了一條執行記錄。
下圖爲執行對配置信息，腳本執行時會使用此處對配置信息，因此中執行腳本前，務必要檢查一下配置信息是否正確。
1.11. 查看測試報告
1.11.1. 概念說明
測試報告承載了整個自動化過程的心血，我們需要通過測試報告分析腳本缺陷、產品缺陷、用例覆蓋率等。擁有良好的測試報告展示效果對於一個自動化框架而言尤爲重要。測試報告的載體多樣化、常見的如：文本、Excel、XML、HTML。
1.11.2. 報告包含信息和功能
1) 執行的過程信息：執行時間、執行信息。
2) 檢查點判斷信息：執行時間、執行判斷結果、執行信息。
3) 排錯輔助信息：截圖、錄像、驅動數據。
4) 報告的排序、過濾、搜索等功能。
1.11.3. 測試報告輸出類型:
1) 日常調試日誌輸出：存放在項目路徑【輸出數據\用例測試報告日誌】下。
2) 腳本執行過程日誌輸出：存放在項目路徑【輸出數據\用例測試報告日誌\debug】下。
3) 批量執行Excel報告：存在在項目路徑【輸出數據】下的測試報告.xlsm。
4) 批量執行Web報告：存放在http://auto.35test.cn/readqtp下。