性能測試進階指南:Loadrunner實戰(zhàn)91-第4章 負載生成及監(jiān)控_第1頁
性能測試進階指南:Loadrunner實戰(zhàn)91-第4章 負載生成及監(jiān)控_第2頁
性能測試進階指南:Loadrunner實戰(zhàn)91-第4章 負載生成及監(jiān)控_第3頁
性能測試進階指南:Loadrunner實戰(zhàn)91-第4章 負載生成及監(jiān)控_第4頁
性能測試進階指南:Loadrunner實戰(zhàn)91-第4章 負載生成及監(jiān)控_第5頁
已閱讀5頁,還剩42頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、.:.; TOC o 1-3 h z u HYPERLINK l _Toc298006555 第4章 負載生成及監(jiān)控Controller PAGEREF _Toc298006555 h 2 HYPERLINK l _Toc298006556 4.1 設(shè)計場景 PAGEREF _Toc298006556 h 2 HYPERLINK l _Toc298006557 4.1.1 新建場景 PAGEREF _Toc298006557 h 2 HYPERLINK l _Toc298006558 4.1.2 負載生成器管理 PAGEREF _Toc298006558 h 17 HYPERLINK l _T

2、oc298006559 4.1.3 用戶管理 PAGEREF _Toc298006559 h 20 HYPERLINK l _Toc298006560 4.1.4 運轉(zhuǎn)設(shè)置 PAGEREF _Toc298006560 h 20 HYPERLINK l _Toc298006561 4.1.5 IP虛擬 PAGEREF _Toc298006561 h 22 HYPERLINK l _Toc298006562 4.1.6 場景運轉(zhuǎn)原理 PAGEREF _Toc298006562 h 25 HYPERLINK l _Toc298006563 4.1.7 Service Level Agreement(

3、效力質(zhì)量保證) PAGEREF _Toc298006563 h 27 HYPERLINK l _Toc298006564 4.2 系統(tǒng)監(jiān)控 PAGEREF _Toc298006564 h 31 HYPERLINK l _Toc298006565 4.2.1 Scenario Groups(場景用戶形狀) PAGEREF _Toc298006565 h 31 HYPERLINK l _Toc298006566 4.2.2 Scenario Status(場景運轉(zhuǎn)形狀) PAGEREF _Toc298006566 h 32 HYPERLINK l _Toc298006567 4.2.3 計數(shù)器原理

4、 PAGEREF _Toc298006567 h 33 HYPERLINK l _Toc298006568 4.2.4 計數(shù)器管理 PAGEREF _Toc298006568 h 35 HYPERLINK l _Toc298006569 4.2.5 SiteScope PAGEREF _Toc298006569 h 42 HYPERLINK l _Toc298006570 4.3 場景運轉(zhuǎn) PAGEREF _Toc298006570 h 44 HYPERLINK l _Toc298006571 4.4 QTP腳本在場景中的運轉(zhuǎn) PAGEREF _Toc298006571 h 45 HYPERL

5、INK l _Toc298006572 4.5 場景數(shù)據(jù) PAGEREF _Toc298006572 h 46 HYPERLINK l _Toc298006573 小結(jié) PAGEREF _Toc298006573 h 47第4章 負載生成及監(jiān)控Controller當(dāng)虛擬用戶腳本開發(fā)完成后,運用Controller將這個執(zhí)行腳本的用戶從單人轉(zhuǎn)化為眾人,從而模擬大量用戶操作,進而構(gòu)成負載。我們需求對這個負載模擬的方式和特征進展配置,從而構(gòu)成場景。場景(Scenario)是一種用來模擬大量用戶操作的技術(shù)手段,經(jīng)過配置和執(zhí)行場景向效力器產(chǎn)生負載,驗證系統(tǒng)各項性能目的能否到達用戶要求,而Controll

6、er可以協(xié)助 我們對場景的設(shè)計、執(zhí)行及監(jiān)控進展管理。運用Controller管理場景主要分為場景設(shè)計和場景監(jiān)控兩部分,最后經(jīng)過運轉(zhuǎn)場景完成性能測試的執(zhí)行。場景執(zhí)行的流程如圖4.1所示。圖4.1場景執(zhí)行流程4.1 設(shè)計場景經(jīng)過對場景的設(shè)計從而構(gòu)成和用戶需求一樣的真實負載。4.1.1 新建場景場景分為目的場景和手工場景,創(chuàng)建場景有兩種方式。圖4.5目的場景設(shè)置窗口單擊Edit Scenario Goal按鈕翻開目的場景編輯對話框,如圖4.6所示。圖4.6設(shè)置目的場景中的目的在目的場景中最重要的就是目的類型,目的場景提供了五種目的,如圖4.7所示,每種目的都有本人獨立的設(shè)置。圖4.7目的場景中提供的

7、目的類型Virtual Users該參數(shù)表示虛擬用戶數(shù),被測系統(tǒng)所需求支持的用戶數(shù)。這里只需求填寫系統(tǒng)可以到達的用戶數(shù)目即可。例如:需求規(guī)定該系統(tǒng)可以支持100個用戶在線發(fā)帖。錄制用戶登錄發(fā)帖后,在目的場景中將Goal Type(目的類型)選擇為Virtual Users,設(shè)置Reach goal of為100個用戶即可,如圖4.8所示。圖4.8設(shè)置目的為100個在線用戶Hits per Second該參數(shù)表示每秒點擊數(shù),是指在一秒鐘能做到的點擊懇求數(shù)目,即客戶端產(chǎn)生的每秒懇求數(shù)(正常情況下每秒點擊數(shù)等同于效力器懇求呼應(yīng)數(shù))。除了要設(shè)置點擊的目的,還需求設(shè)置在線用戶的上下限,場景運轉(zhuǎn)時會自動調(diào)

8、整用戶數(shù),來測試在一定的用戶范圍內(nèi)系統(tǒng)能否都能到達定義的目的。例如:需求規(guī)定系統(tǒng)可以支持50150個在線用戶進展閱讀操作,客戶端發(fā)出的懇求才干為100次s(也就是正常情況下系統(tǒng)可以提供每秒鐘前往100次HTTP頭為200 OK的效力器應(yīng)對)。錄制用戶閱讀操作后,在目的場景中將Goal Type(目的類型)設(shè)置為Hits per Second,設(shè)置Reach goal of為100次點擊,再設(shè)置用戶數(shù)最小為50最大為150即可,如圖4.9所示。圖4.9設(shè)置每秒點擊數(shù)目的Transactions per Second該參數(shù)表示每秒事務(wù)數(shù),一個事務(wù)代表完成一個操作,每秒事務(wù)數(shù)反映了系統(tǒng)的處置才干。當(dāng)

9、腳本中含有事務(wù)函數(shù)時才可以運用,這里需求指定事務(wù)稱號、TPS目的以及需求完成該目的的用戶數(shù)。例如:需求規(guī)定系統(tǒng)可以在50150個用戶下,可以每秒處置100個用戶的登錄操作。在錄制用戶登錄操作后,為登錄行為添加事務(wù),事務(wù)稱號為login,設(shè)置目的場景的Goal Type(目的類型)為Transactions per Second,選擇事務(wù)稱號為login,設(shè)置Reach goal of為100,再設(shè)置用戶數(shù)最小為50最大為150即可,如圖4.10所示。圖4.10設(shè)置每秒事務(wù)數(shù)目的 Transactions Response Time該參數(shù)表示事務(wù)的呼應(yīng)時間,反映了系統(tǒng)的處置速度以及做一個操作所需

10、求破費的時間。和Transactions per Second類似,當(dāng)腳本中含有事務(wù)函數(shù)時,可以設(shè)定事務(wù)呼應(yīng)時問的目的。例如:需求規(guī)定系統(tǒng)可以支持50150個在線用戶,登錄操作的呼應(yīng)時間在1秒以內(nèi)。在腳本中包含登錄操作的事務(wù),設(shè)置目的場景的Goal Type(目的類型)為Transactions Response Time,選擇事務(wù)稱號為login,設(shè)置Reach goal of為1秒,再設(shè)置用戶數(shù)最小為50最大為150即可,如圖4.11所示。圖4.11設(shè)置事務(wù)呼應(yīng)時間目的Pages per Minute該參數(shù)表示每分鐘頁面的刷新次數(shù),反映了系統(tǒng)在每分鐘下所能提供的Page(頁面)處置才干。頁

11、面的生成才干反映了一個系統(tǒng)的整體處置才干,一個頁面懇求包含了多個點擊懇求。例如:需求規(guī)定系統(tǒng)在50150個用戶在線的情況下,可以每秒處置33個頁面懇求。設(shè)置目的場景的Goal Type(目的類型)為Pages per Minute,設(shè)置Reach goal of為2000頁面每分鐘,再設(shè)置用戶數(shù)最小為50最大為150即可,如圖4.12所示。圖4.12設(shè)置每分鐘頁面處置量目的當(dāng)設(shè)置完成性能的目的后,還需求設(shè)置一下場景運轉(zhuǎn)時的方式。這里分為兩大部分。Scenario Settings(場景設(shè)置)提供對目的場景運轉(zhuǎn)的一些根底設(shè)置,如圖4.13所示。圖4.13目的場景的場景設(shè)置Run Time是指當(dāng)目

12、的到達后,需求繼續(xù)運轉(zhuǎn)多少時間來測試系統(tǒng)的穩(wěn)定性,默許情況為30分鐘。目的場景是定性型場景,目的到達并不代表系統(tǒng)就滿足了用戶需求,還需求進展一段時間的穩(wěn)定性測試,確保該目的可以在一段時間內(nèi)到達。而假設(shè)目的無法到達,又該如何處置呢?Stop scenario and save results:假設(shè)無法到達目的,那么整個場景停頓運轉(zhuǎn)。Continue scenario without reaching:無法到達目的場景但仍繼續(xù)運轉(zhuǎn)。當(dāng)勾選了Receive notification復(fù)選框時,一旦出現(xiàn)目的無法到達的情況,Controller會彈出信息框,提示信息The target you defin

13、ed cannot be reached。(2) Load Behavior(負載生成)提供了對目的場景負載生成方式Ramp Up的設(shè)置,如圖4.14所示。此處可以運用自動管理,也可以手工設(shè)置一個需求到達目的的時間。圖4.14目的場景的負載規(guī)那么設(shè)置當(dāng)設(shè)置完成后,就可以啟動目的場景,Controller會自動調(diào)整用戶個數(shù)構(gòu)成負載,確認在這種負載情況下,定義的目的都可以到達。目的場景的目的就是經(jīng)過設(shè)置目的來驗證系統(tǒng)能否到達目的,在工程最后需求確認質(zhì)量時可以運用目的場景來完成最終的測試報告,而當(dāng)需求定位瓶頸的時候我們還是引薦運用手工場景。在最終的驗收測試中經(jīng)常需求多個功能同時滿足某一性能目的。例如

14、:某系統(tǒng)的需求規(guī)定50150個用戶同時在線時(其中用戶類型和所占比例為:登錄論壇用戶20,閱讀論壇用戶40,論壇發(fā)帖用戶40),每個用戶翻開一篇帖子的呼應(yīng)時問在2秒以內(nèi)。那么我們就需求在目的場景中添加這三種用戶行為的腳本,經(jīng)過Scenario Script中的“of Target設(shè)置每個腳本用戶所占的比例,設(shè)置場景目的類型為事務(wù)呼應(yīng)時間,閱讀操作的呼應(yīng)時間為2秒即可。手工場景(Manual Scenario)手工場景就是自行設(shè)置虛擬用戶的變化,經(jīng)過設(shè)計用戶的添加和減少過程,來模擬真實的用戶懇求模型,完成負載的生成。手工場景是定量型性能測試,我們經(jīng)過掌握在負載的添加過程中系統(tǒng)各個組件的變化情況,

15、從而定位性能瓶頸并了解系統(tǒng)處置才干,普通在負載測試和壓力測試中運用。例如需求了解一個運發(fā)動可以舉起多重的杠鈴,那么可以先給出一個足夠輕的杠鈴(10公斤),然后讓他舉一下,假設(shè)可以舉起來,那么再添加5公斤,重新試舉,如此往復(fù)直到無法舉起為止。經(jīng)過這個過程可以了解該運發(fā)動的最大舉重分量。每次添加的舉重分量越小,最后得出的最大分量越準確。好比高考前層層模擬考,目的就是讓學(xué)生了解本人的學(xué)習(xí)情況和考試成果,為填報志愿提供參考。手工場景主要是在設(shè)計用戶變化,經(jīng)過手工場景可以協(xié)助 我們分析系統(tǒng)的性能瓶頸。手工場景的中心就是設(shè)置用戶負載方式,經(jīng)過Scenario Schedule的Schedule by和Ru

16、n Mode選項可以對虛擬用戶的負載方式進展設(shè)置,如圖4.15所示。圖4.15手工場景中的ScenarioSchedule我們設(shè)置場景最大在線用戶為10人,每隔15秒鐘添加2個負載用戶,1分鐘后到達最大在線用戶數(shù),繼續(xù)5分鐘后,用戶每30秒終了5個負載用戶,整個場景共耗時6分30秒。經(jīng)過設(shè)置Global Schedule來設(shè)計用戶的添加和減少過程,詳細的用戶負載情況會在右側(cè)的Interactive Schedule Graph中顯示出來,如圖4.16所示。圖4.16 Interactive Schedule Graph場景負載圖手工場景在Schedule by中分為Scenario方式和Gro

17、up方式。Scenario方式Scenario方式是指一切腳本都運用一樣的場景模型來運轉(zhuǎn),只需求分配每個腳本所運用的用戶個數(shù)即可。Scenario方式下的Run Mode有兩大類:Real-life schedule和Classic schedule。在LoadRunner 9以前的手工場景設(shè)計中,只需一種情況可以設(shè)定,就是一個用戶腳本的運轉(zhuǎn)場景分為用戶上升、用戶繼續(xù)、用戶下降三個過程,只需系統(tǒng)滿足了峰值數(shù)據(jù)后,即可證明系統(tǒng)可以滿足性能需求,但這并不是真實的負載情況。從LoadRunner 9開場提供了Real-life schedule,也就是說可以建立一個完全真實的場景,不用像以前那樣只能

18、模擬一個山峰,從而實現(xiàn)壓力測試和真實情況下的負載測試。Real-life schedule(真實場景方式)和以前不同的是這里可以經(jīng)過Add Action來添加多個用戶變化的過程,包括多次負載添加Start Vusers、繼續(xù)時間Duration或遞減Stop Vusers,如圖4.17所示。圖4.17 Real.1ife下的GlobalSchedule場景添加負載戰(zhàn)略我們先來學(xué)習(xí)設(shè)置用戶的初始化方式。雙擊Initialize Action,彈出Edit Action窗口,如圖4.18所示。圖4。18虛擬用戶初始化戰(zhàn)略系統(tǒng)提供了3種初始化用戶的方式,普通運用默許選項即在每個虛擬用戶開場運轉(zhuǎn)前進展

19、初始化。然后學(xué)習(xí)設(shè)置負載添加Start Vusers。雙擊Start Vusers可以翻開負載用戶添加的戰(zhàn)略設(shè)置窗口,如圖4.19所示。圖4.19修正StartVusers用戶增長負載趨勢在這里可以設(shè)置產(chǎn)生負載的用戶數(shù),在默許情況下普通運用每隔一段時問添加一定的用戶負載方式,但也可以設(shè)置為立刻一次性加載用戶。建議設(shè)置為周期性負載增長方式,這樣可以更加有效地獲得系統(tǒng)在各個負載下的性能目的(防止一次負載太大,系統(tǒng)無法接受),除非需求做某些特殊情況的模擬。接著設(shè)置負載繼續(xù)時間Duration。雙擊Duration翻開設(shè)置窗口。在這里可以設(shè)置繼續(xù)時間長度,經(jīng)過一定時間的負載可以測試系統(tǒng)在該負載情況下的

20、穩(wěn)定性,如圖4.20所示。圖4.20修正用戶負載繼續(xù)時間最后設(shè)置負載釋放的過程Stop Vusers。雙擊Stop Vusers翻開設(shè)置窗口,這里提供了兩種釋放負載的戰(zhàn)略,如圖4.21所示。普通來說可以設(shè)置用戶直接停頓,也可以經(jīng)過設(shè)置負載逐漸下降,分析系統(tǒng)回收資源的才干。圖4.21修正Stop Vusers用戶負載遞減戰(zhàn)略經(jīng)過反復(fù)添加Start Vusers/Duration/Stop Vusers可以生成一個波浪型的場景,正是由于這是一種完全自在的場景設(shè)計方式,所以才被稱為Real-life,即完全真實地模擬用戶負載的過程,經(jīng)過這個過程的模擬抑制了以前場景想要模擬負載反復(fù)起伏的困難。例如:需

21、求模擬以下場景:3分鐘用戶數(shù)到達300個,繼續(xù)5分鐘后,用戶數(shù)在1分鐘內(nèi)下降至50個,最后2分鐘內(nèi)再上升到500個,那么可以設(shè)計為:Start Vusers:3分鐘到達300個,即每6秒添加10個用戶,共300個用戶Duration:5分鐘Stop Vusers:1分鐘減少250個用戶,每6秒減少25個用戶Start Vusers:2分鐘添加450個用戶,每6秒添加12.5個用戶Real-life schedule方式經(jīng)常用在壓力測試和穩(wěn)定性測試中,了解系統(tǒng)在長時間動搖負載下資源管理的才干,而Real-life的負載戰(zhàn)略是根據(jù)性能需求模型來確定的。Classic Schedule(經(jīng)典方式)這

22、種方式就是老版本的場景設(shè)計方式,只能設(shè)置一次負載的上升繼續(xù)和下降。常見的負載測試都是經(jīng)過Classic方式實施的。在Classic Schedule方式下,用戶的Duration繼續(xù)時間設(shè)置會多出Run until Complete和Run indefinitely兩種方式。其中,Run until Complete指腳本只會被執(zhí)行一次;而Run indefinitely指腳本會永不停頓地運轉(zhuǎn)下去。經(jīng)典方式其真實很多時候曾經(jīng)夠用了,經(jīng)過它生成一個峰值負載,只需系統(tǒng)可以滿足這個峰值即可。普通來說只需峰值下滿足性能需求,那么常規(guī)情況也能滿足性能需求。但是有時候會發(fā)現(xiàn)雖然峰值性能目的能滿足,但系統(tǒng)還

23、是會出問題。這是由于系統(tǒng)并不是長期都處在高負載形狀下,隨著負載的變化,系統(tǒng)的資源在不斷地懇求釋放。假設(shè)在這個過程中存在微量的資源回收失敗,那么時間一長系統(tǒng)就會出問題。另一方面我們知道性能測試需求對用戶行為進展模擬,假設(shè)場景只需經(jīng)典方式那么如何模擬真實的用戶負載動搖呢?所以這個時候Real-life就有意義了,它可以設(shè)置一個和真實情況類似的場景來實現(xiàn)負載。負載的真實性是遭到腳本影響的,普通Real-life運轉(zhuǎn)的腳本會更偏向于模擬用戶操作流程,而Classic的腳本那么更偏向于模擬一種操作。例如:設(shè)置一個Real-life的腳本,那么該腳本就能夠包含用戶隨機邏輯選擇、ThinkTime的變化等情

24、況,盡能夠真實地模擬系統(tǒng)負載形狀;而Classic的腳本,只需求針對某一種操作進展模擬即可,這樣可以獲得該操作在性能負載下的情況,從而逐個確認性能目的,最終再將一切腳本加載,了解整個系統(tǒng)的性能目的。以上引見了兩種場景的運轉(zhuǎn)方式,那么當(dāng)多個腳本在場景中運轉(zhuǎn)時,我們?nèi)绾闻渲盟鼈冎g的關(guān)系呢?在Scenario方式下經(jīng)常需求模擬多個腳本共同運轉(zhuǎn)的情況,從而測試系統(tǒng)在多種業(yè)務(wù)下的處置才干。例如:需求規(guī)定系統(tǒng)可以同時支持300個用戶在線進展閱讀操作和100個用戶進展發(fā)帖操作,那么場景就需求添加兩套腳本,如圖4.22所示。在手工場景中,用戶腳本都被稱為Group,這是由于每一個用戶組都代表一種腳本操作,經(jīng)

25、過組名來區(qū)別腳本之間的關(guān)系。圖4.22手工場景中添加多個Group腳本如何修正各個Group的Quantity用戶數(shù)呢?首先需求將場景的用戶修正為百分比方式,選中Scenario菜單下的Convert Scenario to the Percentage Mode,將場景用戶方式改為百分比方式,如圖4.23所示。圖4.23切換手工場景用戶數(shù)為百分比方式修正view的比例為75,然后取消選擇Convert Scenario to the Percentage Mode選項,這個時候view用戶數(shù)就變?yōu)?00了,而post topic用戶數(shù)變?yōu)?00。場景的運轉(zhuǎn)圖如圖4.24所示。圖4.24多腳本

26、場景Interactive Schedule Graph兩個腳本是運用同樣的負載方式進展的,只是根據(jù)用戶的比例分配負載添加的趨勢,這里設(shè)置了每隔15秒添加20個用戶,也就是每15秒添加5個發(fā)帖用戶以及15個查看用戶。Group方式在Group方式下,除了可以獨立設(shè)置腳本開場原那么以外,還可以經(jīng)過Start Group戰(zhàn)略為腳本之間設(shè)置前后運轉(zhuǎn)關(guān)系。雙擊Group Schedule下的Start Group Action,翻開Start Group戰(zhàn)略,設(shè)置該腳本在手工場景下的Group方式中如何開場運轉(zhuǎn),如圖4.25所示。圖4.25 Group方式下的Start Group戰(zhàn)略其中,Start

27、 immediately after the scenario begins表示當(dāng)場景一開場就立刻運轉(zhuǎn);Start (HH:MM:SS)after the scenario begins表示當(dāng)場景運轉(zhuǎn)后多少時間后再運轉(zhuǎn);Start when group finishes表示當(dāng)某一個group終了后再運轉(zhuǎn)。腳本之間的場景設(shè)計運用不同的顏色區(qū)別,選中腳本可以修正該腳本的運轉(zhuǎn)設(shè)置,如圖4.26所示。圖4.26 Group方式下多腳本Interactive Schedule Graph這里設(shè)置了temp腳本是在analysis腳本場景運轉(zhuǎn)終了后再運轉(zhuǎn)。在某些負載戰(zhàn)略中需求運用Group方式才干完成場景

28、設(shè)計。例如:需求規(guī)定系統(tǒng)在每日的19點至20點進展數(shù)據(jù)搜集,而在21點至23點進展數(shù)據(jù)的分析。那么這時需求分別生成數(shù)據(jù)搜集和數(shù)據(jù)分析的兩套腳本,經(jīng)過Group方式來設(shè)置場景中這兩個腳本的先后關(guān)系,來模擬系統(tǒng)的負載情況。圖形化場景設(shè)計經(jīng)過手工修正負載的變化趨勢非常煩瑣,在設(shè)計時還要經(jīng)過一定的計算才干設(shè)計出符合需求的負載場景,而在LoadRunner 9后,這種操作從過去計算的方式變化成為可以直接拖曳的方式,大大降低了設(shè)計場景的復(fù)雜度。在右側(cè)的Schedule Graph圖中單擊Edit mode按鈕,如圖4.27所示。Schedule Gragh中的節(jié)點會顯示出來,這時就可以運用鼠標對圖中的節(jié)點

29、進展修正,如圖4.28所示。 圖4.27Schedule Graph中的 圖4.28在Edit mode下對Edit mode按鈕 Schedule Graph進展修正經(jīng)過直接拖曳節(jié)點來完成對用戶變化規(guī)律的設(shè)置,也可以經(jīng)過單擊(Split Action)按鈕實現(xiàn)對當(dāng)前選中的線條進展分割。到這里我們引見了目的場景和手工場景兩種場景類型。場景提供腳本運轉(zhuǎn)的方式,經(jīng)過目的場景進展定性型負載,經(jīng)過手工場景進展定量型負載。設(shè)計場景在工具上并沒有復(fù)雜的內(nèi)容,關(guān)鍵在于需求和性能測試的目的,設(shè)計的場景究竟為了測試什么東西是在場景沒計前需求好好思索的。普統(tǒng)統(tǒng)過在場景中運轉(zhuǎn)一種用戶行為可以對某一個功能點進展性能測

30、試和分析,假設(shè)需求對整個系統(tǒng)的運轉(zhuǎn)情況進展性能測試和分析,就需求同時運轉(zhuǎn)多個腳本。假設(shè)在場景中加載多個腳本,并分別設(shè)置其負載方式,就能完成真實情況下的負載模擬。4.1.2 負載生成器管理當(dāng)對場景進展設(shè)計后,接著需求對負載生成器進展管理和設(shè)置。Load Generators是運轉(zhuǎn)腳本的負載引擎,在默許情況下運用本地的負載生成器來運轉(zhuǎn)腳本,但是模擬用戶行為也需求耗費一定的系統(tǒng)資源,所以在一臺電腦上無法模擬大量的虛擬用戶,這個時候可以經(jīng)過調(diào)用多個Load Generators來完成大規(guī)模的性能負載。Load Generator的中心是MMDRV.EXE進程,MMDRV.EXE擔(dān)任運轉(zhuǎn)腳本模擬用戶行為

31、,該程序支持進程或線程的方式,經(jīng)過Runtime Settings即可進展設(shè)置。翻開Scenario菜單下的Load Generators,如圖4.29所示。圖4.29 Load Generators管理器Load Generators管理器列出了所管理的負載效力器列表,需求添加負載引擎只需求在這里單擊Add按鈕,然后在對話框中輸入需求銜接的負載引擎所在的電腦IP以及對應(yīng)平臺即可(確保對應(yīng)平臺上曾經(jīng)安裝并啟動了Load Generator效力,安裝過程請參考第2.6.2節(jié)),如圖4.30所示。圖4.30添加遠程Load Generators添加該引擎后,可以單擊Connect按鈕銜接一下,假設(shè)

32、出現(xiàn)Ready那么闡明正確銜接,該負載生效果勞器可以運用,否那么就需求檢查一下是什么緣由導(dǎo)致的銜接錯誤。在Windows下,假設(shè)排除了防火墻的問題后,Load Generator無法銜接普通是由于Load Generator的權(quán)限配置錯誤導(dǎo)致的。詳細的處理方法闡明如下。在安裝Load Generator的電腦上,翻開LoadRunner中Tools菜單下的LoadRunner Agent Runtime Settings Configuration,如圖4.31所示。圖4.31AgentRuntimeSettings遠程銜接賬戶設(shè)置這里有兩個選項,其中,在Allow virtual users

33、 to run on this machine without user login處輸入登錄信息,就可以讓遠程的Controller無須登錄就直接銜接到這個Load Generator,這里需求輸入本地電腦的賬戶,這樣就可以處理無法遠程訪問負載引擎的錯誤。Linux負載生成器的銜接。按照第2.6.2節(jié)的內(nèi)容安裝配置了Linux端的Load Generators后,在Controller中選擇添效力器,輸入Linux端的IP地址并設(shè)置操作系統(tǒng)為Linux后,還需求在Unix Environment中選中Dont use RSH,如圖4.32所示。添加完成,單擊Connect按鈕,Linux平臺

34、下的負載生成器銜接勝利,如圖4.33所示。圖4.32添加Linux平臺下的負載生成器圖4.33添加遠程Linux負載生成器銜接勝利當(dāng)遠程負載效力器被勝利添加至負載效力管理器中后,就可以在Scenario Group中的Group腳本右側(cè)選擇運用哪一臺負載效力器來運轉(zhuǎn)對應(yīng)的腳本了,如圖4.34所示。圖4.34設(shè)置腳本運轉(zhuǎn)所在的負載生成器經(jīng)過設(shè)置多個LoadGenerator可以有效地添加負載量,處理單臺電腦無法模擬大量負載的問題。當(dāng)場景開場運轉(zhuǎn)時,Controller會先將腳本傳輸?shù)礁鱾€負載生成器上,等到運轉(zhuǎn)終了后,各個負載生成器的日志會被Controller回收。在大多數(shù)情況下,運用進程方式時

35、一個Vuser會占用接近3MB的內(nèi)存,而運用線程方式時一個Vuser大約只占用200KB的內(nèi)存。為了保證負載生成的有效性,請在真正實施性能測試前先測試一下負載器能否存在硬件瓶頸(生成負載時的CPU、內(nèi)存、帶寬占用情況),確保負載生成時負載器本身不會成為瓶頸,其CPU和內(nèi)存的運用率最好不超越80。4.1.3 用戶管理在Scenario Groups工具條中,除了運轉(zhuǎn)腳本按鈕、查看腳本和Run-Time Setting功能外,Virtual Users管理器是經(jīng)常運用的一個功能,該功能提供了一個對負載用戶進展快捷有效監(jiān)控的操作平臺,如圖4.35所示。單擊Virtual Users按鈕,彈出虛擬用戶

36、管理器,如圖4.36所示。圖4.35 Scenario Groups工具條圖4.36虛擬用戶管理器在場景運轉(zhuǎn)前可以設(shè)置待運轉(zhuǎn)虛擬用戶的形狀,如手動啟動用戶執(zhí)行,也可為場景添加或停頓用戶。當(dāng)場景運轉(zhuǎn)時,可以經(jīng)過該功能對某個正在運轉(zhuǎn)的用戶進展監(jiān)控。例如:選擇某個正在運轉(zhuǎn)的用戶,右鍵菜單翻開Show User功能,可以獲得該用戶的運轉(zhuǎn)形狀(效果同VuGen中的Browser),也可以選擇Show Vusers Log功能翻開該用戶運轉(zhuǎn)的目志,還可以經(jīng)過過濾規(guī)那么來查找不同形狀的虛擬用戶。4.1.4 運轉(zhuǎn)設(shè)置在場景運轉(zhuǎn)前還需求對腳本的運轉(zhuǎn)戰(zhàn)略進展設(shè)置,確保整個場景中一切用戶的運轉(zhuǎn)方式正確。留意在Con

37、troller中Run-Time Setting獨立存放在場景.lrs文件中,并不會影響該腳本在VuGen中運轉(zhuǎn)的設(shè)置。在場景運轉(zhuǎn)前應(yīng)該對以下選項進展檢查設(shè)置,以確保腳本正確執(zhí)行。1.Think Time在VuGen中Think Time默以為忽略,但是在場景中,該選項會自動按照腳本錄制的lr_hink_time()函數(shù)進展運轉(zhuǎn)。Think Time可以模擬真適用戶的操作等待,假設(shè)該時間設(shè)置得太短,那么得出的性能數(shù)據(jù)就會比較悲觀(模擬的用戶操作比真適用戶快,效力器的負載壓力會比正常情況大,從而結(jié)果較差),反之結(jié)果會過于樂觀,所以這個時間不能隨意設(shè)置。由于錄制腳本的時候?qū)I(yè)務(wù)比較熟習(xí),所以會導(dǎo)致

38、Think Time偏小,這里可以嘗試取一個熟練用戶的操作速度和一個新用戶的操作速度的平均值來設(shè)置合理的Think Time值。2.場景中MMDRV.EXE負載的生成方式Load Generators會調(diào)用mmdrv.exe來生成負載,而負載的生成分為進程方式和線程方式。運用進程方式模擬負載的資源開銷會相對較大,每個虛擬用戶會運用一個單獨的mmdrv.exe來完成負載的實現(xiàn),這樣做用戶之間會相互獨立,不會相互影響。而假設(shè)運用線程方式,那么一切用戶都是在一個mmdrv.exe上模擬的,用戶行為運用線程方式,模擬耗費的資源較小。普通來說運用線程可以在固定的硬件平臺上產(chǎn)生更多的負載模擬,但運用線程也

39、會存在不穩(wěn)定的情況,導(dǎo)致用戶腳本執(zhí)行錯誤。3.系統(tǒng)日志設(shè)置在場景中系統(tǒng)曰志會從Always send messages變?yōu)镾end messages only when an error occurs,不出現(xiàn)錯誤就不記錄日志,這樣可以減少負載時記錄日志的資源開銷,從而提高模擬效率。當(dāng)需求進展錯誤跟蹤時,再將其翻開。4.封鎖自動化事務(wù)在腳本中都會對關(guān)鍵的操作添加事務(wù)從而獲得呼應(yīng)時間,普通會默許設(shè)置自動化事務(wù)(對每個Action都默許設(shè)置一個事務(wù)),導(dǎo)致每次都會多幾個無關(guān)緊要的事務(wù)統(tǒng)計,為了防止多余的數(shù)據(jù)影響,建議封鎖自動化事務(wù)選項。5.帶寬模擬帶寬會直接影響到事務(wù)的呼應(yīng)時間,而真實環(huán)境下每個用戶

40、的帶寬也是有限的,這里需求為用戶設(shè)置一個合理的帶寬來得到真適用戶訪問的呼應(yīng)時間。通常情況下一個客戶端在訪問一個Web網(wǎng)站時的平均銜接速度是在30-50KBs左右,這里可以選擇512 Kbps(DSL),為場景中的每個用戶分配512Kb的帶寬。為了防止出現(xiàn)由于模擬用戶過多,導(dǎo)致Load Generator上出現(xiàn)帶寬瓶頸的情況,需求在設(shè)置前進展計算。假設(shè)設(shè)置每個用戶有512Kb的帶寬,那么在100Mb總帶寬下,最多模擬200個用戶。6.集合點戰(zhàn)略假設(shè)腳本中含有集合點,那么需求根據(jù)需求對集合點的戰(zhàn)略進展設(shè)置。當(dāng)場景需求多腳本并發(fā)負載時,只需設(shè)置同名集合點即可實現(xiàn)。4.1.5 IP虛擬很多時候效力器都

41、對IP有限制戰(zhàn)略,不允許同一個IP地址上有多個客戶銜接操作,這時就需求運用IP虛擬這個功能將虛擬用戶腳本從一個IP運轉(zhuǎn)變成不同IP運轉(zhuǎn)。IP虛擬技術(shù)主要是得益于TCPIP的支持,在TCPIP組中,一塊物理設(shè)備可以綁定多個IP地址。翻開網(wǎng)卡屬性中的高級設(shè)置,找到IP設(shè)置標簽,添加IP地址,如圖4.37所示。添加IP地址后,可以經(jīng)過ipconfig命令確認多個IP能否曾經(jīng)運用在了物理網(wǎng)卡上。當(dāng)網(wǎng)卡綁定多個IP地址后,接著只需求在Controller中翻開IPSpoofer支持功能即可,如圖4.38所示。 圖4.37在TCPIP高級設(shè)置中 圖4.38 Enable IP Spoofer啟動場景下的為

42、網(wǎng)卡添加lP地址 IP虛擬支持該選項翻開后,在Controller下會出現(xiàn)圖標,闡明該功能正在運轉(zhuǎn)。假設(shè)需求生成大量的IP地址,那么可以經(jīng)過Load Runner白帶的IP Wizard工具實現(xiàn)(該工具要求網(wǎng)卡處于非DHCP方式下)。翻開LoadRunner中Tools菜單下的IP Wizard工具,如圖4.39所示。IP Wizard可以快捷生成大量的IP地址并將其添加到網(wǎng)卡中,相對于手工來說方便了很多。選擇創(chuàng)建一個新的設(shè)置后,單擊下一步按鈕。接著需求輸入效力器的IP地址,如圖4.40所示。圖4.39 IP地址生成導(dǎo)游圖4.40需求訪問的效力器lP地址填寫效力器IP地址后,單擊下一步按鈕。在

43、如圖4.41所示的界面中單擊Add按鈕輸入所需求構(gòu)建的網(wǎng)段類型和IP數(shù)目。這里構(gòu)建一個ClassB類(C類的IP地址由于區(qū)域較小,最大只能包容255臺主機,不太適宜用來做性能測試)的IP地址,然后從開場,生成400個IP地址,如圖4.42所示。圖4.41添加IP地址段圖4.42設(shè)置400個B類lP地址Verify that new IP addresses are not already可以校驗IP地址能否存在。確定后,該工具將對每個IP地址進展檢測,假設(shè)已被運用,那么跳過,否那么留下。用IP Wizard將IP地址寫入網(wǎng)卡后,并沒有立刻生效,我們可以運用ipconfig命令來確認。假設(shè)顯示的

44、網(wǎng)卡中沒有新添加的IP信息,那么可以經(jīng)過重啟網(wǎng)卡的方式來完成生效任務(wù)(禁用網(wǎng)卡,啟動網(wǎng)卡)。那么如何檢查每個腳本運用的IP地址呢?在翻開IP Spoofer后,只需求確保場景日志翻開,并且將其設(shè)置為擴展日志,就可以在運轉(zhuǎn)的日志中找到對應(yīng)的IP信息,留意假設(shè)虛擬用戶的數(shù)目大于IP的數(shù)目,那么用戶之間的IP會出現(xiàn)反復(fù)的情況。在Controller 9.1中IP虛擬支持進程和線程方式,也可以在設(shè)置中找到相關(guān)選項。選中Controller中Tools菜單下的Expert mode方式,然后翻開Options對話框,在General標簽中就可以看到IP虛擬的設(shè)置標簽,留意,當(dāng)Scenario菜單下的En

45、able IP Spoofer選項啟用時,才干在這里設(shè)置Multiple IP戰(zhàn)略,如圖4.43所示。圖4.43設(shè)置IP虛擬分配戰(zhàn)略當(dāng)腳本在遠程Load Generator上運轉(zhuǎn)時,只需求在對應(yīng)的Load Generator上配置多IP即可,另外需求留意的是當(dāng)運用IP虛擬的時候引薦先和網(wǎng)絡(luò)管理員商量一下,防止出現(xiàn)一些網(wǎng)絡(luò)架構(gòu)方面的問題。4.1.6 場景運轉(zhuǎn)原理在場景中可以設(shè)置其需求繼續(xù)一段運轉(zhuǎn)時間,而一個腳本運轉(zhuǎn)一次的時間是有限的。在場景中當(dāng)場景運轉(zhuǎn)時間大于腳本運轉(zhuǎn)時間時該如何處置呢?這里可以設(shè)置一個簡單的腳本來嘗試一下:Action()Ir_eval_string(“(interation)

46、;return0;在Parameter List中設(shè)置參數(shù)interation的取值為interation number,格式為:08d。切換這個腳本到手工場景運用一個用戶運轉(zhuǎn),設(shè)置腳本的Duration時間為2分鐘,運轉(zhuǎn)終了后經(jīng)過日志即可了解場景運轉(zhuǎn)的本質(zhì)。Virtual User Script started MsgId:MMSG-15967Starting action vuser_init. Msgld:MMSG-15919Web Turbo Replay of LoadRunner 9.10.0 for Windows Vista; WebReplay85 build 5896 Ms

47、gId:MMSG-27143RunMode:HTML MsgId:MMSG-26000Run-Time Settings file: C:IUsersAdministratorAppDataLocalITemp1r5tmpdirex0.792 1rcfgzJt.793 cfgM51.797 MsgId:MMSG-27141Ending action vuser_init. MsgId:MMSG-15918Running Vuser.MsgId:MMSG-15964Starting iteration 1.MsgId:MMSG-i5968Starting action Action.MsgId:

48、MMSG-15919Action.c(3):Notify:Parameter Substitution:parameterinteration=“00000001MsgId:MMSG-92Ending action Action.MsgId:MMSG-15918Ending iteration 1.MsgId:MMS-15965Starting iteration 2.Msgld:MMSG-159681Starting action Action.MsgId:MMSG-15919Action.c(3):Notify:Parameter Substitution:parameterinterat

49、ion=“00000002MsgId:MMSG-92Ending action Action.Msgld:MMSG-15918Ending iteration 2.MsgId:MMSG-15965/省略中間的內(nèi)容Starting iteration 24893.MsgId: SG-15968Starting action Action.MsgId:MMSG-15919Action.c(3):Notify:ParameterSubstitution:pamameterinterationn00024893MsgId:MMSG-92Ending action Action.MsgId:MMSG-1

50、5918Action was aborted.MsgId:MMSG-10694Ending Vuser.MsgId:MMSG-159661Starting action vuser_end.MsgId:SG-15919Ending action vuser_end.MsgId:MMSG-15918Vuser Terminated.MsgId:MMSG-15963在Run Logic中,恣意一個腳本都是分為init、run、end三個部分。當(dāng)腳本在場景運轉(zhuǎn)時,虛擬用戶被初始化后先會運轉(zhuǎn)init然后進入run,當(dāng)整個run終了后場景會檢查能否到達該虛擬用戶的終了時間,假設(shè)沒有到達,那么繼續(xù)自動迭代

51、這個run過程,直到虛擬用戶到達終了時間該腳本停頓run過程,最后完成end內(nèi)容,如圖4.44所示。圖4.44場景運轉(zhuǎn)原理在場景運轉(zhuǎn)終了時停頓用戶的方式有3種,翻開Options對話框可以對其進展設(shè)置,如圖4.45所示。圖4.45場景終了停頓虛擬用戶戰(zhàn)略設(shè)置在Controller的Options對話框中Run-Time Settings中提供了對Vusers停頓時的戰(zhàn)略設(shè)置,這也是為什么大多數(shù)情況下腳本到達停頓時間后,并不會立刻終了的緣由。其中,Wait for the current iteration to end before exiting表示當(dāng)用戶需求停頓時,會等待本次迭代終了,這個

52、時候用戶會處于Gradual Exiting形狀;Wait for the current iteration to end before exiting表示當(dāng)用戶需求停頓時,會等待當(dāng)前Action執(zhí)行終了(一次迭代下能夠會有多個Action),用戶同樣會處于Gradual Exiting形狀;Stop immediately表示用戶立刻停頓,不完成當(dāng)前操作。當(dāng)設(shè)置負載用戶的Duration繼續(xù)戰(zhàn)略為Run until completion時,run模塊只會被運轉(zhuǎn)一次。4.1.7 Service Level Agreement(效力質(zhì)量保證)Service Level Agreement是Lo

53、adRunner 9新添加的功能,該功能主要是為了方便對某些數(shù)據(jù)的閾值進展監(jiān)控,如圖4.46所示。在高級設(shè)置中可以定義監(jiān)控的間隔周期,默許情況下為5秒鐘,如圖4.47所示。在這里新建一個SLA的規(guī)那么,來對當(dāng)前性能測試的某些數(shù)據(jù)進展閾值的監(jiān)控。單擊New按鈕新建SLA目的,如圖4.48所示。圖4.46 SLA戰(zhàn)略設(shè)置圖4.47 SLA戰(zhàn)略高級選項隨后選擇添加SLA目的的規(guī)那么,如圖4.49所示。圖4.48新建SLA目的定義圖4.49新建SLA目的類別設(shè)置這里提供了兩種方式:假設(shè)基于SLA status determined at time intervals over a timeline,可

54、以針對某個數(shù)據(jù)進展階段級別的劃分;假設(shè)基于SLA status determined over the whole run,那么在整個場景運轉(zhuǎn)過程中對數(shù)據(jù)進展閾值檢測。1.基于SLA status determined at time intervals over a timeline的設(shè)定在這里選擇Average transaction Response Time(根據(jù)平均事務(wù)呼應(yīng)時間),然后選擇需求監(jiān)控的事務(wù)名,將其添加到被選形狀,接著設(shè)置監(jiān)控的負載分段,如圖4.50所示。圖4.50定義SLA平均呼應(yīng)時間目的在這里設(shè)置負載用戶在10個以下、10-20、20-30、30以上這幾個階段中的平均

55、呼應(yīng)時間是需求監(jiān)控的,接著設(shè)置在這些時間段下呼應(yīng)時間的詳細值,如圖4.51所示。圖4.51定義SLA目的在各個用戶數(shù)階段所需求到達的呼應(yīng)時間各階段設(shè)置的監(jiān)控閾值為:10個用戶以下的情況,reg事務(wù)的呼應(yīng)時間應(yīng)該在1秒內(nèi);10-20個用戶情況下,事務(wù)呼應(yīng)時間在2秒內(nèi);20-30個用戶的情況下,事務(wù)呼應(yīng)時間在3秒內(nèi);30個用戶以上呼應(yīng)時間在5秒內(nèi),確定以后就完成了該SLA的監(jiān)控戰(zhàn)略設(shè)置。2.基于SLA status determined over the whole run的閾值設(shè)定選擇閾值類型為Average Through put(平均吞吐量)后,添加對應(yīng)的閾值。例如我們希望系統(tǒng)可以到達500

56、0字節(jié)秒的平均吞吐量目的,如圖4.52所示。這個時候我們?yōu)橄到y(tǒng)設(shè)置了兩個SLA監(jiān)控規(guī)那么,如圖4.53所示。圖4.52設(shè)置針對平均吞吐量的SLA監(jiān)控閾值圖4.53設(shè)置好的兩個SLA監(jiān)控規(guī)那么當(dāng)場景完成后,在Analysis中可以得到專門的SLA數(shù)據(jù)報告,給出在整個場景的運轉(zhuǎn)過程中相關(guān)數(shù)據(jù)能否符合事先制定的SLA閾值,從而提升性能測試報告的專業(yè)性。另外SLA也可以在場景運轉(zhuǎn)后,在Analysis中進展添加和設(shè)置。4.2 系統(tǒng)監(jiān)控在場景運轉(zhuǎn)前還需求對系統(tǒng)進展監(jiān)控,記錄負載生成的規(guī)那么、負載數(shù)據(jù)和系統(tǒng)在負載下的資源運用情況。除了對負載的生成形狀進展監(jiān)控,被負載的系統(tǒng)資源也需求進展監(jiān)控。單擊Contr

57、oller底部的Run標簽,切換到場景運轉(zhuǎn)形狀。運轉(zhuǎn)頁面中主要包含了3部分內(nèi)容:Scenario Groups、Scenario Status、Available Graphs。4.2.1 Scenario Groups(場景用戶形狀)在Scenario Groups中列出了一切運轉(zhuǎn)腳本的虛擬用戶形狀,經(jīng)過這個表格可以明晰地了解當(dāng)前負載中各個虛擬用戶的形狀,也可以經(jīng)過單擊鼠標右鍵菜單中的功能對用戶進展簡單的監(jiān)控和設(shè)置,如圖4.54所示。單擊鼠標右鍵對運轉(zhuǎn)用戶進展進一步的設(shè)置,如圖4.55所示。 圖4.54場景運轉(zhuǎn)時Group虛擬用戶運轉(zhuǎn)形狀 圖4.55場景運轉(zhuǎn)虛擬用戶形狀右鍵菜單在菜單中可以手

58、工設(shè)置腳本運轉(zhuǎn),或者運用Show Vuser翻開小的閱讀器查看每個用戶的運轉(zhuǎn)情況(用戶很多的時候慎用),Show Vuser log用于直接查看當(dāng)前每個用戶的運轉(zhuǎn)日志(可以不用像以前那樣進入目錄查看文件了)。留意:當(dāng)場景的Duration設(shè)置為只運轉(zhuǎn)一次時,每個用戶是以Passed形狀終了的;而當(dāng)場景的Duration設(shè)置為按照一定的周期執(zhí)行時,那么該用戶將以Stopped形狀終了。虛擬用戶普通分為以下幾種形狀,如表4.1所示。表4.1場景用戶形狀4.2.2 Scenario Status(場景運轉(zhuǎn)形狀)Scenario Status列出了當(dāng)前場景的形狀,經(jīng)過它可以了解當(dāng)前負載的用戶數(shù)、耗費時

59、間、每秒點擊量、事務(wù)經(jīng)過失敗的個數(shù),以及系統(tǒng)錯誤的個數(shù),如圖4.56所示。當(dāng)場景運轉(zhuǎn)出錯時,可以單擊Errors后的數(shù)字,翻開Output窗口,也可以經(jīng)過View菜單下的Show output命令翻開Output窗口,如圖4.57所示。圖4.56 Scenario Status場景運轉(zhuǎn)形狀圖4.57 Output窗口單擊Details按鈕可以查看每個錯誤的詳細信息,協(xié)助 我們了解導(dǎo)致場景執(zhí)行錯誤的緣由。4.2.3 計數(shù)器原理Controller可以監(jiān)控系統(tǒng)資源并不是由于安裝了LoadRunner的緣故。在沒有安裝LoadRunner前,它也可以得到當(dāng)前系統(tǒng)的相關(guān)性能數(shù)據(jù)。比如義務(wù)管理器中的CP

60、U和內(nèi)存運用率、各個進程所運用的相關(guān)資源信息等,這些都是系統(tǒng)在設(shè)計中留下的目的接口。幾乎一切的運用和效力軟件都提供了計數(shù)器和監(jiān)控器接口(預(yù)留這些計數(shù)器接口的目的是為了系統(tǒng)本身性能測試和瓶頸定位),在SQL Server中可以經(jīng)過事件探查器完成SQL命令執(zhí)行的監(jiān)控任務(wù)。翻開Windows 2021控制面板管理工具下的可靠性和性能監(jiān)視器(WindowVista以前的操作系統(tǒng)稱之為性能),可以得到當(dāng)前系統(tǒng)的心跳數(shù)據(jù),如圖4.58所示。圖4.58 Windows 2021下的可靠性和性能監(jiān)視器選擇性能監(jiān)視器,在這里可以看到系統(tǒng)Processor Time運用百分比,如圖4.59所示。性能監(jiān)視器支持手動

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論