自動化測試和QTP工具培訓(xùn)資料-大開科技-V10第一頁，共116頁。目錄構(gòu)建自動化測試框架自動化測試介紹自動化測試流程QTP自動化測試工具第二頁，共116頁。對自動化測試的理解定義：指以程序運行的方法替代人工測試，從而達(dá)到減少手工工作量，提高測試效率目的。理解：用機(jī)器或工具自動執(zhí)行的測試，替代人完成重復(fù)性勞動，但不能完全取代人。自動化測試需要用到測試工具，測試工程師的參與。自動化測試技術(shù)可應(yīng)用于所有的測試階段。不僅僅是商業(yè)測試工具、開源測試工具、自行編制測試工具或測試腳本。只要能夠部分代替手工測試提高執(zhí)行效率。第三頁，共116頁。對自動化測試的理解提高測試效率，降低測試成本重復(fù)性強(qiáng)的手工勞動用自動化替代快速的回歸測試，提高新版本發(fā)布的速度和質(zhì)量避免人工測試容易犯的錯誤，如：錯誤測試，漏測試，多測試等。很容易就實現(xiàn)并發(fā)測試，加快進(jìn)展需要規(guī)范的測試管理不能創(chuàng)造性發(fā)現(xiàn)測試腳本沒有設(shè)計的缺陷需要自動化測試開發(fā)工程師對測試環(huán)境要求比較嚴(yán)格在資源投入和產(chǎn)出方面進(jìn)行權(quán)衡自動測試腳本的修改、維護(hù)工作量大為評估軟件質(zhì)量提供數(shù)據(jù)支持，完整的測試是評定軟件質(zhì)量的一種方法第四頁，共116頁。樹立對自動化的正確認(rèn)識適用性培訓(xùn)維護(hù)運用自動化測試優(yōu)缺點提高測試效率，降低測試成本測試人員更注重測試結(jié)果分析提高新版本發(fā)布的速度和質(zhì)量避免人工重復(fù)測試易犯的錯誤可以實現(xiàn)多機(jī)自動化并行測試優(yōu)點不能創(chuàng)造性發(fā)現(xiàn)缺陷需要規(guī)范化的管理對人員有編程要求對測試環(huán)境要求高變化帶來的腳本維護(hù)缺點第五頁，共116頁。自動化測試目標(biāo)只適用于功能測試階段，因為一般會：給定預(yù)算，進(jìn)度，資源給定平均或期望的測試運行次數(shù)根據(jù)業(yè)務(wù)流程的不同（復(fù)雜度和風(fēng)險）最大化自動化率（只能達(dá)到有限值）初級階段目標(biāo)可以適用于回歸測試：自動化率可以逐步提高增加自動化測試的次數(shù)減少測試運行時的缺陷高級階段目標(biāo)通過靈活的合理的自動化測試目標(biāo)最大化時間和資源的利用率和價值第六頁，共116頁。為什么需要自動化測試維護(hù)周期長、兼容性高、多語言多版本的系統(tǒng)無人值守運用，充分利用時間，縮短發(fā)布周期有利于測試資產(chǎn)的積累、存儲和移交、管理第三方自動化測試工具有利于自動化測試的效率組織發(fā)展、技術(shù)更新…第七頁，共116頁。為什么需要自動化測試大多數(shù)項目處于維護(hù)階段，程序界面變動較少大量局部需求變更、增加新業(yè)務(wù)、bug修復(fù)測試任務(wù)在某些業(yè)務(wù)功能測試中經(jīng)常要反復(fù)編造業(yè)務(wù)數(shù)據(jù)冒煙測試、兼容性測試、版本驗證、波及影響測試等需投入大量工作量復(fù)雜的公式計算和統(tǒng)計計算等占用手工測試人員較多的時間，且容易出錯手工測試用例不容易形成資產(chǎn)積累第八頁，共116頁。自動化測試是軟件測試發(fā)展的方向業(yè)務(wù)改進(jìn)軟件下發(fā)研發(fā)過程變更管理測試管理源代碼管理自動化測試全面提高工作效率系統(tǒng)升級配置管理軟件研發(fā)第九頁，共116頁。自動化測試自動化測試版本管理單元測試每日構(gòu)建集成測試系統(tǒng)測試第十頁，共116頁。自動測試技術(shù)的發(fā)展第一代自動測試技術(shù)實現(xiàn)：錄入回放第二代自動測試技術(shù)

實現(xiàn)：腳本技術(shù)，可以加入腳本實現(xiàn)邏輯第三代自動測試技術(shù)實現(xiàn)：數(shù)據(jù)驅(qū)動，數(shù)據(jù)與測試腳本分離第四代自動測試技術(shù)實現(xiàn)：關(guān)鍵字驅(qū)動、構(gòu)件化測試，業(yè)務(wù)驅(qū)動第十一頁，共116頁。數(shù)據(jù)驅(qū)動驅(qū)動

數(shù)據(jù)驅(qū)動主要優(yōu)點是：1、測試腳本與測試數(shù)據(jù)的分離；2、執(zhí)行測試用例的人員關(guān)注測試數(shù)據(jù)表與測試報告表；3、測試腳本的執(zhí)行離散的。第十二頁，共116頁。關(guān)鍵字驅(qū)動技術(shù)關(guān)鍵字驅(qū)動 關(guān)鍵字驅(qū)動的自動化測試框架是在數(shù)據(jù)驅(qū)動的基礎(chǔ)上進(jìn)行改進(jìn)，數(shù)據(jù)源里包含的不只是數(shù)據(jù)，還有關(guān)鍵字，一個測試用例由一個或若干個關(guān)鍵字組成。每個關(guān)鍵字對應(yīng)個不同的業(yè)務(wù)邏輯。關(guān)鍵字主要包括三類：被操作對象（Item）、操作（Operation）和值（value），用面向?qū)ο笮问娇杀憩F(xiàn)為Item.Operation(Value)將測試邏輯按照關(guān)鍵字進(jìn)行分解，形成數(shù)據(jù)文件，測試工具解釋關(guān)鍵字運行

12第十三頁，共116頁。自動化測試適用范圍自動化測試的適用范圍包括兩點：1.減少操作的重復(fù)性：自動化測試工具的使用可以輔助人們完成一些重復(fù)性較高的操作，如完成N條不同內(nèi)容投保單的錄入，在這里自動化測試具有快速、準(zhǔn)確的輸入、節(jié)約時間的特點；2.回歸測試：在系統(tǒng)測試階段開發(fā)針對某一具體功能的自動化測試腳本（如一條記錄的新增操作），在回歸測試階段通過執(zhí)行該腳本來保證該功能沒有被新功能的增加、其它bug的修復(fù)而破壞。例如：1.每輪測試都需要執(zhí)行的基礎(chǔ)測試，如需要對保全功能做測試時，可通過自動化測試工具完成一個保單流程的錄入；2.數(shù)據(jù)驅(qū)動的用例，如需要輸入很多組數(shù)據(jù)，每組數(shù)據(jù)對應(yīng)不同的預(yù)期結(jié)果，如一條投保單的錄入在保存時需要做很多個校驗及檢查，可為每個需要檢查的邏輯判斷做一組數(shù)據(jù)，在保存時檢查校驗條件是否都正常工作；第十四頁，共116頁。自動化測試的成本考慮評估購買或開發(fā)測試工具?每年的維護(hù)費用或升級成本?學(xué)習(xí)工具和培訓(xùn)時間?測試自動化上特定的資源投入?與開發(fā)自動化測試工具所有相關(guān)的抽風(fēng)?維護(hù)腳本的成本?存儲腳本的硬件資源花費第十五頁，共116頁。自動化測試建設(shè)常見錯誤1、缺乏好的自動化測試計劃和設(shè)計過程2、錯誤的選擇了自動化測試工具3、錯誤的自動化框架設(shè)計4、在設(shè)計中缺乏好的設(shè)計管理5、缺乏自動化過程和工具培訓(xùn)第十六頁，共116頁。相關(guān)術(shù)語TestRequirement（測試需求）：是關(guān)于某具體測試目標(biāo)的聲明以及確認(rèn)測試是否通過所要達(dá)到的標(biāo)準(zhǔn)。TestPlan（測試計劃）：包括項目中的測試目標(biāo)和目的的信息。此外，測試計劃還明確了測試實現(xiàn)的策略和所需要的資源。TestStrategy（測試策略）：描述了測試獲得的通用目標(biāo)和方法。TestCase（測試用例）：是一套為特定目標(biāo)開發(fā)的測試輸入、執(zhí)行條件和預(yù)期結(jié)果，例如執(zhí)行一跳特殊程序路徑或者在特定要去下驗證一致性。TestData（測試數(shù)據(jù)）：在測試中所用到的實際數(shù)值或執(zhí)行測試所必須的數(shù)值。測試數(shù)據(jù)是測試條件（作為輸入或預(yù)存在的數(shù)據(jù)）的具體例化，用于驗證已成功實現(xiàn)的特定要求（通過將實際結(jié)構(gòu)與期望結(jié)果比較）。

TestInputs（測試輸入）：是工作過程的產(chǎn)物，用于標(biāo)志和定義發(fā)生在測試期間的動作。這些產(chǎn)物可能是從測試組之外的軟件開發(fā)過程中產(chǎn)生的，例如功能需求規(guī)格說明和設(shè)計規(guī)格說明。它們也可能是從前期測試階段產(chǎn)生的并被留給了后續(xù)的測試活動。第十七頁，共116頁。相關(guān)術(shù)語Testscrīpt（測試腳本）：這是計算機(jī)可讀懂的能令測試程序（或一部分測試程序）自動執(zhí)行的指令。測試腳本可以由人創(chuàng)建（復(fù)制）或者由自動測試工具產(chǎn)生，它使用編程語言限制，或者由記錄、生成和編程混合創(chuàng)建。TestResults（測試結(jié)果）：執(zhí)行測試所捕獲的數(shù)據(jù)，并被用于計算測試的不同關(guān)鍵測度。PerformanceTesting（性能測試）：通過這類測試的實現(xiàn)和執(zhí)行可以對索要測試的應(yīng)用程序與性能相關(guān)的特征作出描繪和評估。這些測試包括時間調(diào)度情況、執(zhí)行流暢、響應(yīng)時間以及操作可靠性和限制。Data－DrivenTesting（數(shù)據(jù)驅(qū)動測試）：這是一種測試腳本的功能及執(zhí)行由外部數(shù)據(jù)所引導(dǎo)的自動測試方法。這種方法將測試及控制數(shù)據(jù)與測試腳本本身分離開了。TestCondition（測試條件）：測試所涉及的各種環(huán)境因素。第十八頁，共116頁。目錄構(gòu)建自動化測試框架自動化測試流程自動化測試介紹自動化測試工具QTP第十九頁，共116頁。正確選擇適合的自動化測試通常適合自動化測試的用例有：產(chǎn)品型項目 產(chǎn)品型的項目，新版本是在舊版本的基礎(chǔ)上進(jìn)行改進(jìn)，功能變不大的項目，但項目的新老功能都必須重復(fù)的測試。回歸測試 回歸測試是自動化測試的強(qiáng)項，它能夠很好的驗證你是否引入了新的缺陷，老的缺陷是否修改過來了。在某種程度上可以把自動化測試工具叫做回歸測試工具。機(jī)械并頻繁的測試 每次需要輸入相同、大量的一些數(shù)據(jù)，并且在一個項目中運行的周期比較長。 有一些交互性比較強(qiáng)，需要人工干預(yù)的操作，就不要指望通過自動化測試來完成了。例如，用戶使用U-Key登錄。第二十頁，共116頁。自動化測試實施條件具有良好定義的測試策略和測試計劃（知道要測試什么、知道什么時候測試）能夠確保多個測試運行的構(gòu)建策略多平臺環(huán)境需要被測試擁有運行自動化測試的硬件擁有關(guān)注在自動化測試進(jìn)程上的資源第二十一頁，共116頁。自動化測試規(guī)劃設(shè)計框架資源計劃好投入的工具設(shè)備和人員等不同的測試框架實施方式不同與研發(fā)類似測試實施之前做一份切實可行的規(guī)劃是自動化能夠得以實施的基礎(chǔ)第二十二頁，共116頁。自動化測試實施規(guī)劃階段一：完成對結(jié)算和信貸主要業(yè)務(wù)的流程覆蓋階段二：完成對業(yè)務(wù)的校驗和約束階段三：應(yīng)用到更多的業(yè)務(wù)中去，規(guī)模擴(kuò)大開發(fā)自動化測試框架，降低對測試工具的依賴使用動作詞的自動化測試第一層次第二層次第三層次層次階段測試自動化程度第二十三頁，共116頁。自動化測試工作任務(wù)的優(yōu)先級自動化ROI度量測試范圍由風(fēng)險驅(qū)動測試 (例如：高風(fēng)險的項先被測試)自動化的優(yōu)先順序:對于能盡快（最少運行次數(shù)）達(dá)到投資回報平衡點高風(fēng)險的測試案例優(yōu)先低復(fù)雜度的測試案例優(yōu)先優(yōu)先級策略#需要自動測試執(zhí)行的次數(shù)復(fù)雜度風(fēng)險HighMediumLowHigh5.05.95.5Medium6.67.38.1Low5.07.38.11342#優(yōu)先級順序58697第二十四頁，共116頁。ROI分析第二十五頁，共116頁。基于風(fēng)險和復(fù)雜度評估達(dá)到測試目標(biāo)的最佳性價比測試自動化基本實踐方法風(fēng)險過程根據(jù)特定測試風(fēng)險等級來選擇合適的測試過程.通過以測試過程的最優(yōu)組合和資源、進(jìn)度、風(fēng)險的約束來多次運行自動化測試次數(shù)，來達(dá)到最小化工作量的目標(biāo)方法過程高風(fēng)險中風(fēng)險低風(fēng)險高復(fù)雜度中復(fù)雜度低復(fù)雜度第二十六頁，共116頁。自動化測試流程描述ID活動描述責(zé)任角色參與角色成果物

01自動化測試計劃

自動化測試計劃

02自動化測試準(zhǔn)備

生成自動化腳本

03自動化測試執(zhí)行

自動化測試報告在測試計劃設(shè)計階段，設(shè)計者應(yīng)盡可能考慮到系統(tǒng)的自身的業(yè)務(wù)和功能特點，將某些業(yè)務(wù)流和功能點確定為自動化測試；而在設(shè)計測試用例時必須對這部分的測試用例描述細(xì)化；自動化測試的操作過程大體分為5步：制定自動化測試計劃、編寫自動化測試用例、開發(fā)調(diào)試自動化測試腳本、執(zhí)行自動化測試、測試腳本的維護(hù)。關(guān)于自動化測試工具的具體使用方法請參考《自動化測試工具之QTP使用方法》。第二十七頁，共116頁。制訂自動化測試計劃

制定測試計劃的目的是確定和描述要實施的執(zhí)行的測試。這是通過生成包含測試需求和測試策略的測試計劃來完成的。可以制定一個單獨的測試計劃，用于描述所要實施和執(zhí)行的不同測試類型，也可以為每種測試類型制定一個測試計劃。換句話說制定自動化測試計劃是個分析、篩選的過程，即通過對被測系統(tǒng)業(yè)務(wù)流程的分析，整理出哪些模塊適合做自動化測試，哪些功能點的驗證可以進(jìn)行腳本的合并。第二十八頁，共116頁。測試自動化實現(xiàn)中的功能分解業(yè)務(wù)功能分解的原則和方法：清晰畫出業(yè)務(wù)流程圖根據(jù)業(yè)務(wù)流程分解業(yè)務(wù)功能，可以被復(fù)用的功能也要被分解出來。按照路徑覆蓋的思想，組織測試用例第二十九頁，共116頁。編寫自動化測試用例

根據(jù)手工測試用例編寫完善相應(yīng)的自動化測試用例，其中包括測試的版本、功能點描述、驅(qū)動數(shù)據(jù)、詳細(xì)操作流程、明確的預(yù)期結(jié)果。

測試用例粒度 測試用例的粒度決定了用例模型級的復(fù)雜度，也決定了每一個用例內(nèi)部的復(fù)雜度。應(yīng)該根據(jù)每個系統(tǒng)的具體情況來把握各個層次的復(fù)雜度，在盡可能保證整個用例模型的易理解性前提下決定用例的大小和數(shù)目。用例不能太大，這樣一旦出執(zhí)行測試用例出錯，不利于定位問題；但也不能太細(xì)化，太小則不方便執(zhí)行。測試用例與測試套件 一個大型的項目有許功能模塊，必然會產(chǎn)生大量的測試用例，怎樣才能有效的管理這些測試用例呢？這就需要創(chuàng)建測試套件，通過測試套件將測試某一個模塊或功能點的測試用例集合起來，方便運行與管理。例如，只驗證“用戶管理”模塊功能，則只需要執(zhí)行“用戶管理”模塊套件即可。第三十頁，共116頁。開發(fā)、調(diào)試自動化測試腳本

以業(yè)界常用的自動化測試工具為例，腳本的開發(fā)通常是通過錄制完成的（需要注意的是在錄制腳本之前設(shè)計好腳本，便于錄制過程的流暢，提高腳本的修改效率），即工具本身通過記錄用戶的操作過程及所輸入的數(shù)據(jù)生成一個由VB語言編寫的可執(zhí)行腳本，測試工程師對腳本進(jìn)行相應(yīng)的修改即可。修改增強(qiáng)腳本主要包括一下幾點：1.刪除錄制過程中多余和錯誤的代碼；2.對輸入輸出值進(jìn)行適當(dāng)?shù)膮?shù)化；3.對于不能通過錄制產(chǎn)生的代碼進(jìn)行手工編寫；4.錄制所產(chǎn)生的腳本是線性的，適當(dāng)加入條件、控制語句，實現(xiàn)更為復(fù)雜的流程；5.設(shè)置文本、圖片、及數(shù)據(jù)庫檢查點；6.適當(dāng)加入注釋、便于閱讀和維護(hù)；第三十一頁，共116頁。執(zhí)行自動化測試

執(zhí)行自動化測試是通過使用工具來替代手工操作的過程，腳本回放的過程中是模擬用戶的實際操作來執(zhí)行的，此時需要注意的是，測試環(huán)境要保持干凈。第三十二頁，共116頁。測試腳本的維護(hù)

隨著工作的不斷推進(jìn)、腳本量會逐漸增多，測試組需要對測試腳本進(jìn)行維護(hù)，將有效的測試腳本上傳至QC服務(wù)器服務(wù)器上，同其對應(yīng)的測試用例放在一起進(jìn)行維護(hù)。1.隨著被測程序的更新，不斷更新相應(yīng)的測試腳本；2.對一些變更較為頻繁的腳本，適當(dāng)采用版本管理工具保存腳本

、如SVN、VSS等以便可以隨時獲取歷史版本；3.腳本采用統(tǒng)一的命名規(guī)范（如健康險_契約錄入_……、健康險_保全_客戶資料變更等等）；第三十三頁，共116頁。自動化測試的評審根據(jù)自動化測試結(jié)果編寫《自動化測試報告》，組長組織自動化測試工作小組首先進(jìn)行內(nèi)部評審，內(nèi)部通過后再提交到測試組進(jìn)行自動化測試策略的外部評審，如果條件允許的情況下此時需要由項目組、自動化測試小組、質(zhì)量控制組共同參加評審過程。第三十四頁，共116頁。目錄自動化測試流程構(gòu)建自動化測試框架自動化測試介紹自動化測試QTP第三十五頁，共116頁。軟件測試框架介紹什么是框架framework?測試框架是一組自動化測試的規(guī)范、測試腳本的基礎(chǔ)代碼，以及測試思想的集合。整個或部分系統(tǒng)的可重用設(shè)計，表現(xiàn)為一組抽象構(gòu)件以及構(gòu)件實例間交互的方法；可被開發(fā)者定制的應(yīng)用框架。測試框架出現(xiàn)的最終目的是花少量的資源來完成盡可能多的測試任務(wù)，所以測試框架的建立以及框架的重用性方面是最值得測試人員深入探究的地方。減少冗余代碼、提高代碼生產(chǎn)率、提高代碼重用性和可維護(hù)性。提高開發(fā)速度，提升測試代碼的執(zhí)行效率；提高軟件代碼質(zhì)量，同時引入重構(gòu)概念，讓代碼更干凈和富有彈性；提升系統(tǒng)的可信賴度，作為回歸測試的一種實現(xiàn)方法支持修復(fù)后“再測試”，確保代碼的正確性。第三十六頁，共116頁。自動化回歸測試框架特點業(yè)務(wù)測試構(gòu)件執(zhí)行監(jiān)控測試數(shù)據(jù)管理異常恢復(fù)缺陷報告自動提交缺陷報告靈活的自動測試過程異常中止恢復(fù)機(jī)制實現(xiàn)業(yè)務(wù)測試構(gòu)件，快速完成業(yè)務(wù)流自動測試監(jiān)控測試運行狀態(tài)被測系統(tǒng)數(shù)據(jù)管理機(jī)制（數(shù)據(jù)與腳本分離與腳本分離，備份和恢復(fù)）第三十七頁，共116頁。38好的自動化測試框架的特點構(gòu)件化的腳本技術(shù)；可復(fù)用的腳本或公共函數(shù)的應(yīng)用，降低自動測試代碼總量；被測系統(tǒng)的界面或功能變化，不需要修改大量的自動測試代碼業(yè)務(wù)的測試流往往由業(yè)務(wù)人員來設(shè)計，根據(jù)業(yè)務(wù)需求的變化，不斷改變業(yè)務(wù)的測試流。如果自動回歸測試系統(tǒng)不能夠適應(yīng)業(yè)務(wù)流的變化，那么改動的工作量將是巨大的如果測試數(shù)據(jù)與自動測試腳本結(jié)合緊密，那么，一旦修改測試案例的數(shù)據(jù)，就必須由專業(yè)的自動測試技術(shù)人員修改自動測試腳本，而且?guī)砭薮蟮墓ぷ髁靠删S護(hù)性業(yè)務(wù)驅(qū)動測試數(shù)據(jù)管理絕大部分失敗案例，都是由于維護(hù)工作量太大，從而將辛苦建設(shè)起來的自動回歸測試系統(tǒng)拋棄第三十八頁，共116頁。基礎(chǔ)案例庫建設(shè)--平臺搭建第三十九頁，共116頁。自動化測試過程框架業(yè)務(wù)分析案例設(shè)計腳本生成實施執(zhí)行業(yè)務(wù)分析人員測試人員技術(shù)人員/測試人員測試人員業(yè)務(wù)流程分析確定測試點確定測試場景測試需求UI流分析數(shù)據(jù)準(zhǔn)備測試案例數(shù)據(jù)模型數(shù)據(jù)采集工具業(yè)務(wù)分析與評估方法編寫腳本裝配流程測試目標(biāo)及策略測試腳本執(zhí)行測試缺陷跟蹤測試報告共享對象庫共享腳本自動化框架測試工具測試管理工具1、從現(xiàn)有的移植案例中選一定范圍的測試需求，作為研發(fā)階段任務(wù)范圍；2、由自動化測試架構(gòu)師為主組織研發(fā)小組，小組組成員包括：測試設(shè)計人員、腳本開發(fā)人員、數(shù)據(jù)管理人員，其中，測試設(shè)計人員由手工功能測試組成員兼任；3、在確定的測試需求范圍內(nèi)建立起自動化測試的共享對象庫、共享腳本庫、測試數(shù)據(jù)模型、測試數(shù)據(jù)抽取SQL腳本庫1、培訓(xùn)各測試項目組成員；2、在實際測試過程中進(jìn)行自動化測試的實施，進(jìn)行效果的評估，并總結(jié)改進(jìn)方案；3、研發(fā)小組完善、擴(kuò)展自動化測試成果資產(chǎn)；研發(fā)階段實施與完善階段第四十頁，共116頁。測試需求定義場景定義場景的流程定義預(yù)期結(jié)果及檢查點定義測試數(shù)據(jù)的要求第四十一頁，共116頁。測試數(shù)據(jù)測試數(shù)據(jù)測試數(shù)據(jù)管理系統(tǒng)基礎(chǔ)數(shù)據(jù)新建業(yè)務(wù)數(shù)據(jù)抽取業(yè)務(wù)數(shù)據(jù)頁面控制數(shù)據(jù)業(yè)務(wù)數(shù)據(jù)模型保單保險人保全信息理賠信息投保信息Ui參數(shù)模型UiUi數(shù)據(jù)對象Ui數(shù)據(jù)規(guī)則UI編碼業(yè)務(wù)數(shù)據(jù)對象.數(shù)據(jù)要素缺省值是否參數(shù)化險種信息測試數(shù)據(jù)投保人數(shù)據(jù)特征：（正常保單失效保單……)保單號=“”保單狀態(tài)=“”第四十二頁，共116頁。自動化測試腳本的生成過程執(zhí)行測試腳本研發(fā)共享對象庫編寫腳本共享腳本庫測試案例（ui流程、測試數(shù)據(jù)）案例生成測試案例（ui流程、測試數(shù)據(jù)）流程裝配測試數(shù)據(jù)配置案例庫第四十三頁，共116頁。基于功能分解的自動化測試框架第四十四頁，共116頁。基于功能分解的自動化測試框架第四十五頁，共116頁。基于功能分解的自動化測試框架優(yōu)缺點優(yōu)點較為模塊化(modular)的設(shè)計，避免重復(fù)的腳本，減少建立或維護(hù)腳本的成本。在應(yīng)用軟件開發(fā)的同時，就可以同步進(jìn)行腳本建立的動作，而且當(dāng)應(yīng)用軟件功能變動時，只需要修改業(yè)務(wù)功能腳本。由于應(yīng)用軟件的功能已經(jīng)被分解成獨立的業(yè)務(wù)功能腳本，測試人員可以隨意組合業(yè)務(wù)功能腳本成為更復(fù)雜多樣的測試個案。測試輸入數(shù)據(jù)與驗證數(shù)據(jù)與腳本分開，儲存在另外的檔案，如純文字文件或Excel文件，測試人員可以更容易修改與維護(hù)。透過判斷Action回傳值是TRUE或FALSE，可以作錯誤處理，讓腳本更有彈性。缺點在編寫業(yè)務(wù)功能腳本時，需要「精通」測試工具腳本語言的工程師。個Action都會有自己的輸入輸出參數(shù)，需要用文檔統(tǒng)一維護(hù)，控制變更。測試人員除了要維護(hù)測試計劃之外，還要另外維護(hù)數(shù)據(jù)文件。對測試工具以及腳本語言來說，使用數(shù)據(jù)文件可能也要注意數(shù)據(jù)文件的格式。

第四十六頁，共116頁。自動化測試解決方案第四十七頁，共116頁。①②QTP和QC自動化測試框架技術(shù)實現(xiàn)

缺陷測試實驗室測試計劃/用例測試需求第四十八頁，共116頁。QC中測試需求的組織第四十九頁，共116頁。從測試需求到測試用例第五十頁，共116頁。自動化腳本組織主控輸入調(diào)度和控制測試數(shù)據(jù)腳本運行結(jié)果輸出任何一個自動化測試框架都要設(shè)計這三部分第五十一頁，共116頁。測試用例腳本公共類庫模塊特定類庫在模塊內(nèi)部將可以為該模塊共享使用的方法抽象出來，作為一個公共類。它可以是一個單的邏輯操作，也比較獨立。比如客戶端登錄操作、控制臺登錄操作、控制臺更新操作等。公共類庫包括所有模塊都可能用

戶的操作方法，其抽象了不同模

塊同性，比如操作excel表的方法

、讀寫測試報告、驅(qū)動引擎等測試用例腳在最上層，它根據(jù)測試點進(jìn)行設(shè)計，面向具體的應(yīng)用。它可直接調(diào)用公共類庫或模塊特定類庫的方法，即調(diào)單個邏輯操作。它是單個或多個邏輯操作的集合，即一個測試用戶腳本為了方便以后腳本的維護(hù)問題，必須對腳本進(jìn)行有效的分層，同時，提高了腳本的復(fù)用率。測試腳本開發(fā)腳本編寫規(guī)范：測試腳本的開發(fā)也要遵循編程的規(guī)則與標(biāo)準(zhǔn)，應(yīng)該統(tǒng)一規(guī)劃，所有開發(fā)腳本的人員按照統(tǒng)一的規(guī)定進(jìn)行編碼。除了編程本身規(guī)范，還考慮測試用例與庫函數(shù)名的命名。第五十二頁，共116頁。測試腳本組織和錄制編輯第五十三頁，共116頁。測試腳本組織和錄制編輯第五十四頁，共116頁。測試腳本執(zhí)行結(jié)果第五十五頁，共116頁。QC中執(zhí)行記錄和報告第五十六頁，共116頁。56BPT（業(yè)務(wù)組件測試）測試設(shè)計和代碼調(diào)試分開機(jī)制測試腳本管理測試結(jié)果管理團(tuán)隊協(xié)作QTP和QC業(yè)務(wù)組件自動化測試框架第五十七頁，共116頁。基礎(chǔ)案例庫建設(shè)—已完成業(yè)務(wù)腳本58HR01人員入職-薪資核算-過帳流程海油發(fā)展PM01集成測試_PM-MM-FICO_維護(hù)處理流程（自修）海油發(fā)展PM02集成測試_PM-MM-FICO_維護(hù)處理流程（外委）海油工程PM03集成測試_PM-MM-QM-FICO_維護(hù)處理流程

（自修-備件運行MRP，執(zhí)行質(zhì)檢）化學(xué)公司PM04集成測試_PM-MM-FICO_維護(hù)處理流程（包含WCM）海油發(fā)展PM05集成測試_PM-MM-FICO_維護(hù)處理流程（安全費用審核）油氣利用PM06集成測試_PM-MM-FICO_設(shè)備大修（子母訂單）油服SD01集成測試_SDMMFICO_新加坡公司三方貿(mào)易流程有限公司SD03集成測試_SDMMFICO_標(biāo)準(zhǔn)銷售業(yè)務(wù)流程有限公司SD04集成測試_SDMMFICO_跨公司銷售業(yè)務(wù)流程油氣利用SD05集成測試_SDMMFICO_標(biāo)準(zhǔn)第三方業(yè)務(wù)流程油氣利用SD06集成測試_SDMMFICO_按單采購銷售流程油氣利用SD07集成測試_SDMMFICO_退貨處理流程海油發(fā)展SD08集成測試_SDMMFICO_寄售結(jié)算流程化學(xué)公司SD09集成測試_SDMMFICO_天然氣照付不議流程有限公司SD10集成測試_SDMMFICO_已售未提業(yè)務(wù)處理流程海油發(fā)展SD11集成測試_SDFICO_服務(wù)銷售流程海油發(fā)展SD12集成測試_SDFICO_借貸項憑單處理流程化學(xué)公司SD13集成測試_SDMM_免費訂單業(yè)務(wù)處理流程海油發(fā)展跨模塊業(yè)務(wù)流程腳本（一）第五十八頁，共116頁。基礎(chǔ)案例庫建設(shè)—已完成業(yè)務(wù)腳本跨模塊業(yè)務(wù)流程腳本（二）PP01集成測試_PPMMQMFICOSD_面向庫存的生產(chǎn)、成本核算到產(chǎn)品銷售化學(xué)公司PP02集成測試_PPMMFICOSD_重復(fù)制造的生產(chǎn)、成本核算到產(chǎn)品銷售化學(xué)公司PP03集成測試_PPMMSDFICO_惠煉產(chǎn)品增值鏈海油發(fā)展PP04集成測試_PPMMQMFICOSD_油氣利用生產(chǎn)、成本核算到產(chǎn)品銷售油氣利用PP05集成測試_PPMMSDFICO_海油發(fā)展成品油生產(chǎn)銷售還有發(fā)展PS01集成測試_PSMMFICO_開發(fā)類項目有限公司PS02集成測試_PSMMFICO_有限公司作業(yè)公司開發(fā)類項有限公司PS03集成測試_PSMMFICO_直接生產(chǎn)操作費有限公司PS04集成測試_PSMMFICO_勘探類項目有限公司PS05集成測試_PSMMFICO_生產(chǎn)資本性支出類項目有限公司PS06集成測試_PSMMFICO_信息類項目有限公司PS07集成測試_PSMMFICO_科研費用項目油服PS08集成測試SD_PSMMFICO_常規(guī)作業(yè)類項目油服PS09集成測試_PSMMFICO_客戶類項目海油工程PS10集成測試_PSMMFICO_油氣利用新建項目油氣利用PS11集成測試_PSMMFICO_海油發(fā)展客戶類項目海油發(fā)展PS12集成測試_PSMMFICO_海油發(fā)展投資類項目海油發(fā)展第五十九頁，共116頁。基礎(chǔ)案例庫建設(shè)—已完成業(yè)務(wù)腳本模塊內(nèi)業(yè)務(wù)流程腳本HR02組織管理海洋工程HR03人事管理海總HR04時間管理海總HR05薪酬管理海總HR06招聘管理海總油服HR07培訓(xùn)管理海總,有限,油服、海油發(fā)展,氣電HR08績效考核管理海總,化學(xué),有限MM01集成測試_WM_FICO_物資盤點流程有限公司MM07有物料編碼的物資采購_發(fā)放有限公司MM11委外加工發(fā)料有限公司第六十頁，共116頁。測試平臺知識轉(zhuǎn)移為了在項目結(jié)束后，海總和實業(yè)方人員能夠承擔(dān)測試平臺的運維工作，項目組從以下幾個方面做好知識轉(zhuǎn)移工作，包括：培訓(xùn)工作。除了測試工具使用的普及型培訓(xùn)，還會針對具體的操作人員進(jìn)行高級培訓(xùn)，并進(jìn)行考核。專題討論。項目實施過程中遇到的各種技術(shù)難點，均會召開專題討論，各方人員均需要參加。知識積累。項目組在項目實施過程中，會總結(jié)一些典型的應(yīng)用場景和解決方案，并在項目組內(nèi)共享。工作模式。在項目實施期間，HP方顧問會采取1盯1的方式，幫助實業(yè)方人員盡快提高測試技術(shù)水平。目前實業(yè)人員已能承擔(dān)一部分工作，但他們很難在短短4個月內(nèi)達(dá)到HP顧問的水平，所以明年在項目結(jié)束后就由實業(yè)方人員承擔(dān)測試平臺的全部運維工作，存在著一定風(fēng)險。第六十一頁，共116頁。回歸測試方案介紹（一）回歸測試策略最終確認(rèn)為：選擇38個跨模塊集成流程，以及49個模塊內(nèi)重點流程（除去部分跨模塊集成流程已經(jīng)包含的）；策略覆蓋面廣，自動化集成度高，保證了各個模塊功能點得到充分的測試，從而確保系統(tǒng)穩(wěn)定運行；選取集成流程（包括跨模塊集成流程和模塊內(nèi)集成流程）作為自動化回歸測試對象，不單單因為集成流程包含了絕大部分常用的T-CODE、關(guān)鍵控制點，更重要的是集成流程貫穿了整個業(yè)務(wù)流程，可以從業(yè)務(wù)流、系統(tǒng)本身集成性來考量“變更”帶來的影響和潛在風(fēng)險；38個跨模塊集成流程包含了11家所屬單位的所有共性流程和個性流程，49個模塊內(nèi)集成流程的選取覆蓋了FICO、MM、SD、HR等模塊，流程的選取覆蓋了11家所屬單位的業(yè)務(wù)，為回歸測試/巡檢測試提供了強(qiáng)有力的數(shù)據(jù)支持。第六十二頁，共116頁。回歸測試方案介紹（二）工作量而言，對于所選的方案進(jìn)行評估，大概需要20個人月，在有限的時間和人員配置里，選取了常用、關(guān)鍵控制點、及主要業(yè)務(wù)覆蓋的T-CODE，從而達(dá)到了“二八效應(yīng)”；該方案數(shù)據(jù)的選取也有自己的局限性，方案重點測試集成流程的功能，共性流程選取單個公司代碼，難以充分測試公司間字段差異化等；單元測試流程只選取了重點流程，沒有全部選取，可能會導(dǎo)致測試不充分；SAP系統(tǒng)的回歸測試和巡檢測試是一項長期的任務(wù)，該選取策略只是我們現(xiàn)階段性的實現(xiàn)方式和成果。在未來的工作中，還可以根據(jù)具體情況進(jìn)行完善。第六十三頁，共116頁。權(quán)限測試方案介紹（一）權(quán)限測試需求：自動化權(quán)限測試替代手工權(quán)限測試，充分保證權(quán)限測試的質(zhì)量；規(guī)避集團(tuán)管控、跨所屬單位、所屬單位內(nèi)部權(quán)限過大的風(fēng)險；權(quán)限測試背景：中海油共計11家所屬單位；本地角色3萬多，最終用戶5千左右；第六十四頁，共116頁。權(quán)限測試方案介紹（二）分步實施：首先實現(xiàn)集團(tuán)管控、跨所屬單位自動化權(quán)限測試需求，規(guī)避集團(tuán)管控、跨所屬單位權(quán)限過大的風(fēng)險；后續(xù)再實現(xiàn)所屬單位內(nèi)部的自動化權(quán)限測試；測試方法：首先選取集團(tuán)管控、跨所屬單位相關(guān)的T-CODE；然后找出此部分T-CODE涉及的本地角色，每種本地角色組合選取對應(yīng)的一個用戶，進(jìn)行此部分T-code的所有權(quán)限控制點的反向測試；并返回結(jié)果日志。優(yōu)點：操作可行性較大，有效的分解了工作量壓力；能夠檢測出集團(tuán)管控、跨所屬單位權(quán)限過大的風(fēng)險；缺點：需要逐步實現(xiàn)；實施過程中，還沒有編制自動化測試腳本的需要人工測試；第六十五頁，共116頁。權(quán)限測試方案介紹（三）工作量評估：在選定的范圍內(nèi)，針對每種不同的本地角色組合建立一個自動化測試的腳本。運行腳本時，系統(tǒng)自動運行組合下所有T-code權(quán)限檢查點反向測試，并返回結(jié)果日志。以集團(tuán)管控、跨所屬單位共計3600個T-CODE為例，在主數(shù)據(jù)準(zhǔn)備齊全的前提下：平均每人每天2個T-CODE的開發(fā)量（默認(rèn)每個T-CODE含有3個權(quán)限檢查點）（注意：T-CODE含有的權(quán)限檢查點以實際數(shù)據(jù)為準(zhǔn)）；每人每天串聯(lián)16個T-CODE的工作量。那么開發(fā)T-CODE的工作量等于（3600/2）1800人天，串聯(lián)用戶T-CODE的工作量等于（3600/16）225天。共計需要（1800+225）2025人天。第六十六頁，共116頁。基礎(chǔ)案例庫建設(shè)—驗收情況介紹項目組組織業(yè)務(wù)專家組成員對已完成的所有集成業(yè)務(wù)流程腳本進(jìn)行了驗收；所有業(yè)務(wù)流程腳本均在專家組成員的監(jiān)督下成功執(zhí)行，并將每一步操作進(jìn)行截圖，記錄在腳本執(zhí)行報告中；專家組成員對于測試腳本涉及的業(yè)務(wù)流程，提出了一些增加檢查點和由于手工測試腳本錯誤，導(dǎo)致腳本與實際業(yè)務(wù)不符的問題，項目組均在當(dāng)場進(jìn)行了腳本修改，解決了相關(guān)問題；項目組對所有執(zhí)行記錄進(jìn)行集中存檔備案；第六十七頁，共116頁。QTP簡介自動化測試的好處快速Q(mào)uickTest執(zhí)行測試比人工測試速度快多了。可靠QuickTest每一次的測試都可以正確的執(zhí)行相同的動作，可以避免人工測試的錯誤。可重復(fù)QuickTest可以重復(fù)執(zhí)行相同的測試。可程序化QuickTest可以以程序的方式，撰寫復(fù)雜的測試腳本，以帶出隱藏在應(yīng)用程序中的信息。廣泛性QuickTest可以建立廣泛的測試腳本，涵蓋應(yīng)用程序的所有功能。可再使用QuickTest可以重復(fù)使用測試腳本，即使應(yīng)用程序的使用接口已經(jīng)改變。如果你執(zhí)行過人工測試，你一定了解人工測試的缺點，人工測試非常浪費時間而且需要投入大量的人力。使用人工測試的結(jié)果，往往是在應(yīng)用程序交付前，無法對應(yīng)用程序的所有功能都作完整的測試。使用QuickTest可以加速整個測試的過程，并且建置完新版本的應(yīng)用程序或網(wǎng)站后，可以重復(fù)使用測試腳本進(jìn)行測試。以QuickTest執(zhí)行測試，就與人工測試一樣。QuickTest會仿真鼠標(biāo)的動作與鍵盤的輸入，不過QuickTest比人工測試快了很多。第六十八頁，共116頁。目錄自動化測試流程自動化測試工具QTP自動化測試介紹構(gòu)建自動化測試框架第六十九頁，共116頁。QTP簡介Keyword-DrivenTesting把自動化測試融入到日常工作流程中對象庫

執(zhí)行和報告

檢查點編輯腳本并參數(shù)化

Item.Operation(Value)

MethodandProsperity—封裝屬性和自身屬性Parameterize（參數(shù)文件更新）CheckPoint（7種檢查點）

RunReportObjectRepository第七十頁，共116頁。QTP工作界面標(biāo)題欄、菜單欄文件工具欄、測試工具欄、調(diào)試工具欄測試窗格：腳本視圖/關(guān)鍵字視圖數(shù)據(jù)表ActiveScreen視窗狀態(tài)欄第七十一頁，共116頁。QTP菜單欄QTP的菜單功能，包括“文件”、“編輯”、“視圖”等等菜單。第七十二頁，共116頁。QTP工具欄文件工具欄－－管理測試或組件的按鈕測試工具欄－－在創(chuàng)建和維護(hù)測試或組件時用到的命令按鈕調(diào)試工具欄－－調(diào)試測試或組件步驟時用到的命令按鈕第七十三頁，共116頁。QTP測試窗格關(guān)鍵字視圖專家視圖第七十四頁，共116頁。QTP參數(shù)表存儲QTP運行時用到的數(shù)據(jù)Global、LocalSheet數(shù)據(jù)可通過手工方式導(dǎo)入、導(dǎo)出第七十五頁，共116頁。ActiveScreen錄制會話過程中執(zhí)行某個特定步驟時，捕獲到的應(yīng)用程序的屏幕快照通過ActiveScreen操作，參數(shù)化、檢查點等第七十六頁，共116頁。安裝QTP安裝QTP臨時License：888更新License安裝示例腳本插件安裝腳本調(diào)試插件第七十七頁，共116頁。QTP工作原理腳本錄制，捕捉對象以及在對象上的操作腳本回放，在可識別的對象上還原操作第七十八頁，共116頁。完整的錄制回放流程準(zhǔn)備錄制進(jìn)行錄制編輯測試腳本調(diào)試腳本在回歸測試中運行測試分析接過，報告問題第七十九頁，共116頁。QTP腳本參數(shù)化把自動測試腳本運行所用到的數(shù)據(jù)以參數(shù)取代，腳本運行時從參數(shù)表取數(shù)據(jù)將數(shù)據(jù)與腳本分離，便于維護(hù)，便于更新數(shù)據(jù)以適應(yīng)新的測試QTP腳本中的參數(shù)化環(huán)境變量參數(shù)化，測試、操作參數(shù)的值，應(yīng)用程序隨機(jī)值。第八十頁，共116頁。參數(shù)化界面第八十一頁，共116頁。輸入數(shù)據(jù)的參數(shù)化輸入數(shù)據(jù)可以直接輸入輸入數(shù)據(jù)可以從參數(shù)表取值輸入數(shù)據(jù)可以設(shè)置為參數(shù)并為該參數(shù)設(shè)置默認(rèn)值，在腳本運行時可以修改，如取參數(shù)表中的值、取被測系統(tǒng)實時生成的某個相關(guān)值。第八十二頁，共116頁。直接輸入數(shù)據(jù)：如在登陸窗口輸入用戶名“ggg”，自動生成語句：Window("ProgramManager").Dialog("Login").WinEdit("AgentName:").Set"ggg"前面部分用來確認(rèn)操作的對象，Set是在對象上所做的操作，ggg為輸入值。輸入數(shù)據(jù)的參數(shù)化第八十三頁，共116頁。輸入數(shù)據(jù)從參數(shù)表取值，從當(dāng)前表、全局表（GlobalSheet）或指定表取值。前置條件：所被指定的表存在參數(shù)列且有參數(shù)數(shù)據(jù)。使用datatable.value方法，示例語句如下：Window("ProgramManager").Dialog("Login").WinEdit("AgentName:").Setdatatable.Value("username",dtglobalsheet)Window("ProgramManager").Dialog("Login").WinEdit("AgentName:").Setdatatable.Value("username",dtlocalsheet)輸入數(shù)據(jù)的參數(shù)化第八十四頁，共116頁。輸入數(shù)據(jù)已經(jīng)定義為參數(shù)并設(shè)置默認(rèn)值；為當(dāng)前Action設(shè)置參數(shù)，在可復(fù)用腳本中常用到。在腳本中示例語句如下：Window("ProgramManager").Dialog("Login").WinEdit("AgentName:").Setparameter("username")輸入數(shù)據(jù)的參數(shù)化第八十五頁，共116頁。輸出值的參數(shù)化被測系統(tǒng)生成的實時值，可用作后續(xù)操作的某些輸入值。輸出值被輸出到參數(shù)表或者輸出參數(shù)；在目標(biāo)對象，點擊右鍵選擇“InsertOutputvalue”功能；第八十六頁，共116頁。示例如下：輸出值的參數(shù)化第八十七頁，共116頁。輸出值被參數(shù)化后，后續(xù)操作可以直接使用被輸出值。從數(shù)據(jù)表取得輸出值，方法參考輸入數(shù)據(jù)從參數(shù)表取值。輸出值的參數(shù)化第八十八頁，共116頁。QTP腳本檢查點檢查點檢查頁面、對象或者文本字符串中的特定值或特征，是將指定屬性的當(dāng)前值與該屬性的期望值進(jìn)行比較的驗證點。通過它可以標(biāo)識網(wǎng)站或者應(yīng)用程序是否正常運行。關(guān)鍵步驟、關(guān)鍵操作的檢查，如：與服務(wù)器交互后，客戶端的信息檢查。標(biāo)準(zhǔn)檢查點、對象檢查點、文本檢查點、數(shù)據(jù)庫檢查點等第八十九頁，共116頁。添加檢查點界面第九十頁，共116頁。插入檢查點－－標(biāo)準(zhǔn)檢查點ActiveScreen視窗，在目標(biāo)對象上點擊鼠標(biāo)右鍵選擇“InsertStandardCheckpoint”第九十一頁，共116頁。設(shè)置標(biāo)準(zhǔn)檢查點檢查點可以檢查目標(biāo)對象的多個屬性，如同時檢查enabled、text、height等。設(shè)置屬性的值為固定值或者從數(shù)據(jù)表取值（可參考對象屬性設(shè)置）。設(shè)置檢查點的超時時限。設(shè)置檢查點檢查的時機(jī)。第九十二頁，共116頁。插入檢查點－文本檢查點第九十三頁，共116頁。插入檢查點－文本檢查點第九十四頁，共116頁。添加事務(wù)第九十五頁，共116頁。腳本的分割功能：Step－>SplitAction生成并列腳本還是第二個腳本被第一個腳本調(diào)用。第九十六頁，共116頁。QTP腳本對象應(yīng)用界面上的按鈕、編輯框、標(biāo)簽、選框等控件被QTP當(dāng)作對象，在錄制自動測試腳本時這些能夠被識別的對象信息被存儲到QTP對象庫回放時會將對象庫中的對象信息與實際操作應(yīng)用界面上的控件對比QTP常用對象方法：Click、Dblclick、Exist、type、set、GetRoProperty、GetVisibleText等。第九十七頁，共116頁。對象庫查看、編輯和管理第九十八頁，共116頁。QTP對象庫結(jié)構(gòu)錄制腳本時，QTP可識別的對象存儲在對象庫中。第九十九頁，共116頁。QTP對象屬性設(shè)置對象的名稱、類型、屬性添加、刪除顯示的屬性將影響對象的識別配置屬性值：固定值、參數(shù)表取值第一百頁，共116頁。QTP定位對象庫中的對象在對象列表選擇目標(biāo)對象，激活當(dāng)前被選中對象所屬窗體，點擊第一百零一頁，共116頁。識別某個對象的詳細(xì)屬性通過功能可以識別某個對象的詳細(xì)屬性以及該對象支持的方法。第一百零二頁，共116頁。Web對象的識別靜態(tài)Web對象的識別序號Web對象推薦識別屬性方法1

BrowsercreationTime

2

Pageindex

3

Framename

4WebTablename

5WebEditnameSet6WebButtontextClick7WebListnameSelect8LinktextClick9Imagename

10WebCheckBoxname

11WebRadioGroupname

12WebElementinnertext/htmltag

13Dialogtext

14WinButtontext

第一百零三頁，共116頁。靜態(tài)Web對象的識別QuickTest可以使用三種類型的順序標(biāo)識符來標(biāo)識對象：

索引（index）：指示該對象在應(yīng)用程序代碼中相對于其他描述都相同的其他對象的顯示順序。

QTP在錄制和執(zhí)行中，為測試對象屬性分配一個值，以便唯一標(biāo)識該對象。該值基于對象在源代碼中的顯示順序。第一個出現(xiàn)的是0。注意，index屬性值是特定于對象的。因此，如果使用Index:=3描述WebEdit測試對象，QuickTest將在頁中搜索第四個WebEdit對象。位置（location）：指示該對象在父窗口、框架或?qū)υ捒蛑邢鄬τ谄渌枋龆枷嗤钠渌麑ο蟮娘@示順序。

QuickTest可以為對象的location測試對象屬性分配一個值，以便唯一標(biāo)識該對象。該值基于對象在窗口、框架或?qū)υ捒蛑邢鄬τ诰哂邢嗤瑢傩缘钠渌麑ο蟮娘@示順序。第一個出現(xiàn)的對象是0。各列值的分配從上到下、從左到右。creationTime

（僅限于瀏覽器對象）：指示該瀏覽器打開的順序，相對于其他描述都相同的其他打開的瀏覽器。 如果QuickTest不能僅基于測試對象描述唯一標(biāo)識瀏覽器對象，它將為“CreationTime”測試對象屬性分配一個值。該值指示該瀏覽器打開的順序，相對于其他描述都相同的其他打開的瀏覽器。在運行會話期間，如果QuickTest不能只是基于其測試對象描述來標(biāo)識某個瀏覽器對象，那么，它將檢查瀏覽器的打開順序，然后使用“CreationTime”屬性標(biāo)識正確的對象。第一百零四頁，共116頁。舉例Browser(“creationTime:=0”).Page(“index:=0”).WebEdit(“name:=amount”).Set“1000”

在第一個被創(chuàng)建的IE窗口，查找name屬性為am