第一篇：Android客戶端性能測試總結

Android客戶端性能軟件測試小結

發布時間: 2012-3-09 13:52 作者: xiaowan 來源: TaoBao QA Team 字體: 小 中 大 |上一篇下一篇 |打印 |我要投稿 |推薦標簽：性能測試軟件測試

Android手機客戶端的性能測試開展近3個月了，期間包括性能監測工具的開發周期和工具的投入使用和優化；客戶端性能測試從這里起步，從這里開始。

一般情況，對于新生的產品，都會用定勢的思維考慮：優先功能測試，之后才會是安全、性能等方面。android客戶端從誕生到現在，在測試上走的也是這樣的路線。隨著客戶端功能越來越完善、越來越繁大，用戶群越來越多，性能、響應、穩定等被正式提上議程，重點考慮關注。

為什么我們要從以上幾個點來考慮客戶端性能呢？ 針對上面的幾個點我們是如何開展監控測試的？如何來評估一個客戶端的性能好不好，是否給予通過？下面就我自己看法跟大家詳細交流。

有數據統計：有很大一部分人群喜歡睡覺前、公交車、廁所、或者會議中開小差中使用手機；在看下移動互聯網的發展趨勢【下圖摘自某次互聯網統計報告】：

在上圖為各大運營商所占移動市場份額的變化情況：整體上移動用戶數仍絕對領先，但其市場份額也明顯的下降趨勢，百度推斷導致此變化的原因是基礎網絡的性能已經開始影響移動互聯網應用的使用，即網絡到底好不好，速度到底快不快，已經開始在影響應用市場份額了。同樣，對用戶而言：特定網絡下客戶端流暢不流暢、響應快不快決定著用戶對客戶端的使用時長和粘度；此外，用戶在考慮速度的同時，還會考慮跟自身利益相關的—-金額&網絡流量的消耗。

一個成熟的場景包括：人、時間、地點、行為。換言之：什么特征的人在什么情況下會使用比較容易比較經常使用客戶端，他們又經常使用客戶端的哪些面呢？

在客戶端性能監測前，我們需要采集真實場景中的性能數據：2G的網絡下的時間指標、訪問量較多頁面的流量消耗情況、整個客戶端的穩定情況。

（1）穩定性測試：【不同網絡、不同軟硬件系統下】

客戶端可穩定運行的時間、以及長時間操作后的流量消耗和內存消耗；

（2）性能測試指標：【不同網絡下】

界面流暢性、界面切換時間、占用的內存數、服務器返回數據消耗流量大小及數據的返回時間；

對以上的點，有幾種方法可以采用來監測。現在我們使用的是自己開發的客戶端性能工具。其中：流量統計使用TrafficStats.getUidRxBytes()來獲取下行流量值；響應時間通過判斷activity的狀態和日志中記錄的時間戳來獲取響應時間段； 內存通過解析dumpsys命令返回內容，截取我們需要的值進行分析；電量統計android系統提供查看。除了自己研發的小工具之外，外界也提供很多工具，都可以幫助我們完成相關的性能監測。

對用戶而言，性能不等于響應。堅持客戶第一，通過我們一個測試環節來保證用戶手中的每個客戶端都用的暢快。

第二篇：性能測試學習總結

性能測試學習總結

一、明確性能測試的范圍

例如：以iptv系統為例，是需要測試bss頁面、中間件具體接口、boss/crm具體接口

二、明確性能測試的指標 例如：

1、支持最大并發用戶數是多少？（壓力測試）

2、每秒n個用戶并發，能正常持續運行多久？（負載測試）

3、在系統用戶為n個的情況下，每秒x個用戶并發，持續運行y分鐘，查看系統硬件io、cpu、內存；查看軟件平均吞度量、tps、平均響應時間、事務成功率、事務失敗率、錯誤率等（性能測試）、響應時間：事務從開始到完成所花費時間

平均吞吐量：指單位時間內系統處理用戶的請求數

TPS：transaction per second 服務器單位時間處理的事務數（事務數/運行時間s）

事務：指訪問并可能更新數據庫中各種數據項的一個程序執行單元。例如訂購操作，它含有多個請求

事務成功率：成功事務數占完成總事務數的比率 事務失敗率：失敗事務數占完成總事務數的比率

三、定義數據模型

1、目標系統用戶數、目標每秒并發數、硬件系統配置情況，如下：模板

IPTV-BSS 性能指標.docx

四、設計性能測試方案

IPTV BSS四川電信版本性能

五、搭建性能測試環境

1、盡可能模擬現網的環境與組網結構

2、前臺應用和后臺數據庫安裝在獨立干凈的服務器上。

3、當前性能測試環境分別為：192.168.12.11（前臺）192.168.12.31（數據庫）192.167.12.177（Loadrunner）

六、構造性能測試數據

1、使用LR、QTP自動化工具構造（比較慢，不需要了解表結構，但是需要了解業務流）

2、編寫存儲過程構造用戶、包月、訂購數據（比較快，需要對相關表結構和數據庫了解）

七、錄制、調試測試腳本

1、中間件接口目前是web services協議，因當前測試指標均超過100個并發，故使用web（http/html）協議錄制。中間件接口錄制頁面：

2、boss接口當前有兩種協議，一種是web services協議，一種是sockets協議，因當前測試指標最大為100個并發，故可以使用web services協議或http/html協議錄制。

3、bss頁面基于ie運行，故使用web（http/html）協議錄制。

注明：當前中間件接口，四川boss接口，浙江電信bss部分頁面均有現成的腳本，如果其它局點需要測試可使用原有的腳本調試即可。

詳細參考：LoadRunner性能測試_劉雙林_20110115.doc

2.3/2.4章節 進行學習

八、執行性能測試場景

1、按照測試方案文檔中的測試用例執行即可。

2、在執行性能測試過程中會具體使用到性能測試工具LR。關于性能測試工具的使用方法網上有大把資料。請自行學習：場景設置、參數化等

詳細參考：LoadRunner性能測試.doc

3章節 進行學習

九、監控并記錄性能測試結果

1、硬件性能：bss應用服務器cpu、內存；數據庫服務器cpu、內存、io 內存、cpu 不高于70% ；IO不高于80% 否則可能存在性能瓶頸 統計方式：

（1）通過命令在服務器上查詢

內存 sar-r 5 120

（每5s刷新1次共刷新120次）cpu sar-u 5 120 io

iostat 5 120（2）在服務器上安裝rpc.rstatd工具，通過LR客戶端窗口監控記錄

2、軟件性能：平均吞度量、tps、平均響應時間、事務成功率、事務失敗率、錯誤率等（場景運行完畢可通過loadrunner工具導出性能測試結果），是否達標是要與性能測試指標進行比對。

詳細參考：LoadRunner性能測試.doc

4章節 進行學習

十、分析性能測試結果輸出總結報告

1、將實際測試結果和性能測試指標進行對比，總結出不達標測試對象及具體測試數據

2、測試與開發人員根據性能測試數據，從硬件環境和軟件本身進行分析。例如：優化硬件配置、軟件處理邏輯、數據庫架構腳本等。

3、具體分析的方法：一般是具體問題具體分析，查找瓶頸時按以下順序，由易到難。（1）服務器硬件瓶頸

（2）網絡瓶頸(對局域網，可以不考慮)（3）服務器操作系統瓶頸(參數配置)（4）中間件瓶頸(參數配置，數據庫，web 服務器等)（5）應用瓶頸(SQL 語句、數據庫設計、業務邏輯、算法等)注：以上過程并不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力(并發用戶數、數據量)下，系統的硬件瓶頸在哪兒就夠了。

十一、LoadRunner性能測試工具操作文檔

LoadRunner性能測試.doc

loadrunner8.1教材.pdf

第三篇：手機銀行客戶端測試總結

手機銀行測評總結

一、功能總結

通過對十三家手機銀行的功能試用和對比，可以將目前手機銀行的功能大致分為以下四類與賬戶服務、金融產品及其服務、生活服務、其他業務。以下是多家銀行的手機界面：

賬戶服務：

這部分的服務是銀行最基本的服務，所以各家銀行在功能上沒有太大差別。一般分為賬戶管理、轉賬匯款、無卡取現、信用卡這四部分。除了無卡取現這一相對比較新鮮的業務外，其他的功能可以用應有盡有來描述。細化的功能就不再贅述，可以參考各家銀行手機測評報告中的功能地圖。金融產品及其服務：

金融產品及其服務目前主要提供的業務有：基金業務、外匯業務、理財業務、貴金屬業務、國債業務、保險業務、銀期業務、銀證業務、個人貸款、結售匯、手機股市、大智慧；以及個別銀行針對自己的特色產品提供的相關服務，如工行的賬戶原油、高爾夫，交行的雙利理財、薪金寶等。生活服務：

生活服務方面目前提供的主要業務有：生活繳費（水費、電費、燃氣費、通信費、取暖費、有線電視費、小區物業費、彩票站點繳費）、手機充值、游戲點卡充值、電影票、彩票、飛機票、演出票、酒店預訂、公益捐款、銀醫服務、代駕服務、交通罰款、優惠商戶、商城購物等。其他業務：

除上述業務外，還有諸如理財計算器、網點查詢、排號預約、業務指南、優惠活動、銀行資訊、自助注冊、客戶服務等輔助業務。

以上基本是目前我國手機銀行業提供的所有功能和業務，每家手機銀行并不是都具有了上面所說的全部，除了賬戶服務和其他業務相差較小外，其他兩個服務因為每家銀行的側重點不一樣，在各個銀行間還是具有較大差異。做的較好較全面的，要數工行、建行、招行、交行、民生等銀行。做的最差的當屬中國銀行，功能稀少、操作不便、界面粗糙等等，各方面都排在了眾多銀行的后面，實在是有辱其大行之名。

二、特色分析

對比各家銀行，目前手機銀行所具有的特色主要體現在轉賬支付手段的創新以及營銷手段的創新等方面。轉賬支付創新: 在銀行傳統轉賬操作的基礎上，各家銀行充分發揮自己的創作能力。提供了搖一搖轉賬、手機號轉賬、二維碼轉賬、手機無卡取現等多種新穎別致，頗具個性化的功能。并且由于支付實質上也是歸結為一種轉賬，將以上各服務運用在消費支付上，就形成了一種新的支付手段。這方面做的比較好的有建行、平安、民生等。

以下就是建行搖一搖功能，除了進行轉賬功能外，還可以進行個性化設置，實現賬戶余額、外匯買賣、賬戶貴金屬、網點的快速查詢。

以下是建行“一拍享購”的二維碼功能，通過建行手機銀行客戶端拍攝二維碼，可以輕松享受一拍理財、購物等時尚生活體驗。

營銷手段創新：

在營銷手段方面，各家銀行互相發揮自己的優勢和才智，除了借鑒已經成功的互聯網電子商業模式外，還結合手機銀行自身的特性，推出了不少新的服務。這其中比較有特色的是招行、交行和建行。

1、在其他手機銀行的優惠商戶里面一般只有衣食住行方面的普通優惠商戶，這些商戶的特點就是單次消費低，客戶需求大優惠方式以折扣為主；招行另辟蹊徑，提供了針對醫療、教育、家電、汽車、通訊等昂貴產品和服務的分期商戶，迎合了市場，滿足了人們的不同需求。以下是招行優惠商戶和分期商戶的界面：

2、另外一個比較具有特色的就是交行的“最紅星期五”和建行的“建行e路惠，最炫星期天”。他們都選取了周末這個平日消費相對集中的時間段進行一種折上折的促銷，或者是開展本行的一些優惠活動，這樣活動必將會引發客戶的爭相參與，引起一波消費熱潮。長期使用他們手機客戶端的人，很容易由于這種活動而對他們的手機客戶端產生習慣和依賴。以下是相關界面：

3、除此之外，還有一個不得不提的就是民生銀行，其跨行賬戶管理功能十分強大。在其余手機銀行里面，一般只能對本行賬戶進行管理，而在民生手機銀行里面，只要進行了簽約，就可以對他行賬戶進行余額查詢操作，為多卡用戶提供了極大的方便。并且民生銀行將年初炒的比較熱的“超級網銀”，即跨行資金歸集業務也移植到了手機上，如果用戶辦理了相關業務，并合理運用。只用一個手機，不同銀行多個賬戶之間的資金真是想怎么轉就怎么轉，將手機銀行的優勢發揮到了極致。由于這些業務只有需要多張銀行卡，且辦理了相關業務資費才能顯示，過程較為繁瑣，相關頁面就不再列出了。下面是民生銀行的轉賬匯款業務，其中的“同名匯款”在其他銀行較為少見，列出來算是一種補充。

4、其他如排號預約、理財計算器、交行的語音服務、火車票查詢；招行的“e代駕”、《財經內參》和《財智生活》；工行的業務指南等功能也頗具特色。以下是一些相關界面：

建行轉賬匯款的界面：

工行的理財計算器：

工行的業務指南：

招行的“e代駕”、《財經內參》和《財智生活》：

類似的功能很多家銀行都有，每家銀行也都有自己的一項或數項特色功能，在此就不一一列舉了。其實特色功能不一定代表實用，看起來很實用的功能，也不不一定代表用的人就很多。具體情況如何，也只能待若干年后，我國手機銀行穩定和壯大，方能見分曉。

三、總結

由于我國手機銀行客戶端還處于起步的階段，能熟練使用的人還不是很多，許多人對這一新鮮事物還不了解，有的了解卻對它的業務只是停留在像網銀一樣的賬戶管理、投資理財、代繳費等傳統業務上面，甚至對它的安全性還抱懷疑態度。

目前，各大銀行都處于一種劍拔弩張的態勢。隨著移動互聯網大潮的到來，移動支付是一種必然的趨勢。手機銀行客戶端作為其中的媒介，誰的客戶端占領了用戶的手機，誰就占領了市場。所以客戶端的界面好壞，操作是否方便快捷，功能是否齊全，安全性能如何，是否具有特色服務等等都會在用戶做出選擇時起到十分重要的作用。當然，銀行的宣傳力度對于手機銀行市場占有率的提升也是至關重要的，尤其是在現在這種起步階段。

上面以幾家銀行為例，列舉了一些特色業務，其實這些業務并非他們所獨有，甚至也不是他們所首創。比如“搖一搖”轉賬，百度里面搜到的最先推出這種服務的是中信銀行，現在建行、平安等也推出了同樣的業務，并且建行活學活用，還將“搖一搖”用到了其他功能上，顯得比中信更勝一籌。其他如二維碼轉賬支付、手機號轉賬、無卡取款、排號預約等特色服務，目前雖然并不是每家銀行都有，但確實是處于逐漸添加和完善的狀態。比如工行10月23號更新的客戶端里面添加了二維碼購物等多項功能。究其原因，我們可以歸結為目前我國的手機銀行市場還不太成熟和穩定，但市場空間又無比廣闊，銀行間競爭激烈，都希望先人一步，占據盡可能多的市場份額。即使在某項功能尚不成熟，市場前景未知的情況下，也去盲目跟風推出，寄希望于增加功能來吸引用戶。然而一個APP的功能容量是有限的，以往多家銀行都缺乏產品策略規劃，估計就在今年，功能增加將走向盡頭。銀行必須考慮重新建立產品策略和產品形態。

銀行業務復雜，產品眾多，用戶面也非常廣泛，僅靠一個APP承載這么多使得產品臃腫而市場響應遲鈍。銀行應該學習新浪、騰訊、阿里巴巴這類企業，根據業務特點做垂直應用。同時，手機銀行產品雷同問題嚴重，而獨立APP產品線是差異化的出路。目前，招行除了手機銀行還有掌上生活APP，交行新推出了校園版APP；估計其他銀行也會陸續跟進，女性手機銀行、理財專用APP、黃金買賣APP、青少年用戶版本APP等各種細分產品將形成銀行APP產品線。

得益于智能手機的普及，以及各商業銀行的重視以及宣傳，手機銀行的用戶數正在直線上升，交易額也呈現出一種爆發式增長的態勢，將來極有可能發展到與網上銀行體積相當的程度。專家預計，移動支付和移動金融，將是手機銀行的主要增長點。

注：

1、以上圖片有看不清的，可以放大word文檔的倍數進行查看！

2、本文檔數個人原創，僅限學習交流，嚴禁下載后到其他網站四處上傳，做人要厚道！

第四篇：性能測試QQ面試總結

21克

9:46:17 你全權參與的性能測試項目有幾個？ 低調的魚

9:48:08 BECIF平安銀行客戶信息管理系統

平安銀行個人網銀改造（接入一帳通卡后）平安投行證券管理系統 交通銀行積分管理系統 中銀聯OA系統

21克

9:48:50 那在性能測試中有沒有發現什么缺陷？ 低調的魚

9:53:09 我去整理一下 21克

9:55:29 好的

低調的魚

10:03:24 BECIF平安銀行客戶信息管理系統 1822 BECIF1.0.0 性能測試-客戶基本信息查詢（20并發 場景腳本 查詢客戶基本信息_byBecif_c.lrs）P2 L2 關閉 2 1842 BECIF 新增客戶性能優化 P4 L3 已關閉 3 1848 綜合場景測試（300 4hour）未達到1S響應時間要求 P2 L2 已分配

1.疑似客戶判斷代碼取線程數有誤。

2.查詢疑似客戶返回值最大個數未做限定。

3.中間件ESB對于XML腳本的最大長度限制過小。4.數據庫連接數不夠。

平安銀行個人網銀改造（接入一帳通卡后）1.weblogic線程數不夠 2.數據庫連接池數不夠

平安投行證券管理系統 1.服務器系統資源不夠

2.用戶登陸驗證機制時間過長。

交通銀行積分管理系統

1.100并發用戶時積分查詢交易超時

中銀聯OA系統 1.tomcat JVM過少

2.tomcat 線程數過少。

3.多用戶登陸時流量統計插件報錯。

低調的魚

10:04:09 BECIF的缺陷當時我有記錄，其他的項目只是記得自己當時做性能測試過程中發現的問題。21克

10:06:45 對BECIF平安銀行客戶信息管理系統來說，你提及的4條調優的建議是基于什么測試結果提出的？

21克

10:07:00 也就是說你是如何得出這4調結論的 低調的魚

10:25:36 1.疑似客戶判斷代碼取線程數有誤。

查詢疑似交易單獨運行時，weblogic的線程數增長速度過快，系統線程數迅速到到最大負荷

2.查詢疑似客戶返回值最大個數未做限定。

我當時編寫的腳本是新增用戶后再進行疑似查詢操作，用戶的五項關鍵信息為：姓名，性別，生日，證件類型，證件號碼 2.1 證件類型，證件號碼同 2.2 姓名、性別、生日三者相同 如上兩種情況都是屬于疑似客戶，我的查詢疑似的腳本中只用戶姓名進行了參數化，（每增加一個用戶，疑似判斷的用戶就+1）

因為當時跑了100并發用戶的綜合場景，分了15分鐘，1小時，4小時幾次運行。查詢疑似交易的平均響應時間越來越長，后面去CC上取代碼看的時候，發現開發未對疑似的最大值進行限制。

3.中間件ESB對于XML腳本的最大長度限制過小。

新增用戶不添加產品信息時，查詢客戶所有信息交易平均響應時間正常。

但是從生產上取下來的數據屏蔽名字后，進行綜合場景運行過程中，查詢客戶所有信息的交易失敗率大大增加.原因為客戶產品信息和基本信息所涉及的字段有300余個，有80多個字段為文本類型，如果客戶有多個產品信息的話 查詢時系統后臺生成的XML腳本文件有可能大于

而ESB對于BECIF傳出的XML腳本文件限制的最大值為1M

4.數據庫連接數不夠。

200用戶綜合場景運行時,查詢類的交易平均響應時間過長，后臺log中，返回交易有超時情況 weblogic中事務排隊嚴重。21克

10:32:10 上面的這些的調優工作是有測試人遠來做還是由開發人員來做的？ 低調的魚

10:35:33 中間件的參數變更平安銀行那邊是有專門的人做的，我們只能是提缺陷和建議，然后由他們評審之后確定是他們的問題再作修改的，至于代碼類的問題是開發來改的。

我所做的事情就是盡自己可能去收集資源，發現問題，提出自己的見解 21克

10:36:41 你提出的這些建議都有別接受嗎？ 21克

10:37:02 他們修改后的性能提高了多少？ 低調的魚

10:37:36 這幾個都是接受了的 21克

10:37:44 他們修改后的性能提高了多少？ 低調的魚

10:37:55 BECIF項目，按照平安規范，依據性能測試需求分析和方案。進行壓力測試

測試目的（1）模擬真實應用，系統各個主要業務流程能否在78個并發用戶同時訪問情況下響應時間為1s以內。

（2）在系統各業務流程能正常運行的情況下，系統能承受多少個并發用戶同時訪問（系統承壓能力）。

（3）測試主要業務流程（或者某事物）的響應時間。

低調的魚

10:38:25 這個是一期的要求，經過一系列調整后所有交易都達到上面的指標 21克

10:39:25 你們的性能測試時有自己的環境還是在生產環境上進行的？ 低調的魚

10:43:10 生產上肯定是禁止運行的，專門的性能測試應當說有的 一般都是在STG環境上運行的，BECIF這個項目，當時用于性能測試的有三個環境，PER環境 新功能及系統的測試環境

PIR環境主要用于常規版本測試的生產缺陷問題驗證和修復

還有一個是容災環境，這個環境都是最新版本的系統，一般都是在這個上面做性能測試。21克

10:44:15 你們的性能測試用的是什么工具？ 低調的魚

10:46:30 loadrunner 8.1 和loadrunner9.0 當時做性能測試的時候都是在專門的遠程服務器上做的，我用過的一共有5臺，3臺上面裝的是loadrunner8.1另外2臺上面裝的是loadrunner9.0

21克

10:46:56 好的

21克

10:47:36 你的簡歷已經通過了篩選，我會吧你的簡歷提交給測試經理。結果會盡快通知你的 21克

10:47:42

謝謝

低調的魚

10:47:51 好的，多謝了

第五篇：Linux_網絡性能測試(總結)

Linux網絡性能測試 使用 Ipref測試吞吐

1.1 安裝

tar-zxvf iperf-2.0.5.tar.gz cd iperf-2.0.5./configure make && make install

1.2 測試UDP

服務器命令：iperf-s-i 1-u 客戶端命令：iperf-c 170.0.0.100-i 1-t 999-b 1000000000-u-l 22-c：服務器地址-i：每次報告的間隔-t：持續測試的時間-b：帶寬-u：UDP-l：UDP 有效負荷大小

各字節測試時，輸入-l參數如下：

在服務端查看結果，64字節UDP小包的吞吐約是7.32 Mbits/s。

[root@localhost ~]# iperf-s-u-i 2-----------------------------Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 208 KByte(default)-----------------------------[ 3] 10.0-12.0 sec 1.72 MBytes 7.22 Mbits/sec 0.022 ms 55728/137802(40%)[ 3] 12.0-14.0 sec 1.79 MBytes 7.49 Mbits/sec 0.016 ms 52637/137735(38%)[ 3] 14.0-16.0 sec 1.74 MBytes 7.30 Mbits/sec 0.040 ms 53247/136227(39%)[ 3] 16.0-18.0 sec 1.74 MBytes 7.32 Mbits/sec 0.071 ms 54608/137771(40%)[ 3] 18.0-20.0 sec 1.79 MBytes 7.52 Mbits/sec 0.021 ms 52133/137632(38%)[ 3] 20.0-22.0 sec 1.75 MBytes [ 3] 22.0-24.0 sec 1.74 MBytes 7.32 Mbits/sec 0.020 ms 54508/137672(40%)[ 3] 24.0-26.0 sec 1.79 MBytes 7.51 Mbits/sec 0.022 ms 52519/137838(38%)[ 3] 26.0-28.0 sec 1.72 MBytes 7.20 Mbits/sec 0.019 ms 55779/137599(41%)[ 3] 28.0-30.0 sec 1.72 MBytes 7.23 Mbits/sec 0.016 ms 55504/137640(40%)[ 3] 30.0-32.0 sec 1.77 MBytes 7.41 Mbits/sec 0.017 ms 52849/137002(39%)[ 3] 32.0-34.0 sec 1.74 MBytes 7.31 Mbits/sec 0.022 ms 54785/137842(40%)[ 3] 34.0-36.0 sec 1.74 MBytes 7.30 Mbits/sec 0.019 ms 54717/137710(40%)

7.32 Mbits/sec 0.021 ms 54418/137616(40%)2 使用http_load測試HTTP Server吞吐和并發

2.1 安裝Apache服務器

1、安裝并啟動

yum-y install httpd service httpd start

2、在Apache服務端準備好各字節大小的頁面

（頁面大小：64、128、256、512、768、1024、1280、1518）cd /var/ Document Length: 64 bytes

Concurrency Level: 10 // 每秒測試并發數 Time taken for tests: 9.920 seconds Complete requests: 100 // 成功的請求數 Failed requests: 0 // 失敗的請求數 Write errors: 0 Total transferred: 45100 bytes HTML transferred: 6400 bytes Requests per second: 10.08 [#/sec](mean)// 每秒事物處理，mean表示平均值 Time per request: 992.027 [ms](mean)//平均事物響應時間

Time per request: 99.203 [ms](mean, across all concurrent requests)Transfer rate: 4.44 [Kbytes/sec] received //傳輸為4.44字節每秒 吞吐為4.44 * 8 = 35.52 Mbit/s 3.3 其他參數

-n requests 全部請求數-c concurrency 并發數

-t timelimit 最傳等待回應時間-p postfile POST數 據文件-T content-type POST Content-type-v verbosity How much troubleshooting info to print-w Print out results in HTML tables-i Use HEAD instead of GET-x attributes String to insert as table attributes-y attributes String to insert as tr attributes-z attributes String to insert as td or th attributes-C attribute-H attribute Inserted after all normal header lines.(repeatable)-A attribute http-P attribute Add Basic Proxy Authentication, the attributes are a colon separated username and password.-X proxy:port-V-k Use HTTP KeepAlive feature-d Do not show percentiles served table.-S Do not show confidence estimators and warnings.-g filename Output collected data to gnuplot format file.-e filename Output CSV file with percentages served-h Display usage information(this message)加入cookie, eg.'Apache=1234.(repeatable)加入http頭, eg.'Accept-Encoding: gzip' 驗證,分隔傳遞用戶名及密碼

代理服務器 查看ab版本

使用sendip發原地址跳變的數據包（并發）

3.1 安裝

1、到http://www.tmdps.cn and CWR bits Default: 0-tfe x TCP ECN bit(rfc2481)Default: 0(options are 0,1,r)-tfc x TCP CWR bit(rfc2481)Default: 0(options are 0,1,r)-tfu x TCP URG bit Default: 0, or 1 if-tu specified(options are 0,1,r)-tfa x TCP ACK bit Default: 0, or 1 if-ta specified(options are 0,1,r)-tfp x TCP PSH bit Default: 0(options are 0,1,r)-tfr x TCP RST bit Default: 0(options are 0,1,r)-tfs x TCP SYN bit Default: 1(options are 0,1,r)-tff x TCP FIN bit Default: 0(options are 0,1,r)-tw x TCP window size Default: 65535-tc x TCP checksum Default: Correct-tu x TCP urgent pointer Default: 0-tonum x TCP option as string of hex bytes(length is always correct)Default:(no options)-toeol TCP option: end of list-tonop TCP option: no op-tomss x TCP option: maximum segment size-towscale x TCP option: window scale(rfc1323)-tosackok TCP option: allow selective ack(rfc2018)-tosack x TCP option: selective ack(rfc2018), format is-tots x TCP option: timestamp(rfc1323), format is tsval:tsecr l_edge1:r_edge1,l_edge2:r_edge2...