前言：中文期刊網精心挑選了測試報告結論與建議范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
測試報告結論與建議范文1
【關鍵詞】配網故障搶修流程 監測 驗證 測試報告 時長
為了提高供電企業供電的安全性與可靠性，必須提高配網故障的搶修效率，是否能夠順利、高效地完成配網故障的搶修，直接反映出電力企業的服務水平。因此，監測配網故障搶修流程，可以促進制度落實、業務協同、流程優化和效率提升。
1 設計依據
公司依據配網故障搶修流程監測的業務設計說明，對其中涉及的《國家電網公司配網故障搶修管理規定》[國網（運檢/4）312-2014]、《國家電網公司電網調度控制管理通則》[國網（調/1）93-2014]、《國家電網公司95598故障報修處理規范》[國網（營銷/4）272-2014]進行核實。經驗證，其內容與設計說明文檔中設計依據的內容相符。
2 監測要素及監測維度情況
在與公司配網搶修指揮班溝通后了解到，按照省客服中心安排，現配網故障搶修流程中工單審核環節已經取消，地市配網搶修指揮班收到搶修班組的工單回復后直接向國網客服中心回復，因此建議取消對工單審核環節時長的監測。主要從配網故障搶修總時長及業務受理、接單派工、到達現場、故障處理、回訪歸檔5個關鍵環節時長開展業務驗證。
2.1 配網故障搶修總時長監測
共梳理相關數據字段10項，均為線上數據，涉及客服工單管控系統，包括：供電單位、工單編號，用戶名稱、聯系電話、電壓等級、故障報修類型、城鄉類別、故障處理部門、業務受理時間、回訪歸檔時間。驗證結論：經驗證，配網故障搶修總時長雖不能從工單管控系統中查出，但可通過數據字段業務受理時間和回訪歸檔時間計算得出。故涵蓋的10項數據字段可滿足配網故障搶修總時長監測要求。
2.2 關鍵環節時長監測
共梳理相關數據字段16項，均為線上數據，涉及客服工單管控系統，包括：供電單位、工單編號，用戶名稱、聯系電話、電壓等級、故障報修類型、城鄉類別、故障處理部門、業務受理時間、派發時間、接單派工時間（工單到達）、接單派工時間（處理時間）、到達現場時間、故障處理時間、回訪歸檔時間（工單到達）、回訪歸檔時間（處理時間）。驗證結論：經驗證，接單派工環節時長和工單回訪歸檔時長不能在工單管控系統中查出，但可從相關時間節點計算得出。通過對比其余主要環節時長與規定時長，可掌握制度執行情況。其他監測要素和監測維度基本滿足配網故障搶修流程關鍵環節時長監測業務的預期要求。
3 業務系統及數據支撐情況
依據已確定配網故障搶修總時長和關鍵環節時長兩個監測要素，對相關業務系統和業務數據支撐情況進行梳理，確定相關字段16項，均為線上數據，涉及客服工單管控系統。
3.1 業務系統支撐情況
配網故障搶修監測業務相關的16項線上數據，均可從客服工單管控系統中提取。經驗證，業務系統可滿足配網故障搶修監測業務的系統支撐。
3.2 數據支撐及數據質量情況
經驗證，線上16項數據中，10項數據（供電單位、工單編號、用戶名稱、聯系電話、電壓等級、故障報修類型、城鄉類別、故障處理部門、到達現場時長和故障處理時長）可通過系統直接提取。業務受理時間（工單到達、工單處理）接單派工時間（工單到達、工單處理）、回訪歸檔時間（工單到達、工單處理）系統中可提取數據，通過這幾項數據可計算得到配網故障搶修流程總時長、業務受理時長、接單派工時長、回訪歸檔時長。因此，16項線上數據可以滿足配網故障搶修監測業務的系統支撐。詳細數據支撐情況見附件二。
4 監測價值
按照業務設計確定的監測維度和要素，從國網銅川供電公司2016年4月份配網故障報修工單中按供電單位選取了18份工單，重點對各環節涉及數據準確性、完整性、可用性進行驗證分析。具體情況如下：
4.1 配網故障搶修總時長監測
因設計說明《國家電網公司95595故障報修處理規范》[國網（營銷/4）272-2014]中未涉及配網故障搶修總時長的時限要求，且配網故障搶修流程中的業務受理環節和審核歸檔環節為國網客服中心完成，時間不受地市公司支配，具有一定監測價值。業務受理環節時長監測：經驗證，18組數據的工單到達時間節點均與業務受理時間節點一致，在2分鐘的規定時限之內，有一定監測價值。
4.2 接單派工環節時長監測
通過客服工單管控系統導出的數據，接單派工環節時長包含工單到達時間和處理時間，可由這兩個時間節點計算出接單派工環節時長。經驗證，18份工單的接單派工環節平均時長為19秒，遠小于設計依據規定的3分鐘時限，表明地市配網搶修指揮班對國網工單的接收下達執行情況較好。從監測分析結論看，可促進配網故障搶修流程的優化和效率提升，具有較高監測價值。
4.3 到達現場環節時長監測
經驗證，將18份工單按照供電單位來分，印王分公司6份、耀州分公司6份、宜君分公司6份，分別計算每個單位的到達現場平均時長，印王分公司為17分41秒、耀州分公司為18分39秒、宜君分公司為16分52秒。對比三個單位的平均時長，可發現耀州分公司的6份工單中有5份為農村用戶，其到達現場平均時長最長，故到達現場時長受用戶地理位置影響。但搶修班組可通過建立有效的應急機制等途徑減少到達現場用時，因此監測到達現場環節時長具有較高價值。
4.4 故障處理環節時長監測
經驗證，故障處理環節時長受現場環境狀況、備品備件是否齊全、故障修復難易程度等因素影響。通過對比三個供電分公司的故障處理平均時長，可在不同單位間進行橫向比較，促進部門間的良性競爭，提高供電服務水平，因此監測價值較高。
4.5 回訪歸檔環節時長監測
通過客服工單管控系統導出的數據，接單派工環節時長包含工單到達時間和處理時間，可由這兩個時間節點計算出工單回訪歸檔環節時長。經驗證，18份工單的回訪歸檔環節時長均在規定時限內，但由于工單的回訪歸檔是由國網客服中心完成的，時間不受地市公司支配。因此對于地市公司來說，回訪歸檔環節時長具有一定監測價值。
5 結論
5.1 驗證結論
優化完善監測要素和監測維度。結合數據獲取和業務現狀，建議取消工單審核環節時長的監測。
5.2 分析結論
配網故障搶修流程的回訪歸檔時長受國網客服中心掌控，因此建議地市公司將監測重點放到接單派工環節時長、到達現場時長和故障處理環節時長上，其他項（配網故障搶修總時長、業務受理環節時長、回訪歸檔環節時長）作為一般關注。通過驗證，接單派工環節、到達現場環節和故障處理環節的用時均在設計依據的規定時限內，反映出公司對配網故障搶修相關制度標準執行情況較好，部門間工作流程流轉順暢。
參考文獻
[1]國家電網公司配網故障搶修管理規定[國網（運檢/4）312-2014.[Z].2014.
測試報告結論與建議范文2
關鍵詞：校園網綜合布線
校園網正逐漸成為各學校必備的信息基礎設施，其規模和應用水平將是衡量學校教學與科研綜合實力的一個重要標志。很多學校準備利用暑期組建校園網，特別是校園網基礎設施的鋪設更是難得的好時機。要想組建高性能、低成本的校園網，綜合布線的好壞至關重要好的綜合布線系統如同給校園網打了一個好的地基。
綜合布線目標
綜合布線系統是建筑物或建筑群內的傳輸網絡，是計算機網絡的線路基礎。它使語音與數據通信設備、交換設備和其他信息管理系統彼此相連，也使這些設備與外部通信網絡相連。結構化布線設計應該滿足以下目標。
1、滿足要求，兼顧發展布線設計必須能夠滿足學校各樓宇、實驗室、圖書館等的主要業務需求，并能兼顧未來的發展需要。
2、易于擴展，預留空間符合當前和以后的信息傳輸需要，保證較好的擴展性和足夠的升級空間。
3、遵從標準，采用星型布線系統設計遵從國際(ISO/IEC11801)標準和郵電部、建設部標準，布線系統采用國際標準建議的星型拓撲結構。
4、高質傳輸，適應面廣布線系統應該能夠支持語音、數據等綜合信息(如ISDN、B-ISDN、ATM等)的高質量傳輸，并能適應各種不同類型、不同廠商的電腦及網絡產品的需要。
5、統一出口，線路規范布線系統的信息出口采用國際標準的RJ-45插座，以統一的線路規格和設備接口，使任意信息點都能接插不同類型的終端設備，如電腦、打印機、網絡終端、電話機、傳真機等，以支持話音、數據、圖像及多媒體信息的傳輸。
6、預備互連、國際接軌布線系統符合綜合業務數據網ISDN的要求，以便與國內國際其他網絡互聯。
綜合布線原則及方式
1、性價比原則選擇的線纜、接插件、其他設備應具有良好的物理和電氣性能，而且價格適中；
2、實用性原則設計、選擇的系統應滿足用戶在現在和未來10至15年內對通信線路的要求；
3、靈活性原則做到信息口設備合理，可即插即用；
4、擴充性原則盡可能采用易于擴展的結構和接插件；
5、易管理原則便于管理，有統一標識，方便配線、跳線。
機房的布線系統直接影響到未來機房的功能，一般布線系統要求布線距離盡量短而整齊，排列有序。具體的方式有“田”字形和“井”字形兩種：“田”字形較適用于環形機房布局，“井”字形較適用于縱橫式機房布局，它的位置可安排在地板下，也可吊頂安裝，各有特點。
綜合布線要點
1、地板布線最常見的布線方式，充分利用了地板下的空間,要注意地板下的漏水、鼠害和散熱，還應保證在每個機柜下方開鑿相應的穿線孔(包括地板和線槽)。
2、吊頂布線特別適合于經常需要布線的機房，此方式中吊頂內包含了各種電源布線、弱電布線，在每個機柜上方開鑿相應的穿線孔(包括地板和線槽)，當然也要注意漏水、鼠害和散熱。具體布線的內容有：電源布線、弱電布線和接地布線。其中電源布線和弱電布線均放在金屬布線槽內，具體的金屬槽尺寸可根據線量的多少并考慮一定的發展余地(一般為100×50或50×50)。電源線槽和弱電線槽之間的距離應保持至少5厘米以上，不能互相穿越，以防止相互之間的電磁干擾。
(1)電源布線：在新機房裝修進行電源布線時，應根據整個機房的布局和UPS的容量來安排，在規劃中的每個機柜和設備附近，安排相應的電源插座，插座的容量應根據接入設備的功率來定，并留有一定的冗余，一般為10A或15A。電吹南呔隊Ω蕕繚床遄娜萘坎⒘粲幸歡ǖ娜萘俊?br>
(2)弱電布線：弱電布線中主要包括同軸細纜、五類網線和電話線等，布線時應注意在每個機柜、設備后面都要有相應的線纜，并應考慮以后的發展需要，各種線纜應分門別類用尼龍編織帶捆扎好。
3、接地布線由于新機房內部都是高性能的計算機和網絡設備，故對接地應有嚴格要求；接地也是消除公共阻抗、防止電容耦合干擾、保護設備和人員的安全、保證計算機系統穩定可靠運行的重要措施。在機房地板下應布置信號接地用的銅排，以供機房內各種接地需要，銅排再以專線方式接入該處的弱電信號接地系統。
4、綜合布線重點顯然，綜合布線重點就是“光纜”。很多校園網絡在園區架設或地埋室外多模光纖，為千兆網和ATM網絡打下了堅實的基礎，同時，提供了高帶寬(10Mbps~622Mbps)、高傳輸性、高抗干擾能力支持。光纜按芯數分為四芯、六芯、八芯三種；按鋪設方式分為架空、直埋兩種；按支持的距離分為多模(2公里以內)、單模(2公里到幾十公里)。其接續方式常見的是：熔接、研磨、壓接。常用的光纖產品有：光纜、光纖耦合器、光纖終端器、各種接口形式的光纖跳線、光纖接續設備。
綜合布線方案
以交換式千兆以太網作為校園網的主干，按10M/100M交換式子網方式接入(如圖)。校園網布線設計一般采用多級物理星型結構、點到點連接，任何一條線路故障均不影響其他線路的正常運行。網絡采用分散式三層交換體系，二級交換機具有第三級交換能力，主干線路壓力小，而且全部實現百兆交換入室。三級交換機可以堆疊，能將一個主干和桌面交換機組成一個整體，提供足夠的交換口，可擴展性好。
1、主干網選用千兆以太網，其第三層以太網路由器交換機大都滿足IEEE802.3Z標準，技術成熟，具有流量優先機制能有效保證多媒體傳輸時的QoS(QualityofService服務質量)。
2、千兆以太網具有良好的兼容性和可擴展性，在ATM技術成熟時，可平滑集成到ATM網絡中，作為ATM網的邊緣子網。
3、工作組子網可選用100M交換模式。使用戶終端獨占100M帶寬的數據交換。在核心交換機與工作組交換機之間，采用100Mbps傳輸帶寬，當使用全雙工時，傳輸帶寬為200Mbps。
綜合布線過程
1、布線前詢問客戶網絡需求，現場勘察建筑，根據建筑平面圖等資料結算線材的用量，信息插座的數目和機柜定位、數量，做出綜合布線調研報告。根據前期勘察數據做出布線材料預算表、工程進度安排表。
2、布線中協調施工隊與學校進行職責商談，提出布線許可，主要是鉆孔、走線、信息插座定位、機柜定位、做線纜標識等。安裝信息模塊、配線架及機柜內部。
3、測試線路測試是在完工后用專用儀器按EIA/TIATSB-67《非屏蔽雙絞線系統與性能驗收規范》對系統進行全面測試，并提交測試報告。信息點測試一般采用12點測試儀，主要測試通斷情況。深度測試用美國FlukeDSP-100線纜測試儀，根據TSB-67標準，對接線圖(WireMap)、長度(Length)、衰減量(Attenuation)、近端串擾(NEXT)、傳播延遲(PropagationDelay)五方面數據測試，可打印出詳細的測試報告。
4、布線后鏈路測試后，選擇若干節點，聯接網絡設備進行聯通測試并提交。施工后打印出測試報告，學校以測試報告為標準對整個布線作出判斷和結論。在施工質量達到合同要求、性能測試合格和軟件驗收合格的前提下，雙方簽字認定工程驗收合格。
(1)網絡硬件系統驗收：校方可以在線路測試和系統聯調階段派技術人員參加測試驗收。也可在施工方提交測試報告后，組織技術人員進行復測驗收。
(2)網絡軟件系統驗收：檢查應配置軟件是否齊全，并逐一進行操作檢驗。軟件應運行暢通，圓滿實現各種功能。
測試報告結論與建議范文3
【關鍵詞】工程勘察 報告編制
工程勘察報告是工程地質勘察的最終成果，是建筑地基基礎設計和施工的重要依據。報告是否正確反映工程地質條件和巖土工程特點，關系到工程設計和建筑施工能否安全可靠、措施得當、經濟合理。當然，不同的工程項目，不同的勘察階段，報告反映的內容和側重有所不同；有關規范、規程對報告的編寫也有相應的要求。下面著重談一談有關巖土工程勘察報告編寫工作中應注意的問題，且側重于詳細勘察階段。
1勘察附件
報告編制時往往不注重一些附件，缺少《任務委托書》、《室內巖土試驗報告》、《波速測試報告》等等。缺少任務委托書就意味著勘察時缺少工作依據，勘察工作中的擬建物的標高、基礎埋深、場地環境邊坡等均不能如實的反映，對勘察報告質量存在著重要的影響。
2工程勘察綱要
工程勘察綱要應在充分了解設計意圖、技術要求并經現場踏勘的基礎上編寫。工程勘察綱要中應明確執行的主要技術標準。根據重慶市地方標準涵蓋的建筑工程、市政工程、邊坡、特殊地基、地質災害勘察項目應首選重慶地方標準。關于技術標準選擇的順序：地方標準-行業標準-國家標準。勘察綱要中勘探點平面圖應布置貫穿場地的通長剖面，邊坡部分的剖面應垂直邊坡和沿邊坡支擋線布置，勘察范圍應大于用地范圍。
3勘察圖件
勘察圖件是勘察報告中重要的組成部分，主要有平面圖、剖面圖、柱狀圖和原位測試曲線圖等。鉆孔柱狀圖常常缺水位觀測日期或水位觀測日期與終孔日期相同。平面圖、剖面圖上缺用地范圍，地下室范圍標注不準確。剖面長度不足（特別是需進行穩定性計算的剖面）。平面圖、剖面圖成圖比例尺偏小。
4工程勘察等級劃分及勘察工作布置
勘察等級是確定勘察工作量的主要依據，應根據勘察規范結合場地情況綜合確定。因地質環境的差異，如重慶市地方標準DBJ50-043-2005與國家標準GB50021-2001（2009年版）在勘探點布置上的最大差異是地方標準的勘探點密而淺，國家標準的勘探點是稀而深。常見勘探點數量不足，特別是與場地同時進行勘察的環境邊坡部分，測試手段及工作量偏少等常見問題?？辈旃ぷ鲬搰@著“查明地質環境、強度巖土參數和對各類工程地質進行評價”進行。
5勘察文字成果報告
編寫勘察報告時不注重勘察文件編制深度的要求，達不到勘察深度的要求。根據平時重慶地區勘察報告編寫中存在的一些問題總結如下：
（1）勘察報告名稱中的“勘察階段”應與使用的技術標準中的稱謂一致，國標為“直接勘察”地標為“一次性詳細勘察”。
（2）前言中應明確任務來源、工程概況、目的、任務（往往任務部分很亂）、工作依據、執行的主要技術標準、工程勘察等級以及勘察工作布置和勘察工作質量評述等內容。
（3）地質環境敘述中，當存在溪、河時，一定要有重現期20年、50年的洪水位（必要時應有100年或歷史最高水位）。應準確、仔細描述結構面的結合程度及結構面類型。巖土分層不是地層巖性的描述、表述要準確；如部分“坡度”應為“坡角”、地層單位的“段”代表一定地質時期的一套沉積物與單一巖性層是不同的；地層代號的上下角標要清楚；填土除一般描述外，尚應描述填土成分、填土方式、填土時間等；工程勘察中應盡可能的采集水樣進行水質分析。
（4）地震效應評價應盡可能進行巖土層的剪切波速測試，以利場地類別的劃分。應注意區分Ⅰ0、Ⅰ1場地土和Ⅱ場地土、一般地段和不利地段。對于抗震重點設防及其以上的勘察項目，應實測剪切波速。《建筑工程抗震設防分類標準》GB 50223-2008第5.1.3條“給水建筑工程中，20萬人口以上城鎮、抗震設防烈度為7度及其以上的縣及縣級市的主要取水設施和輸水管線、水質凈化處理廠的主要水處理建（構）筑物、配水井、送水泵房、中控室、化驗室等，抗震設防類別應劃為重點設防類。
（5）巖土參數統計國家標準GB50021-2001（2009年版）按置信度0.95進行統計；重慶地方標準DBJ50-043-2005第L.0.2條按不同的工程安全等級分別選擇0.90（三級）、0.95（二級）、0.975（一級）。統計表中應有指標的平均值、范圍值、標準差、變異系數和標準值。采用重慶市地方標準時所有指標均應統計到標準值（DBJ50-043-2005第9.2.1條）。
統計時應注意：當指標作為作用項時取“+號”，作為抗力項時取“-”；指標分為實測和計算兩類。計算指標平均值和標準值是通過計算確定的。指標的單位應書寫正確，如KN、MPa、MN/m3、MN/m4等。
統計的數據量必須滿足數理統計最小數據量要求。當抗剪強度指標數據量不足時，不能直接以平均值作為標準值，應結合地區經驗綜合確定。粘聚力с、內摩擦角φ的確定原則：“宏觀判斷為前提，測試成果是基礎，工程經驗作參考，反演分析作校核?！苯Y構面c、φ采用查表確定時，常常是取值與描述不一致。
GB50021-2001（2009年版）采用飽和單軸抗壓強度確定巖體基本質量等級，而DBJ50-043-2005采用天然單軸抗壓強度確定巖體基本質量等級。
（6）穩定性評價：斜（邊）坡除應有基本特征（高度、長度、坡角、邊坡類別等）的描述外，應對斜（邊）坡進行穩定性評價。穩定性評價分為：定性評價和定量評價（含定量計算和粗略定量）。對于巖質斜（邊）坡定性評價一般通過極射赤平投影，應包括結構面與邊坡的關系，對邊坡整體穩定性的影響、邊坡可能破壞模式、邊坡工程安全等級、邊坡巖體類型、巖體等效內摩擦角；定量評價要明確計算工況、計算模式、計算參數；注意計算結果應與宏觀判斷進行比較；要確定穩定安全系數（特別不同的規范是有差別的）。常見問題：①條塊劃分過少，且不合理（沒考慮特征水位）；②當采用折線法時，FS≤1.05地表出現裂縫，宏觀判斷處于強變形階段，而第1條塊抗力大于下滑力；③未區分條塊所處位置的不同，采用不同的с、φ。
（7）進行地基均勻性評價、地基承載力評價時國標、行標與地標的區別。
（8）持力層的選擇和基礎型式建議：當有可能采用樁基礎時，應評價成樁可能性和論證樁基礎施工條件及其對環境的影響。當存在尚未完成沉降變形的新填土時，應提供填土的負摩阻力系數。
（9）道路勘察、室外管道勘察：應區別道路和公路；線狀工程應分段進行工程地質評價（有條件是應分工點進行勘察評價）；勘探工作量普遍偏少（特別是高邊坡部分）。
（10）結論中應明確提出使用本次勘察報告的范圍，如初步勘察階段的勘察報告，只能用于初步設計，一期工程的勘察文件不能直接用于二期工程。應注意當邊坡地段存在平緩外傾層面時，宜提出以下建議 ：鑒于一些工程的經驗教訓，應避免雨季爆破施工；當不能避免時，應注意預留1.0m以上厚度巖體采用人工剔打，同時作好地表水和地下水的截導排等處理措施。
工程勘察報告是建筑地基基礎設計和施工的重要依據，在編制過程中應盡量避免產生以上一些不必要錯誤。
參考文獻：
[1] 《巖土工程勘察規范》（GB50021-2001）2009年版；
測試報告結論與建議范文4
1 火電廠能源審計技術和方法
在實踐中,各類學科都在發展自己的方法,逐步建立和完善適合于本學科的認識和研究方法體系?；鹆Πl電廠能源審計是一門新興的交叉學科,也需要建立系統完整的評價指標和研究方法體系。根據《熱力發電廠》和《審計學》的原理,火力發電廠能源審計可以描述為:火力發電廠能源審計是依據國家有關的節能法規和標準,應用熱力發電廠原理和審計學方法,對火力發電廠的能源轉換和利用的物理過程、財務過程和管理過程的合理性、合規性、經濟性和潛力進行調查、分析和評價,屬于技術性專項審計。
從傳統審計學角度,審計方法是實施審計工作的模式、程序、手續、措施和手段的總和,涵蓋了審計管理方法、審計取證方法和取證的技術手段?；鹆Πl電廠能源審計在審計分類上屬于企業內部審計,在審計性質上屬于技術審計的范疇,是傳統審計科學的工程化,見圖1。
研究火力發電廠能源審計的方法論體系必須注重能源審計的實務和操作性。在火電廠能源審計的實務工作中,從火力發電廠的能源轉換和利用的物理過程、財務過程和管理過程3個方面切入,可以把火電廠能源審計方法具體分為:考察物理過程,依托熱量法、作功能力法等以技術為基礎的熱力學方法;考察財務過程,依托以賬戶為基礎的會計系統的審閱法、核對法等會計學方法;考察管理過程,依托以制度為基礎的內部控制檢查法、對比法等管理學方法。
2 火電廠能源審計程序及內容
2.1 火電廠能源審計程序
審計學認為,審計程序是確定審計方法的前提,是使審計工作能夠按照科學合理的軌跡有序運轉的保證。只有先確定出科學、合理和規范的程序,審計人員才能選定適用的審計方法,高效地實施審計和實現審計目標。不同類型的審計有不同的審計程序。研究審計程序需要解決3個問題:審計程序的一般規律、影響審計程序制定的制約因素和不同類型審計程序的特點?；鹆Πl電廠能源審計主要運用審計學中關于行業審計與專項審計的基礎審計理?；鹆Πl電廠能源審計主要運用審計學中關于行業審計與專項審計的基礎審計理論,對火力發電廠能源轉換和利用的專門事項開展節能分析工作?；鹆Πl電廠能源審計根據審計目標不同,可分為初步能源審計、重點能源審計和詳細能源審計3類;根據審計實施主體不同,分為實施基本項的企業內部能源審計、實施規定項的社會(行業)能源審計、實施選擇項的政府能源審計3級。綜合有關能源審計的研究成果,雖然火力發電廠能源審計有不同類型和分級要求,相應的審計程序會有差異,但也有共同的步驟,可以歸納為l2個環節,詳見火力發電廠能源審計程序,如圖2所示。
2.2 火電廠能源審計內容
針對上文所述,火電廠能源審計關注的是火力發電廠能源轉換以及利用的物理過程、財務過程和管理過程的合理性、合規性、經濟性和潛力等目標,應用熱力發電廠、審計學等原理分析其合理性;根據與節能減排相關的法律規定、政府監管機構制定的監管規則、行業標準化中心制定的行業導則以及各大發電集團制定的內部規章制度等考察其合規性;評價其用較少的投入獲得較大的成果帶來的經濟性;分析存在于企業內部不容易發現或發覺的能力,挖掘其潛力,構成火電廠能源審計實務的核心內容?；痣姀S能源審計實務具體包括:
(1)立項。包括確定火力發電廠能源審計任務;擬定火力發電廠能源審計工作計劃;成員組成和分工;必需的設備與儀器等技術條件。
(2)數據采集。確定火力發電廠原則性熱力系統及測點;火力發電廠能量平衡方框圖、能流圖的計算及其數據采集;查閱能源數據臺賬、主要參數報表和有關數據信息。
(3)調查測試?；鹆Πl電廠能源審計調查大綱;火力發電廠的用能概況、能源管理現狀;必要的能源檢測以及確定重點等。
(4)能量平衡計算。火力發電廠的能源計量及統計狀況;火力發電廠能源消費指標(如供電煤耗率、水耗率等)計算分析;火力發電廠能量平衡和分析。
(5)能源物理過程分析。鍋爐熱力系統、管道熱力系統、汽輪發電機組熱力系統和輔助生產系統的能量平衡分析;主要設備或系統的運行經濟性分析。
(6)能源財務過程分析?；鹆Πl電廠能源成本指標計算分析;火力發電廠電、熱產品財務成本指標分析;火力發電廠能源消耗、價格、成本數據核定,以及小機組發電量指標交易補償的節能量等。
(7)能源管理過程分析。按國家或行業標準檢查能源管理、計量、統計等的合規性。通過火電力發廠節能潛力的計算分析,與國內外同類型電廠的先進水平作對比,改進能源管理,完善內部控制,提高技術維護水平,健全管理制度。
(8)能源審計報告。提出火力發電廠能源審計報告是本項工作的標志性成果,要按照規定格式編寫火力發電廠能源審計報告,主要內容有能源審計概況、依據、結論、決定、從管理和技術途徑提出建議以及必要的附件說明。
(9)制定整改措施。根據火力發電廠能源審計報告提出的意見和建議,制定整改措施。
(10)無/低成本項目。通過能源審計,可以確定的無成本/低成本節能技術項目優先實施,有的應該即知即改。
(11)重大項目?；鹆Πl電廠重大節能技術改造項目是節能的根本措施,要進行可行性分析、環評分析以及提出進度表等。
(12)能源審計回訪。為保證能源審計效果,檢查和回訪火力發電廠能源審計報告的落實情況是必要的,可以參照后續審計的準則進行。火力發電廠能源審計工作的質量取決于能源審計工作底稿的質量。根據中國內部審計協會2003年6月的內部審計基本準則第4號關于審計工作底稿的定義,能源審計工作底稿應該是審計過程中形成的工作記錄,是聯系審計證據和審計結論的橋梁。火力發電廠能源審計底稿類似于節能減排專項工作的熱力計算書、調研分析報告、熱力測試報告等,是火力發電廠能源審計工作報告的基礎。
3 火電廠能源審計報告體系
一般審計方法是在審計過程中,審計人員根據所確定的審計目標和可支配的審計資源,針對具體的審計事項取得具有充分證明力的審計證據,依據審計證據去證實審計事項與審計依據的相符程度,就審計事項的性質作出審計結論,并將審計結果傳達給企業?；痣姀S能源審計是針對火力發電廠生產過程的經濟運行水平、能源管理現狀以及節能潛力分析所開展的專門檢查和評價。根據火電廠能源審計任務,運用國家或行業相關標準,獲取在火電廠能源審計規定期限內相關的技術數據、文本文件,或進行必要的檢測,可以通過“三圖三表一報告”技術分析體系,實現火電廠能源審計目標。“三圖三表一報告”是開展火電廠能源審計的簡捷評價方法和實現途徑。具體為,繪制火力發電廠熱力系統圖、火力發電廠能量平衡方框圖、火力發電廠能流圖;編制火力發電廠能源統計表、火力發電廠能量平衡表、火力發電廠能源財務分析表以及火力發電廠能源審計報告。
(1)火力發電廠熱力系統圖是熱力發電廠實現熱功轉換熱力部分的工藝過程圖,有原則性和全面性之分?；痣姀S能源審計以全廠原則性熱力系統圖為基礎,相應的火力發電廠能量平衡方框圖為依據,完成火力發電廠能源統計表、火力發電廠能量平衡表以及火力發電廠能源財務分析表的編制,計算并繪制火力發電廠能流圖,最終完成火力發電廠能源審計報告。
(2)火力發電廠能量平衡方框圖。清晰、簡明地表示火力發電廠生產過程,繪制熱平衡、電平衡、水平衡方框圖,或能源審計期限內的能源平衡網絡圖。
(3)火力發電廠能流圖。根據熱力發電廠原理,通過計算,繪制出與動力循環能量轉換、傳遞和利用物理過程一致的火力發電廠熱流圖和質流圖。
(4)火力發電廠能源統計表。能源統計是開展火力發電廠能源審計的基礎性工作,按照統計學原理,圍繞火力發電廠能源審計任務,設計統計指標體系,按能耗分類采集數據,確定能量單位及其換算方法,編制火力發電廠能源統計表。
(5)火力發電廠能量平衡表?；鹆Πl電廠能量平衡是以火力發電廠為對象,研究各類設備的能源收入與支出平衡、消耗與利用以及損失的數量平衡,并進行定性與定量分析,依據DL/T606《火力發電廠能量平衡導則》的規定設計表格,進行熱平衡、電平衡、水平衡計算與分析,計算技術經濟指標,編制能量平衡表。
(6)火力發電廠能源財務分析表。根據會計學原理,火力發電廠能源財務分析是關于火力發電廠能源管理、電量和熱量交易及其資金流的收支平衡和計算的事務。設計的能源財務分析表要包含購入能源消耗(實物)費用、產值能耗及能源成本分析、企業自用能源費用、能源單價以企業平均結算價計算等內容。
(7)火力發電廠能源審計報告?；鹆Πl電廠能源審計報告的主要內容有,火電企業能源管理、能源統計的體系和制度;火電企業節能管理與技術措施;能源利用效果評價,存在的主要問題及節能潛力分析,節能技術改造的財務分析和合理化建議等。火力發電廠能源審計,要盡可能利用電力企業已有的相關數字化技術平臺實現計算機能源審計。
測試報告結論與建議范文5
關鍵詞：深埋隧道；地應力；巖爆
Abstract: in order to avoid the ping of buried deep in the tunnel on the area there exist high geostress may cause brittle surrounding rock produce rock burst, based on the qualitative determination, water pressure of stress method of crack the measured results, and use the hou shine once, and put forward the ground stress the occurrence of critical conditions rockburst comprehensive analysis, it is concluded that the SuiDaoJu would produce the ping of rock burst conclusion.
Keywords: deep tunnel; Ground stress; Rock burst
中圖分類號：U452.1+2 文獻標識碼：A 文章編號：
深埋隧道圍巖中的高地應力可能引起脆性圍巖產生巖爆，而造成開挖工作面破壞、設備損壞或人員傷亡。本文運用定性分析結合定量計算，探討了上坪隧道發生巖爆的可能性。
1、工程概況
上坪隧道為大慶至廣州高速公路粵境連平至從化段D1合同段最長的隧道，位于廣東省連平縣境內。隧道穿越九連山支脈，地貌類型屬中低山地貌，山體植被茂密，隧址區地面標高320.0~706.8m。隧道為分離式，左線隧道起迄里程ZK17+403～ZK20+890，長3487m，右線隧道起迄里程YK17+399～YK20+977，長3578m。隧道最大埋深365.1m。隧道走向北西向。屬公路深埋特長隧道。
2、工程地質條件
2.1地層巖性
根據鉆探、調繪資料，隧道深埋段的地層巖性主要為侏羅系吉嶺灣組火山角礫巖頂蓋，下伏為白堊系丹霞組礫巖、砂巖等，底部為石炭系測水組灰巖，北西側為寒武系高灘組變質砂巖，呈平行不整合與灰巖接觸。
2.2地質構造
隧道深埋段以外的北西側山溝發育推測F9斷裂，經過路線K19+800附近，順溝谷發育，控制地貌，斷裂走向北東，在斷裂帶上地層巖石硅化強烈，并有揉皺、撓曲，推測與隧道相交。
2.3水文地質
深埋段地下水類型以基巖裂隙水為主，主要賦存于開放性的節理、裂隙中，分布極不均勻，含水量小。此外不排除下伏灰巖有溶蝕裂隙水或巖溶水存在的可能。地下水以大氣降水入滲、溪流及側向逕流方式接受補給，以蒸發、下降泉、側向逕流方式排泄。
3、地應力判定
3.1定性判定
初勘階段未進行隧道深孔勘探及地應力測試，根據彈性理論進行高地應力的初步判定。判別模型如下：
a、垂直向主應力按上覆巖體的重力計算，σv=γH，圍巖重度γ取26.5kN/m3；
b、圍巖側壓系數λ1= SH max/ Sv取經驗值1.2；
c、根據隧道埋深H處垂直向主應力σv，圍巖側壓系數λ1，計算得深度H處最大水平應力σmax=λ1*σv。
d、隧道開挖影響范圍段微風化灰巖單軸飽和抗壓強度48.9~94.8MPa，標準值為Rc=62.4MPa，屬于硬質巖，按公路隧道設計規范計算得Rc/σmax，當Rc/σmax7時將無巖爆發生。
判別結果：當埋深H 為280.3m~365.1（最大埋深）時，Rc/σmax=5.4~7.0，埋深280.3m為低應力與高應力的臨界深度，埋深小于280.3m為低應力區，埋深大于280.3m為高應力區。
根據計算結果初步得出圍巖高地應力區的范圍，該范圍圍巖存在應力集中現象，有巖爆發生的可能。
3.2水壓致裂法判定
詳勘階段，結合洞身XSZK12號鉆孔進行了地應力測試。XSZK12號鉆孔孔口標高為639.20m，該位置路面設計標高為328.53m，兩者高差為310.7m，故隧道開挖影響圍巖范圍主要在孔深285~315m之間，取該影響范圍內的295.24~296.04m測試段及304.90~305.70m測試段進行分析，取得的試驗成果如下表所示：
上坪隧道XSZK12號鉆孔地應力測試成果表表1
序號 測段深度(m) 壓裂參數(MPa) 主應力值(MPa) 破裂方向 (°) 主應力方向優勢方位(°) 主應力方向與路線夾角 (°) 計算孔壁最大切應力值(MPa)
Pb Pr Ps PH P0 T SH Sh Sv max
1 295.24
~296.04 11.39 6.39 6.39 2.89 1.3 5 11.48 6.39 7.66 N52E N55E 14° 16.29
2 304.90
~305.70 11.49 7.49 6.99 2.99 1.39 3.5 12.09 6.99 7.91 N68E N55E 14° 16.47
注：Pb巖石原位破裂壓力；Pr 破裂重張壓力；Ps瞬時閉合壓力；PH 試段深度上的水柱壓力；
P0試段深度上的孔隙壓力；T 巖石抗拉強度；SH最大水平主應力；Sh 最小水平主應力；
Sv用上覆巖層(重度26.5 kN/m3)重量估算的垂直應力；孔深為317.40m，測試時靜水位約為163.0m。
4、巖爆分析
目前隧道工程常用的兩種巖爆判據方法，多以應力分析為基礎，結合大量工程經驗，歸納出圍巖應力與巖石單軸抗壓強度的關系，即發生巖爆的臨界判據。
4. 1侯發亮教授等提出的臨界判據：
侯教授等人在前人研究的基礎上，提出了發生巖爆的洞壁切向臨界應力與巖石單軸抗壓強度的關系式：
lcr(0.188~0.402)c
其中，lcr為發生巖爆的圍巖切向臨界應力，c為圍巖的單軸抗壓強度，式中括號內的系數值需要根據圍巖應力的組合狀態而定，即取決于隧洞軸線截面內的最小與最大主應力值3、1之比。3/1在不同圍巖應力狀態下發生巖爆的臨界應力lcr公式為：
A狀態3/1＝0.00, lcr=0.188c
B狀態3/1＝0.25, lcr=0.294c；
C狀態3/1＝0.50, lcr=0.360c；
D狀態3/1＝0.75, lcr=0.383c；
E狀態3/1＝1.00, lcr=0.402c；
由以上判斷依據，根據測試成果獲取的SH、Sv及Sh值（SH>Sv>Sh），可計算出隧道開挖影響范圍段巖體發生巖爆的臨界應力，如下表所示：
發生巖爆的臨界應力判別表 表2
序號 測段深度 主應力值(MPa) σ1取值 σ3取值 σ3/σ1 對應狀態 σc σlcr
(m) SH Sh Sv MPa MPa
1 295.24~296.04 11.48 6.39 7.66 11.48 6.39 0.56 C 48.90
~94.80 17.60
~34.13
2 304.90~305.70 12.09 6.99 7.91 12.09 6.99 0.58 C
注：巖樣單軸飽和抗壓強度σc取試驗段附近的灰巖強度，范圍為48.90~94.80MPa。
由以上判別表可知，發生巖爆的臨界應力lcr =17.60~34.13MPa，經分析計算得知該段圍巖開挖孔壁上的最大切向應力max =16.29~16.47MPa。兩者比較孔壁上圍巖的最大切向應力均小于發生巖爆的臨界應力，故XSZK12孔區開挖圍巖不存在巖爆發生的可能。
4.2 切向應力準則：
切向應力準則首先由挪威學者巴頓提出，并經過演化改進。該準則將圍巖的切向應力θ與巖石的抗壓強度c之比作為判斷有無巖爆及發生巖爆等級劃分的原則。有關研究表明：
θ/c 0.3無巖爆活動
θ/c介于0.3~0.5間輕微巖爆
θ/c介于0.5~0.7間中等巖爆
θ/c 0.7強烈巖爆
根據地應力測試計算出的該段圍巖開挖孔壁上的最大切向應力max =16.29~16.47MPa，隧道開挖影響范圍段微風化灰巖單軸飽和抗壓強度c =48.9~94.8MPa，計算結果θ/c =0.17~0.34，按發生巖爆的臨界條件判斷，XSZK12孔區開挖的局部圍巖存在輕微巖爆發生的可能。
4.3 根據線性回歸公式對最大埋深處洞體開挖巖爆的預測：
根據最大主應力、最小主應力及水平主應力在鉆孔深度上增加而逐漸增大的規律，推算出主應力隨深度分布的線性回歸計算公式為：最大主應力SH = 0.037H +0.65；最小主應力Sh = 0.025H-0.68；垂直應力SV= 0.026H。
由此可計算出最大埋深365.1m處max =19.70MPa，lcr=18.1~35.1m，max>lcrmin，圍巖會局部產生巖爆，又θmax/c=0.2~0.4，巖爆級別介于不發生~輕微之間。
5、結論與建議
1、目前對于巖爆的眾多研究中存在許多理論和判別巖爆條件，每種理論與判別方法都是側重于巖爆的某方面條件而提出的。通過本文運用的兩種分析方法，按對工程最不利的可能性進行判別，可得出結論：高應力區的圍巖，巖爆局部發生，發生的級別為輕微。
2、巖爆的發生原因較復雜，和巖石的結構、構造、完整性、賦水性緊密相關。初勘定性判別在沒有進行地應力測試的情況下，對構造、節理裂隙及地下水的分析與詳勘鉆探、地應力測試的實際結果有一定出入。故在條件允許的情況下，深埋特長隧道應開展地應力測試，以獲取較為準確的原始圍巖應力狀態的數據。
3、由于隧道長，各路段的地質情況也存在差異性，隧道上覆地形地貌起伏較大的地段、坡角部位有可能存在應力集中，對于斷裂帶、裂隙發育的路段，存在斷面收斂變形以致片幫或冒頂的可能，建議在開挖隧道過程中采取相應的預防措施。
參考文獻
[1] 廣東省公路勘察規劃設計院股份有限公司.大慶至廣州高速公路粵境連平至從化段D1合同段施工圖設計階段工程地質勘察報告（第S4合同段）[R].廣州，2011
[2] 中國地震局地殼應力研究所.大慶至廣州高速公路粵境連平至從化段上坪隧道XSZK12孔水壓致裂法地應力專項測試報告[R]. 2011
[3] 交通部.公路隧道設計規范(JTG D70－2004)[S].北京: 人民交通出版社,2004：74,248-249
[4] 交通部.公路隧道設計細則(JTG/T D70－2010)[S].北京: 人民交通出版社,2010：168-172
測試報告結論與建議范文6
關鍵詞：性能測試；管道；多線程
中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2011)04-0809-04
The Development and Research On Apache Performance Testing Tools
DENG Jing1, ZHANG Hai-quan2, WANG Zhi-jian3
(1.Dept. of Computer Engineering, Nanjing Institute of Technology, Nanjing 211167, China; 2.Dept. of Computer Engineering, Hohai University, Nanjing 210024, China)
Abstract: In this paper, based on analyzing of ApacheBench, we used the CMMI 3 software development methods, make use of multi-threaded to simulate multiple users to achieve a number of concurrent user testing, use pipe technology on a number of thread operation, and realize the sharing of data. Design a new test instrument. It can be achieved in line with the HTTP protocol on the performance of thewebsite for testing.
Key words: performance testing; pipe; multi-threaded
隨著互聯網的迅猛發展和用戶數的不斷增加，作為互聯網應用之一的WEB服務也扮演著越來越重要的角色。提供WEB服務的站點和服務器必須具有良好的性能和快速的事務處理能力。為此，在WEB應用系統開發過程中和WEB應用軟件部署過程中，對其進行性能測試，找出性能上的缺陷，定位問題，解決問題，也是相當重要的一個環節。性能測試是通過記錄和描述真實用戶的行為，用一種自動、可控的方式重復執行這些用戶的行為，得到應用系統運行相關數據的過程。目前，國內外對 Web 應用軟件的測試進行了一系列研究，在基本測試技術、測試模型和測試工具開發等方面取得了具有價值的研究成果。其中AB（ApacheBench）是Apache自帶的超文本傳輸協議（HTTP）性能測試工具。其設計意圖是描繪當前安裝的Apache的執行性能，幫助我們在網站開發期間仿真實際上線的可能情況，利用仿真出來的數據作為調整服務器或程序的依據。在實際應用中， ApacheBench 程序中存在很多不足和缺陷。如：用戶需要花費很多時間來學習使用AB，測試數據的非漢化，測試數據的不全面，對命令行參數、服務器的響應頭和其他外部輸入的解析也簡單。另外沒有完整實現HTTP/1.x，僅接受某些“預想”的響應格式，Strstr（）的頻繁使用可能會帶來性能問題，即你可能是在測試AB而不是服務器性能等等。針對以上問題，在Apache上基于AB系統設計開發一種新的性能測試工具勢在必行。利用多線程技術實現多用戶并發，采用管道技術實現對數據的共享。設計并實現一個新的系統，可以很好的對網站進行性能測試。
1 系統功能
WEB性能測試工具通過記錄用戶操作并把它們與腳本語言相結合來生成測試腳本，并能產生多個線程，每個線程運行一個特定的測試腳本或場景，以模擬發送到服務器的真實請求。進行性能分析時，可以跟蹤性能度量結果（如響應時間和數據吞吐量），并且用表格和圖形格式生成報告，根據報告系統自動給出性能優化建議。
整個系統是在 ApacheBench 的原型下進行的改進，目的是為了提供更加方便、有效的性能測試工具。因此，系統設計應該考慮如下幾點：
1）易用性：系統界面簡潔，明確。用戶不需要經過復雜的軟件配置和操作流程，只要簡單的操作就能獲得用戶想要的數據。
2）直觀性：系統能夠在運行后，直接查看到數據。用戶可以通過不同的測試數據得出被測服務器的性能情況，承受壓力的能力等。
3）可控性：系統應該能夠根據實際情況，給出異常報告。在模擬多用戶進行測試過程中，發送的請求頻率、數據、持續增壓都在可控制范圍內。
WEB性能測試系統的功能分為兩部分：系統測試部分和數據處理部分，如圖1。
系統測試模塊中又分為測試參數、配置參數、Socket池、線程池、測試、控制和管道等模塊。參數模塊用于配置測試時用戶所需要的參數內容，包括模擬用戶數量、并發用戶數等內容?？刂颇K在測試過程中根據測試參數來控制整個過程。Socket 池是提供多個Socket 連接池的功能模塊，Socket 池的大小由模擬的用戶數量、請求遠程服務器IP 地址數、端口號數決定。使用Socket 池目的是提高測試速度和效率。線程池是用于存放線程的地方，在測試過程中，利用一個線程來模擬一個瀏覽器用戶。使用線程池的目的是提高系統利用率，實現程序的大量并發處理，避免因頻繁地創建、銷毀線程而降低系統的效率。測試模塊是利用系統中提供的Socket 和線程，按照測試參數將測試腳本發送到Web 服務器，同時將Web 服務器的響應結果記錄下來，生成數據內容，顯示在報告中。測試過程的控制由控制模塊負責。
數據分析模塊部分包括數據分析模塊、文本結果模塊、生成報告模塊。數據分析模塊是對測試數據進行判斷、計算、比較和綜合分析，得出測試結果。文本結果模塊是將整個數據分析結果以文本的形式保存下來進行比較。生成報告模塊是根據測試數據結果和推理規則而生成測試報告和優化建議。
2 系統設計
2.1 系統需求設計
以系統功能需求描述為依據，建立系統業務模型。按照RUP的思想， 用Use Case 對象來描述系統的功能需求。以選定的Use Case 作為研究對象，用面向對象的概念和方法對問題進行轉述，為后續進一步的設計活動提供必要的鋪墊。用Use Case 為對象描敘測試系統的功能需求用例圖如圖2所示。用例圖中的每個Use Case 表示實現特定功能的用例。根據系統的業務邏輯模型，在各個Use Case 用例之間建立某種關系，包括包含、擴展關系。用戶（Actor）通過配置腳本文件、服務設置請求、配置測試參數、分析數據等作用于系統。HTTP 捕捉測試信息，經過處理生成測試腳本。系統中的核心用例“測試”用例是根據測試計劃來對服務器進行測試，并生成測試數據。用戶依據測試數據進行分析，對整個服務器性能做出描述。
2.2 系統流程設計
使用用例圖對系統功能需求進行描述，是從系統的業務邏輯模型和關聯關系角度展開。這里從數據流的角度出發，詳細分析系統各個模型間的業務關系和關聯關系，建立系統的數據流程圖。系統數據流程圖如圖3所示。
首先用戶將瀏覽器設置指定的服務器來訪問Internet，當用戶訪問Web 服務器時，將HTTP 請求發送到服務器，解析請求的目的IP 和Port，并與目的IP 建立Socket 連接，將瀏覽器發來的請求轉發到Web 服務器，同時將全部請求傳遞給解析器。解析器把接收的字節流轉換成字符流并對其解析，分析提取HTTP 請求和每個請求中的各個域值，同時將每個請求創建一個請求對象，并傳遞給測試腳本。測試腳本存放請求對象集合并負責處理。以上過程完成系統的測試腳本分析功能。
用戶界面負責接收用戶輸入的數據和響應用戶操作，輸入數據包括待測Web 的URL、并發數、模擬用戶數等數據。用戶輸入的數據作為參數傳遞到參數數據組件中，參數數據組件將參數傳遞到控制中心。控制中心根據測試參數和測試腳本中傳入的測試對象集來創建Socket 連接池和線程池。Socket 連接池的大小和每個Socket 連接由測試對象集和線程數決定。線程池的大小由線程組屬性參數決定?？刂浦行目刂普麄€測試過程，是系統的核心部分，負責控制測試模塊來模擬真實用戶行為，啟動和調度每個測試線程，并為每個測試線程分配Socket 連接。
測試組件是系統的核心組件，由線程加載并執行。測試組件在執行過程中啟動兩個子線程。這兩個子線程分別執行發送請求和接收響應。發送請求組件從測試組件傳遞的Socket連接中取得輸出流對象，并將請求對象集以字節流的形式發送到WEB服務器。接收響應組件在指定的Socket連接上接收HTTP響應的數據流，利用輸入流對象接收數據。同時接收響應組件負責對響應信息的HTTP頭進行解析，設過程響應對象，并對對象中ID、線程、時間戳屬性賦值，最后將響應對象傳遞給測試數據組件。
測試數據組件中可以將測試結果以文本的方式保存下來。我們可以對測試結果對象集進行統計、計算、分析，并生成對 Web 系統測試的圖形結果，給出系統的優化建議。
2.3 系統詳細設計
在系統設計任務中，按照如下三個步驟展開：
1）提取分析類。根據對Web性能測試系統的用例分析，獲得測試系統活動的“關鍵抽象”以及特定的Use Case 的文字內容。從不同角度抽取那些能夠協作完成Use Case行為的分析類。分析類可以形象理解為“點”的集合。
2）轉述需求場景。用分析類的實例作為行為的載體，通過消息傳遞的方式實現對UseCase 場景的分解。系統數據流程圖中的數據流轉化為消息，用順序圖分析說明系統需求和系統活動流程。
3）整理分析類。根據分析類的實例在Use Case 需求場景中的消息傳遞關系，歸納分析類所承擔的“責任”和分析類之間的“關系”，用參與類圖來說明分析結果。對分析類的責任和關系的描述，可以形象地理解為一個面。
通過以上三個步驟，系統中的需求用例圖和數據流程圖轉換為順序圖和協作圖，按照分析類的關聯關系，將分析類繪制成“參與類圖”，并根據分析類所承擔的“責任”確定其屬性。在設計中將系統用例轉換為腳本分析順序圖、系統測試順序圖、數據分析順序圖，圖4是系統測試順序圖。
3 系統實現
WEB性能測試系統主要包括建立測試計劃、執行測試、測試結果存儲等三個部分。測試計劃是指在要測試之前制定的測試方案和計劃，制定測試計劃包括要測試的并發數、模擬用戶數、測試結果的存儲等。測試部分是按照測試計劃來實現對系統的測試。線程組的設置是系統測試的關鍵內容，線程組的每個參數直接影響測試方式和測試過程。在測試系統中，用一個線程模擬一個真實用戶的請求行為，一個線程組來模擬若干個用戶請求的真實場景，線程數的大小表示在測試時將要模擬的用戶數，而并發用戶數是由用戶數和啟動持續時間決定的。
系統測試部分的實現是整個系統實現的關鍵部分，也是采用的關鍵技術最多、復雜程度最高的部分，在這里對其的實現過程作簡單的介紹：
1）多線程用管道來實現通訊：
首先，創建與 Spawn.exe 通訊的可繼承的匿名管道
with Security do begin
nlength := SizeOf(TSecurityAttributes);
binherithandle := True;
lpsecuritydescriptor := nil;
end;
if not Createpipe (ReadPipe, WritePipe, @Security, 0) then
begin
PostMessage(MainFrm.Handle,WM_CREATEPIPE_ERROR,0,0);
Exit;
end;
然后準備Spawn 的命令行，在命令行給出寫管道句柄和要Spawn 執行的命令
FmtStr(command_line, 'spawn -h %d %s',[WritePipe, DosApp]);
with StartInfo do begin
cb := SizeOf(TStartUpInfo);
dwFlags :=STARTF_USESHOWWINDOW;
wShowWindow := SW_HIDE;
end;
接著創建Spawn 子進程
if not CreateProcess( nil, PChar(Command_line), nil, nil, TRUE,0, nil, nil, StartInfo, ProcessInfo) then begin
PostMessage(MainFrm.Handle,WM_CREATEPROCESS_ERROR,0,0);
Exit;
end;
讀管道，并顯示Spawn 從管道中返回的輸出信息
if (not ReadFile(ReadPipe, len, Sizeof(integer), dwRead, nil)) or (dwRead = 0) then Exit;
while (len0) do begin
Buf := AllocMem(len + 1);
try
ZeroMemory(buf,len+1);
if (not ReadFile(ReadPipe, buf[0], len, dwRead, nil)) or (dwRead = 0) then Exit;
buf[dwRead]:= #0;
將結果顯示在Memo 中，并刷新對話框
Synchronize(UpdateShow);
if (not ReadFile(ReadPipe, len, Sizeof(integer), dwRead, nil)) or (dwRead = 0) then Exit;
finally
FreeMem(Buf);
end;
等待Spawn 結束
WaitForSingleObject(ProcessInfo.hProcess, 30000);
最后關閉管道句柄
CloseHandle(ProcessInfo.hProcess);
CloseHandle(ProcessInfo.hThread);
CloseHandle(ReadPipe);
CloseHandle(WritePipe);
PostMessage(MainFrm.Handle,WM_FINISHED_COMMAND,0,0);
2）后臺中定義了一個全局的參數，也是整個系統的接口，具體如下：
unit GlobalPara;
interface
uses Messages, SyncObjs, Classes, Windows, Graphics;
const
//自定義消息碼
WM_CREATEPIPE_ERROR = WM_USER + 1;
WM_CREATEPROCESS_ERROR = WM_USER + 2;
WM_READPIPE_ERROR = WM_USER + 3;
WM_FINISHED_COMMAND = WM_USER + 4;
implementation
end.
3）測試指標的實現
temps1:=Tstringlist.create;
temps2:=Tstringlist.Create ;
temps1.Text:=memo1.Text;
temps2.LoadFromFile(extractfilepath(application.ExeName)+'engtochn.txt') ;
這里是對測試腳本engtochn.txt 的加載，在我們準備測試計劃的時候，首先就得把測試腳本engtochn 的測試指標設置好，也就是自己想測試的Web 服務器的哪幾個方面的性能。
4 結論
本文給出了 Delphi 環境下開發一個新的Apache性能測試工具的全部過程，利用了多線程、管道、DLL 等技術，整個開發過程嚴格按照CMMI 3 要求進行。新系統繼承了AB系統的優勢，并對其不足之處進行了改進。主要表現在：用戶界面可視化，系統簡單易用；增加了一些新的測試指標，如往返請求/響應次數等，并且測試指標完全漢化；測試過程的可控性更加完善；對命令行參數、服務器的響應頭和其他外部輸入的解析更加具體細化等。
參考文獻：
[1] 侯景華.基于Apache的Web服務器性能優化和分析[D].西安:西安電子科技大學,2006.
[2] 蘭景英,王永恒.Web系統性能測試研究[J].計算機技術與發展,2008,18(11):18-20.
[3] 邵芬,于國防,付海燕.AB: 一種簡單的性能測試工具[J].計算機時代,2007(12):59-61.
