web測評圖

⑴ Web測試的主要內容和測試方法有哪些

測試分類：

1、界面測試

1）給用戶的整體感：舒適感；憑感覺能找到想要找的信息；設計風格是否一致

2）各控制項的功能

2、功能測試

1）刪除/增加某一項：是否對其他項造成影響，這些影響是否都正確

2）列表默認值檢查

3）檢查按鈕功能是否正確：新建、編輯、刪除、關閉、返回、保存、導入、上一頁、下一頁、頁面跳轉、重置（常見錯誤）

4）字元串長度檢查：超出長度

5）字元類型檢查

6）標點符號檢查：空格、各種引號、Enter鍵

7）特殊字元：常見%、「、」

8）中文字元：是否亂碼

9）檢查信息完整：查看信息，查看所填信息是否完整更新；更新信息，更新信息與添加信息是否一致

10）信息重復：需唯一信息處，比如重復的名字或ID、重名是否區分大小寫、加空格

11）檢查刪除功能：不選擇任何信息，按Delete，看如何處理；選擇一個或多個進行刪除；多頁選、翻頁選刪除；刪除是否有提示

12）檢查添加和修改是否一致：添加必填項，修改也該必填；添加為什麼類型，修改也該什麼類型

13）檢查修改重名：修改時把不能重名的項改為已存在的內容

14）重復提交表單：一條已經成功提交的記錄，返回後再提交

15）檢查多次使用返回鍵：返回到原來頁面，重復多次

16）搜索檢查：存在或不存在內容，看搜索結果是否正確；多個搜索條件，同時輸入合理和不合理條件；特殊字元

17）輸入信息的位置

18）上傳下載文件檢查：功能是否實現，

上傳：上傳文件是否能打開、格式要求、系統是否有解釋信息、將不能上傳的文件格式修改後綴為可上傳的文件格式；

下載：下載是否能打開、保存、格式要求

19）必填項檢查：必填項未填寫；是否有提示，如加*；對必填項提示返回後，焦點是否自動定位到必填項

20）快捷鍵檢查：是否支持快捷鍵Ctrl+C、Ctrl+V、backspace；對不允許做輸入的欄位（如：下拉選項），對快捷方式是否也做了限制

21）Enter鍵檢查：輸入結束後按Enter鍵，系統如何處理

22）刷新鍵檢查：按瀏覽器刷新鍵如何處理

23）回退鍵檢查：按瀏覽器回退鍵如何處理

24）空格檢查：輸入項輸入一個或多個空格

25）輸入法半形全形檢查：比如，浮點型，輸入全形小數點「。」或「. 」，如4. 5；全形空格

26）密碼檢查：輸入加密方式的極限字元；密碼盡可能長

27）用戶檢查：不同種類管理員用戶的不同許可權，是否可以互相刪除、管理、編輯；一般用戶的許可權；注銷功能，老用戶注銷再注冊，是否為新用戶

28）系統數據檢查：數據隨業務過程、狀態的變化保持正確，不能因為某個過程出現垃圾數據，也不能因為某個過程而丟失數據。

29）系統可恢復性檢查：以各種方式把系統搞癱，測試系統是否可以迅速恢復

30）確認提示檢查：系統更新、刪除操作：是否有提示、取消操作；提示是否准確；事前、事後提示

31）數據注入檢查：對資料庫注入，特殊字元，對SQL語句進行破壞

32）時間日期檢查：時間、日期、時間驗證：日期范圍是否符合實際業務；對於不符合實際業務的日期是否有限制

33）多瀏覽器驗證

3、性能測試

1）壓力測試：實際破壞一個Web應用系統，測試系統的反應，測試系統的限制和故障恢復能力

2）負載測試：在某一負載級別上的性能，包括某個時刻同時訪問Web的用戶數量、在線數據處理的數量

3）強度測試：測試對象在性能行為異常或極端條件下（如資源減少或用戶過多）的可接受性，以此驗證系統軟硬體水平

4）資料庫容量測試：通過存儲過程往資料庫表中插入一定數量的數據，看是否能及時顯示

5）預期指標的性能測試：在需求分析和設計階段會提出一些性能指標，對於預先確定的性能要求要首先進行測試

6）獨立業務性能測試：對核心業務模塊做用戶並發測試，包括同一時刻進行完全一樣的操作、同一時刻使用完全一樣的功能

7）組合業務性能測試：模擬多用戶的不同操作，最接近實際用戶使用情況，按用戶實際的實際使用人數比例來模擬各個模塊的組合並發情況

8）疲勞強度性能測試：系統穩定運行情況下，以一定負載壓力來長時間運行系統的測試

9）網路性能測試：准確展示帶寬、延遲、負載、埠的變化是如何影響用戶的相應時間的

10）大數據量性能測試：實時大數據量，模擬用戶工作時的實時大數據量；極限狀態下的測試，系統使用一段時間，積累一段數據量時能否正常運行，以及對前面兩種進行結合

11）伺服器性能測試：在進行用戶並發性能測試、疲勞強度、大數據量性能測試時，完成對伺服器性能的監控，並進行評估

12）一些特殊的測試：配置測試、內存泄漏的一些特殊測試

4、可用性測試(介面測試）

1）整體界面測試

2）多媒體測試

3）導航測試

5、客戶端兼容性

平台測試：windows；unix；macintosh；linux

瀏覽器測試：不同廠商的瀏覽器對Java、Javascript、ActiveX、plug-ins或不同的HTML的規格

不同的支持；框架和層次結構在不同瀏覽器也不同的顯示

6、安全性

安全性測試要求：

1）能夠對密碼試探工具進行防範

2）能夠防範對Cookie攻擊的常用手段

3）敏感數據保證不用明文傳輸

4）能防範通過文件名猜測和查看html文件內容獲取重要信息

5）能保證在網站收到工具後在給定時間內恢復，重要數據丟失不超過1小時

web的性能測試工具：

隨著Web2.0技術的迅速發展，許多公司都開發了一些基於Web的網站服務，通常在設計開發Web應用系統的時候很難模擬出大量用戶同時訪問系統的實際情況。

因此，當Web網站遇到訪問高峰時，容易發生伺服器響應速度變慢甚至服務中斷。

為了避免這種情況，需要一種能夠真實模擬大量用戶訪問Web應用系統的性能測試工具進行壓力測試，來測試靜態HTML頁面的響應時間，甚至測試動態網頁（包括ASP、PHP、JSP等）的響應時間，為伺服器的性能優化和調整提供數據依據。

1、企業級自動化測試工具WinRunner

MercuryInteractive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。

2、工業標准級負載測試工具Loadrunner

LoadRunner是一種預測系統行為和性能的負載測試工具

3、全球測試管理系統testdirector

TestDirector是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。

4、功能測試工具RationalRobot

IBMRationalRobot是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。

它集成在測試人員的桌面IBMRationalTestManager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。

這種測試和管理的雙重功能是自動化測試的理想開始。

5、單元測試工具xUnit系列

目前的最流行的單元測試工具是xUnit系列框架，常用的根據語言不同分為JUnit（java），CppUnit（C++），DUnit（Delphi），NUnit（.net），PhpUnit（Php）等等。

該測試框架的第一個和最傑出的應用就是由ErichGamma（《設計模式》的作者）和KentBeck（XP（ExtremeProgramming）的創始人）提供的開放源代碼的JUnit.

6、功能測試工具SilkTest

BorlandSilkTest2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。

這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。

7、性能測試工具WAS

是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。

透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。

8、自動化白盒測試工具Jtest

Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。

parasoft同時出品的還有C++test，是一款C/C++白盒測試工具。

9、功能和性能測試的工具JMeter

JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。

10、性能測試和分析工具WEBLOAD

webload是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。

(1)web測評圖擴展閱讀：

漏洞測試

企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的，是通過代碼堆積起來的。如果這個代碼只供企業內部使用，那麼不會帶來多大的安全隱患。

但是如果放在互聯網上使用的話，則這些為實現特定功能的代碼就有可能成為攻擊者的目標。

天眼舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊，來獲取管理員的密碼等等破壞性的動作。

有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時，其實就有可能在安裝一個木馬（這可能訪問者與被訪問者都沒有意識到）。

為此在為網站某個特定功能編寫代碼時，就要主動出擊。從編碼的設計到編寫、到測試，都需要認識到是否存在著安全的漏洞。

天眼在日常過程中，在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。

已知的病毒、木馬不能夠在所開發的插件中有機可乘。通過這層層把關，就可以提高代碼編寫的安全性。

⑵ web測試有哪些方面

第一，分析產品結構，明確性能測試的需求，包括並發、極限、配置和指標等方面的性能要求，必要時基於LOAD測試的相同測略需同時考慮穩定性測試的需求。
第一，分析應用場景和用戶數據，細分用戶行為和相關的數據流，確定測試點或測試介面，列示系統介面的可能瓶頸，一般是先主幹介面再支線介面，並完成初步的測試用例設計。
第三，依據性能測試需求和確定的測試點進行測試組網設計，並明確不同組網方案的重要程度或優先順序作為取捨評估的依據，必要時在前期產品設計中提出支持性能測試的可測試性設計方案和對測試工具的需求。
第四，完成性能測試用例設計、分類選擇和依據用戶行為分析設計測試規程，並准備好測試用例將用到的測試數據。
第五，確定採用的測試工具。
第六，進行初驗測試，以主幹介面的可用性為主，根據測試結果分析性能瓶頸，通過迭代保證基本的指標等測試的環境。
第七，迭代進行全面的性能測試，完成計劃中的性能測試用例的執行。
第八，完成性能測試評估報告。
在進行性能測試的時候，我們需要知道一些有效的性能指標，下面我們來列出一些主要的性能指標：
一是，通用指標（指Web應用伺服器、資料庫伺服器必需測試項）：
*ProcessorTime：指伺服器CPU佔用率，一般平均達到70%時，服務就接近飽和；
*Memory Available Mbyte：可用內存數，如果測試時發現內存有變化情況也要注意，如果是內存泄露則比較嚴重；
*Physicsdisk Time ：物理磁碟讀寫時間情況。
二是，Web伺服器指標：
*Avg Rps：平均每秒鍾響應次數＝總請求時間/秒數；
*Avg time to last byte per terstion（mstes）：平均每秒業務角本的迭代次數；*Successful Rounds：成功的請求；
*Failed Rounds：失敗的請求；
*Successful Hits：成功的點擊次數；
*Failed Hits：失敗的點擊次數；
*Hits Per Second：每秒點擊次數；
*Successful Hits Per Second：每秒成功的點擊次數；
*Failed Hits Per Second：每秒失敗的點擊次數；
*Attempted Connections：嘗試鏈接數。
三是，資料庫伺服器指標：
*User 0 Connections ：用戶連接數，也就是資料庫的連接數量；
*Number of deadlocks：資料庫死鎖；
*Butter Cache hit：資料庫Cache的命中情況）。

可用性測試：1導航測試（Web應用系統的層次一旦決定，就要著手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。）2圖形測試3內容測試3整體界面測試4客戶端兼容性測試（1平台測試2瀏覽器測試）5安全性測試（測試重點：（1）現在的Web應用系統基本採用先注冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。（2）Web應用系統是否有超時的限制，也就是說，用戶登陸後在一定時間內（例如15分鍾）沒有點擊任何頁面，是否需要重新登陸才能正常使用。（3）為了保證Web應用系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。（5）伺服器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯腳本的問題。 ）

⑶ WEB測試應該注意哪些地方，怎樣才能做好WEB

基於Web的系統測試與傳統的軟體測試既有相同之處，也有不同的地方，對軟體測試提出了新的挑戰。基於Web的系統測試不但需要檢查和驗證是否按照設計的要求運行，而且還要評價系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基於Web的系統測試方法。

隨著Internet和Intranet/Extranet的快速增長，Web已經對商業、工業、銀行、財政、教育、政府和娛樂及我們的工作和生活產生了深遠的影響。許多傳統的信息和資料庫系統正在被移植到互聯網上，電子商務迅速增長，早已超過了國界。范圍廣泛的、復雜的分布式應用正在Web環境中出現。Web的流行和無所不在，是因為它能提供支持所有類型內容連接的信息發布，容易為最終用戶存取。

Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作為一門新興的學科，提倡使用一個過程和系統的方法來開發高質量的基於Web的系統。它"使用合理的、科學的工程和管理原則，用嚴密的和系統的方法來開發、發布和維護基於Web的系統"。目前，對於web工程的研究主要是在國外開展的，國內還剛剛起步。

在基於Web的系統開發中，如果缺乏嚴格的過程，我們在開發、發布、實施和維護Web的過程中，可能就會碰到一些嚴重的問題，失敗的可能性很大。而且，隨著基於Web的系統變得越來越復雜，一個項目的失敗將可能導致很多問題。當這種情況發生時，我們對Web和Internet的信心可能會無法挽救地動搖，從而引起Web危機。並且，Web危機可能會比軟體開發人員所面對的軟體危機更加嚴重、更加廣泛。

在Web工程過程中，基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基於Web的系統測試與傳統的軟體測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。因此，我們必須為測試和評估復雜的基於Web的系統研究新的方法和技術。

一般軟體的發布周期以月或以年計算，而Web應用的發布周期以天計算甚至以小時計算。Web測試人員必須處理更短的發布周期，測試人員和測試管理人員面臨著從測試傳統的C/S結構和框架環境到測試快速改變的Web應用系統的轉變。
一、功能測試
1、鏈接測試
鏈接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。鏈接測試可以自動進行，現在已經有許多工具可以採用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之後進行鏈接測試。

2、表單測試
當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給伺服器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。

3、Cookies測試
Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web伺服器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什麼影響等。

4、設計語言測試
Web設計語言版本的差異可以引起客戶端或伺服器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、javascript、 ActiveX、VBScript或Perl等也要進行驗證。

5、資料庫測試
在Web應用技術中，資料庫起著重要的作用，資料庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最常用的資料庫類型是關系型資料庫，可以使用SQL對信息進行處理。在使用了資料庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由於網路速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。

二、性能測試
1、連接速度測試
用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鍾），用戶就會因沒有耐心等待而離開。另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。

2、負載測試
負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量用戶對同一個頁面的請求？

3、壓力測試
負載測試應該安排在Web系統發布以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。
三、可用性測試
1、導航測試
導航描述了用戶在一個頁面內操作的方式，在不同的用戶介面控制之間，例如按鈕、對話框、列表和窗口等；或在不同的連接頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可通過主頁存取？Web系統是否需要站點地圖、搜索引擎或其他的導航幫助？

在一個頁面上放太多的信息往往起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的信息，如果沒有，就會很快地離開。很少有用戶願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要盡可能地准確。導航的另一個重要方面是Web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道Web應用系統裡面是否還有內容，內容在什麼地方。Web應用系統的層次一旦決定，就要著手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。

2、圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要盡量地小，並且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
（2）驗證所有頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮。

3、內容測試
內容測試用來檢驗Web應用系統提供信息的正確性、准確性和相關性。信息的正確性是指信息是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛；信息的准確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟體來進行，例如使用Microsoft Word的"拼音與語法檢查"功能；信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般Web站點中的所謂"相關文章列表"。

4、整體界面測試
整體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個整體感。例如：當用戶瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的信息在什麼地方？整個Web應用系統的設計風格是否一致？對整體界面的測試過程，其實是一個對最終用戶進行調查的過程。一般Web應用系統採取在主頁上做一個調查問卷的形式，來得到最終用戶的反饋信息。對所有的可用性測試來說，都需要有外部人員（與Web應用系統開發沒有聯系或聯系很少的人員）的參與，最好是最終用戶的參與。

四、客戶端兼容性測試
1、平台測試
市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。因此，在Web系統發布之前，需要在各種操作系統下對Web系統進行兼容性測試。

2、瀏覽器測試
瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、javascript、 ActiveX、 plug-ins或不同的HTML規格有不同的支持。例如，ActiveX是Microsoft的產品，是為Internet Explorer而設計的，javascript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。

五、安全性測試
Web應用系統的安全性測試區域主要有：
（1）現在的Web應用系統基本採用先注冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
（2）Web應用系統是否有超時的限制，也就是說，用戶登陸後在一定時間內（例如15分鍾）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
（3）為了保證Web應用系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。
（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
（5）伺服器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯腳本的問題。

六、總結
本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基於Web的系統測試方法。基於Web的系統測試與傳統的軟體測試既有相同之處，也有不同的地方，對軟體測試提出了新的挑戰。基於Web的系統測試不但需要檢查和驗證是否按照設計的要求運行，而且還要評價系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。

⑷ 如何使用LoadRunner進行Web性能測試

1、明確壓力點，根據壓力點設計多少種場景組合
2、把文檔（包括多少種場景組合、場景與場景組合條件的對應表）寫好
3、如果監測UNIX機器，在被監測的機器需要安裝監測Unix的進程
4、讓開發人員幫助我們准備測試數據或他們寫相關的文檔我們來准備數據
5、讓開發人員做一個恢復數據的腳本，以便於我們每次測試的時候都能夠有一個相同的環境
6、針對每一個模塊包括四個子文件夾：如模塊A下包括「腳本」「場景」「結果」「圖表」 四個子文件夾，每個子文件夾儲存對應的文件，如下表所示
其中：結果名「1場景」是在場景中的「Results Setting」中設置的，具體的設置見「建立場景」部分，這里也可以有另外一種方法：在打開模板設置，如下：
選中「Automatically save the session as:」並且在「%ResultDir%」後面填寫你想保存的文件名，當你打開某個lrr文件時，系統自動在當前目錄中生成一個文件保存分析圖表，如下圖所示：
生成測試腳本
1、 把登陸部分放到「vuser_init」部分,把需要測試的內容部分放到「Action」部分執行；但是如果是模擬多個用戶登陸系統，則要把登陸部分放到Action部分來實現
2、 錄制腳本後，想查詢某個函數的原型，按「F1」鍵
3、 確認腳本中哪些參數是需要進行參數化的（最好能可以和開發人員一起確認）
4、 在腳本參數化時把函數web_submit_data()中的ITEMDATA後面的數據參數化，因為這些數據是傳遞給伺服器的，當然也可以把一個函數中的所有相同變數都替換掉
5、 腳本中無用的部分用「/*」「*/」「//」注釋掉，但最好不要刪除
6、 調試腳本遵循以下原則：
確認在VU里SUSI（單用戶單循環次數single user & single iteration）
確認在VU里SUMI（單用戶多循環次數single user & multi iteration）
確認在controller中MUSI（多用戶單循環次數multi user & single iteration）
確認在controller中MUMI（多用戶多循環次數 multi user & multi iteration）
7、 事務的名稱取的有意義便於事務之間的區分，把所有的事務名都記錄在一起，便於在測試結果概要中區分它們，這要寫成一個表：某次測試有哪些模塊，每個模塊中有哪些事務(見對應的「關系表」)
8、 在 「Parameter List」中可以選擇參數類型「Random Number」，使某一個參數取設定的范圍內的隨機值
建立場景
1、 把場景名稱編號，並制定出一份場景名稱和場景條件組合的對應表。比如，場景m對應於「某一模塊_xx個vu _分z台machine」(見「關系表」中的例子)
2、 根據上面的對應表把場景設置好，需要設置的要素如下：總體多少個用戶、分多少個組、每個組有多少個用戶、分幾台機器運行、每個腳本迭代多少次、是否回放think time時間、檢查Parameter List中每個參數設置是否正確、參數從表中取值間隔是否正確、是否選中「Initialize all Vusers before Run」
3、 測試結果應該保存為「m場景0，m場景1,…」
4、 把虛擬用戶分散到幾台機器上和在一台機器上面都要進行測試，因為有可以效果不同
5、 場景中如果有需要改動的地方，必須新建一個場景(建議使用「另存為」，然後再修改結果文件名，再選擇相應的腳本)，並把場景按順序編號，先維護好場景與場景組合條件的對應表，以便以後的查找，並且在結果 「Results Setting」中設置的結果名與場景名相同。建議在「Results Setting」中選中「Automatically create a results directory for each scenario executeon」讓它每次自動累加，不建議選中「Automatically overwrite existing results directory without prompting for confirmation」，因為我們不要覆蓋掉以前的測試結果，把它保存下來以便有個根據。
6、 需要注意的地方：當在「Parameter List」中的「Select next row」選中「Unique」時，如果再在「Edit Schele\Schele by Scenario\Duration」中選中第二項「Run for XX after the ramp up has been completed」時系統就會報錯，提示「Unique」類型不相符。
7、 在「Run-time Setting」設置中，「General」中的「Pacing」非常有用，可以設置每次迭代之間相隔多少時間，也可以是隨機的取值
8、 建議：把「Parameter List」和「Run-time Setting」中的所有設置都搞熟悉，這樣便於以後對腳本和場景進行設置
9、 設計「Parameter List」時的小技巧：即在「Allocate X values for each Vuser」時，盡量 把它的間隔在數據容許的范圍內取大些，這樣可以做從一次迭代到最大值迭代，而且對腳本沒有什麼影響
10、當一個腳本中有多個事務，在事務前面增加集合點時需要一點技巧。或者我們把腳本復制幾個，或者我這樣做：測試前面的事務的壓力時，把後面的事務前的集合點設置為不激活狀態；在測試後面的事務的壓力時，把前面的事務的集合點設置為不激活狀態，另外最好不選中Initialize all Vusers before Run，具體參見Controller中的「Scenario/Rendezvous」，及用戶手冊(按F1)
11、把持續時間從最後60秒改為整個場景的時間，右鍵單擊某個圖，選擇「Configue」，修改Graph Time即可
12、每次從一個場景修改後保存為另一個場景時別忘記把結果保存文件名修改相對應的文件名。在設置結果保存文件名時有一個技巧：如果你打開這個窗口時，點擊確定則系統會
默認以「4場景2」為基點向後加「4場景20」「4場景21」等等，但是如果你把結果文件名後面的數據去掉，改為「4場景」，點擊確定後，系統會自動搜索是以「4場景」開頭的文件名，並在它的後面繼續增加，比如把它改為「4場景」時，下次結果保存在「4場景3」中。而且他在搜索的時候搜索以「4場景」開頭的文件名，從0開始，有的話就不取代而跳過，沒有的話就取代。
運行場景
1、 運行場景前需要注意的事項：每個組的虛擬用戶數、迭代次數、think time、參數化時的取值間隔、執行恢復數據的腳本、確認虛擬機的LoadRunner Agent Service打開
2、 如果監測Unix，運行場景前需要啟動監測Unix進程，啟動的命令「rpc.rstatd」、查看這個進程是否啟動的命令「rpcinfo –p」
3、 運行前使Generator機器處理Ready狀態
4、 確認被監測的機器已經連接上去，並且添加自己所需要的計數器
5、 運行之前一定要確認系統中壓力點的數據量是多少
6、 確認以上都正確時再運行測試場景

監視場景
打開 「Passed Transactions」或「Failed Transactions」，可以隨時觀察到事務的運行狀態
分析測試結果
1、 打開Analysis後，把經過數據處理的結果圖表保存到「圖表」文件夾，並且文件名和場景名、結果名相同，這樣便於以後的查閱。也可以省去每次進行數據處理的時間。
2、 可以通過點擊界面上的 「View Run Time Setting」可以看到此場景運行時的一些場景設置
3、 在關聯圖表時可以自動調節每個元素的比例，點擊右鍵，選擇 即可
4、 每次測試結束後確認所做的操作是正確的，確認正確後再分析結果
5、 在結果文件夾中為每個場景建立一個文檔，把每次運行時的情況記錄下來以便於寫測試報告，尤其運行錯誤的原因記錄下來，並把開發人員所做的修改也記錄下來以便知道開發人員做了些什麼修改
6、 在分析運行結果時可以把幾個結果合在一起進行比較，打開如下「Cross with Result…」

⑸ Web測試的主要內容和測試方法有哪些

1功能測試 2 1.1鏈接測試 2 1.2表單測試 2 1.3數據校驗 3 1.4 cookies測試 3
1功能測試 2
1.1鏈接測試 2
1.2表單測試 2
1.3數據校驗 3
1.4 cookies測試 3
1.5資料庫測試 3
1.6應用程序特定的功能需求 4
1.7設計語言測試 4
2性能測試 4
2.1連接速度測試 4
2.2負載測試 4
2.3壓力測試 5
3用戶界面測試 6
3.1導航測試 6
3.2圖形測試 6
3.3內容測試 7
3.4表格測試 7
3.5整體界面測試 7
4兼容性測試 8
4.1平台測試 8
4.2瀏覽器測試 8
4.3解析度測試 8
4.4 Modem/連接速率 9
4.5列印機 9
4.6組合測試 9
5安全測試 9
5.1目錄設置 9
5.2登錄 10
5.3日誌文件 10
5.4腳本語言 10
6介面測試 10
6.1伺服器介面 10
6.2外部介面 11
6.3錯誤處理 11
7結論 11
在Web工程過程中，基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基於Web的系統測試與傳統的軟體測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。因此，我們必須為測試和評估復雜的基於Web的系統研究新的方法和技術

⑹ WEB標準的標准測試

頁面校驗地址 http://validator.w3.org/
CSS文檔校驗 http://jigsaw.w3.org/css-validator/
XHTML 1.0 標准規格 : The Extensible HyperText Markup Language
W3C標准測試網址 http://validator.w3.org/
測試時一定要有文件類別宣告還有指定文件編碼
<meta http-equiv=Content-Type content=text/html; charset=gb2312 />
才能順利進行測試動作，開始打造一個標準的網站！ 1.XHTML 1.0文件類別宣告的正確寫法 (不可小寫)
過度標准（外語全稱：Transitional）
公共標識符 稱為：「-//W3C//DTD XHTML 1.0 Transitional//EN」。
<!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
>
框架標准（外語全稱：Frameset）
公共標識符 稱為：「-//W3C//DTD XHTML 1.0 Frameset//EN」。
<!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Frameset//EN
>
嚴格標准（外語全稱：Strict） 包含以上須注意的問題,還有其他更嚴格的標准
公共標識符 稱為：「-//W3C//DTD XHTML 1.0 Strict//EN」。
<!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
>
2.頭文件問題
所有的網頁頭文件都一律都改為標准形式，寫法如下： <head><metahttp-equiv=content-typecontent=text/html;charset=gb2312/><metahttp-equiv=content-languagecontent=zh-cn/><metaname=keywordscontent=.../><metaname=descriptioncontent=.../><title>...</title></head>3.不允許使用target=_blank
在HTML4.01可以使用target=_blank,但XHTML1.0是不被允許的.
我使用了一個HTML4.0的新屬性：rel，這個屬性用來說明鏈接和包含此鏈接頁面的關系，以及鏈接打開的目標。
原來這樣寫的代碼： 打開一個新窗口
現在要寫成這樣：打開一個新窗口
這是符合strict標準的方法。當然還必須配合一個javascript才有效。
javascript完整的代碼JS如下： function外部鏈接()//萬國碼unicodejavascript{if(!document.getElementsByTagName)return;varanchors=document.getElementsByTagName(a);for(vari=0;i<anchors.length;i++){varanchor=anchors;if(anchor.getAttribute(href)&&anchor.getAttribute(rel)==external)anchor.target=_blank;}}window.onload=外部鏈接;你可以把它保存成一個.js文件(比如外部鏈接.js)，然後通過外部聯接方法調用：
<script type=text/javascript src=外部鏈接.js></script>
4.XHTML 1.0要求所有的標簽必須關閉
所有沒有成對的空標簽必須以 />結尾
和這就是成對
錯誤
<hr>
正確
<hr />
錯誤 <input type=text name=name>
正確 <input type=text name=name />
錯誤 <meta ...>
正確 <meta ... />
錯誤 <link rel=stylesheet type=text/css href=style.css>
正確 <link rel=stylesheet type=text/css href=style.css />
錯誤 <img src=bg.gif border=0 alt=說明文字>
正確 <img src=bg.gif border=0 alt=說明文字 />
5.所有標簽元素名稱都使用小寫
錯誤 <HTML> <TITLE> <HEAD> <BODY>
正確 <html> <title> <head> <body>
錯誤 <IMG SRC=BG.GIF BORDER=0 ALT=說明文字>
正確 <img src=bg.gif border=0 alt=說明文字 />
錯誤 <UL><LI></LI></UL>
正確 <ul><li></li></ul>
以上只是舉例,是所有標簽元素名稱都必須是小寫
6.同一個id選擇器不可重復使用
一個網頁中id=xx同一個選擇器不能重復使用,若需要重復請用class=xx
7.標簽必須是一對
[font][/font]
8.正確的標簽順序
錯誤文字
正確文字
9.JavaScript寫法
Javascript我們通常會寫為
錯誤 <script language=javascript>
W3C標准必須為程式指定類型type=text/javascript,所以要寫為
正確 <script type=text/javascript>
或者 <script language=javascript type=text/javascript>
載入外部.js獨立檔案的寫法
正確 <script type=text/javascript src=script.js></script>
10.絕對不可省略雙引號或單引號
錯誤 style=font-size:9pt
正確 style=font-size:9pt
錯誤 <img src=bg.gif width=140 height=30 alt=text />
正確 <img src=bg.gif width=140 height=30 alt=text />
錯誤 text
正確 text
11.圖片標簽加上文字說明alt=說明
錯誤 <img src=bg.gif height=50 border=0 />
正確 <img src=bg.gif height=50 border=0 alt=說明文字 />
12.背景音樂不允許使用 bgsound 標簽
我只好用JavaScript解決這個問題。javascript完整的代碼如下：
<!-- Begin
var MSIE=navigator.userAgent.indexOf(MSIE);
var NETS=navigator.userAgent.indexOf(Netscape);
var OPER=navigator.userAgent.indexOf(Opera);
if((MSIE>-1) || (OPER>-1)) {
document.write(<BGSOUND SRC=背景音樂地址 LOOP=INFINITE>);
} else {
document.write(<EMBED SRC=背景音樂地址 AUTOSTART=TRUE );
document.write(HIDDEN=true VOLUME=100 LOOP=TRUE>);
}
// end -->
你可以把它保存成一個.js文件(比如bjmusic.js)，然後通過外部聯接方法調用：
<script type=text/javascript src=bjmusic.js></script>
13. 標簽的爭議
<embed>是Netscape的私有標簽,W3C 從HTML3.2 HTML 4.01 到 XHTML 1.0 中都沒有這個標簽,所以使用的頁面是不能通過標准測試。
W3C推薦使用 <object> 標簽,用<object>插入flash影片的代碼可以寫為:
<object type=application/x-shockwave-flash data=index.swf width=400 height=200>
</object>
但這樣的寫法可能IE5/IE6 Win瀏覽器版本會出現問題。
標簽因為廣大的受到運用,不再標准范圍引起很大的爭議，想要解決這個問題，只能等IE瀏覽器對<object>有更好的支持或者W3C願意收錄標簽。
14. 不允許使用框架標簽<IFRAME>
這次又要用JavaScript解決問題了。javascript完整的代碼如下：
function ifr(url,w,h){document.write('<iframe id=ifr name=ifr width='+w+' height='+h+' border=0 frameborder=0 scrolling=no src='+url+'></iframe>');}
把它保存成一個.js文件(比如ifr.js)，然後通過外部聯接方法調用：
<script type=text/javascript src=ifr.js></script>
在你需要插入框架的地方寫以下代碼即可：
<script type=text/javascript>ifr('需插入的網頁地址','567','485');</script>
函數ifr()使用說明：ifr('這里寫地址','這里寫寬度','這里寫長度',)
15.google廣告問題
google廣告的代碼是不符合W3C標準的，我只好又把它轉成JS調用，但GOOGLE政策里是寫著不允許修改代碼的，
關於這點我正在寫信給GOOGLE詢問中，應該很快會有答案。
我的JS文件(google.js)代碼如下：
document.writeln(<script type= ext/javascript><!--);
document.writeln(google_ad_client = pub-0538745384335317;);
document.writeln(google_ad_width = 125;);
document.writeln(google_ad_height = 125;);
document.writeln(google_ad_format = 125x125_as;);
document.writeln(google_ad_type = ext_image;);
document.writeln(//2007-06-29: www.ybj86.cn);
document.writeln(google_ad_channel = 4751988107;);
document.writeln(google_color_border = 1a1a1a;);
document.writeln(google_color_bg = 1a1a1a;);
document.writeln(google_color_link = d0eb6a;);
document.writeln(google_color_text = ffffff;);
document.writeln(google_color_url = 8ad459;);
document.writeln(google_ui_features = c:6;);
document.writeln(//-->);
document.writeln(</script>);
document.writeln(<script type= ext/javascript);
document.writeln( src=http://pagead2.googlesyndication.com/pagead/show_ads.js>);
document.writeln(</script>)
各位朋友可以按照自己的情況修改，網上也有把HTML代碼轉為JS代碼的地方。
最後在需要掛廣告的地方放入代碼 <script type=text/javascript src=google.js></script>
其他需注意的地方：
16.註解文字不可包含--符號
錯誤 <!-- OEC--SPACE -->
正確 <!-- OECSPACE -->
17.正確使用CSS樣式表
一定要放在<head></head>之間
<link rel=stylesheet type=text/css href=style.css />
<style type=text/css>
<!--
body{font-size:9pt;}
-->
</style>
錯誤 <style>
正確 <style type=text/css>
18.使用表格常犯的錯誤
我們在做表格通常會指定寬與高,例如: 內容 這樣做是沒有辦法通過,W3C建議使用CSS來控制標簽元素的高度
.table{
height:55px;
} TEXT 但是若使用太多表格,在CSS一一指定不同高,也不是好方法
其實很簡單將高度height屬性指定在儲存格就可以了通過測試 TEXT 但這不是w3c希望的標准,建議能夠使用div代替不必要的table
19.非標簽一部分的符號以編碼表示
表單內包含以下符號也必須用編碼表示
< 以 &lt; 表示
> 以 &gt; 表示
& 以 &amp; 表示
程式中的連結 & 也要改用 &amp;
錯誤 <a href=foo.cgi?chapter=1&ion=2>
正確 <a href=foo.cgi?chapter=1&amp;ion=2>
20.所有屬性都必須有值
XHTML1.0規定所有屬性都必須有值,若沒有就必須重復屬性作為值
錯誤 <input type=radio value=v1 checked name=s1 />
正確 <input type=radio value=v1 checked=checked name=s1 />
錯誤 <option selected>S1</option>
正確 <option selected=selected>S1</option>
錯誤
正確

⑺ Web應用的測試內容都包括哪些方面

1、通用指標

指Web應用伺服器、資料庫伺服器必需測試項，包括：處理器時間：指伺服器CPU佔用率，一般平均達到70%時，服務就接近飽和。可用內存數：如果測試時發現內存有變化情況也要注意，如果是內存泄露則比較嚴重。物理磁碟讀寫時間。

2、Web伺服器指標

平均每秒響應次數為總請求時間與秒數之比。平均每秒業務腳本的迭代次數。成功的請求和失敗的請求。成功的點擊次數和失敗的點擊次數。每秒點擊次數、每秒成功的點擊次數和每秒失敗的點擊次數。嘗試連接數。

3、資料庫伺服器指標

用戶連接數，也就是資料庫的連接數量。資料庫死鎖量。資料庫緩存的命中情況。

(7)web測評圖擴展閱讀

對被測的Web應用程序進行需求分析，即對所做的測試作一個簡要的介紹，包括描述測試的目標和范圍，所測試的目標要實現一個什麼樣的功能，總結基本文檔、主要活動。

寫出測試策略和方法，這里包括測試開始的條件、測試的類型、測試開始的標准以及所測試的功能、測試通過或失敗的標准、結束測試的條件、測試過程中遇到什麼樣的情況終止和怎麼處理後恢復等。

一個Web應用程序由完成特定任務的各種Web組件（web components)構成的並通過Web將服務展示給外界。在實際應用中，Web應用程序由多個Servlet、JSP頁面、HTML文件以及圖像文件等組成。所有這些組件相互協調為用戶提供一組完整的服務。

⑻ 如何進行WEB安全性測試

安全性測試
產品滿足需求提及的安全能力
n 應用程序級別的安全性，包括對數據或業務功能的訪問，應
用程序級別的安全性可確保：在預期的安全性情況下，主角
只能訪問特定的功能或用例，或者只能訪問有限的數據。例
如，可能會允許所有人輸入數據，創建新賬戶，但只有管理
員才能刪除這些數據或賬戶。如果具有數據級別的安全性，
測試就可確保「用戶類型一」 能夠看到所有客戶消息（包括
財務數據），而「用戶二」只能看見同一客戶的統計數據。
n 系統級別的安全性，包括對系統的登錄或遠程訪問。
系統級別的安全性可確保只有具備系統訪問許可權的用戶才能
訪問應用程序，而且只能通過相應的網關來訪問。
安全性測試應用
防SQL漏洞掃描
– Appscan
n防XSS、防釣魚
– RatProxy、Taint、Netsparker
nget、post -> 防止關鍵信息顯式提交
– get：顯式提交
– post：隱式提交
ncookie、session
– Cookie欺騙

⑼ web測試用例設計從哪些方面入手

常用的測試用例方法:
等價類：有效等價類和無效等價類。
邊界值：[1,10]正整數范圍為（0,1,2, 9,10,11），浮點數的話為最接近的范圍點。
因果圖：根據條件組合生成判定表。
正交實驗設計方法：抽取有代表性的元素數據來進行測試。
錯誤推測法：容易發生錯誤的地方進行有針對性地測試。
隨機測試：像一個普通用戶隨意地點擊操作去進行測試。
需求轉化法：通過正常操作、異常操作、特殊規約、用戶提示、數據一致性等要點轉化需求為成高粒度測試點。
對象屬性分析法：文件屬性：大小、路徑、文件名、文件編碼、文件內容、文件內容、
文件讀寫、文件共享。
全路徑覆蓋： 通過對每個業務數據流每個路徑進行測試。
場景法： 場景通常包括 正常場景、異常場景、備選場景、組合場景。

⑽ 如何進行Web服務的性能測試

貼一篇我們內部的文章：
隨著瀏覽器功能的不斷完善，用戶量不斷的攀升，涉及到web服務的功能在不斷的增加，對於我們測試來說，我們不僅要保證服務端功能的正確性，也要驗證服務端程序的性能是否符合要求。那麼性能測試都要做些什麼呢？我們該怎樣進行性能測試呢？
性能測試一般會圍繞以下這些問題而進行：
1. 什麼情況下需要做性能測試？
2. 什麼時候做性能測試？
3. 做性能測試需要准備哪些內容？
4. 什麼樣的性能指標是符合要求的？
5. 性能測試需要收集的數據有哪些？
6. 怎樣收集這些數據？
7. 如何分析收集到的數據？
8. 如何給出性能測試報告？
性能測試的執行過程及要做的事兒主要包含以下內容：
1. 測試評估階段
在這個階段，我們要評估被測的產品是否要進行性能測試，並且對目前的伺服器環境進行粗估，服務的性能是否滿足條件。
首先要明確只要涉及到准備上線的服務端產品，就需要進行性能測試。其次如果產品需求中明確提到了性能指標，那也必須要做性能測試。
測試人員在進行性能測試前，需要根據當前的收集到的各種信息，預先做性能的評估，收集的內容主要包括帶寬、請求包大小、並發用戶數和當前web服務的帶寬等
2. 測試准備階段
在這個階段，我們要了解以下內容：
a. 伺服器的架構是什麼樣的，例如：web伺服器是什麼？是如何配置的？資料庫用的是什麼？服務用的是什麼語言編寫的？；
b. 服務端功能的內部邏輯實現；
c. 服務端與資料庫是如何交互的，例如：資料庫的表結構是什麼樣的？服務端功能是怎樣操作資料庫的？
d. 服務端與客戶端之間是如何進行交互的，即介面定義；
通過收集以上信息，測試人員整理出伺服器端各模塊之間的交互圖，客戶端與服務端之間的交互圖以及服務端內部功能邏輯實現的流程圖。
e. 該服務上線後的用戶量預估是多少，如果無法評估出用戶量，那麼可以通過設計測試執行的場景得出這個值；
f. 上線要部署到多少台機器上，每台機器的負載均衡是如何設計的，每台機器的配置什麼樣的，網路環境是什麼樣的。
g. 了解測試環境與線上環境的不同，例如網路環境、硬體配置等
h. 制定測試執行的策略，是需要驗證需求中的指標能否達到，還是評估系統的最大處理能力。
i. 溝通上線的指標
通過收集以上信息，確定性能測試用例該如何設計，如何設計性能測試用例執行的場景，以及上線指標的評估。
3. 測試設計階段
根據測試人員通過之前整理的交互圖和流程圖，設計相應的性能測試用例。性能測試用例主要分為預期目標用戶測試，用戶並發測試，疲勞強度與大數量測試，網路性能測試，伺服器性能測試，具體編寫的測試用例要更具實際情況進行裁減。
用例編寫的步驟大致分為：
a. 通過腳本模擬單一用戶是如何使用這個web服務的。這里模擬的可以是用戶使用web服務的某一個動作或某幾個動作，某一個功能或幾個功能，也可以是使用web服務的整個過程。
b. 根據客戶端的實際情況和伺服器端的策略，通過將腳本中可變的數據進行參數化，來模擬多個用戶的操作。
c. 驗證參數化後腳本功能的正確性。
d. 添加檢查點
e. 設計腳本執行的策略，如每個功能的執行次數，各個功能的執行順序等
4. 測試執行階段
根據客戶端的產品行為設計web服務的測試執行場景及測試執行的過程，即測試執行期間發生的事兒。通過監控程序收集web服務的性能數據和web服務所在系統的性能數據。
在測試執行過程中，還要不斷的關注以下內容：
a. web服務的連接速度如何？
b. 每秒的點擊數如何？
c. Web服務能允許多少個用戶同時在線？
d. 如果超過了這個數量，會出現什麼現象？
e. Web服務能否處理大量用戶對同一個頁面的請求？
f. 如果web服務崩潰，是否會自動恢復？
g. 系統能否同一時間響應大量用戶的請求？
h. 打壓機的系統負載狀態。
5. 測試分析階段
將收集到的數據製成圖表，查看各指標的性能變化曲線，結合之前確定的上線指標，對各項數據進行分析，已確定是否繼續對web服務進行測試，結果是否達到了期望值。
6. 測試驗證階段
在開發針對發現的性能問題進行修復後，要再執行性能測試的用例對問題進行驗證。這里需要關注的是開發在解決問題的同時可能無意中修改了某些功能，所以在驗證性能的同時，也要關注原有功能是否受到了影響。

想看原文或者有測試其他相關的問題可以關注下 搜狗測試 微信公眾號，我們上面有不少關於性能測試分享~