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表中是否存在指定的表
原文轉自:http://www.uml.org.cn/Test/201304163.asp