一、效能測試流程

計劃測試->建立指令碼->建立場景->執行場景->分析效能資料->生成x效能測試報告，如下圖所示：

1.1 計劃測試

在任何型別的測試中，編寫測試計劃都是必要的步驟。有條不紊、計劃周密的計劃，可以確保在執行中能夠有章可循。在計劃測試階段需要輸出效能測試計劃，而計劃階段需要經歷如下幾個環節，如下圖所示： 

 1.1.1 分析系統階段

要進行效能測試，瞭解被測物件是需要做的第一步。首先需要確認系統的架構和所使用的協議，對工具的可行性進行分析，然後對整個業務進行熟悉，確認相關的資料和業務操作可以被工具錄製回放。

✔ 通過分析系統階段需要知道該系統能不能進行效能測試。

1. 確定協議

如何確定系統所使用的協議，這是大家經常討論的問題，其實詢問一下需求分析人員或開發人員就知道，絕大多數時候系統都使用標準的開發架構，而所使用的協議也是系統事先封裝好的，不過萬一開發人員也不知道系統到底使用了哪些協議呢？這時不能隨意懸著錄製協議，否則會由於漏錄軟體互動協議導致回放失敗，或錄製了大量無用互動協議導致指令碼無法維護，這時就需要引入網路資料包攔截分析，來確認系統協議。

網路資料包攔截軟體其實有很多，比如常見的Wireshark、Omnipeek等。通過這類工具，可以攔截整個被測系統所使用的協議型別，甚至明確資料包的封裝格式。它們和HttpWach略有不同，HTTPWatch是一個基於瀏覽器的外掛，可以幫助我們攔截HTTP的資料包；而這裡使用的網路攔截工具是基於網絡卡的底層掃描的。

這裡以Omnipeek為例具體說明一下。Omnipeek是由Wildpackets公司研發的網路掃描維護工具，其提供了高效的故障診斷和定位能力，這一特效能夠明顯縮減日常花費大量尋障和排障的時間，使我們有精力去完善日常其他的工作以及學習更多的業務知識。在很長一段時間內，Sniffer都是網路掃描和資料包攔截方面的指導性軟體，作為後起之秀的Omnipeek，在最近幾年中其鋒芒已經壓過Sniffer成為各大雜誌推薦的最佳產品。

Omnipeek提供以下幾種功能，可幫助測試人員快速對網路問題進行故障診斷/定位。

• 主機排名。發現網路中通訊量最大的主機，對比故障現象與影響範圍，如下圖所示：

  

• 協議排名。可以對監控的所有協議進行排名，找到使用最多的協議，如下圖所示：

  

• 具體哪些主機在使用某種通訊協議，如下圖所示：

  

• 通過PeerMap網路分佈圖瞭解主機會話的實時情況，如下圖所示： 

  

• 深入解碼分析。發現異常後，可以進行深入的解碼分析，如下圖所示： 

  

通過以上步驟可以很容易的發現流量異常的主機、主機不正常的協議通訊以及網路中實際傳輸的資料內容。從某些角度來說，使用Omnipeek來做協議分析，真是殺雞用牛刀。讀者可以在各大網路下載到免費版本的Omnipeek安裝包。下面我們使用Omnipeek來嘗試捕捉和分析系統，瞭解其使用的網路協議。

• 開啟Omnipeek，在主介面的左上側單機New Capture按鈕，如下圖所示：

  

• 新建一個數據捕捉，彈出Capture Options協議捕捉設定視窗，如下圖所示：

  

• 在這裡需要設定以下內容。

1. General中的捕捉名稱。

2. Adapter需要捕捉的裝置。

3. Filters對於協議包的過濾規則。

在多網絡卡的情況下，這裡選擇的裝置不能有錯，否則會導致沒有資料包被捕捉的情況。確認後進入監控頁面，如下圖所示：

• 單擊Start Capture按鈕就可以開始進行協議捕獲了。

如果現在想知道自己的有線網絡卡在做些什麼，那麼只要確保前面設定的捕獲裝置是本地網絡卡即可，不需要設定任何Filters過濾規則，單擊Start Capture按鈕開始捕獲，稍等片刻，可以看到有大量的資料包被捕獲下來，如下圖所示：

在列表中可以看到通過網路資料包捕獲得到了每個請求的傳送源、接收請求的地址、資料包的大小、傳送時間及協議型別。

通過這種方式可以輕鬆地確認需要進行效能測試的系統所使用的協議型別。另一方面還能對每個請求進行更加深入的分析，雙擊開啟請求，即可得到該請求的詳細分析，包括髮送的資料包格式、所使用的協議及該協議下的資料內容，如下圖所示：

一般從效能測試工具的協議選擇角度來說，應儘可能使用高階的協議，作為底層的Windows Sockets 協議只有在萬不得已的情況下才使用。通過工具分析掃描以後可以確定系統所使用的協議型別、協議格式和封包規則，而Omnipeek幾乎能夠識別所有的協議標準，下圖所示：

掃描後可以根據掃描的結果去檢查VuGen是否支援這種協議，如果遇到VuGen不支援的協議，那麼使用LoadRunner來進行效能測試可能就不是最佳選擇，雖然可以通過Windows Sockets來模擬這個過程，但是使用過程相對煩瑣。

對於這次需要測試的Phpwind和Discuz論壇來說，從其官方網站可以瞭解這是基於PHP技術的B/S架構論壇系統，在客戶端上通過HTTP完成對整個論壇的訪問，所以確認該系統可以使用LoadRunner的HTTP協議完成操作的錄製，該工具是適合進行該系統的效能測試的。

2. 熟悉業務流程

每一個系統都有自己的業務流程，通過檢視相關文件，可以瞭解系統的執行步驟和業務流程，從而瞭解使用者如何使用整個系統。我們需要先將各種業務操作的流程進行整理，並且通過VuGen進行錄製回放，檢查該系統是否能夠被效能測試工具模擬使用者行為。

對於一個要測試的論壇來說，常見的操作包括髮帖、檢視帖子、使用者間收發短訊息等操作。這裡簡單分析一下使用者進行常見操作所需要的一些業務流程。

1）瀏覽帖子

一個論壇所能提供給使用者主要的功能就是帖子的瀏覽功能，絕大多數情況下論壇都會被設定為無需登入即可瀏覽大部分板塊的帖子。使用者在訪問到論壇首頁後會點選自己感興趣的板塊，並且進行前後翻頁，查詢自己關心的話題，然後進入該話題，進行瀏覽操作。

2）查詢帖子

使用搜索引擎是大家最常做的事情，而論壇也提供了強大的查詢功能。當登入系統後，就可以使用查詢功能在論壇中查詢各種話題，查詢後列出符合查詢條件的相關記錄，查詢速度一般受到論壇資料量的影響較大。

3）回帖/發帖

相對於瀏覽來說，回帖或發帖的操作並不會如此頻繁，使用者發帖或回帖需要先登入論壇，進入線上使用者狀態後，即可在不同的模組中進行發帖或對某些帖子進行回帖操作。

4）註冊新使用者

當用戶想要進行回帖、發帖或查詢等操作時，都需要成為註冊使用者而不是遊客，註冊新使用者也是論壇比較常用的功能，但是大多數情況下對於任何一個真實使用者來說，註冊使用者也只是只做一次的事情，只需要單擊註冊後輸入相關使用者名稱和密碼即可完成使用者的操作，而不會每次使用系統新註冊使用者。

通過VuGen錄製上述操作後，檢查對應的指令碼，回放這些指令碼均可以成功並且沒有出現漏錄協議互動的情況，那麼就可以認為該系統的效能測試是能夠使用LoadRunner工具進行的。如果出現腳本回放失敗，並不能說明無法使用LoadRunner進行效能測試，需要再參考下面的系統相關資訊來進一步確認。對於基於HTTP的應用來說，LoadRunner已經非常成熟了，所以很少會發生在基於HTTP的應用中無法進行效能測試的情況。

3. 獲得系統相關資訊

當腳本回放出錯時，某些情況是由於無法錄製到某些操作導致回放失敗，而大多數情況是由於系統中存在某些動態資料，導致操作無法達到預期的效果，這時需要通過關聯來解決動態資料的問題。

那麼什麼資料需要關聯，什麼資料需要關聯呢？這要求我們熟悉系統業務流程。常見系統的動態資料無非就是session和一些頁面引數，通過詢問開發或系統設計人員來了解動態資料的產生規則和使用方式。

在需要測試的Discuz論壇中，可以在操作中發現一些常見的動態資料。例如論壇的帖子編號、使用者編號、板塊編號等，而並沒有session這種複雜的檢查手段出現（可以通過對相同物件的多次操作，對比請求和返回的區別來識別動態資料）。

而在Phpwind中我們知道需要對verify和_hexie這兩個資料進行關聯，這兩個屬性會輔助驗證發帖。

當完成了協議的確定、業務的熟悉和相關資訊的收集後，接著可以對指令碼進行簡單的開發了，那麼是不是需要把使用者所有的行為都進行模擬呢？非也，效能測試並不是要求德智體美勞全面發展，而是強調核心競爭力，接著要做的是對效能測試的目標進行定義，避免效能測試的眉毛鬍子一把抓。

1.1.2 定義測試目錄

作為任意一個測試來說，瞭解了被測物件後，接著就需要了解使用者的測試目標或者叫做需求。不是在開發前已經和使用者確認生成SRS（需求規格說明書）了嗎？其實問題就出在我們總認為有了SRS軟體就能夠做出來了，但是實際情況是一方面SRS並無法包含所有的使用者需求，另一方面在設計SRS的時候總會忽視在效能方面的需求，即在設計階段效能隱患就被植入了軟體。

使用者自身是無法提供準確有效的需求的，所以作為需求中的效能測試，需要效能需求分析工程師對其進行顯式和隱式的分析，得到準確清晰的效能需求，當需求被確認後我們就能知道效能測試該測什麼了。

✔ 通過定義測試目標需要知道的是使用者想要什麼。

那麼如何獲得性能需求呢？在此之前請先考慮一個問題：上海鐵路人民廣場1號線站臺和換乘大廳應該修建多寬？

乍看一眼，你可能覺得這是一個功能需求，怎麼可能和效能相關呢？但這個確實是效能問題，如果換乘的樓梯修建過窄，會導致大量乘客無法疏散出月臺引起事故，而如果修建過寬又會帶來不必要的浪費，合適的疏散能力就是效能的吞吐量指標。

可能有些朋友會說，我沒去過上海，也沒有坐過地鐵，如何知道這個效能是多少呢？確實，很多時候我們對使用者所需要的系統聞所未聞，現在需要我們來做效能需求定義效能測試的目標不是無稽之談麼？那麼按照這個道理來說，做效能需求分析的人都應該是業務專家，從某些角度來說需求分析本來就是需要對業務或技術的專家才能擔當，但並不是說沒有簡便入手的方法，對於這種情況，可以通過一下幾個方法來獲取系統的效能需求。

1. 通過使用者提供的資料進行分析

使用者永遠是需求的最後確認人，通過使用者介紹和提供相關資料是分析系統性能需求最直接也是最簡便的方式。例如使用者想要新建一個系統，來將公司的業務無紙化，那麼他會提出相關的要求，例如容量、響應時間、併發量、伺服器資源等。而作為實現方，當效能需求分析工程師將使用者的需求進行整理後，需要參考以前的專案或相關資訊去確定該需求是否合理可實施，進一步和使用者協調製定合理有效的效能需求，已達到雙贏的結果。

例如，這裡有一個OA系統的客戶資料，整個公司有500個使用者會使用這個系統，主要是在上面完成各種訂單的內部處理，每筆業務的提交大概平均要15分鐘，每個使用者每天大概要提交20筆訂單，高峰期時會有33個訂單的提交量。整個公司大概有400人事負責訂單提交的，還有50個使用者負責訂單的審查，每個訂單都會被2個審查人員複審，複審的時間平均為5分鐘。

通過整個客戶資訊我們能給出什麼樣的建議和效能需求呢？使用者並不瞭解具體的效能指標，而只能提供業務資料，但是我們在這個業務資料中可以和使用者確認一些事情來幫助我們瞭解效能需求。

在這裡我麼知道有400個使用者線上提交訂單，每個訂單的提交平均速度是15分鐘，而全天每個使用者的訂單量是20~33筆。通過這個資料我們大概可以計算出訂單處理這個模組所需要的系統吞吐量。按照最悲觀的考慮方式，以500個使用者全部都做訂單提交操作，每個使用者的提交時間按照10分鐘~12分鐘較快的模式來計算，那麼可以得到系統的處理能力需要達到500*60/10=3000筆業務/小時。進一步計算也就是50筆業務/分鐘，每秒不到1筆業務，但是在這裡我們並不能按照平均值來計算，這裡需要適當地放鬆，避免多使用者併發操作時系統出現問題。

所以需求應該定義為：系統支援500使用者併發操作訂單提交操作，提供每小時3000筆業務以上的操作能力，單位時間的處理能力大於10筆業務/秒（這個資料可以自己先進行性容量測試後再做確定，參考系統日誌中得峰值資料，一般來說峰值資料是按照平均業務的10倍來計算的），標準處理能力下響應時間在2s以內，普通負載下10使用者併發響應時間在3s以內，50使用者以內的大業務併發響應時間在5s以內。按照每筆業務50個數據欄位來計算，一筆業務需要使用500KB（帶附件）的資料量，系統對於100Mb/s頻寬的設計能夠支援20個使用者併發提交訂單（不包含其他業務的頻寬需要），在資料庫中每存放一筆訂單大概需要開銷1MB的磁碟空間，按照每小時3000筆業務的基礎加上8~10小時的標準工作時間，所以每天的業務應該有30000筆，需要開銷3GB的磁碟空間。

當擁有這樣一個性能需求時，如何進行效能測試，如何設計場景，如何評估伺服器處理能力，如何確定伺服器配置及容量是不是已經清晰了很多。

2. 通過系統日誌

當進行舊系統升級的時候，歷史資料即系統日誌的方式是獲得真實使用者需求最有效的參考資料（對於峰值併發量的計算通過日誌才是最可靠的）。作為常用的Web伺服器IIS、Apache或者Nginx，當用戶通過客戶端傳送請求到Web伺服器的時候，都會訪問日誌中記錄下來。

IIS日誌設定的方法說明如下。在IIS中找到需要的網站，開啟日誌功能，如下圖所示：

IIS預設支援以下4種日誌格式：

• Microsoft IIS 日誌檔案格式。

1.  資訊記錄在以逗號分隔的ASCII文字檔案中。
2. 資料是固定的，不能自定義該日誌。
3. 單個傳輸有多條記錄。

• NCSA公用日誌檔案格式。

1. 資訊記錄在使用（美國）國家超級計算技術應用中心（NCSA）格式的ASCII文字檔案中。
2. 資料是固定的，不能自定義該日誌。
3. 單個傳輸有多條記錄。

• W3C擴充套件日誌檔案格式。

1. W3C（全球資訊網聯合會）擴充套件日誌檔案格式是SMTP服務以及其他IIS服務的預設日誌記錄格式。
2. 資料是變化的，可以選擇要跟蹤的內容。
3. 此種格式是限制日誌大小很好的選擇。
4. 資訊記錄在ASCII文字檔案中。
5. 這種格式包括某些僅適用於Web和檔案傳輸協議（FTP）服務的欄位選項。
6. 單個傳輸有多條記錄。

• ODBC日誌記錄

1.  使用此格式錢，必須建立一個開放式資料庫連線（ODBC）相容的資料庫。
2. 資訊記錄在資料庫中。
3. 單個傳輸有多條記錄。

如果使用IIS作為Web伺服器的話，建議使用W3C格式。這裡可以通過格式後的選擇欄位功能為日誌新增監控屬性，如下圖所示：

監控的資料越多，對後期分析可以提供的支援就越強。

Apache日誌設定的方法說明如下。

 Apache的訪問日誌格式支援自定義，開啟Apache下的httpd.config檔案，使用LogFormat命令來查詢系統預設的日誌格式，也可以自行定義需要的日誌格式。

在httpd.config檔案中找到以下內容：

<IfModule log_config_module> 
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined  # 日誌的格式
    LogFormat "%h %l %u %t \"%r\" %>s %b" common  # 普通訪問日誌格式
<IfModule logio_module>
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio 
</IfModule>  # 預設站點訪問日誌配置
    CustomLog "logs/access_log" common  # 訪問日誌路徑 common
    #CustomLog "logs/access_log" combined # 訪問日誌路徑 combined （複合日誌）
</IfModule>

我們先來簡單介紹以下LogFormat的使用格式。以下是一個典型的記錄格式：

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common

它定義了一種特殊的記錄格式字串，並給它起了個別名叫common，其中的“%”指示伺服器用某種資訊替換，其他字元則不做替換。引號（''）必須加反斜槓轉義，以避免被解釋為字串的結束。格式字串還可以包含特殊的控制符，如換行符“\n”、製表符“\t”。

CustomLog指令建立一個使用指定別名的新日誌檔案，除非其檔名是以斜杆開頭的絕對路徑，否則其路徑就是相對於ServerRoot的相對路徑。

上述配置是一種被稱為通用日誌格式（CLF）的記錄格式，它被許多不同的Web伺服器所採用，並被許多日誌分析程式識別，它產生的記錄形如：

127.0.0.1 - frank [19/Aug/2000:14:47:37 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 

記錄各部分說明如下：

127.0.0.1 （%h）

這是傳送請求到伺服器的客戶IP地址。如果HostnameLookups設為On，則伺服器會嘗試解析這個IP地址的主機名並替換此處的IP地址，但並不推薦這樣做，因為它會顯著拖慢伺服器，最好是用一個日誌後續處理器來判斷主機名，比如logresolve。如果客戶和伺服器之間存在代理，那麼記錄中的這個IP地址就是代理的IP地址，而不是客戶端的真是IP地址。

- （%l）

這是由客戶端identd程序判斷的RFC1413身份（identity），輸出中的符號“-”表示此處的資訊無效。除非在嚴格控制的內部網路中，此資訊通常很不可靠，不應該被使用。只有在將IdentityCheck指令設為On時，Apache才會試圖得到這項資訊。

frank （%u）

這是HTTP認證系統得到的訪問該網頁的客戶標識（userid），環境變數RENOTE_USER會被設為該值並提供給CGI指令碼。如果狀態碼是401，表示客戶未通過認證，則此值沒有意義。如果網頁沒有設定密碼保護，則此項將是“-”。

[19/Aug/2000:14:47:37 -0700] （%t）

這是伺服器完成請求處理時的時間，其格式是：

[日/月/年:時:分:秒 時區]
日=2個數字位
月=3個字母位
年=4個數字位
時=2個數字位
分=2個數字位
秒=2個數字位
時區 = （+正 | -負） 4個數字位

可以在格式字串中使用%{format}t 來改變時間的輸出形式，其中的format與C標準庫中的strftime()用法相同。

"GET /apache_pb.gif HTTP/1.0" （\"%r\"）

引號中是客戶端發出的包含需要有用資訊的請求行。可以看出，該客戶的動作是GET，請求的資源是apache_pb.gif，使用的協議是HTTP/1.0。另外，還可以記錄其他資訊，如格式字串"%m%U%q%H"會記錄動作、路徑、查詢字串、協議，其輸出與"%r"一樣。

200（%>s）

最後這項是返回給客戶端的不包括響應頭的位元組數。如果沒有資訊返回，則此項應該是“-”，如果希望記錄為“0”的形式，就應該用%B。

首先使用LogFormat命令LogFormat "%h %l %u %t \"%r\" %>s %b" common 定義日誌格式，然後再通過CustomLog命令CustomLog "c:/logs/access.log" common 為日誌設定存放的地址。這樣就完成了 Apache 日誌的設定工作。

Nginx日誌相關指令主要有兩條：

• log_format，用來設定日誌格式。access_log，用來指定日誌檔案的存放路徑、格式和快取大小。

1）log_format格式

log_format name（格式名稱）格式樣式（即想要得到什麼樣的日誌內容）

預設的示例：

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

註釋如下。

• $remote_addr: 與$http_x_forwarded_for 一起用以記錄客戶端的IP地址。
• $remote_user: 用來記錄客戶端使用者名稱稱。
• $time_local: 用來記錄訪問時間和時區。
• $request: 用來記錄請求的URL和HTTP協議。
• $status: 用來記錄狀態：成功是200。
• $body_bytes_sent: 記錄傳送給客戶端檔案主體內容大小。
• $http_referer: 用來記錄從哪個頁面連線訪問過來的。
• $http_user_agent: 記錄客戶瀏覽器的相關資訊。

通常Web伺服器放在反向代理的後面，這樣就不能獲取到客戶的IP地址了，通過$remote_add得到的IP地址是反向代理伺服器的IP地址。反向代理伺服器在轉發請求的HTTP頭資訊中，可以增加x_forwarded_for資訊，用以記錄原有客戶端的IP地址和原來客戶端的請求的伺服器地址。舉例如下：

log_format  mylogformat '$http_x_forwarded_for- $remote_user [$time_local] "$request" '
                        '$status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent"';

2）用access_log指令日誌檔案存放路徑

用了log_format指令設定了日誌格式之後，需要用access_log指令指定日誌檔案的存放路徑。

access_log path（存放路徑） format（自定義日誌名稱）

示例：

#access_log  logs/access.log   main;

我們用log_format定義了一個mylogformat的日誌，可以寫成這樣：

access_log  logs/access.log   mylogformat ;

如果不想啟用日誌；

access_log off ;

在定義日誌目錄要注意的是，Nginx程序設定的使用者和組必須有對該路徑建立檔案的許可權，假設Nginx的usr指令設定的使用者名稱和使用者組都是www，而logs目錄的使用者名稱和組都是root，那麼日誌檔案將無法被建立。

接著讓使用者在正常情況下使用一段時間這個配置了日誌的系統，就能得到大量的訪問資料，以便進行下一步的日誌分析工作。

什麼是日誌分析？雖然現在得到了使用者的訪問日誌，但是面對數以億計的使用者請求記錄，如何才能從這眾多的資料中找到想要的資料，這個時候就需要通過日誌分析工具來實現了，這也是為什麼在前面需要規範日誌格式的原因，否則工具會不支援自定義的日誌格式。

日誌的分析工具其實也很多，這裡介紹的是WebLog Expert。作為一個強有力的日誌分析工具，WebLog Expert能夠分析網站的流量記錄，將原始的流量記錄分析出Activity statistics、Access statistics、Information about visitors、Referrers、Information about errors等基本而重要的流量資訊，幫助你瞭解網站的使用情況，另外它同時支援IIS和Apache日誌也是我們選用該軟體的原因之一。

整個工具的使用比較簡單，開啟WebLog Expert，單擊新建按鈕，建立一個新的分析日誌專案，填寫專案名稱和伺服器地址後，選擇事先準備好的日誌檔案，如下圖所示：

 一般來說IIS的日誌都預設存放在inetpub\logs\LogFiles地址下，在這個目錄下會看到以W3SVC1開頭的目錄，該目錄中有很多.log檔案，這些檔案就是使用者訪問IIS所留下的訪問日誌。如果是Apache或Nginx日誌請檢查主配置檔案中定義的日誌存放地址。

新增完成後，單擊下一步按鈕，確認需要分析的時間段，如下圖所示：

 WebLog Expert支援多種時間過了規則，由於這裡是裡的日誌比較小，所以我們選擇All activity選項對日誌中所有的時間段進行分析，後面的跟蹤型別和過濾規則一般不設定，接著轉到最關鍵的地方，如下圖所示：

使用日誌分析工具的核心就是生成的報告能幫助我們挖掘到那些感興趣的內容，這裡WebLog Expert支援輸出HTML/PDF/CVS等格式的分析報告，還可以自定義輸出的格式和分析報告的內容，選中Custom report content後可以自定義需要輸出的報告內容，如下圖所示： 

系統提供了大量的報告選項可以根據情況進行定義。當這些都做完後，單擊完成按鈕，結束日誌分析設定。單擊選單中的Analyze按鈕，稍等片刻便會生成一份詳盡的日誌分析報告（使用者行為記錄），如下圖所示：

通過這份報告，可以得到系統當前的負載情況，如果能夠結合同時期的系統資源日誌和系統錯誤日誌，就能夠得到非常珍貴的效能測試資料（系統在過去的負載情況以及對應資源的利用率和響應時間），為後期的效能調優提供基準資料。接下來看看一個真實的系統所得到的日誌資料，如下圖所示： 

 這是某個論壇系統在2008年8月19日至2008年9月1日的系統訪問日誌分析報告，整個日誌大約12GB，分析這個日誌檔案也需要點時間。

通過這個簡單的Summary可以粗略地瞭解系統當前的一些基礎效能指標。在大約兩週的時間內，整個系統共有581427人訪問，共產生29930396次點選，總頻寬使用1849.27GB。

是不是得到這些資料就能做效能測試了呢？非也！平均資料和總計資料其實對於做效能測試並沒有什麼用處，因為訪問並不是平均的，從測試的角度，更在意峰值資料。整個系統只要能夠瞞足使用者在真實訪問下的峰值資料，就能保證整個系統能夠滿足使用者的效能需求。所以一般橋或堤壩是按照50年一遇標準或者100年一遇標準來修建，其實就是根據歷史記錄獲得峰值的情況，按照這個標準來衡量效能。

那麼如何獲得峰值資料呢？我們來看看這份日誌報告中還能得到什麼。首先如果想知道在這段時間內，哪一天的訪問量是最高的，可以找到日誌中的Activity Statistics標籤，這裡提供的都是訪問量的統計，開啟該標籤即可得到在這段時間內系統的訪問資料。首先映入眼簾的是每日訪問量、每日點選量、每日頻寬統計表和生成這些圖所使用的資料表。

 

 

 通過分析這些資料，可以輕鬆地獲得系統的每日峰值吞吐量和峰值訪問量，從而建立效能測試需求的指標（目標場景的依據），另一方面也得到了使用者訪問系統的真實情況（手工場景），那麼是不是可以參考這個資料來生成場景了呢？

無論對於目標場景還是手工場景來說，上面的這些資料以天為單位還是大了一些，無法得到更精確的資料，不利於效能分析。那麼繼續往下看日誌分析，即可得到每天各小時訪問量統計圖，如下圖所示：

 當看到下圖的時候，大家肯定有一種豁然開朗的感覺，原來想得到的資訊就是這個啊。在下圖中可以看到一天中各個時間點上的系統訪問量，在這個週期中可以發現對於每天來說使用者的訪問量並不是平均的。

通過日誌分析可以發現一天的訪問量是出現在圖上的0:00（注意日誌時間是根據該作業系統的系統時間設定的，按照時差轉換為中國時間需要倒扣8小時），也就是北京時間PM8:00，這就是系統的峰值資料，在這一個小時中收到的負載量如下表所示：

Hour	Hits	Page Views	Visitors	Bandwidth(KB)
00:00 - 00:59	2,679,676	399,673	41,440	159,594,667

1小時內產生了260萬的點選量、接近40的頁面重新整理、4.1萬訪問使用者和159GB的頻寬。這裡可以計算一下系統有沒有出現頻寬瓶頸，如果系統是在機房託管，頻寬為1000Mbps那麼換算一下就是每秒提供120MB的寬頻，換算成小時是432000MB的寬頻也就是432GB/小時，所以還沒有達到頻寬峰值，沒有明顯的頻寬瓶頸出現。那麼什麼時候會出現頻寬瓶頸呢？

當系統的訪問量達到600萬點擊量、120萬頁面重新整理、12萬線上使用者的時候，頻寬已經無法承受這些負載帶來的頻寬需求了，結果就是每個使用者所能分享到的頻寬降低，訪問速度變慢。

通過以上資料可以得到最終的峰值效能需求（如果需要精確到分鐘的峰值效能，那麼該工具無法提供，可以自行編寫程式對日誌進行分析），另一方面場景設定中的手工場景已經可以設計了，只需要按照該日誌的走勢就可以得到場景模型生成Real-Life Scenario。

1）目標場景設計（預估系統擴張規模，預留20%增長空間）

在1小時內，系統承受5萬用戶線上、頁面重新整理48萬次、點選量320萬、頻寬吞吐量191GB，在該負載下CPU以記憶體資源利用率低於80%，無明顯磁碟網路瓶頸。

2）手工場景（Real-World Scenario）

根據日誌中的使用者訪問趨勢，可以設計得到如下圖所示的Real-life Scenario（計算了20%的富餘）。

3）手工場景（Basic Scenario）

通過日誌得知了最大使用者線上數，就可以得到Basic下的手工場景。設定使用者最大訪問量為5萬用戶，持續1小時，根據具體情況（設定負載生成速度和負載取消速度），瞭解在負載逐漸增加到5萬用戶的過程中，系統各資源是否走向瓶頸，在峰值負載下，獲得系統的峰值效能資料，並驗證能否滿足使用者需求。

除了目標場景和手工場景的資訊以外還能獲得什麼資訊呢？對於效能測試來說，其實並不需要整個系統的所有功能都達到某個效能，因為有些功能用得多，那麼效能要求就高，而某些功能的使用率非常低，效能方面自然就不做要求。通過日誌可以得到哪些功能和頁面被經常訪問，以確定整個系統承受負載的功能集中在哪裡，效能測試指令碼的目的性會更強。

開啟日誌的Access Statistics功能，即可得到整個系統使用者訪問最多的頁面分析，還有系統中的檔案、圖片、進入系統頁面、使用者在系統中的操作路徑等資訊。通過這些資訊可以更加準確地編寫有效的測試指令碼來模擬大多數使用者的行為，確保效能負載的真實性。後期的頁面優化也可以參考這裡的常用訪問記錄。

在Daily Page Access圖中可以找到系統被訪問最多的頁面（業務），如下圖所示：

 Visitors表示訪問系統的使用者資訊，對於系統來說還需要考慮訪問使用者的所屬地，由於各地的網路發達程度不同，並且還有跨國訪問的問題，那麼這裡還要考慮模擬使用者的地區性（可以通過設定頻寬速度來模擬真實使用者訪問系統的感受）。

頻寬較小及網路延遲較高的使用者，自然訪問時間會比較長，而和伺服器同一個城市的使用者自然訪問比較快。在下圖中可以發現系統的使用者來著中國，如果希望進一步得到中國城市訪問量的分佈可以匯出資料根據IP規則進行進一步分析。這裡列出系統訪問量最高的20個國家和地區記錄，如下表所示：

 

對我們來說，在確定了系統的主要客戶群以後，效能測試也要兼顧這些地區的網路特點進行測試，從而得到真實的響應時間，避免出現自己訪問很快，但是主要客戶群訪問很慢的尷尬情況。

最後在日誌中還能得到系統執行的錯誤統計。這些錯誤日誌可以幫助我們分析系統存在的問題，另一方面，當進行效能測試後，也可以通過它來了解系統出錯的原因。

衡量效能測試的有效性和真實性也可以通過日誌來實現。如果效能測試後得到的日誌分析結果和真實的歷史日誌資料接近，那麼就可以說明效能測試幾乎完全模擬了使用者的行為，效能負載生成是成功有效的。所以日誌是一個非常大的寶庫，當做好資料探勘後，可以從中得到大量的需求，來指導效能測試的設計和執行。

有一點請不要遺忘，就是系統負載是動態的。某些系統的客戶是固定的，不會有太大的變化。例如，公司內部採用C/S架構的系統，那麼這種系統負載是可控的，而如果是一個對外訪問的B/S架構的網站，對效能測試的資料有一個容量規劃，確保系統在不可控的增長下也能正常使用。而使用者的增長可以參考日誌的變化規律，通過一個模型來預估未來的容量。

根據過去日誌得到的2008年8月最高訪問時間段訪問量，再按照2008年8月月度訪問量7185742對比2011年8月份月度最高訪問量14278923，可以推算出現在我們需要進行效能測試的峰值資料應該為（20%富餘處理能力保留）：

在一小時內，系統承受10萬用戶線上、頁面重新整理96萬次、點選量640萬、頻寬吞吐量382GB，在該負載下CPU及記憶體資源利用率低於80%，無明顯磁碟網路瓶頸。

進一步我們可以通過策略來對上線環境進一步的預估。

• 通過硬體評測一般每臺伺服器支撐動態請求1000個/臺/s，每臺伺服器支撐靜態流量400M/臺/s。
• 現在知道系統1小時有96萬次的頁面重新整理，預設每個頁面重新整理包括1~3個動態請求，那麼每秒的併發請求最大為(960000*3)/(1*3600)=800個/s，按照峰值併發為平均併發10倍來計算，最大併發量為8000個/s，所以8000/1000=8大約需要8臺伺服器來完成動態請求處理。
• 預計每個頁面包含img/js/css/50個靜態檔案，平均併發=960000/(1*3600)*50=13333/s，峰值併發約140000/s。
• 預計每個檔案5Kb，平均頻寬=960000/(1*3600)*50*5*8約0.521Gb/s，峰值頻寬約=5~5.5Gb/s，根據靜態容量指標需要13~14臺伺服器。*8的作用是單位換算從Kb換做KB。
• 根據運營經驗值，頁面：圖片：素材=14%：64%：22%，推導各業務模組頻寬=頁面13G：圖片59G：素材20G，再通過各業務模組的容量指標推導需要多少臺接入伺服器，根據接入伺服器反推需要多少中間層伺服器。

根據業務監控資料，電信：網通=2:1，推導電信、網通個需要多少頻寬，在推導平均分佈到現有電信、網通IDC，根據每個IDC需要支撐的頻寬，反推每個IDC需要上架構多少伺服器。

3. 通過參考同類業務

如果需要新建一個專案，而從前有沒有想關的歷史記錄，前面通過日誌的方法就不能使用了，不過這時可以參考一下同類的業務。

雖然是第一次做這類專案，但是並不代表別人沒有做過，可以參考一下別人是怎麼做的。

例如：如果希望自己做一個51Testing規模的技術論壇，那麼在進行效能測試時需要達到的效能指標是什麼呢？答案很簡單，打電話給51Testing說想要購買一個首頁廣告位，瞭解一下訪問量和相關業務即可。

4. 通過80/20原則

80%的功能只會有20%的使用者訪問，反過來也可以說80%的使用者只使用20%的功能。對於效能測試來說並不需要確保整個系統所有的功能都能完全滿足效能需求，而是應該把精力集中在使用者最常使用的功能上。

通過這個規則結合前面的日誌或者同類項目使用者的訪問特徵，可以對系統的功能進行劃分，將不太常用的功能刪除，得到最終的效能需求。

通過上面幾種方法還可以根據國家或行業規範標準來確定需求，從而得到Discuz或Phpwind論壇的效能測試目標，包括目標場景和手工場景的場景模型，以及效能測試的主要業務。

到了這裡我們再回來看看最開始提的問題，上海地鐵人民廣場1號線站臺和換乘大廳的樓梯應該修建多寬？

現在知道怎麼確定這個需求了麼？接著我們來計算一下這個需求應該怎麼寫。

樓梯的主要作用是解決換乘大廳和地鐵月臺兩個系統的介面，如果不能及時將月臺上的乘客通過樓梯輸送到換乘大廳沒那麼就會導致很嚴重的月臺擁堵，甚至出現地鐵上的顧客下不了車，月臺上的顧客上不了車的情況。這裡我們不考慮月臺和換乘平臺的效能瓶頸，假設這兩個系統都不存在問題，那麼樓梯要解決的就是講月臺上的乘客及時送上換乘大廳。

到底有多少乘客要送上換乘大廳呢？這裡我們計算一下地鐵到站的頻率，根據百度百科（https://baike.baidu.com/view/1199997.htm）和新華網新聞（http://www.yn.xinhuanet.com/newscenter/2011-05/18/content_227916.htm），可以查詢到的結果高峰期發車頻率在2分44秒，而每節車廂設計容量320人（高峰時期能擠入400人），也就是說一列地鐵（8節）大概能夠容納3200人，由於人們廣場站是雙向的，所以平均1分22秒就會有一列地鐵導致下車。假設到達人們廣場站有65%的乘客需要下車換乘（這裡需要現場監控評估），也就是說樓梯需要在1分鐘22秒內將3200*0.65=2080名乘客從月臺上疏散。這裡還是理論情況，因為地鐵不會那麼平均到站，經常會出現擁堵導致多輛地鐵連續到進站的情況，由於前面月臺設定了足夠的處理能力，所以這裡我們不考慮月臺放不下那麼多乘客的情況。對乘客的疏散能力做一個小的限制，將處理時間從1分22秒限制到1分10秒（也就是70秒），提供12秒的富餘空間。

那麼70秒如何疏散2080名乘客呢？按照月臺到換乘大廳有4個樓梯來計算，每個樓梯平均要在70秒疏散520名乘客，約等於8乘客/秒，扣除自動扶梯的每秒2乘客處理能力，我們只需要設計一個能同時6乘客上樓的樓梯即可。按照一部自動扶梯和6人並排上樓的樓梯為基礎，我們可以得到樓梯的設計寬度約為4米，這裡不包括兩部自動扶梯的情況和有乘客需要從換乘大廳下到月臺的情況，如果包含這兩點，那麼樓梯設計應該在7米以上，如果乘客過多，需要限制下月臺的人數，避免月臺出現無法容納的問題。

有時候經常在地鐵上有人抱怨上海的地鐵怎麼擁擠，提議應該多開幾部地鐵，想法雖然是好的，但是這樣的做法並不一定能得到應有的效果。因為表面的瓶頸是在地鐵的數量上，但隱藏的瓶頸是在月臺的大小疏散能力，否則車再多都在等人下車上車也快不起來。另一方面不斷地減少地鐵班次的間隔時間從技術角度不會有太大的問題，但是一旦系統在超設計負載下出現某些Bug，那麼“輕微性碰擦”的事件就在所難免了。

解決地鐵擁堵的方法一般都是採用合理的線路安排，例如，4號線改變了很多張江男女的路線，為1、2號線中心地段提供了大量的分流。如果需要解決上下車效率的問題，那麼8號線的左右兩邊門一起開，是一個非常好的辦法，也許在不遠的將來我們會看到1、2號線人民廣場站會出現兩邊一起開門的情況（實施難度和成本有點高）。

通過效能需求分析我們需要達到以下目的：

• 知道使用者會做什麼。
• 知道使用者怎麼做這件事情。
• 知道多少使用者做這件事情。
• 知道對呀的效能指標是什麼。

效能需求是需求分析人員需要提供的重要文件之一，作為效能測試工程師來說也需要具備一定的效能分析及評審的能力。

1.1.3 明確定義概念

通過上面的效能需求分析得到了關鍵的使用者需求規格，接著需要對需求規格轉化成效能測試工具中的目標。

✔  明確定義概念需要知道測試的最終目標是什麼。

在效能測試中需要的目標主要為在一定的負載下系統主要業務操作的響應時間、伺服器的資源佔用率、不同業務的最大吞吐量、系統所能支援的線上使用者數以及主要業務的併發處理能力。另外也可以使用LoadRunner自帶SLA的一些指標來做參考項，如系統在負載過程中的錯誤產生情況和響應時間的變化情況，以及系統在整個效能測試過程中的總點選量、平均每秒點選量、總頻寬使用量和平均每秒頻寬使用量。

這裡需要明確的內容包括：

• 系統真實環境平臺的架構及軟硬體標準。
• 需要進行效能測試的模組以及對於案例。
• 指令碼開發中可能需要解決的技術。
• 業務完成與否的判斷標準。
• 相關資訊的監控策略。
• 場景模型的定義。
• 對系統負載後的結果預估。

明確相關的效能測試目標後，即可開始測試計劃文件的編寫工作。

1.1.4  編寫效能測試計劃

編寫效能測試計劃的目的是為了整個效能測試階段的管理工作和技術工作提供指南，在測試計劃中需要明確測試的內容和範圍，為評價系統提供依據，此外還需要說明對裝置及人員資源的要求，依據測試結果的評價指標。

如果被測系統比較簡單，那麼可以在效能測試計劃中直接明確測試的方法及物件，而如果是一個比較大的專案，建議使用性測試方案文件來說明效能測試的實施方法。針對於我們這次所需要測試的專案情況，將前面的內容整理後可以得到以下的而測試計劃。

---

Phpwind 系統性能測試計劃

文件目的

描述Phpwind效能測試流程、範圍、環境、風險等因素作為效能測試實施依據。

專案背景介紹

Phpwind作為國內知名的通用型系統品牌，憑藉其產品的非凡速度、強大的功能模組、卓越的負載能力、領先的技術優勢、富於創新的研發團隊及自主版權的核心競爭力，為眾多行業門戶、專業型站點提供最有價值的方案和技術保障。致力於推動網際網路資訊的交流與共享，將開源共享與合作創造財富的理念作為公司的發展宗旨。

Phpwind Board（中國國家版權局著作權登記號為2004SR06082）擁有眾多原創的核心技術，包括獨創的模組設計思想、成熟的資料庫設計理念、索引資料檔案的利用及其演算法、檔案讀寫穩定性演算法、資料庫索引負載均衡演算法、安全防護技術等。基於Phpwind的優異效能，公司成為浙江省Linux專業委員會會員單位，並獲得Linux產品測評證書。

通過這次效能測試，為評估Phpwind8.5和DiscuzX2論壇之間的優劣，並獲得允許該論壇的最佳配置，提供參考資料及結論。

術語及縮寫

1. 效能測試（Performance Testing）：在一定的負載情況下，西柚的響應時間、吞吐量等特性是否滿足特定的效能需求。
2. 負載測試（Load Testing）：在一定軟體、硬體及網路環境下，在不同虛擬使用者數量的情況下執行一種或多種業務，測試伺服器的效能指標是否在使用者的要求範圍內，用於確定系統所能承受的最大使用者數、最大有效使用者數以及不同使用者數下的系統響應時間和伺服器的資源利用率。
3. 壓力/強度測試（Stress Testing）：在一定軟體、硬體及網路環境下，通過模擬大量的虛擬使用者向伺服器產生負載，使伺服器的資源處於極限狀態下長時間連續執行，已測試伺服器在高負載情況下是否能夠穩定工作。
4. 配置測試（Configuration Testing）：在不同的軟體、硬體以及網路環境下，在一定數量虛擬使用者執行一種或多種業務，獲得不同配置的效能指標，用於選擇最佳的裝置及引數配置。
5. 基準測試（Benchmark Testing）：在不同的軟體、硬體以及網路環境下，模擬一定數量虛擬使用者執行一種或多種業務，將測試結果作為基準資料，在系統調優或者系統評測過程中，通過執行相同的業務場景比較測試結果，確定調優是否達到效果或者為系統的選擇提供決策依據。
6. LAMP、LNMP、LANMP（LNMPA）：LAMP是Linux+Apache+MySQL+PHP的縮寫，是一種常見的PHP架構。LNMP是Linux+Nginx+ MySQL+PHP的縮寫，由於Nginx在靜態頁面處理上相對Apache有超高的處理能力，所以現在更為流行Nginx作為Web服務，但PHP模組無法直接在Nginx上執行，所以是單獨作為CGI模式執行的，相對來說沒有Apache整合模式執行穩定，容易出現502錯誤。LANMP（LNMPA）是結合了LAMP和LNMP的有點誕生的新型架構，使用Apache模式執行動態頁面，使用Nginx執行靜態頁面，從而獲得性能和穩定性的最大化收益。
7. CentOS：CentOS（Community ENTerprise Operating System）是Linux發行版本之一，它來自Red Hat Enterprise Linux依照開放原始碼規定釋出的原始碼所編譯而成的。由於出自同樣地原始碼，因此有些要求高度穩定性的伺服器以CentOS替代商業版的Red Hat Enterprise Linux使用。兩者的不同，在於CentOS並不包含封閉原始碼軟體。

輸入

《專案計劃文件》

《效能需求規格說明書》

《系統架構設計文件》

《系統測試計劃》

入口標準

無

系統執行環境

1. 網路拓撲圖

1. 軟硬體配置

裝置名稱	硬體配置	軟體配置	備註
伺服器	CPU： I7 930 2.8GHZ 133x21 記憶體： DDR3 1333 2GB X 3（三通道） 硬碟： ST 7200.12 1TB（7200轉\32MB 快取）X2 RAID 0 網絡卡： Intel10/100/1000 自適應	作業系統： Windows 7 X64 SP1 6.1.7601 VMware8.0.0 build-47178 CentOS 5.5. 32位 CentOS 5.6. 64位 Web服務： Apache Nginx 資料庫： MySQL 監控工具： Nmon Spotlight Rpc.rstatd	所有測試環境均在虛擬機器下完成，虛擬機器預設配置均為雙CPU雙執行緒，2GB記憶體
負載生成器	CPU： Inter I3 3210 記憶體： DDR3 1333 6GB 硬碟： 500GB（7200轉） 網絡卡： Realtek PCle GBE Family Controller	作業系統： Windows 2008 R2 SP1 負載生成工具：LoadRunner 11

測試內容

根據效能測試需求分析，在本次測試中我們需要對Phpwind論壇的瀏覽、發帖、註冊及查詢功能進行效能測試，評估LAMP、LNMP、LANMP三大主流架構在CentOS系統32位及64位下的執行表現，確認何種框架更加適合執行論壇系統，進一步得到各個功能在一定平臺下的最大資料處理能力。最終在最優平臺下對比DiscuzX2論壇執行效率，得到最佳硬體平臺下的執行對比。

非測試內容

由於以下功能在真實情況中使用較少，並對響應時間無明確需求，故不進行測試：

1. 使用者間的簡訊息功能
2. 帖子的移動管理功能
3. 論壇後臺的管理功能

角色和職責

角色	資源數量	職責	備註
測試經理	1	跟蹤監督效能測試專案進度 稽核效能測試報告
高階效能測試工程師	1	撰寫效能測試計劃 分析效能需求，制定效能測試方案、測試用例 設計效能測試場景及效能測試平臺 輔助開發人員修改效能缺陷 撰寫測試報告
效能測試工程師	1	開發效能測試指令碼 執行效能測試場景 搭建測試環境	相關推薦 效能測試實戰--計劃測試（一）   一、效能測試流程 計劃測試->建立指令碼->建立場景->執行場景->分析效能資料->生成x效能測試報告，如下圖所示： 1.1 計劃測試 在任何型別的測試中，編寫測試計劃都是必要的步驟。有條不紊、計劃周密的計劃，可以確保在執行中能夠有章 效能測試常見的指標（一）   效能測試最基本要考慮以下幾點： 1、時間特性，主要指的是軟體產品的事物響應時間（使用者發出請求到收到應答的這段時間） 2、資源利用率，包括：cpu、記憶體、網路、硬碟、虛擬記憶體（如Java虛擬機器） 3、伺服器可靠性，指伺服器能在相對高負載情況下持續的執行 4、可配置優化性，指伺服器 效能測試工具操作資料庫（一）-Loadrunner與Mysql 分別庫檔案和程式碼新增到Loadrunner bin目錄和include目錄下 2、vuser_init檔案新增程式碼： #include "Ptt_Mysql.h" #include "mysql OPENCV----在APP性能測試中的應用（一） 核心 color frame pan ems span urn sqrt || 應用項目： APP的性能測試 應用場景： APP啟動速度 視頻開播速度 加載速度 等~~ 緣來： 基於APP日誌和UiAutomator的測試方案，測試結果不能直白且精確的 selenium + python自動化測試unittest框架學習（一）selenium原理及應用 自動化 網上 下載安裝 src .cn 基礎 client cnblogs pytho unittest框架的學習得益於蟲師的《selenium+python自動化實踐》這一書，該書講得很詳細，大家可以去看下，我也只學到一點點用於工作中，閑暇時記錄下自己所學才能更加印象深刻 shell中條件測試常用的語法（一） shell中條件測試常用的語法     shell   bashshell中條件測試常用的語法（一）執行條件測試表達式後通常會返回“真”或“假”，就像執行命令後的返回值為0表示真，非0表示假一樣。在bash編程裏，條件測試常用的語法形式如下：說明：（1）語法1與語法2是等價的， Web網站的測試流程和方法（一） 不同的 ui測試 放置 有時 測試流程 數據 測試的 雲測 切換 近期，Alltesting的眾測平臺　　有不少web網站的功能測試項目，像：　　農事GERP種植系統 　　雲測試平臺 　　頭號專家網項目第三輪功能測試 　　於是，有些新加入眾測平臺的 測試平臺開發記錄（一） 文檔 直接 重新整理 繼續 框架 運行 自動化 一點 開發 最近幾個月最主要的工作就是測試平臺開發，由於內容比較多，我計劃分幾期來討論。 提到“測試平臺”測試會覺得比較高大上，其實就是“xx測試管理系統”，既然是一個管理系統，又是主要服務於測試的，所以，主要功能就是：管理接 測試環境docker化（一）—基於ndp部署模式的docker基礎鏡像制作 XML spl nec 快速部署 onf 問題 java 加載 ons 本文來自網易雲社區作者：孫婷婷背景我所在測試項目組目前的測試環境只有一套，在項目版本叠代過程中，開發或產品偶爾會在測試環境進行數據校驗，QA人數在不斷增加，各個人員在負責不同模塊工作時也會產生臟數據，導 一個人的武林：滲透測試常規思路分析（一） 寫在前面 滲透測試是門技術，也是一門藝術。 這門技術（藝術）一開始也不是每個人都會的，正所謂沒有人一出生就會走路，從不懂到入門到深諳，一步步慢慢來，每個人都是這樣；但是在這個過程中，思路無疑是最重要的，沒有做不到只有想不到，就跟咱們高中解題時有了思路就迎刃而解一樣，手裡拿著鏟子（技巧知識）但不是道從何挖起 軟體測試工程師筆試題（一） 軟體測試筆試題(答案) 判斷題1．軟體測試的目的是儘可能多的找出軟體的缺陷。（Y） 2．Beta 測試是驗收測試的一種。（Y） 3．驗收測試是由終端使用者來實施的。（N） 4．專案立項前測試人員不需要提交任何工件。（Y） 5．單元測試能發現約80% 軟體測試基礎知識總結（一） 一、什麼是軟體測試？ 1、軟體測試是指使用人工或者自動手段，來執行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。 二、一般的軟體測試的應用場景有： APP、WEB和小程式。 三、軟體測試的發展歷程： 軟體測試從開始到現在，已經經歷了三個階段的發展，到現在 軟件測試基礎知識總結（一） 質量 本質 峰值 驗收測試 分類 過渡 等等 用戶 基礎知識總結 一、什麽是軟件測試？ 1、軟件測試是指使用人工或者自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。 二、一般的軟件測試的應用場景有： APP、WEB 介面測試基礎與工具（一） 介面測試是整合測試實現的一種方式，分為： 訊息介面測試 程式碼介面測試兩類 本章主要還是針對訊息介面為主的。 1 介面測試基礎   1.1 什麼是介面測試 介面是指系統模組與模組或系統與系統間進行互動，一般現在我們用的多的是基於HTTP協議為基礎的介 Java單元測試工具：JUnit4（一）——概述及簡單例子 （一）JUnit概述及一個簡單例子         看了慕課網的JUnit視訊教程： http://www.imooc.com/learn/356，總結筆記。         這篇筆記記錄JUnit的 網易自動化測試工具Airtest初探（一） Airtest是一款自動化測試工具，主要是基於影象和poco控制元件識別。該工具是由網易遊戲團隊自主研發的工具。 主要有以下優點： 1、上手簡單、低門檻，僅需要了解一點點的python語法，便可以實現指令碼編寫和錄製。 2、執行日誌齊全，還可以一鍵生成報告。 3、最新版本已經支援 Web自動化測試Selenium 學習筆記（一） 1、Web自動化測試簡介自動化基礎：自動化用例編寫、Selenium優勢及原理、自動化環境搭建Selenium基礎：常見8大元素定位（表格）、常見元素處理、下拉框元素處理、不同視窗切換、元素進階、元素等待需求到框架    需求分析-用例設計-基礎指令碼-登入/購物指令碼重構- 軟體測試常見面試題（一） 1、開發犯低階錯誤怎麼辦？ 開發首先要規範好編碼，出低階錯時不要職責，內心指出錯誤。讓他們自己進行測試，反思找出錯誤。 2、你進行過那些測試，擅長什麼？ 我主要從事web測試，搭建環境，對程式進行整合測試、系統測試、迴歸測試。還有編寫測試用例，使用手冊，功 Selenium測試結果視覺化工具--Sahagin測試框架使用入門（一） @Test public void inquiryTest_2() { wd.get("http://www-demo.trident-qa.com/en/contact/"); wd.findElement(By.name("your-name")).clear(); wd.find Selenium2 Python 自動化測試實戰學習筆記（四） 第五章          自動化測試模型 一個自動化測試框架就是一個整合體系，在這一體系中包含測試功能的函式庫、測試資料來源、測試物件識別標準，以及種可重用的模組。自動化測試框架在發展的過程中經歷了幾個階段，線性測試、模組驅動測試、資料驅動測試、關鍵字驅動測試。 Pytho