軟件性能測試過程詳解與案例剖析學習筆記

1、文檔編碼 : CK3R6W10U10V6 HV9H7H10J4X8 ZW3S5Z2M10R7學習必備 歡迎下載 第一章 性能測試基本概念 軟件性能 從用戶的角度,軟件性能就是軟件對用戶操作的響應時間； 從治理員的角度,軟件性能第一表現(xiàn)在響應時間上；仍包括資源利 用率,可擴展性,系統(tǒng)容量（并發(fā)等）和系統(tǒng)穩(wěn)固性等；為了 保證系統(tǒng)的穩(wěn)固運行和連續(xù)的良好性能； 對于開發(fā)人員而言,最想知道“如何通過調整設計和代碼實現(xiàn),或是如何通過調整系統(tǒng)設置等方法提高軟件的性能表現(xiàn)”和“如 何發(fā)覺并解決軟件設計和開發(fā)過程中產生的由于過多用戶拜望引起的缺陷”,也就是性能瓶頸和大量用戶拜望時的缺陷；關注的是系統(tǒng) 架構,數(shù)據(jù)

2、庫設計,代碼和設計； 所以在性能測試時,既要關注響應時間,仍要關注軟件可擴展性,并發(fā)才能等指標,仍要為性能問題定位； 術語 1,響應時間 系統(tǒng)響應時間為應用系統(tǒng)從發(fā)出懇求開頭到客戶端接收到響應所消耗的時間； 合理的響應時間取決于實際用戶的需求； 2,并發(fā)用戶數(shù) 有兩種懂得,一種是同一時間段拜望系統(tǒng)的用戶數(shù)量,一種是服務器所能承擔的壓力（同時發(fā)出懇求的客戶）；在性能測試中我 們更關注前者,業(yè)務并發(fā)用戶數(shù)； 公式 c=nL/T, 運算平均并發(fā)用戶數(shù),仍可用 c=n/10 仍做簡潔的估量； n 為每天拜望系統(tǒng)的用戶數(shù)； 仍可以通過分析服務器的日志來明白用戶的使用狀態(tài)； 3,吞吐量 單位時間內系統(tǒng)處理

3、的客戶懇求的數(shù)量,懇求數(shù) 預期設計目標,幫忙分析性能瓶頸； 4,性能計數(shù)器 / 秒,頁面數(shù) / 秒,拜望數(shù) / 天,業(yè)務數(shù) / 小時,字節(jié)數(shù) / 天；可用于衡量是否達到了 描述服務器或操作系統(tǒng)性能的一些數(shù)據(jù)指標；例如,內存數(shù),進程時間；用于監(jiān)控和分析；常與資源利用率進行橫向對比,例如 cpu 占用率 68%； 5,摸 索時間（休眠時間） 用戶在進行操作時,每個懇求之間的間隔時間； 方法 1,SEI 負載測試方案過程 關注于負載測試方案的方法,目標是產生清楚,易懂得,可驗證的負載測試方案；關注目標,用戶,用 例,生產環(huán)境,測試環(huán)境 和測試場景； 2,RBI 方法 rapid bootleneck

4、 identify, 3,性能下降曲線分析法 用于快速識別系統(tǒng)性能瓶頸的方法； 描述性能隨用戶數(shù)量增長而顯現(xiàn)下降趨勢的曲線； 4,LoadRunner 的性能測試過程 包括方案測試,測試設計,創(chuàng)建 VUvirtual user 腳本,創(chuàng)建測試場景,運行測試場景,分析結果； 5,Segue 供應的性能測試過程 先確定性能基線, 然后設定可接受的性能目標, 用不同的并發(fā)用戶數(shù)等重復測試； 適合性能調優(yōu)和性能優(yōu)化, 通過不斷的 try-check 過程,逐步找到可能導致性能瓶頸的地方并對其優(yōu)化； 6,PTGM模型 performance testing general model ；分為測試前期預備

5、,測試工具引入,測試方案,測試設計與開發(fā),測試執(zhí)行和治理以及測 試分析； 第 2 章 性能測試的應用領域 2.1 性能測試的方法 1,性能測試 performance testing 模擬生產運行的業(yè)務壓力氣和使用場景組合,測試系統(tǒng)的性能是否中意生產性能的要求； 2,負載測試 load testing 通過在系統(tǒng)上不斷增加壓力,直到性能指標超過預定或某種資源的使用達到飽和；找到系統(tǒng)的處理極限； 3,壓力測試 stress testing 測試系統(tǒng)在確定飽和狀態(tài)下,系統(tǒng)能夠處理的會話才能,以及系統(tǒng)是否會顯現(xiàn)錯誤；常用于測試系統(tǒng)的穩(wěn)固性； 4,配置測試 configuration testing

6、通過對被測軟件的軟 / 硬件環(huán)境的調整,明白各種不同環(huán)境對系統(tǒng)性能的影響的程度,從而找到系統(tǒng)各項資源的最優(yōu)支配原就； 5,并發(fā)測試 concurrency testing 模擬用戶的并發(fā)拜望,測試多用戶并發(fā)拜望同一個應用,同一個模塊或者數(shù)據(jù)記錄時是否存在死鎖或者其他性能問題； 關注內存是否有太多暫時對象,超過設計生命周期的對象,數(shù)據(jù)庫死鎖,常常顯現(xiàn)長事務,是否顯現(xiàn)線程 / 進程同步失敗,資源爭 用導致死鎖,未處理反常導致死鎖； 6,牢靠性測試 reliability testing 通過給系統(tǒng)加載確定的業(yè)務壓力的情形下,讓應用系統(tǒng)連續(xù)運行一段時間,測試系統(tǒng)在這種條件下能否穩(wěn)固運行； 7,實效復

7、原測試 failover testing 針對冗余備份和負載均衡的系統(tǒng)；檢驗假如系統(tǒng)局部發(fā)生故障,用戶是否能夠連續(xù)使用系統(tǒng),假如這種情形發(fā)生,用戶將受多大 程度影響； 第 1 頁,共 8 頁學習必備 歡迎下載 2.2 應用領域分析 1,才能驗證 performance testing,reliability testing,stress testing,failover testing 2,才能規(guī)劃 load testing,configuration testing,stress testing 3,性能調優(yōu) configurationg testing,load testing,stres

8、s testing,failover testing 4,缺陷發(fā)覺 concurrency testing,stress testing,failover testing 第 3 章 性能計數(shù)器及性能分析方法 用來衡量被測系統(tǒng)當前的狀況和進行性能測試結果分析；可在操作系統(tǒng)級,應用服務器級和數(shù)據(jù)庫級別上查看和記錄性能計數(shù)器 的數(shù)值； 3.1 操作系統(tǒng)計數(shù)器及分析 1,Windows Memory:available mbytes,pages/sec,pages read/sec,page faults/sec,cache bytes Process:%processor time,page fa

9、ults/sec,work set,private bytes Processor:%processor time,%user time,%privileged time,%dpc time Physical Disk:%disk time,average disk queue length,average disk read/write queue length,disk readswrites/sec,average disk sec/read,average disk sec/transfer Network Interface:bytes total/sec System:%total

10、 processor time,file data operation/sec,processor queue length 2,unix 3,內存分析方法 用于分析系統(tǒng)有無遇到內存瓶頸,是否需要通過增加內存等手段提高系統(tǒng)性能表現(xiàn)； 第一查看 memory/available mbytes ；留意 pages/sec,pagesread/sec,page faults/sec 反映進行磁盤交換的頻率 ；依據(jù) physical disk 分析； 4,處理器分析方法 先看 system%Total processor time, 然后看每個 cpu 的指標,最終分析； 5,磁盤 I/O 分析方法

11、運算每個磁盤的 I/O 數(shù)；然后與 processorprivileged time 合并分析；最終依據(jù) disk sec/transfer 分析； 6,進程分析方法 觀看 %processor time ,反映進程消耗的處理其時間；然后查看每個進程產生的頁面失效,對于產生最多頁面失效的進程要重點分 析；明白進程的 process/private bytes, 看是否存在內存泄露； 7,網(wǎng)絡分析方法 network interfacebytes total/sec 為發(fā)送和接收字節(jié)的速率,與當前帶寬進行比較； 3.2 應用服務器計數(shù)器 1,IIS 2,J2EE 應用服務器計數(shù)器 weblogi

12、c ： JVM:heap size;heap free JDBC connection pool:waiting for connection current count;connection total count;max capacity;active connections current count execute queue:execute thread current idle count;pending request oldest time;serviced request oldest time;serviced request total count;pending req

13、uest current count; 3,數(shù)據(jù)庫計數(shù)器 第 4 章 性能測試工具原理 4.1 性能測試工具模型 性能測試工具只能幫忙您實施性能測試,并不能幫忙您完成性能測試的需求； 性能測試工具能夠依據(jù)您的要求以各種方式供應報表,這些報表是分析的基礎； 性能測試工具一般包括虛擬用戶腳本產生器；壓力產生器；用戶代理；壓力調度和把握系統(tǒng)；壓力結果分析工具； 4.2 性能測試腳本錄制時的協(xié)議類型 對于 j2ee, 建議挑選 http/https 協(xié)議； 第 2 頁,共 8 頁學習必備 歡迎下載 4.3 性能測試工具的挑選與評估 工具支持被測系統(tǒng)運行的平臺嗎？ 支持被測系統(tǒng)使用的協(xié)議嗎？ 能夠支持我

14、們的特別要求？ 能夠供應對我們關懷的服務器,應用服務器或是數(shù)據(jù)庫類型計數(shù)器的監(jiān)控嗎？ 工具使用的腳本語言功能完善嗎？ 常用的包括 Loadrunner 和 silk performer ； 第 5 章 性能測試的組織 5.1 人員構成 經(jīng)理,測試設計,測試開發(fā),測試執(zhí)行,測試分析,支持 5.2 過程模型 基于 ATLM 和 TMap 模 型； 1,前期預備 保證系統(tǒng)穩(wěn)固,建立合適的測試團隊,測試工具需求確認； 2,測試工具引入 挑選；培訓；應用過程； 3,測試方案 測試目的（應用領域,測試目標）；用戶活動剖析與業(yè)務建模（系統(tǒng)日志與用戶調查分析）；確定性能目標；制定方案； 4,測試設計與開發(fā) 測

15、試環(huán)境設計；測試場景設計；測試用例設計；腳本和幫忙工具開發(fā)活動； 5,測試執(zhí)行與治理 建立測試環(huán)境；部署測試腳本和測試場景；執(zhí)行測試和記錄結果； 6,測試分析 依據(jù)測試的目的和目標給出測試結論； 第 8 章 案例三某通信企業(yè)的 8.1 背景 web 業(yè)務系統(tǒng)性能測 試 該系統(tǒng)用于治理企業(yè)的備品和備件,包括網(wǎng)絡設備的庫存治理,庫存流轉,備品備件的查詢統(tǒng)計； 測試的主要目的是驗證系統(tǒng)的性能是否達到用戶要求； 8.2 項目特點 接受 J2ee,tomcat,struts+ejb+hibernate ；一臺 unix 服務器用作數(shù)據(jù)庫服務器,一臺 unix 服務器用作應用服務器；性能表達 主要是響應時

16、間；協(xié)議為 http/https ； 8.3 測試過程 1,前期預備 5 人：一個數(shù)據(jù)庫工程師,一個性能測試設計和分析人員,三名性能測試開發(fā)和實施人員； 工具需要支持 Http/https 協(xié)議, 監(jiān)控 unix/windows 服務器的主要性能計數(shù)器值, 支持 oracle 數(shù)據(jù)庫計數(shù)器值監(jiān)控, 支持 tomcat 應用服務器的 jvm 內存使用狀況監(jiān)控； 2,測試工具引入 挑選 LoadRunnder； tomacat 的 jvm 自行開發(fā)工具來實現(xiàn)； 3,測試方案 （1）測試目的：驗證系統(tǒng)是否達到預期性能指標 （2）用戶活動剖析與業(yè)務建模：得到典型用戶活動分析表,并發(fā)用戶數(shù)和吞吐量 用戶

17、活動分析表 業(yè)務名稱 實際使用用戶數(shù)量 業(yè)務發(fā)生數(shù)（筆 / 天） 備件信息 200 1500 庫存流轉 - 申請單 200 4000 庫存流轉 - 審批 100 4000 庫存流轉 - 借用 150 3000 庫存流轉 - 仍庫 150 3000 庫存流轉 - 報廢 100 200 查詢統(tǒng)計 - 備件查詢 200 5000 查詢統(tǒng)計 - 申請單查詢 100 2022 導入備件 Excel 文件 20 80 第 3 頁,共 8 頁 平均每天該系統(tǒng)的用戶為 600；平均每個用戶每天使用 學習必備 歡迎下載 500 個業(yè)務操作； 4 小時；平均每個用戶進行 所以并發(fā)用戶數(shù)： 600*4/8=300

18、吞吐量： 300*500/4*60*60=10, 瀏覽數(shù) / 秒 （3）確定性能目標：得到性能需求描述 具體描述 在典型數(shù)據(jù)量,頁面響 數(shù)據(jù)規(guī)模備件 500000 條記錄, 應時間不超過 10 秒 半年流轉數(shù)據(jù) 750000 條記錄 系統(tǒng)能夠穩(wěn)固運行 壓力條件： 高于實際系統(tǒng)運行壓力 1 倍 系統(tǒng)穩(wěn)固判定條件： 測試中,各進程內存沒有明顯變化 測試中,響應時間和業(yè)務才能沒有明顯變化 連續(xù)測試時間 72 小時 典型規(guī)模的 excel 備 文件規(guī)模 20M,包含記錄 50000 條 件文件導入時間性能 在 10 秒的響應時間下, 以響應時間 10 秒作為負載測試的終止條件, 能承擔的用戶數(shù) 獲得系

19、統(tǒng)能承擔的最大用戶數(shù)量 在典型用戶數(shù)量下, cpu 平均使用率不高于 75%,內存使用率不高于 75%；在穩(wěn)固性測試的壓力條件下, cpu 使用率不高于 95%,內存使用率不高于 4 制定時間方案； 90%； 子項目名稱 子項目起止時間 里程碑成果 參加者 測試環(huán)境和場景設計 測試環(huán)境文檔,測試場景文檔 測試用例設計和腳本開發(fā) 測試用例文檔,測試腳本 測試環(huán)境構建 測試工具 測試環(huán)境,測試環(huán)境描述文檔 和場景部署 執(zhí)行性能測 測試工具部署說明,場景部署說明 試 穩(wěn)固性測試 測試結果 測試結果記錄 分析和報告編寫 測試結果記錄 測試報告 4,測試設計與開發(fā) 1 測試環(huán)境設計 由于本測試主要與于驗

20、證系統(tǒng)在實際環(huán)境中的性能才能,因此盡可能挑選接近 實際環(huán)境的配置； 測試環(huán)境 設備 硬件配置 軟件配置 數(shù)據(jù)庫服務器 SUN V880 服務器（ 1 臺） Solaris 8 Oracle 4CPU 8GB 內存 磁盤陣列 服務器性能計數(shù)器腳本 應用服務器 SUN V880 服務器（ 1 臺） Solaris 8 Tomcat 5 4CPU 8GB 內存 磁盤陣列 服務器端應用 服務器性能計數(shù)器腳本 性能測試 Console PC 機（ 1 臺） 512MB 內存 WindowsXP+SP1 LoadRunner Controller 40GB 硬盤 LoadRunner Analysis M

21、icrosoft Office WindowsXP+SP1 硬 負載產生設備 PC 機（ 5 臺） 512MB 內存 LoadRunner Agent40GB 盤 基礎數(shù)據(jù)量在需求中已有描述 2 測試場景設計 設計并發(fā)用戶數(shù) 300,每個 VU 操作之間的時間間隔30 秒 第 4 頁,共 8 頁為 學習必備 歡迎下載 典型測試場景 場景名稱 場景業(yè)務及支配比例 測試指標 性能計數(shù)器 系統(tǒng) 用戶支配： 4 個 頁面 數(shù)據(jù)庫服務器常用性能計數(shù)器 應用 備件信息 100 響應 應用服務器 cpu 使用率 典型 申請單 100 時間 應用服務器內存使用率 場景 1備件查詢 100 小于 應用服務器 J

22、VM 可用內用戶增長模式： 10 秒 存 響應時間 ramp up, 每 15 秒增加 迭代時間間隔 30 秒 運行時間 30 分鐘 系統(tǒng) 用戶支配： 頁面 數(shù)據(jù)庫服務器常用性能計數(shù)器 應用 申請單 100 響應 應用服務器 cpu 使用率 應典型 審批 100 時間 用服務器內存使用率 應用場景 2仍庫 50 小于 服務器 JVM 可用內存 報廢 10 10 秒 響應時間 用戶增長模式： ramp up, 每 15 秒增加 4 個 迭代時間間隔 30 秒 運行時間 30 分鐘 系統(tǒng) 用戶支配： 4 個 頁面 數(shù)據(jù)庫服務器常用性能計數(shù)器 應用 申請單 100 響應 應用服務器 cpu 使用率

23、典型 審批 100 時間 應用服務器內存使用率 場景 3備件查詢 100 小于 應用服務器 JVM 可用內存 報廢 10 10 秒 響應時間 用戶增長模式： ramp up, 每 15 秒增加 迭代時間間隔 30 秒 運行時間 30 分鐘 穩(wěn)固 用戶支配： 頁面 數(shù)據(jù)庫服務器常用性能計數(shù)器 性測 典型場景 3 用戶數(shù) 響應 應用服務器 cpu 使用率 試場 的兩倍 時間 應用服務器內存使用率 景 備件查詢 100 小于 應用服務器 JVM 可用內運行時間 72 小時 10 秒 存 響應時間 數(shù)據(jù) 用戶支配： 4 個 頁面 數(shù)據(jù)庫服務器常用性能計數(shù)器 導入 導入 Excel 文件 申請單 100

24、 10 響應 應用服務器 cpu 使用率 應場景 時間 用服務器內存使用率 審批 100 10 秒 小于 應用服務器 JVM 可用內用戶增長模式： 存 ramp up, 每 15 秒增加 響應時間 迭代時間間隔 30 秒 運行時間 30 分鐘 3 測試用例設計 將用戶業(yè)務操作形成更具體的用例步驟； 審批業(yè)務： 用例編號： TC_xxxx_xxx-1用例條件：用戶已經(jīng)登錄,具有審批的權限用戶步驟和驗證方法： 1 ,用戶單擊“庫存流轉”鏈接,進入庫存流轉頁面 驗證：頁面顯現(xiàn)庫存流轉提示字符串 2 ,用戶在頁面左側樹試圖上單擊“審批”鏈接,進入審批頁面 驗證：頁面上顯現(xiàn)審批單：列表提示字符串 3 ,

25、用戶在頁面給出的等待審批的申請單列表中挑選最上方的一個,單擊審批按鈕,進入審批頁面 驗證：給出選中審批單信息,頁面上顯現(xiàn)被選中審批單的編號 4 ,用戶輸入審批信息,單擊通過按鈕 驗證：頁面上顯現(xiàn)審批通過提示字符串 4 腳本和幫忙工具開發(fā)活動； 5,測試執(zhí)行與治理 建立測試環(huán)境；部署測試腳本和測試場景；執(zhí)行測試和記錄結果； 第 5 頁,共 8 頁學習必備 歡迎下載 6,測試分析 依據(jù)測試的目的和目標給出測試結論； 軟件性能測試過程詳解與案例剖析學習筆記 20XX 年 10 月 20 日 星期二 13:39 11. RBI Rapid Bottleneck Identify 方法是一種用于快速識別

26、系統(tǒng) 性能瓶頸的方法；該方法基于以下一些事實： a. 發(fā)覺的 80%系統(tǒng)的性能瓶頸都由吞吐量制約； b. 并發(fā)用戶數(shù)和吞吐量瓶頸之間存在確定的關聯(lián)； c. 接受吞吐量測試可以更快速定位問題； RBI 方法第一拜望服務器上的“小頁面”和“簡潔應用”,從應用服務器,網(wǎng)絡等基礎的層次上明白系統(tǒng) 吞吐量表現(xiàn)；其次挑選不同的場景,設定不同的并發(fā)用戶數(shù),使其吞吐量保持基本一樣的增長趨勢,通過 不斷增加并發(fā)用戶數(shù)和吞吐量,觀看系統(tǒng)的性能表現(xiàn)； 在確定具體的性能瓶頸時, RBI 將性能瓶頸的定位依據(jù)一種“自上而下”的分析方式進行分析,第一確定 是由并發(fā)仍是由吞吐量引發(fā)的性能表現(xiàn)限制,然后從網(wǎng)絡,數(shù)據(jù)庫,應用服

27、務器和代碼本身 4 個環(huán)節(jié)確定 系統(tǒng)性能具體的瓶頸； RBI 方法在性能瓶頸的定位過程中能發(fā)揮良好的作用,其對性能分析和瓶頸定位的方法值得借鑒,但其也 不是完整的性能測試過程； PS:可以通過 RBI 測試,可以順便發(fā)覺當前系統(tǒng)所能承擔的最大并發(fā)用戶數(shù)和正確并發(fā)用戶數(shù)； 2. SEI 負載測試方案過程 SEI 負載測試方案過程（ SEI Load Testing Planning Process ）是一個關注于負載測試方案的方法,其目 標是產生 “清楚, 易懂得, 可驗證的負載測試方案” ；SEI 負載測試方案過程包括 6 個關注的區(qū)域 （Area ）： 目標,用戶,用例,生產環(huán)境,測試環(huán)境和

28、測試場景； SEI 負載測試方案過程將以上述 6 個區(qū)域作為負載測試方案需要重點關注和考慮的內容,其重點關注以下 幾個方面的內容： a. 生產環(huán)境與測試環(huán)境的不同：由于負載測試環(huán)境與實際的生產環(huán)境存在確定的差異,因此,在測試環(huán)境 上對應用系統(tǒng)進行的負載測試結果很可能不能精確反映該應用系統(tǒng)在生產環(huán)境上的實際性能表現(xiàn),為了規(guī) 避這個風險,必需認真設計測試環(huán)境； b. 用戶分析：用戶是對被測應用系統(tǒng)性能表現(xiàn)最關注和受影響最大的對象,因此,必需通過對用戶行為進 行分析,依據(jù)用戶行為模型建立用例和場景； c. 用例：用例是用戶使用某種次序和操作方式對業(yè)務過程進行實現(xiàn)的過程,對負載測試來說,用例的作用 主

29、要在于分析和分解出關鍵的業(yè)務,判定每個業(yè)務發(fā)生的頻度,業(yè)務顯現(xiàn)性能問題的風險等； 從 SEI 負載測試方案過程的描述中可以看到, SEI 負載測試方案過程給出了負載測試需要關注的重點區(qū)域, 但嚴格來說,其并不能被稱為具體的方法論,由于其僅僅給出了對測試方案過程的一些關注內容,而沒有 能夠形成實際的可操作的過程；同功能測試一樣,性能測試也必需經(jīng)受測試需求,測試設計,測試執(zhí)行, 測試分析等階段,但由于性能測試自身的特別性（例如,需要引入工具,分析階段相對重要）,性能測試 過程又不能完全套用功能測試過程； SEI 負載測試方案過程在負載測試需要關注的具體內容上供應了參考,但其并不是一個完整的測試過程

30、； PS:SEI 主要關注的是業(yè)務模型,用戶比例；建立相對真實的業(yè)務模型可以通過系統(tǒng)日志或者用戶調查來獲 得； 3. 性能下降曲線分析方法：四個區(qū)域 a. 單用戶區(qū)域 b. 性能平整區(qū) c. 壓力區(qū)域 d. 性能拐點 baseline benchmark 第 6 頁,共 8 頁4. 常用理論公式 = T session length / T think time 學習必備 歡迎下載 摸索時間 R request rate PS:在壓力測試的時候,一般不需要摸索時間,測試系統(tǒng)滿負荷的情形下所能支撐的用戶數(shù)； 在負載測試的時候,需要確定的摸索時間,來模擬真實的用戶體驗； 方法一： 并發(fā)數(shù) C co

31、ncurrent user = N user number * T session length / T total time concurrent user 最大并發(fā)數(shù)： Cmax concurrent user C concurrent user + 3 * sqrtC 方法二： 依據(jù) 原就,運算并發(fā)用戶數(shù)； 最大并發(fā)數(shù) = 并發(fā)數(shù) * r r, 23 方法三： 依據(jù)體會,始終有 10 %用戶始終作用于應用系統(tǒng)； 吞吐量 F = U average request number * C concurrent user F = N number user * R request rate / T total time PS: 相同的吞吐量下,并發(fā)用戶數(shù)不同可以得到不同的結果； 軟件性能測試過程詳解與案例剖析學習筆記 20XX 年 10 月 20 日 星期二 13:40 25. 性能調優(yōu)常見的錯誤 a. 數(shù)據(jù)庫記錄,每次做測試前后要保證數(shù)據(jù)量的一樣； 和.net 應用在使用前需要預熱； 6. 調優(yōu)標準過程 7. 穩(wěn)固性測試 MTBF 平均無故障時間,假如在 CPU 處于較大壓