1. web端和移動端優秀的自動化測試工具有哪些
QTP 全名HP QuickTest Professional software ，2012年12月6日發布11.5版本，並更名為Unified Functional TestingQTP是quicktest Professional的簡稱，是一種自動測試工具。使用QTP的目的是想用它來執行重復的手動測試，主要是用於回歸測試和測試同一軟體的新版本。因此你在測試前要考慮好如何對應用程序進行測試，例如要測試那些功能、操作步驟、輸入數據和期望的輸出數據等 QuickTest針對的是GUI應用程序，包括傳統的Windows應用程序，以越來越流行的Web應用。它可以覆蓋絕大多數的軟體開發技術，簡單高效，並具備測試用例可重用的特點。其中包括:創建測試、插入檢查點、檢驗數據、增強測試、運行測試、分析結果和維護測試等方面。 WinRunner Mercury Interactive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄制、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對復雜的企業級應用的不同發布版進行測試，提高測試人員的工作效率和質量，確保跨平台的、復雜的企業級應用無故障發布及長期穩定運行。企業級應用可能包括Web應用系統，ERP系統，CRM系統等等。這些系統在發布之前，升級之後都... QTP 全名HP QuickTest Professional software ，2012年12月6日發布11.5版本，並更名為Unified Functional TestingQTP是quicktest Professional的簡稱，是一種自動測試工具。使用QTP的目的是想用它來執行重復的手動測試，主要是用於回歸測試和測試同一軟體的新版本。因此你在測試前要考慮好如何對應用程序進行測試，例如要測試那些功能、操作步驟、輸入數據和期望的輸出數據等 QuickTest針對的是GUI應用程序，包括傳統的Windows應用程序，以越來越流行的Web應用。它可以覆蓋絕大多數的軟體開發技術，簡單高效，並具備測試用例可重用的特點。其中包括:創建測試、插入檢查點、檢驗數據、增強測試、運行測試、分析結果和維護測試等方面。 WinRunner Mercury Interactive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄制、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對復雜的企業級應用的不同發布版進行測試，提高測試人員的工作效率和質量，確保跨平台的、復雜的企業級應用無故障發布及長期穩定運行。企業級應用可能包括Web應用系統，ERP系統，CRM系統等等。這些系統在發布之前，升級之後都要經過測試，確保所有功能都能正常運行，沒有任何錯誤。如何有效地測試不斷升級更新且不同環境的應用系統，是每個公司都會面臨的問題。 RationalRobot 是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。它集成在測試人員的桌面IBM Rational Test Manager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。這種測試和管理的雙重功能是自動化測試的理想開始。 AdventNetQEngine AdventNet QEngine是一個應用廣泛且獨立於平台的自動化軟體測試工具，可用於Web功能測試、web性能測試、Java應用功能測試、Java API測試、SOAP測試、回歸測試和Java應用性能測試。支持對於使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、傳統客戶端/伺服器等開發的應用程序進行測試。此工具以Java開發，因此便於移植和提供多平台支持。 SilkTest 是業界領先的、用於對企業級應用進行功能測試的產品，可用於測試Web、Java或是傳統的C/S結構。SilkTest提供了許多功能，使用戶能夠高效率地進行軟體自動化測試。這些功能包括:測試的計劃和管理;直接的資料庫訪問及校驗;靈活、強大的4Test腳本語言，內置的恢復系統(Recovery System);以及具有使用同一套腳本進行跨平台、跨瀏覽器和技術進行測試的能力。 QARun QARun的測試實現方式是通過滑鼠移動、鍵盤點擊操作被測應用，即而得到相應的測試腳本，對該腳本可以進行編輯和調試。在記錄的過程中可針對被測應用中所包含的功能點進行基線值的建立，換句話說就是在插入檢查點的同時建立期望值。在這里檢查點是目標系統的一個特殊方面在一特定點的期望狀態。通常，檢查點在QARun提示目標系統執行一系列事件之後被執行。檢查點用於確定實際結果與期望結果是否相同 TestPartner 是一個自動化的功能測試工具，它專為測試基於微軟、Java和Web技術的復雜應用而設計。它使測試人員和開發人員都可以使用可視的腳本編制和自動向導來生成可重復的測試，用戶可以調用VBA的所有功能，並進行任何水平層次和細節的測試。TestPartner的腳本開發採用通用的、分層的方式來進行。沒有編程知識的測試人員也可以通過TestPartner的可視化導航器來快速創建測試並執行。通過可視的導航器錄制並回放測試，每一個測試都將被展示為樹狀結構，以清楚地顯現測試通過應用的路徑。 Holodeck-強大的故障植入軟體測試工具 TelelogicTAU TAU第二代包含三個最新的、最強大的技術用來加速大規模軟體開發和測試:統一建模語言(UML)及它的許多最新修訂版本中的特性，UML2.0;功能強大的測試語言TTCN-3和新的構造系統的方法:Model Driven Architecture(模型驅動構架)。這三個新的業界標准結合成TAU的已經過認可的軟體開發平台，形成了一個系統，一個一流的穩定可靠的工具解決方案。TAU第二代是系統與軟體開發解決方案的一個突破，它把業界從使用了太長時間的手工、易出錯、以代碼為中心的方法中釋放出來，自然而然地邁向下一步，一個更加可視化、自動化及可靠的開發方法。Telelogic TAU/Tester是基於通用測試語言TTCN-3,用於自動化的系統和集成測試的強大工具。TAU/Tester以現代化的開發工具為基礎，提供高層測試功能，支持整個測試生命周期，加速自動化測試。TAU/Tester可使用戶特別關注於測試的開發，因為TTCN-3語言是獨立於開發語言或測試設備的，且是抽象和可移植的。 試工具。最新版本是1.1.8，該工具支持無腳本執行模式，無人值守執行模式，自由定製模式。不僅執行模式可以定製，功能模塊也支持定製。使用該工具的界面創建用例，組裝腳本，啟動執行。使用該工具其他開放的介面，可手動創建腳本，組裝並執行。它支持兩種部署模式，第一種是Server-Client方式，Server與Client均為EXE程序，通信協議是Socket;另一種是WEB版部署，方便與現有系統集成，支持Linux，將Server與Client放到Tomcat或Weblogic伺服器下部署，通信協議為Http，通過WEB頁面控制並監控Client端的執行
2. 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的系統研究新的方法和技術
3. web應用軟體的測試環境怎麼寫
定義測試策略 目前止您肯定參加議客戶倚靠寬議桌問您:系統能處理千用戶傳統負載測試要求您編寫腳本並執行測試試圖給問題精確答案於種測試您需要定義處理含義及 1000 名典型用戶站點情形您需要定義測試用例代表各種用戶:例購買股票或注冊新帳戶接您必須估計用戶些測試用例布數據進行假設即模擬真實用戶與應用程序交互需要思考間(或等待間)負載測試期間某面致反映同數量真實用戶站點情形 種幾足處首先其結比您做假設更顯確假設使結現偏差 其估計真實用戶需要量客戶端硬體每名虛擬用戶給定需要處理能力內存量則典型客戶端計算機處理約 200 名虛擬用戶 2000 名用戶並發處理級別測試需要 10 台客戶端計算機 - 筆重投資測試使用 HTTPS 站點需要客戶端硬體 終難向您發團隊提供操作導向信息某處現故障難再現該問題 作備選案我建議您圍繞些關鍵問題設計測試用例: ?? 系統瓶頸哪系統能同步處理少並發請求 ?? 響應間變接受前台機器能處理少名同步超級用戶 ?? 添加額外硬體結線形增 ?? 任何穩定性問題妨礙站點運行於產環境 使用發團隊(發團隊參與能現問題領域)提供附加信息請關注些領域於示例其瓶頸能定單提交領域您派更具體問題例提交流程同處理少請求攻擊些特定領域快且本用向發團隊提供操作導向信息便能改進系統使用種同我推薦您記住遵循建議 關注負載測試我已提首先要做構建導致潛瓶頸穩定性問題腳本種數據第假設第二使您能夠應用程序收集原始數據根據假設確定更高級別結用擔識別低風險站點腳本編寫問題例站點幫助領域或讀文檔領域編寫腳本能現系統瓶頸 同步請求使用同步請求攻擊瓶頸處主意模擬壞情況:即站點用戶精確同間攻擊瓶頸通使用戶同步您重復進行測試同步結則難再現故障情況使用同步點做點同步點數較健壯(本較高)測試工具提供項功能同步點迫使每名虛擬用戶直等剩餘用戶達腳本定義點才能始請求允許您精確並重復確定站點潛瓶頸區域能處理並發用戶數例限 7 名並發同步用戶 創建循環測試用例腳本使測試用例循環另種每測試用例迭代前站點應處於相同狀態允許您間重復運行測試用例 使用超級用戶使用我所稱超級用戶前面所提超級用戶運行思考間設置零請記住思考間假設用於規測試使虛擬用戶模擬真實用戶虛擬用戶思考間減半則伺服器實際負載加倍另種伺服器真關與負載關變數每秒請求數虛擬用戶數量及其思考間結合起該負載 讓我進行些數運算使概念更清晰面公式計算訪問站點真實用戶負載(請求數/秒): 例某站點 100 名並發用戶假設載間 10 秒思考間 30 秒則每秒 2.5 頁我假設每頁 3 請求則 Web 伺服器轉化每秒 7.5 請求 超級用戶運行測試觀察每秒請求數並與剛剛計算值比較根據我經驗真實用戶數與超級用戶數比例通約 15:1於同示例意味著 (100/15) 名超級用戶與 100 名普通用戶相同負載再舉例假設 10 名超級用戶響應間變接受請注意轉換真實用戶數該點每秒請求數現您進行任何希望思考間假設甚至更改需重新運行測試幾測試您能根據直覺超級用戶數轉換真實用戶數允許您保持用戶數控減少所需客戶端硬體數量並包含負載測試軟體本 些超級用戶測試用例於機測試用要測試站點伸縮性添加第二台 Web 伺服器負載平衡器並重復超級用戶測試理想情況看見相同相應數前您能加倍超級用戶數量 要答穩定性問題運行測試延間段內維持合理數量並發且未同步超級用戶我項目熬通宵甚至 24 晝夜停持續間與應用程序關我稱內置測試旦您已採取步驟識別並潛解決找瓶頸則重復同步點測試看限否所增用所支持新並發用戶數重新運行內置測試努力提高數字目標重復該循環直達質量條 少用戶呢 盡管向發團隊提供價值信息使您更難於答議室問題您近似估計答案例假設站點壞情況瓶頸顯示每台計算機於 20 名超級用戶情況響應間超 10 秒根據您我建議公式計算結近似估計 300 名真實用戶(20 名超級用戶 × 15 名真實用戶)您做與規用例相同假設通情況百少用戶使用站點領域假設預期 50% 用戶使用領域其領域例文檔或資料庫讀取用戶比例則沒意味著具台 Web 伺服器系統處理約 600 名用戶 目前止我已討論能明確指向站點瓶頸領域情況該何做影響性能領域止您應何做呢答案創建單獨查看各領域測試腳本首先孤立運行些腳本起運行再比較結看站點領域另領域影響
4. app測試和web測試的區別， web測試和app測試的區別
一、測試方式不同
1、app測試：指對移動應用進行測試，包括自動化測試和人工測試等。
2、web測試：是軟體測試的一部分，是針對Web應用的一類測試。
二、測試內容不同
1、app測試：模擬用戶操作對應用程序進行黑盒測試，並使用Cucumber作為自然語言來編寫測試用例。還會對應用測試操作進行記錄，以幫助開發者進行測試回顧。
2、web測試：包括內容測試、界面測試、功能測試、性能測試、兼容性測試、安全性測試等。
三、特點不同
1、app測試：可通過增加預先測試環節來確認環境已經測試就緒，同時還能知道哪些錯誤是環境不穩定引起的，哪些是一般的測試用例錯誤。
2、web測試：通過測試可以盡可能地多發現瀏覽器端和伺服器端程序中的錯誤並及時加以修正，以保證應用的質量。
5. Web測試的測試分類
界面測試、功能測試、性能測試、可用性測試(介面測試）、客戶端兼容性、安全性
web 的性能測試工具
隨著Web 2.0技術的迅速發展，許多公司都開發了一些基於Web的網站服務，通常在設計開發Web應用系統的時候很難模擬出大量用戶同時訪問系統的實際情況，因此，當Web網站遇到訪問高峰時，容易發生伺服器響應速度變慢甚至服務中斷。為了避免這種情況，需要一種能夠真實模擬大量用戶訪問Web應用系統的性能測試工具進行壓力測試，來測試靜態HTML頁面的響應時間，甚至測試動態網頁（包括ASP、PHP、JSP等）的響應時間，為伺服器的性能優化和調整提供數據依據。
另外，CSDN也總結了一些其他的測試工具，包括性能測試工具和功能測試工具，前十大測試工具排名如下：
企業級自動化測試工具WinRunner
Mercury Interactive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。
工業標准級負載測試工具Loadrunner
LoadRunner 是一種預測系統行為和性能的負載測試工具。
全球測試管理系統testdirector
TestDirector 是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。
功能測試工具Rational Robot
IBM Rational Robot 是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。它集成在測試人員的桌面IBM Rational TestManager 上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。這種測試和管理的雙重功能是自動化測試的理想開始。
單元測試工具xUnit系列
目前的最流行的單元測試工具是xUnit系列框架，常用的根據語言不同分為JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。該測試框架的第一個和最傑出的應用就是由Erich Gamma （《設計模式》的作者）和Kent Beck（XP（Extreme Programming）的創始人 ）提供的開放源代碼的JUnit.
功能測試工具SilkTest
Borland SilkTest 2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。
性能測試工具WAS
Microsoft Web Application Stress Tool 是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。
自動化白盒測試工具Jtest
Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。parasoft同時出品的還有C++ test，是一款C/C++白盒測試工具。
功能和性能測試的工具JMeter
JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。
性能測試和分析工具WEBLOAD
webload 是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。
6. 如何對J2EE的WEB應用系統進行性能測試
用loadrunner 這個軟體
hp的產品，可以模擬 多個用戶同時操作你的軟體。
7. Web應用的測試內容都包括哪些方面
1、通用指標
指Web應用伺服器、資料庫伺服器必需測試項，包括：處理器時間：指伺服器CPU佔用率，一般平均達到70%時，服務就接近飽和。可用內存數：如果測試時發現內存有變化情況也要注意，如果是內存泄露則比較嚴重。物理磁碟讀寫時間。
2、Web伺服器指標
平均每秒響應次數為總請求時間與秒數之比。平均每秒業務腳本的迭代次數。成功的請求和失敗的請求。成功的點擊次數和失敗的點擊次數。每秒點擊次數、每秒成功的點擊次數和每秒失敗的點擊次數。嘗試連接數。
3、資料庫伺服器指標
用戶連接數，也就是資料庫的連接數量。資料庫死鎖量。資料庫緩存的命中情況。
(7)web應用程序做軟體產品測試擴展閱讀
對被測的Web應用程序進行需求分析，即對所做的測試作一個簡要的介紹，包括描述測試的目標和范圍，所測試的目標要實現一個什麼樣的功能，總結基本文檔、主要活動。
寫出測試策略和方法，這里包括測試開始的條件、測試的類型、測試開始的標准以及所測試的功能、測試通過或失敗的標准、結束測試的條件、測試過程中遇到什麼樣的情況終止和怎麼處理後恢復等。
一個Web應用程序由完成特定任務的各種Web組件（web components)構成的並通過Web將服務展示給外界。在實際應用中，Web應用程序由多個Servlet、JSP頁面、HTML文件以及圖像文件等組成。所有這些組件相互協調為用戶提供一組完整的服務。
8. 如何對Web應用程序進行負載測試
定義測試策略 到目前為止，您肯定參加過這樣的會議，客戶倚靠在寬大的會議桌上，問您：「這個系統能處理上千個用戶嗎？」傳統的負載測試方法要求您編寫腳本並執行測試，以試圖給出此問題的精確答案。對於這種測試，您需要定義「處理」的含義以及 1000 名典型用戶在站點活動時的情形。您需要定義測試用例以代表各種用戶活動：例如，購買股票或注冊新的帳戶。接下來，您必須估計用戶在這些測試用例上的分布。對以下數據進行假設，即模擬真實用戶與應用程序交互時，需要多長的思考時間（或等待時間）。因此，負載測試期間活動的可從某個方面大致反映出同樣數量的真實用戶在站點活動時的情形。 這種方法有幾個不足之處。首先，其結果不會比您做的假設更好。顯然，不正確的假設將使結果出現偏差。 其次，估計真實用戶需要大量客戶端硬體。如果對每名虛擬用戶給定需要的處理能力和內存量，則典型的客戶端計算機可以處理大約 200 名虛擬用戶。因此，對 2000 名用戶並發處理級別的測試需要 10 台客戶端計算機 — 這是一筆重大投資。測試使用 HTTPS 的站點將需要多得多的客戶端硬體。 最終，此方法難以向您的開發團隊提供以操作為導向的信息。當某處出現故障時，常常難以再現該問題。 作為備選方案，我們建議您圍繞以下這些關鍵問題設計測試用例： �6�1 系統瓶頸在哪裡？系統能同步處理多少個並發請求？ �6�1 在響應時間變得不可接受之前，一台機器能處理多少名不同步的超級用戶？ �6�1 添加額外的硬體時，結果是線形增長的嗎？ �6�1 有任何穩定性問題會妨礙站點運行於生產環境中嗎？ 此方法將使用開發團隊（此開發團隊參與可能出現問題的領域）提供的附加信息。請關注這些領域。對於上一個示例，其瓶頸可能出在定單提交領域。從這里您可以派生出更具體的問題，例如「提交流程可以同時處理多少個請求？」攻擊這些特定領域是最快且成本最小的方法，用來向開發團隊提供以操作為導向的信息，以便他們能改進系統。在使用這種方法的同時，我們推薦您記住遵循以下建議。 關注負載測試正如我們已提到的那樣，首先要做的是構建導致潛在瓶頸和穩定性問題的腳本。這種「數據第一，假設第二」的方法使您能夠從應用程序收集原始數據，然後根據假設確定更高級別的結果。不用擔心為識別低風險站點的腳本編寫問題。例如，為站點的幫助領域或只讀文檔領域編寫腳本不大可能出現系統瓶頸。 同步請求使用同步請求攻擊瓶頸。此處的這個主意是模擬最壞的情況：即，站點上的用戶精確地在同一時間攻擊瓶頸。通過使用戶同步，您可以重復進行此測試。如果不同步結果，則難以再現故障情況。可以使用同步點做到這一點，同步點是大多數較健壯（成本也較高）的測試工具中提供的一項功能。同步點迫使每名虛擬用戶一直等到剩餘的用戶到達腳本中定義的點後，才能開始下一請求。它允許您精確並重復地確定站點的潛在瓶頸區域能處理的並發用戶數。例如，下限可以是 7 名並發同步用戶。 創建循環測試用例腳本使測試用例循環。在另一種方法中，每次測試用例迭代前後，站點應處於相同狀態。這允許您長時間地重復運行測試用例。 使用超級用戶最後，使用我們所稱的超級用戶。正如前面所提到的，超級用戶運行時思考時間設置為零。請記住，思考時間假設是用於常規測試中，以使虛擬用戶模擬真實用戶。但是，如果將虛擬用戶思考時間減半，則伺服器的實際負載將加倍。在另一種方法中，伺服器真正關心的與負載有關的變數是每秒的請求數。虛擬用戶的數量及其思考時間結合起來生成該負載。 讓我們進行一些數學運算以使此概念更清晰。下面的公式計算訪問站點的真實用戶生成的負載（請求數/秒）： 例如，某個站點有 100 名並發用戶，假設下載時間為 10 秒，思考時間為 30 秒，則每秒將生成 2.5 頁。如果我們假設每頁 3 個請求，則在 Web 伺服器上將轉化為每秒 7.5 個請求。 以超級用戶運行測試時，觀察每秒請求數，並與剛剛計算的值比較。根據我們的經驗，真實用戶數與超級用戶數的比例通常約為 15:1。對於同一個示例，這意味著 (100/15) 名超級用戶將生成與 100 名普通用戶相同的負載。再舉一個例子，假設在 10 名超級用戶之後響應時間變得不可接受。請注意轉換回真實用戶數的該點每秒請求數。現在您可以進行任何希望的思考時間假設，甚至可以更改它而無需重新運行測試。在幾天的測試之後，您將能根據直覺從超級用戶數轉換成真實用戶數。此方法允許您保持用戶數可控，減少所需的客戶端硬體數量，並包含負載測試軟體的成本。 這些超級用戶測試用例對於多機測試很有用。要測試站點的可伸縮性，可添加第二台 Web 伺服器和一個負載平衡器，並重復超級用戶測試。理想情況下，在看見相同的相應次數之前，您將能加倍超級用戶數量。 要回答穩定性問題，可運行測試，以在延長的時間段內維持合理數量的並發且未同步超級用戶。我們在上一個項目中熬了很多個通宵，甚至 24 小時晝夜不停，但持續時間與應用程序有關。我們稱之為「內置」測試。一旦您已採取步驟識別並潛在地解決了找到的瓶頸，則重復同步點測試，看下限是否有所增長。然後用所支持的新的並發用戶數重新運行「內置」測試。以努力提高此數字為目標重復該循環，直到達到質量條。 但是有多少用戶呢？ 盡管此方法向開發團隊提供了有價值的信息，但它使得您更難於回答會議室的問題。不過，您可以近似地估計答案。例如，假設站點的最壞情況瓶頸顯示，每台計算機多於 20 名超級用戶的情況下，響應時間超過 10 秒。根據您從我們建議的公式計算的結果，近似地估計有 300 名真實用戶（20 名超級用戶 × 15 名真實用戶）。此時，您可以做出與常規用例中相同的假設。通常情況下，有百分之多少的用戶正在使用站點的此領域？假設預期 50% 的用戶正在使用此領域，而其他領域，例如文檔或資料庫讀取，用戶比例則沒有這么大。這意味著具有一台 Web 伺服器的系統將處理大約 600 名用戶。 到目前為止，我們已討論了在能明確地指向站點的一個瓶頸領域的情況下該如何做，但如果影響性能的領域不止一個時您又應如何做呢？答案是創建單獨查看各個領域的測試腳本。首先孤立地運行這些腳本，然後一起運行。再比較結果，看站點的一個領域對另一個領域的影響有多大。