1. 第五章：Web伺服器
5.1各種形狀和尺寸的Web伺服器
Web伺服器會對HTTP請求進行處理並提供響應。術語「Web伺服器」可以用來表示Web伺服器的軟體，也可以用來表示提供Web頁面的特定設備或計算機。
Web伺服器有著不同的風格、形狀和尺寸。有普通的10行Perl腳本的Web伺服器、50MB的安全商用引擎以及極小的卡上伺服器。但不管功能有何差異，所有的 Web伺服器都能夠接收請求資源的 HTTP請求，將內容回送給客戶端（參見圖1-5)。
5.1.1Web伺服器的實現
Web伺服器實現了HTTP和相關的TCP連接處理。負責管理Web伺服器提供的資源,以及對Web伺服器的配置、控制及擴展方面的管理。
Web伺服器邏輯實現了HTTP 協議、管理著Web資源，並負責提供Web伺服器的管理功能。Web伺服器邏輯和操作系統共同負責管理TCP連接。底層操作系統負責管理底層計算機系統的硬體細節，並提供了TCP/IP網路支持、負責裝載Web資源的文件系統以及控制當前計算活動的進程管理功能。
5.3實際的Web伺服器會做些什麼
例5-1顯示的 Perl伺服器是一個Web伺服器的小例子。最先進的商用Web伺服器要比它復雜得多，但它們確實執行了幾項同樣的任務，如圖5-3所示。
(1)建立連接一—接受一個客戶端連接，或者如果不希望與這個客戶端建立連接，就
將其關閉。
(2)接收請求——從網路中讀取一條HTTP請求報文。(3)處理請求——對請求報文進行解釋，並採取行動。(4)訪問資源-———訪問報文中指定的資源。
(5)構建響應——創建帶有正確首部的 HTTP響應報文。(6)發送響應——將響應回送給客戶端。
(7)記錄事務處理過程—-將與已完成事務有關的內容記錄在一個日誌文件中。
5.4第一步——接受客戶端連接
如果客戶端已經打開了一條到伺服器的持久連接，可以使用那條連接來發送它的請求。否則，客戶端需要打開一條新的到伺服器的連接（回顧第4章，復習一下HTTP的連接管理技術)。
5.4.1處理新連接
客戶端請求一條到Web伺服器的TCP連接時，Web伺服器會建立連接，判斷連接的另一端是哪個客戶端，從TCP連接中將IP地址解析出來。'一旦新連接建立起來
並被接受，伺服器就會將新連接添加到其現存Web伺服器連接列表中，做好監視連接上數據傳輸的准備。
Web伺服器可以隨意拒絕或立即關閉任意一條連接。有些Web伺服器會因為客戶端IP地址或主機名是未認證的，或者因為它是已知的惡意客戶端而關閉連接。Web伺服器也可以使用其他識別技術。
5.4.2客戶端主機名識別
可以用「反向 DNS」對大部分Web伺服器進行配置，以便將客戶端IP地址轉換成客戶端主機名。Web伺服器可以將客戶端主機名用於詳細的訪問控制和日誌記錄。但要注意的是，主機名查找可能會花費很長時間，這樣會降低Web事務處理的速度。很多大容量Web伺服器要麼會禁止主機名解析，要麼只允許對特定內容進行解析。
可以用配置指令HostnameLookups啟用Apache的主機查找功能。比如，例5-2中的Apache配置指令就只打開了HTML和CGI資源的主機名解析功能。
例5-2配置Apache,為 HTML和CGI資源查找主機名
HostnameLookups off
<Files ~" - 《html |htmlcgi)$">
HostnameLookups on
</Files>
5.5第二步—接收請求報文
連接上有數據到達時，Web伺服器會從網路連接中讀取數據，並將請求報文中的內容解析出來（參見圖5-5)。
解析請求報文時，Web伺服器會:
·解析請求行，查找請求方法、指定的資源標識符（URI)以及版本號，3各項之
間由一個空格分隔，並以一個回車換行(CRLF)序列作為行的結束,「
·讀取以CRLF結尾的報文首部;
檢測到以CRLF結尾的、標識首部結束的空行（如果有的話)﹔
·如果有的話（長度由content-Length首部指定)，讀取請求主體。
解析請求報文時，Web伺服器會不定期地從網路上接收輸入數據。網路連接可能隨時都會出現延遲。Web伺服器需要從網路中讀取數據，將部分報文數據臨時存儲在內存中,直到收到足以進行解析的數據並理解其意義為止。
5.5.1 報文的內部表示法
有些Web伺服器還會用便於進行報文操作的內部數據結構來存儲請求報文。比如，數據結構中可能包含有指向請求報文中各個片段的指針及其長度，這樣就可以將這些首部存放在一個快速查詢表中，以便快速訪問特定首部的具體值了（參見圖5-6)。
5.5.2連接的輸入/輸出處理結構
高性能的 Web伺服器能夠同時支持數千條連接。這些連接使得伺服器可以與世界各地的客戶端進行通信，每個客戶端都向伺服器打開了一條或多條連接。某些連接可能在快速地向Web伺服器發送請求，而其他一些連接則可能在慢慢發送，或者不經常發送請求,還有一些可能是空閑的，安靜地等待著將來可能出現的動作。
因為請求可能會在任意時刻到達，所以Web伺服器會不停地觀察有無新的Web請求。不同的Web伺服器結構會以不同的方式為請求服務，如圖5-7所示。
·單線程Web伺服器(參見圖5-7a)
單線程的Web伺服器一次只處理一個請求，直到其完成為止。一個事務處理結束之後，才去處理下一條連接。這種結構易於實現，但在處理過程中，所有其他連接都會被忽略。這樣會造成嚴重的性能問題，只適用於低負荷的伺服器，以及type-o-serve這樣的診斷工具。
·多進程及多線程Web伺服器(參見圖5-7b)
多進程和多線程Web伺服器用多個進程,或更高效的線程同時對請求進行處理。3可以根據需要創建，或者預先創建一些線程/進程。°有些伺服器會為每條連接分配一個線程/進程，但當伺服器同時要處理成百、上千，甚至數以萬計的連接時，需要的進程或線程數量可能會消耗太多的內存或系統資源。因此，很多多線程Web伺服器都會對線程/進程的最大數量進行限制。
·復用I/O的伺服器(參見圖5-7c)
為了支持大量的連接，很多Web伺服器都採用了復用結構。在復用結構中，要同時監視所有連接上的活動。當連接的狀態發生變化時（比如，有數據可用，或出現錯誤時)，就對那條連接進行少量的處理，處理結束之後，將連接返回到開放連接列表中，等待下一次狀態變化。只有在有事情可做時才會對連接進行處理,在空閑連接上等待的時候並不會綁定線程和進程。
·復用的多線程Web伺服器（參見圖5-7d)
有些系統會將多線程和復用功能結合在一起，以利用計算機平台上的多個CPU.多個線程（通常是一個物理處理器）中的每一個都在觀察打開的連接(或打開的連接中的一個子集)，並對每條連接執行少量的任務。
5.6第三步———處理請求
一旦Web伺服器收到了請求，就可以根據方法、資源、首部和可選的主體部分來對請求進行處理了。
有些方法（比如POST)要求請求報文中必須帶有實體主體部分的數據。其他一些方法（比如OPTIONS）允許有請求的主體部分，也允許沒有。少數方法（比如GET)禁止在請求報文中包含實體的主體數據。
這里我們並不對請求的具體處理方式進行討論，因為本書其餘大多數章節都在討論這個問題。
5.7第四步——-對資源的映射及訪問
Web 伺服器是資源伺服器。它們負責發送預先創建好的內容，比如HTML頁面或JPEG 圖片，以及運行在伺服器上的資源生成程序所產生的動態內容。
5.7.1 docroot
Web伺服器支持各種不同類型的資源映射，但最簡單的資源映射形式就是用請求URI作為名字來訪問Web伺服器文件系統中的文件。通常，Web伺服器的文件系統中會有一個特殊的文件夾專門用於存放Web內容。這個文件夾被稱為文檔的根目錄(document root，或docroot)。Web伺服器從請求報文中獲取URI，並將其附加在文檔根目錄的後面。
在圖5-8中，有一條對/specials/saw-blade.gif 的請求到達。這個例子中Web伺服器的文檔根目錄為/us/local/httpd/files。Web伺服器會返迴文件/usr/local/httpd/files/specials/saw-blade.gif。
在配置文件httpd.conf中添加一個 DocumentRoot行就可以為Apache Web伺服器設置文檔的根目錄了:
DocumentRoot /usr/ local/httpd/files
伺服器要注意，不能讓相對URL退到docroot之外，將文件系統的其餘部分暴露出來。比如，大多數成熟的Web伺服器都不允許這樣的URI看到Joe的五金商店文檔根目錄上一級的文件:
http://www.joes-hardware.com/ ..
5.8.3重定向
Web伺服器有時會返回重定向響應而不是成功的報文。Web伺服器可以將瀏覽器重定向到其他地方來執行請求。重定向響應由返回碼3XX說明。Location響應首部包含了內容的新地址或優選地址的URI。重定向可用於下列情況。
·永久刪除的資源
資源可能已經被移動到了新的位置，或者被重新命名，有了一個新的URL。Web伺服器可以告訴客戶端資源已經被重命名了，這樣客戶端就可以在從新地址獲取資源之前，更新書簽之類的信息了。狀態碼301 Moved Permanently就用於此類重定向。·臨時刪除的資源
如果資源被臨時移走或重命名了，伺服器可能希望將客戶端重定向到新的位置上去。但由於重命名是臨時的，所以伺服器希望客戶端將來還可以回頭去使用老的URL，不要對書簽進行更新。狀態碼303 See Other以及狀態碼307 TemporaryRedirect就用於此類重定向。
2. 為什麼web應用的性能在i/o
AIO 簡介
Linux 非同步 I/O 是 Linux 內核中提供的一個相當新的增強。它是 2.6 版本內核的一個標准特性，但是我們在 2.4 版本內核的補丁中也可以找到它。
AIO 背後的基本思想是允許進程發起很多 I/O 操作，而不用阻塞或等待任何操作完成。稍後或在接收到 I/O 操作完成的通知時，進程就可以檢索 I/O 操作的結果。
I/O 模型
在深入介紹 AIO API 之前，讓我們先來探索一下 Linux 上可以使用的不同 I/O 模型。這並不是一個詳盡的介紹，但是我們將試圖介紹最常用的一些模型來解釋它們與非同步 I/O 之間的區別。圖 1 給出了同步和非同步模型，以及阻塞和非阻塞的模型。
圖 1. 基本 Linux I/O 模型的簡單矩陣
每個 I/O 模型都有自己的使用模式，它們對於特定的應用程序都有自己的優點。本節將簡要對其一一進行介紹。
同步阻塞 I/O
I/O 密集型與 CPU 密集型進程的比較
I/O 密集型進程所執行的 I/O 操作比執行的處理操作更多。CPU 密集型的進程所執行的處理操作比 I/O 操作更多。
Linux 2.6 的調度器實際上更加偏愛 I/O 密集型的進程，因為它們通常會發起一個 I/O 操作，然後進行阻塞，這就意味
著其他工作都可以在兩者之間有效地交錯進行。
最常用的一個模型是同步阻塞 I/O 模型。在這個模型中，用戶空間的應用程序執行一個系統調用，這會導致應用程序阻塞。
這意味著應用程序會一直阻塞，直到系統調用完成為止（數據傳輸完成或發生錯誤）。調用應用程序處於一種不再消費 CPU 而
只是簡單等待響應的狀態，因此從處理的角度來看，這是非常有效的。
圖 2 給出了傳統的阻塞 I/O 模型，這也是目前應用程序中最為常用的一種模型。其行為非常容易理解，其用法對於典型的
應用程序來說都非常有效。在調用 read 系統調用時，應用程序會阻塞並對內核進行上下文切換。然後會觸發讀操作，當響應返
回時（從我們正在從中讀取的設備中返回），數據就被移動到用戶空間的緩沖區中。然後應用程序就會解除阻塞（read 調用返回）。
圖 2. 同步阻塞 I/O 模型的典型流程
從應用程序的角度來說，read 調用會延續很長時間。實際上，在內核執行讀操作和其他工作時，應用程序的確會被阻塞。
同步非阻塞 I/O
同步阻塞 I/O 的一種效率稍低的變種是同步非阻塞 I/O。在這種模型中，設備是以非阻塞的形式打開的。這意味著 I/O 操
作不會立即完成，read 操作可能會返回一個錯誤代碼，說明這個命令不能立即滿足（EAGAIN 或 EWOULDBLOCK），如圖 3 所示。
圖 3. 同步非阻塞 I/O 模型的典型流程
非阻塞的實現是 I/O 命令可能並不會立即滿足，需要應用程序調用許多次來等待操作完成。這可能效率不高，因為在很多情況下，
當內核執行這個命令時，應用程序必須要進行忙碌等待，直到數據可用為止，或者試圖執行其他工作。正如圖 3 所示的一樣，這個方
法可以引入 I/O 操作的延時，因為數據在內核中變為可用到用戶調用 read 返回數據之間存在一定的間隔，這會導致整體數據吞吐量的降低。
非同步阻塞 I/O
另外一個阻塞解決方案是帶有阻塞通知的非阻塞 I/O。在這種模型中，配置的是非阻塞 I/O，然後使用阻塞 select 系統調用來確定一個
I/O 描述符何時有操作。使 select 調用非常有趣的是它可以用來為多個描述符提供通知，而不僅僅為一個描述符提供通知。對於每個提示符
來說，我們可以請求這個描述符可以寫數據、有讀數據可用以及是否發生錯誤的通知。
圖 4. 非同步阻塞 I/O 模型的典型流程 (select)
select 調用的主要問題是它的效率不是非常高。盡管這是非同步通知使用的一種方便模型，但是對於高性能的 I/O 操作來說不建議使用。
非同步非阻塞 I/O（AIO）
最後，非同步非阻塞 I/O 模型是一種處理與 I/O 重疊進行的模型。讀請求會立即返回，說明 read 請求已經成功發起了。在後台完成讀操作時，
應用程序然後會執行其他處理操作。當 read 的響應到達時，就會產生一個信號或執行一個基於線程的回調函數來完成這次 I/O 處理過程。
圖 5. 非同步非阻塞 I/O 模型的典型流程
在一個進程中為了執行多個 I/O 請求而對計算操作和 I/O 處理進行重疊處理的能力利用了處理速度與 I/O 速度之間的差異。當一個或
多個 I/O 請求掛起時，CPU 可以執行其他任務；或者更為常見的是，在發起其他 I/O 的同時對已經完成的 I/O 進行操作。
下一節將深入介紹這種模型，探索這種模型使用的 API，然後展示幾個命令。
非同步 I/O 的動機
從前面 I/O 模型的分類中，我們可以看出 AIO 的動機。這種阻塞模型需要在 I/O 操作開始時阻塞應用程序。這意味著不可能同時重疊
進行處理和 I/O 操作。同步非阻塞模型允許處理和 I/O 操作重疊進行，但是這需要應用程序根據重現的規則來檢查 I/O 操作的狀態。這樣
就剩下非同步非阻塞 I/O 了，它允許處理和 I/O 操作重疊進行，包括 I/O 操作完成的通知。
除了需要阻塞之外，select 函數所提供的功能（非同步阻塞 I/O）與 AIO 類似。不過，它是對通知事件進行阻塞，而不是對 I/O 調用進行阻塞。
3. 衡量web性能的幾個指標
DNS解析時間
TCP鏈接時間
HTTP重定向時間
首位元組載入時間
HTML內容時間
整個頁面對象載入時間
4. web伺服器優化的方法
在對Web伺服器進行優化時要根據真實的Web應用系統的情況和特徵來採取有針對性地優化方案。
1.根據不同的網路特性來看：
1.1區域網
在區域網中，降低M T U (最大傳輸單位)值對可以避免復制數據和要求校驗，而通過優化select系統調用或在Socket事件處理器中執行計算可以優化請求並發管理，利用HTTP1．1持續連接等都可以使系統性能得到相應的改善但在廣域網的環境下卻沒有什麼大的作用，有的甚至恰恰相反。
1.2廣域網
在廣域網中，終端用戶的請求的等待時間依賴於與網路延遲的程度，連接帶寬限制情況。對於廣域網，軟硬中斷在網路處理中佔有很大的分量，所以採用適應的中斷處理機制將會給伺服器的響應能力帶來很大的好處；將伺服器定位在內核和將基於進程設計改為基於事務處理也可以不同程度的提高伺服器的性能。
2.關於Web負載
除了對Web負載的特徵進行分析以便在評測時更好地再現真實負載之外，還要考慮Web伺服器所在的網路環境下負載的情況。人們不僅要求伺服器滿足正常的工作負載要求，而且在高峰時期依然要保持較高的吞吐量。但是，伺服器在高負載的情況下的性能表現往往低於人們的期望。
伺服器過載的情況分為兩種：
2.1瞬間過載
伺服器暫時的、短時間的超載，這種情況主要是由伺服器負載的特點引起的。大量的研究表明，Web請求的網路通信量分布是自相似的，即Web請求的通信量可以在很大范圍內有顯著的變化。這就造成伺服器常常短時間的超載，但這樣情況持續的時間一般很短
2.2伺服器長時間的超載
這種情況一般是由某一特殊事件引起的，例如伺服器受到拒絕服務攻擊或者發生了「活鎖」現象
第一種伺服器超載情況是不可避免的，但第二種情況則可以通過對伺服器改進來改善。拋開惡意的攻擊不算，仔細分析伺服器處理信息包的過程可以發現，造成系統在超載情況下性能下降的根本原因是高優先順序處理階段對CPU的不公平搶占。
因此，如果限制高優先順序處理階段對CPU的佔用率，或者限制處理高優先順序的CPU個數，都可以減輕或者消除收包活鎖現象。
具體的可以採用以下的方法:
2.2.1採用輪詢機制
為了減少中斷對系統性能的影響，在負載正常的情況下採用「下半處理」 的方法就非常有效，而在高負荷情況下，採用這個方法仍然會造成活鎖現象，這時可以採用輪詢機制。雖然這個方法在負載正常的情況下會造成資源的浪費和響應速度降低，但在網路數據頻繁到達伺服器時就要比中斷驅動技術有效的多。
2.2.2減少上下文切換
這種方法不管伺服器在什麼情況下對性能改善都很有效，這時可以採用引入核心級（kerne1—leve1）或硬體級數據流的方法來達到這個目的。核心級數據流是將數據從源通過系統匯流排進行轉發而不需要使數據經過應用程序進程，這個過程中因為數據在內存中，因此需要CPU操作數據。
硬體級數據流則是將數據從源通過私有數據匯流排或是雖等DMA通過系統匯流排進行轉發而不需要使數據經過應用程序進程，這個過程不需要CPU操作數據。這樣在數據傳輸過程中不需要用戶線程的介入，減少了數據被拷貝的次數，減少了上下文切換的開銷。
2.2.3減低中斷的頻率（主要是針對高負荷情況的方法）
這里主要有兩種方法：批中斷和暫時關閉中斷。批中斷可以在超載時有效的抑制活鎖現象，但對伺服器的性能沒有什麼根本性的改進；當系統出現接收活鎖跡象時，可以採用暫時關閉中斷的方法來緩和系統的負擔，當系統緩存再次可用時可以再打開中斷，但這種方法在接收緩存不夠大的情況下會造成數據包丟失。
四．Web伺服器優化總結
Web伺服器性能是整個Web系統的關鍵環節，提高Web伺服器的性能也是長久以來人們一直關注的課題。這里通過對Web伺服器的工作原理和現有的優化方法和技術的分析，得出了對待Web伺服器性能的提高也應該具體問題具體分析，要在具體的應用環境中，根據其特點來採取相應的優化措施。
5. 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的性能。
(5)web設備性能擴展閱讀：
漏洞測試
企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的，是通過代碼堆積起來的。如果這個代碼只供企業內部使用，那麼不會帶來多大的安全隱患。
但是如果放在互聯網上使用的話，則這些為實現特定功能的代碼就有可能成為攻擊者的目標。
天眼舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊，來獲取管理員的密碼等等破壞性的動作。
有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時，其實就有可能在安裝一個木馬（這可能訪問者與被訪問者都沒有意識到）。
為此在為網站某個特定功能編寫代碼時，就要主動出擊。從編碼的設計到編寫、到測試，都需要認識到是否存在著安全的漏洞。
天眼在日常過程中，在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。
已知的病毒、木馬不能夠在所開發的插件中有機可乘。通過這層層把關，就可以提高代碼編寫的安全性。
6. App測試與Web測試的區別是什麼
App測試和web測試都屬於軟體測試，它們在整個測試流程上沒有太大的區別，主要的區別體現在以下幾個方面： 功能、性能、兼容性、專項測試、操作方式 等，下面我們一一舉例說明。
1、功能方面：
App和web基於不同的網路架構，App是C/S架構（即客戶端/服務端），web是B/S架構（即瀏覽器/伺服器），對於web來說，一般情況下如果服務端發生了更新，那麼瀏覽器端也會隨著更新，這個更新是即時的，不需要用戶額外操作的，用戶只需要打開瀏覽器訪問具體的伺服器地址便可以完成這個過程；而App端則首先需要用戶在自己的終端上安裝一個應用，當服務端發生了變更時，不能保證每個客戶端的內容都獲得更新，除非用戶自己手動選擇更新。
2、性能方面：
App和web在性能上都會關注響應時間以及負載情況等，但App還需要額外考慮應用的耗電情況、流量、CPU和內存佔用情況、後台進程等。
3、兼容性方面：
Web是基於瀏覽器架構，在兼容性方面，一般只需要考慮所使用的瀏覽器版本，如Google Chrome、edge、Firefox等，而App就復雜一些，除了要關注終端系統，如iOS、macOS或Android等移動操作系統，還需要測試不同的硬體設備型號，比如iPhone系列、華為、小米、OPPO、vivo等廠商，每一家在設備的CPU、屏幕尺寸、解析度等硬體系統上都是有差別的，App測試需要確保在軟體和硬體系統上的兼容性。
4、專項測試：
正如我們前面所說的，App是基於C/S架構，所以App測試需要關注某些專項測試，比如客戶端的安裝、卸載和更新，而web是基於B/S架構是不需要考慮這些的。
此外，App還要考慮一些特殊場景，比如系統和應用的優先順序、操作許可權、應用奔潰、後台進程、中斷、重啟、以及網路專項測試等，網路專項又包括網路切換（如2/3/4/5G/WIFI等）、網路中斷以及弱網測試等。
5、操作方式：
Web端在操作方式上是基於滑鼠點擊和鍵盤輸入實現的，一般來說相對簡單，而App端是基於屏幕，一般是通過觸摸屏幕或者功能設備（如觸摸筆）來實現具體步驟的，由於操作方式的不同，App測試時要留意屏幕的旋轉和縮放、多點觸控、特殊事件觸發區域、應用層等。
小結
隨著軟體和技術的不斷發展，App和web端測試在具體細分領域的區別會越來越明顯，有效地加深二者異同的認識對於我們的測試能力的提升具有良好的指引作用，或許測試在具體領域還會進一步細分，但是對於測試工程師能力的要求會不斷地提高，如何提高對於不同分支的認知情況值得我們去思考。
7. web伺服器硬體配置要求
300網站。在這個階段，雙四核伺服器可以首先使用，具有標準的E5620四核處理器，英特爾5500晶元組伺服器主板。
2gb DDR3 REGECC內存，80G SSD，雙千兆網卡，性能可以說相當不錯，與100萬廣告聯盟沒有問題。如果訪問次數增加，可以擴展到2個處理器，8個處理核心，復雜的16個處理線程，內存可以增加到24GB！
如果以後訪問量增加，可以擴展到兩顆處理器，達成內8顆處理核心，16條處理線程，內存可以增加到24GB
產品型號：I2496194S－H
產品類型：雙路四核機架式服務容器
處理器：Xeon E5620
內存：2G DDR 3REGEC
硬碟：SSD 80G
機構：1U機架式
(7)web設備性能擴展閱讀：
在「互聯網信息服務」管理窗口，右鍵點擊「默認網站」，在彈出菜單中選擇「屬性」選項，進入屬性設置對話框。
設置「網站」，這里可以設置網站伺服器的IP地址和訪問埠。在「IP地址」列中，選擇可用的IP地址；「TCP」埠默認為80，但是可以為安全目的設置一個特殊的埠。
設置「主目錄」，「本地路徑」默認：c：＼Inetpub＼wwwroot，當然你可以輸入（或使用「瀏覽」按鈕選擇）你自己的網頁目錄作為主目錄。
設置「文檔」選項，選擇「啟用默認文檔」，當在瀏覽器中輸入域名或IP時，zd系統會自動在「主目錄」中按列表順序查找指定的文件名。
其他設置可以設置為默認設置。
8. 如何測試web伺服器的網速
電腦進入運行程序，輸入CMD，然後鍵入ping+空格+你的IP地址（+號無需輸入），按回車鍵就可以了。
如果是聯通寬頻用戶，可登陸網上營業廳www.10010.com 後，首頁點擊「我的聯通」-「便民服務」-「寬頻測速」，即可根據頁面提示信息進行測速。也可以使用寬頻號碼登錄聯通手機營業廳客戶端——查詢——寬頻業務查詢——立即測試（「寬頻測速」業務不支持免流）。
溫馨提示：以上路徑以網上營業廳實際顯示信息為准。
9. Web伺服器的作用是什麼
1、響應終端的服務請求，並進行處理。我們在上網的時候是不可能直接將網路接入互聯網的，我們都需要通過伺服器來連接網路，只有伺服器響應你的聯網請求，並且進行處理以後才可以聯網；
2、存儲的功能，伺服器的存儲空間一般比較充足，可以存儲非常多的信息。
拓展資料：
1、伺服器的構成包括處理器、硬碟、內存、系統匯流排等，和通用的計算機架構類似，但是由於需要提供高可用的服務，因此在處理能力、穩定性、可靠性、安全性、可擴展性、可管理性等方面的要求較高。
2、在正常的網路環境下，根據伺服器提供的服務類型不同，分為文件伺服器，資料庫伺服器，應用程序伺服器，WEB伺服器等。