四、客戶端兼容性測試

1、平臺測試

市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決于用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。

因此，在Web系統發布之前，需要在各種操作系統下對Web系統進行兼容性測試。

2、瀏覽器測試

瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、JavaScript、ActiveX、plug-ins或不同的HTML規格有不同的支持。例如，ActiveX是Microsoft的產品，是為InternetExplorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。

測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。

五、安全性測試

Web應用系統的安全性測試區域主要有：

（1）現在的Web應用系統基本采用先注冊，后登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。

（2）Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。

（3）為了保證Web應用系統的安全性，日志文件是至關重要的。需要測試相關信息是否寫進了日志文件、是否可追蹤。

（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。

（5）服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。

六、總結

以上從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基于Web的系統測試方法。

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

web頁面測試注意事項：

Web測試往往不被測試人員重視，認為是沒有技術含量的體力活，本人結合自己的工作經驗談談Web測試中的一些注意事項，或許會對大家有所幫助。測試過程中主要考慮HTML頁面、TCP/IP通訊、Internet鏈接、防火墻和運行在web頁面上的一些程序（例如，applet、javascript、應用程序插件），以及運行在服務器端的應用程序（例如，CGI腳本、數據庫接口、日志程序、動態頁面產生器）。另外，因為服務器和瀏覽器類型很多，不同版本差別很小，但是表現出現的結果卻不同，連接速度以及日益迅速的技術和多種標準、協議。當然還可以借助Web測試工具對其進行自動化測試。其它要考慮的如下：

1、服務器上期望的負載是多少（例如，每單位時間內的點擊量），在這些負載下應該具有什么樣的性能（例如，服務器反應時間，數據庫查詢時間）。性能測試需要什么樣的測試工具呢（例如，web負載測試工具，其它已經被采用的測試工具，web自動下載工具，等等）？

2、系統用戶是誰？他們使用什么樣的瀏覽器？使用什么類型的連接速度？他們是在公司內部還是外部？

3、在客戶端希望有什么樣的性能（例如，頁面顯示速度？動畫、applets的速度等？如何引導和運行）？

4、允許網站維護或升級嗎？

5、需要考慮安全方面（防火墻，加密、密碼等）是否需要，如何做？怎么能被測試？需要連接的Internet網站可靠性有多高？對備份系統或冗余鏈接請求如何處理和測試？web網站管理、升級時需要考慮哪些步驟？需求、跟蹤、控制頁面內容、圖形、鏈接等有什么需求？

6、需要考慮哪種HTML規范？多么嚴格？允許終端用戶瀏覽器有哪些變化？

7、頁面顯示和/或圖片占據整個頁面或頁面一部分有標準或需求嗎？

8、內部和外部的鏈接能夠被驗證和升級嗎？多久一次？

9、產品系統上能被測試嗎？或者需要一個單獨的測試系統？瀏覽器的緩存、瀏覽器操作設置改變、撥號上網連接以及Internet中產生的“交通堵塞”問題在測試中是否解決，這些考慮了嗎？

10、服務器日志和報告內容能定制嗎？它們是否被認為是系統測試的主要部分并需要測試嗎？

11、CGI程序、applets、javascripts、ActiveX組件等能被維護、跟蹤、控制和測試嗎？

18、測試用的評審需要注意一些什么？主要是針對哪些人群？

專家分析：在國內這個評審這個概念很淡薄，但是卻是無處不在的。比如經常做的代碼走查、立項會議、需求討論等等其實都是一種簡化的評審，有的公司把這叫做“頭腦風暴”（往往是遇到難題的時候集中大家的智慧來沖關）

1、可以評審的東東很多，需求、策略、計劃、用例、代碼…基本上項目中你能想到的東西，都可以拿出來評審。

2、組織評審需要有清晰的目的（這個是整個環節中重要的部分），很簡單，你首先要知道，你需要從這個評審中得到什么？也許是希望被評審東東更加完善，也許是希望增加大家交流的機會，甚至可能是為了應付上面的檢查等等。

3、不同目的評審，參與人員自然也隨之變化：比如，希望需求更加完善的評審，理論一切與產品有關的人員，大到項目經理，小到一線銷售人員都需要來參加。但是，往往評審的人員越多，時間上就越難安排，所以需要結合實際情況來刪減。當然，也不是說必須要XX人參加的評審才叫評審，比如一個BA與一個客戶或開發人員私下的一次交流，只要做了詳細的記錄，也可以算作是一個評審。

所以，有內容的評審其實是不拘形式的，假如非得搞個內審或外審來規范，我只能說那是走過場而已。

4、在組織評審的細節上，有一點很重要：不要在評審過程中“照本宣書”。

很多公司在評審前不做準備，評審時拉個主持人上去就對著文檔、PPT一陣讀，半天下來，問大家有沒問題，結果只能是只言片語。

所以，在評審前最好先做預審，也就是在評審前，給予評審人員一定的時間，也許是三、兩天，也許是一星期，讓評審人員熟悉評審目標，并提出自己的意見，由一個統一的程序收集起來，在評審中逐一解決。這樣的效果會好很多。

5、最后說說比較規范的評審流程

確定評審目標——確定參與人員（包括主持人、記錄員、評審員等）——安排評審時間——預審——整理預審報告——評審——整理評審報告——作者修改評審目標——復審（復審可以走簡單流程，由各個提建議的評審人員查看自己的建議是否得到合理的修改）——存檔

19、測試用例的粒度如何界定？碰到功能復雜的測試，應該如何書寫測試用例？

專家分析：根據需求來定。較復雜的，可以先畫出流程圖，再進行編寫測試用例。

文章來源：網絡 版權歸原作者所有

上文內容不用于商業目的，如涉及知識產權問題，請權利人聯系小編，我們將立即處理