三、接口測試
在很多情況下，web 站點不是孤立。Web 站點可能會與外部服務器通訊，請求數據、驗證數據或提交訂單。
1、 服務器接口第一個需要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，然后查看服務器記錄，并驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還可以查詢數據庫，確認事務數據已正確保存。
2、 外部接口有些 web 系統有外部接口。例如，網上商店可能要實時驗證信用卡數據以減少欺詐行為的發生。測試的時候，要使用 web 接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。如果商店只使用 Visa 卡和 Mastercard 卡， 可以嘗試使用 Discover 卡的數據。（簡單的客戶端腳本能夠在提交事務之前對代碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover.）通常，測試人員需要確認軟件能夠處理外部服務器返回的所有可能的消息。
3、錯誤處理最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認系統能夠處理所有錯誤，但卻無法預期系統所有可能的錯誤。嘗試在處理過程中中斷事務，看看會發生什么情況？
訂單是否完成？嘗試中斷用戶到服務器的網絡連接。嘗試中斷 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應用系統開發沒有聯系或聯系很少的人員）的參與，最好是最終用戶的參與。
五、兼容性測試
需要驗證應用程序可以在用戶使用的機器上運行。如果您用戶是全球范圍的，需要測試各種操作系統、瀏覽器、視頻設置和 modem 速度。最后，還要嘗試各種設置的組合。
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的設置也不一樣。
測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。
采用測試工具：通過白盒測試或者黑盒測試導出的測試用例，采用相應的工具進行測試，可以采用OpenSTA進行測試，此測試工具可以采用不同的瀏覽器進行測試。
3.視頻測試頁面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否顯示正常？ 字體是否太小以至于無法瀏覽？ 或者是太大？ 文本和圖片是否對齊？
4.Modem/連接速率測試是否有這種情況，用戶使用 28.8 modem下載一個頁面需要 10 分鐘，但測試人員在測試的時候使用的是 T1 專線？ 用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。最后，需要確認圖片不會太大。
5、打印機測試用戶可能會將網頁打印下來。因此網頁在設計的時候要考慮到打印問題，注意節約紙張和油墨。有不少用戶喜歡閱讀而不是盯著屏幕，因此需要驗證網頁打印是否正常。有時在屏幕上顯示的圖片和文本的對齊方式可能與打印出來的東西不一樣。測試人員至少需要驗證訂單確認頁面打印是正常的。
6、組合測試最后需要進行組合測試。600x800 的分辨率在 MAC 機上可能不錯，但是在 IBM 兼容機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻無法使用 Lynx 來瀏覽。
如果是內部使用的 web 站點，測試可能會輕松一些。如果公司指定使用某個類型的瀏覽器，那么只需在該瀏覽器上進行測試。如果所有的人都使用 T1 專線，可能不需要測試下載施加。
�。ǖ枰⒁獾氖�，可能會有員工從家里撥號進入系統） 有些內部應用程序，開發部門可能在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。但是，理想的情況是，系統能在所有機器上運行，這樣就不會限制將來的發展和變動。
六、安全測試
Web應用系統的安全性測試區域主要有：
1、 目錄設置Web 安全的第一步就是正確設置目錄。每個目錄下應該有 index.html 或 main.html 頁面，這樣就不會顯示該目錄下的所有內容。如果沒有執行這條規則。那么選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑"…com/objects/images".然后在瀏覽器地址欄中手工輸入該路徑，發現該站點所有圖片的列表。這可能沒什么關系。但是進入下一級目錄 "…com/objects" ，點擊 jackpot.在該目錄下有很多資料，其中有些都是已過期頁面。如果該公司每個月都要更改產品價格信息，并且保存過期頁面。那么只要翻看了一下這些記錄，就可以估計他們的邊際利潤以及他們為了爭取一個合同還有多大的降價空間。如果某個客戶在談判之前查看了這些信息，他們在談判桌上肯定處于上風。
2.登錄現在的Web應用系統基本采用先注冊，后登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
3.Session Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
4.日志文件為了保證Web應用系統的安全性，日志文件是至關重要的。需要測試相關信息是否寫進了日志文件、是否可追蹤。
5.加密當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
6.安全漏洞服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
目前網絡安全問題日益重要，特別對于有交互信息的網站及進行電子商務活動的網站尤其重要。目前我們的測試沒有涵蓋網站的安全性的測試，我們擬定采用工具來測定，工具如下SAINT—— Security Administrator‘s Integrated Network Tool此工具能夠測出網站系統的相應的安全問題，并且能夠給出安全漏洞的解決方案，不過是一些較為常見的漏洞解決方案。
七、代碼合法性測試
代碼合法性測試主要包括2個部分：程序代碼合法性檢查與顯示代碼合法性檢查。
1、程序代碼合法性檢查程序代碼合法性檢查主要標準為《intergrp小組編程規范》，目前采用由SCM管理員進行規范的檢查，未來期望能夠有相應的工具進行測試。
2、顯示代碼合法性檢查顯示代碼的合法性檢查，主要分為Html、JavaScript、Css代碼檢查，目前采用HTML代碼檢查——采用CSE HTML Validator進行測試JavaScript、Css也可以在網上下載相應的測試工具。
八、 文檔測試
l、產品說明書屬性檢查清單
1）完整。是否有遺漏和丟失，完全嗎？ 單獨使用是否包含全部內容
2）準確。既定解決方案正確嗎？ 目標明確嗎？ 有沒有錯誤？
3）精確、不含糊、清晰。描述是否一清二楚？ 還是自說自話？容易看懂和理解嗎？
4）一致。產品功能能描述是否自相矛盾，與其他功能有沒有沖突
5）貼切。描述功能的陳述是否必要？有沒有多余信息？ 功能是否原來的客戶要求？
6）合理。在特定的預算和進度下，以現有人力，物力和資源能否實現？
7）代碼無關。是否堅持定義產品，而不是定義其所信賴的軟件設計，架構和代碼
8）可測試性。特性能否測試？ 測試員建立驗證操作的測試程序是否提供足夠的信息？
2、 產品說明書用語檢查清單
1）說明。 對問題的描述通常表現為粉飾沒有仔細考慮的功能——可歸結于前文所述的屬性。從產品說明書上找出這樣的用語，仔細審視它們在文中是怎樣使用的。產品說明書可能會為其掩飾和開脫，也可能含糊其詞——無論是哪一種情況都可視為軟件缺陷。
2）總是，每一種，所有，沒有，從不。如果看到此類絕對或肯定的，切實認定的敘述，軟件測試員就可以著手設計針鋒相對的案例。
3）當然，因此，明顯，顯然，必然。這些話意圖誘使接受假定情況。不要中了圈套。
4）某些，有時，常常，通常，慣常，經常，大多，幾乎。這些話太過模糊。"有時"發生作用的功能無法測試。
5）等等，諸如此類，依此類推。以這樣的詞結束的功能清單無法測試。功能清單要絕對或者解釋明確，以免讓人迷惑，不知如何推論。
6）良好，迅速，廉價，高效，小，穩定。這些是不確定的說法，不可測試。如果在產品說明書中出現，就必須進一步指明含義。
7）已處理，已拒絕，已忽略，已消除。這些廉潔可能會隱藏大量需要說明的功能。
8）如果……那么……（沒有否則）。找出有"如果……那么……"而缺少配套的"否則"結構的陳述。想一想"如果"沒有發生會怎樣。
相關的測試工具OpenSTA主要做性能測試的負荷及壓力測試，使用比較方便，可以編寫測試腳本，也可以先行自動生成測試腳本，而后對于應用測試腳本進行測試。
SAINT網站安全性測試，能夠對于指定網站進行安全性測試，并可以提供安全問題的解決方案。
CSE HTML Validator一個有用的對于HTML代碼進行合法性檢查的工具Ab（Apache Bench）
Apache自帶的對于性能測試方面的工具，功能不是很多，但是非常實用。
Crash-me Mysql自帶的測試數據庫性能的工具，能夠測試多種數據庫的性能。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
