第一篇：web測試心得

做電子商務網站測試已經一個月了，這一個月基本上是熟悉網站產品和流程的一個過程，對網站的各個部分基本上都進行了一次測試，感覺電子商務網站主要注意以下幾點：

1、注冊和登錄模塊的測試

在測試該部分時，給我印象最深的就是：

1)注冊成功，但登陸失敗：注冊時，密碼設置為一些特殊的符號，比如：空格、%等，但登錄時，失敗。

后來經開發人反映出現這樣的問題，原因是：在登錄模塊，對密碼設置了一些限定。

2)登錄時，沒區分大小寫，就是說，用小寫字母注冊的，登錄時，用相應的大寫字母登錄也能成功。

出現問題的原因：登錄時，沒用MD5加密進行驗證

2、購物車的測試

1)測試產品能否放入購物車中

2)當某種產品有購物數量限制時，超過這一數值，能否也能放入購物車中

3)購物車中的購物限制是否正確

3、支付流程測試

1)購物車中的產品能否正常支付

2)當支付完成，不等頁面跳轉，直接關閉瀏覽器，數據傳遞是否正確

3)當支付完成，等待頁面跳轉，跳轉到得頁面是否正確

4、網站某個模塊間的數據傳遞是否正確

當網站某個模塊涉及的數據傳遞比較多而且比較復雜時，一定要搞清楚數據是怎么傳遞的，因為這是最容易出現bug的地方。比如：下拉菜單的數據沒有傳遞過來，或傳遞過來了，但不正確，這時就要靜下心來，慢慢濾清思考，耐心去測試。

最后一點就是，在購買的過程中，也要考慮到并發，比如，當某種產品只剩一件了，這時兩個用戶或更多同時并發點擊該產品，放入購物車中，那么在多個用戶同時點擊這個只剩一件的產品時，系統是否有相應的提示，或是，該產品能否都放入不同用戶的購物車中，我上周測試的過程中，該問題是存在的，等待明天程序的解答和修改。

第二篇：WEB測試總結

WEB測試總結(架構,設計)精華部分

1、總計架構測試

1）瘦客戶端，業務邏輯規則多數在服務器端執行。如新聞站點、門戶網站、信息發布網站等。

2）胖客戶端，安全性要求較高、交互操作頻繁、業務邏輯復雜。銀行系統、網絡游戲、網上辦公系統等。

2、Web架構組成部分是否滿足需求

成本、功能、安全性要求、容量要求、傳輸實時性。

3、服務器配置分布是否滿足要求

Web服務器、應用服務器、數據庫服務器可以分布在不同物理機器上也可以分布相同的物理機器上，一般優先考慮獨立數據庫服務器，Web服務器、應用服務器可以在相同的機器上。

4、客戶端設計測試

1）功能設置測試：信息服務、辦公自動化、Internet支持； 2）信息組織結構測試：線性結構、分層結構、非線性結構； 3）頁面設計測試：a.頁面一致性測試

b.用戶界面友好性及導航直觀性測試；、c.是否適合多種瀏覽器； d.頁文件的命名； e.頁面布局技術。

5、服務器端設計測試

1）容量規劃測試：點擊率、延遲和流量、服務器資源；

2）系統安全測試：a.常識性安全策略，取消不必要的協議、控制寫權限、取消服務器目錄瀏覽屬性、記錄日志等； b.使用加密技術；

c.構造防火墻，網絡級、應用級、電路級； d.構建網絡防毒體系。3）數據庫設計測試。

6、Web開發測試

1）源代碼分析，主要是使用檢查工具來完成； 2）鏈接測試，主要借助工具來完成； 3）框架測試：a.自動調整窗口大小； b.是否提供滾動條；

c.打開新頁面是否正常。4)表格測試，隨窗體變化自動調整大小； 5）圖形測試：a.顏色飽和度及對比度； b.鏈接標識；

c.圖形顯示是否正確。

1、與一般應用軟件相比，Web測試有以下區別：

第一、Web測試的側重點是性能、安全、易用性、兼容

第二、測試工具有所不同，如鏈接測試、表單測試、界面測試

2、功能測試

一、客戶端的選擇，優先測試流行的客戶客戶端；

二、客戶端瀏覽器的配置

三、客戶端的顯示設置

四、內容測試

3、鏈接測試

一、該鏈接將用戶帶到它所說明的地方

二、被鏈接的頁面是存在的

三、保證沒有孤立頁面

工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等

4、鏈接測試工具的優勢：

一、簡單易用

二、在實現上采用多線程技術，檢查速度特別快；

三、對斷開的鏈接可以再次測試，可以避免誤判；

四、沒有檢查鏈接的數量限制，只受系統資源的約束；

五、可以分析Web應用的結構；

六、檢查結果可以分類查看，自動生成HTML格式的報告；

5、Web應用鏈接主要測試點如下

一、測試內部鏈接和外部鏈接中成功和失敗的鏈接點，以及應用中不被其他鏈接調用的頁面；

二、測試鏈接中新網頁、老網頁、慢網頁以及丟失的圖象標題標簽和屬性標簽等；

三、分析Web應用的結構是否合理，包括顯示和某個URL相關的鏈接以及按照標題、描述、作者、大小、最后修改時間、類型為URL鏈接分類等。

6、易用性測試

易用性測試要考慮以下幾個方面： 1）用戶的計算機使用經驗；

2）用戶對瀏覽器以及Web的使用經驗； 3）用戶的業務專業知識。

7、Web系統的易用性測試分為三個方面： 1）界面測試

2）輔助功能測試 3）圖形測試

一、界面測試要考慮以下幾個問題 A．WEB應用系統的最終用戶群是誰？ B．WEB應用界面的設計策略是什么？ C．頁面中各元素布局的協調性 a.各元素位置的協調性 b.各元素顏色的協調性

c.各元素大小比例的協調性 D．不同頁面風格的統一性

E．用戶在界面中操作的便利性 F．界面動態操作測試

a.屏幕分辯率設置的影響

b.瀏覽窗口最大化/最小化的影響 c.選定目標元素的置中與縮放

二、輔助功能測試 A．使用說明，這個沒有多大意義，WEB網頁按F1彈出來的頁面都是IE的幫助頁面，除非有特定的幫助說明內容； B．導航功能 C．站點地圖

D．幫助，這個沒有多大意義，WEB網頁按F1彈出來的頁面都是IE的幫助頁面，除非有特定的幫助說明內容；

第三篇：Web測試工具小結

Web測試工具小結

單元測試方面：（對開發人員比較有用）J-Unit工具。

功能測試方面：E-test是個不錯的選擇，功能很強大，由于不是采用Post URL的方式回放腳本，所以可以支持多內碼的測試數據（當然要程序支持）。基本上可以應付大部分的Web Site。

如果只是利用腳本回放代替手工勞動，或者做對頁面響應數的性能測試，Microsoft Web Application Stress Tool是個不錯的選擇。

另外，在性能測試方面，PureLoad也是一個不錯的工具，完全用Java寫成，可以測試各種C/S程序，如SMTP Server等。這兩個工具都是使用Post URL的方法測試Web Application的。對大量使用JavaScript的頁面不太適合。當然，如果程序在Unix，linux下面運行的話，可以直接編寫Shell腳本程序，更加方便。

另外，還有很多專門的工具，比如說Linkbot是專門作頁面鏈接測試的。

另外，測試流程管理工具也有不少，個人用過也一直在用的是Test Plan Control，短小精悍，不錯。

至于WinRunner和LoadRunner之類，因為沒有License，所以都沒怎么用過，慚愧。不過我看過一篇英國人評價英國測試市場上最流行的五個軟件的文章。WinRunner得分最高。

測試工具從測試的方法上可以分為兩種：白盒測試和黑盒測試

白盒測試工具主要有：

內存資源泄漏檢查：Numega中的bouncechecker,Rational的Purify等

代碼覆蓋率檢查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等

代碼性能檢查：Numega中的truetime,Rational的Quantify等

代碼靜態度量分析質量檢查工具：logiscope和Macabe等

黑盒測試工具主要有：

客戶端功能測試：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等

服務器端壓力性能測試： MI公司的winload,compuware的qaload,Rational的SQA load等等

Web測試工具：MI公司的Astra系列，rsw公司的e-test suite等等

測試管理工具：rational的test manager,compuware的qadirector等等，此外還有缺陷跟蹤工具 trackrecord等。

數據庫測試工具:TestBytes

黑盒測試工具：QACenter、SQATeamTest，Rational Viaual Test。

回歸測試工具：Rational TeamTest，WinRunner（MI公司）

WEB系統測試工具：TEST，Workberch，Web Appication Stress Tool（WAS）

白盒測試工具：Numega、PuRe、軟件糾錯工具（Rational Purity）。

嵌入式測試工具：Logiscope（靜態測試工具）、CodeTest。

系統負荷測試工具：RationalPerformance

涵蓋測試工具范圍評估工具

軟件性能測試工具：LoadRunner（MI產品）、Rational Visual Qantify

測試管理工具：TestDirector（MI產品支持整個生命周期中測試流程管理）

第四篇：WEB軟件測試總結報告

XXX管理平臺

XXX項目測試總結報告

目錄

1.項目測試結果........................................................................................................................2 1.1 BUG嚴重程度................................................................................................................2 1.2 BUG問題分布狀況........................................................................................................3 2.測試結論................................................................................................................................4 2.1界面測試.........................................................................................................................4 2.2功能測試.........................................................................................................................4 2.3兼容性測試.....................................................................................................................4 2.4易用性.............................................................................................................................4 2.5 負載/壓力測試...............................................................................................................5 3.軟件問題總結與分析............................................................................................................6 4.建議........................................................................................................................................7

XXX管理平臺

1.項目測試結果

1.1 BUG嚴重程度

測試發現的bug主要集中在次要功能和輕微，屬于一般性的缺陷，但測試的時候出現了37個主邏輯級別的bug,以及嚴重級別的2個.XXX管理平臺

1.2 BUG問題分布狀況

由上圖可以看出，主要為代碼錯誤占36%,以及標準規范的問題占35%,界面優化占17%,設計缺陷占9%,其他占2%

XXX管理平臺

2.測試結論

2.1界面測試

網站系統實現與設計稿一致。站點的導航條位置，導航的內容布局，首頁呈現的樣式與需求一致。網站的界面符合標準和規范，直觀性強。

2.2功能測試

分不同賬號 總權限賬號,以及店長賬號分別進行功能測試。1:鏈接測試無問題,不存在死鏈接,測試鏈接都存在.2:對頁面各個不同數據的測試,主要的出入庫,銷售報表,訂單查看管理等一一對應,不存在數據有誤差的問題.2.3兼容性測試(Windows下)測試總的瀏覽器包括:360極速瀏覽器,火狐瀏覽器,谷歌瀏覽器,IE瀏覽器,測試通過,主要邏輯以及次要功能都沒問題,因為瀏覽器的不同,導致界面瀏覽不一定相同,例如有的界面瀏覽頁面顯示正常,有的界面顯示不一樣。

2.4易用性

網站實現了如下易用性： 1.輸入限制的正確性

2.輸入限制提示信息的正確性，可理解性，一致性 3.界面排版美觀

4.web應用系統易于導航，直觀

5.web應用系統的頁面結構、導航、菜單、連接的風格一致

XXX管理平臺

2.5 負載/壓力測試

主要測試了壓了測試: 測試

結

果

60秒內發請求,一次1000個請求,總共請求了2230個請求,成功了2208個失敗兩個 1:每個請求用時30ms(吞吐量)2:服務器收到請求，響應頁面要花費的時間:332ms 3: 并發的每個請求平均消耗時間 :33.ms 4:請求一共花了:72s

XXX管理平臺

第一個1000個人同時發出1000個請求 總共1004個請求失敗4個,成功1000 1:每個請求用時9ms(吞吐量)2:服務器收到請求，響應頁面要花費的時間:109128ms 3: 并發的每個請求平均消耗時間 :109.ms 4:請求一共花了:109s

1:如上圖當同時在線人數達到45時候,服務器崩潰,導致成功率一直下降到達40%,直到結束總請求達到:26796.平均每個請求響應時間為281ms,系統吞吐量(tps)20.89/s.因為系統被困導致數據反映不準.3.軟件問題總結與分析

從測試過程中發現bug的嚴重程度與分布狀況來看，引起缺陷主要有以下幾方面：

1.沒有需求文檔

需求文檔只是個大綱的形式，沒有詳細的需求文檔。沒有相應的輸入輸出字段限制及統一的字段名稱，使得開發人員根據需求進行設計時，沒有考慮相關功能的關聯性。在沒有詳細需求的指引下，開發人員根據自己的經驗進行設計，負著不同模塊開發的人員沒有統一設計。在測試過程中，需求相關聯的問題表現出來，及風格統一的問題。例外沒有需求文檔導致測試,無法根據需求文檔來進行用例的設計,只有靠自己自己測試經驗來測試排除BUG.2.功能性錯誤

在測試的過程中，部分功能沒有現實，導致部分模塊無法進行功能的測試。功能實現錯誤，在功能模塊的開發時，是進行先開發后調整的策略，沒有具體的需求文檔，部分模塊的功能實現有所偏差。

3.頁面設計易用性缺陷 頁面輸入字段限制不統一，系統中多個頁面存在相同的字段，但用戶輸入相

XXX管理平臺

同的數據，提示輸入的限制不相同，沒有統一輸入字段的限制。

提示信息錯誤，不同模塊相同結果的提示信息不一致，用戶操作后，相應的提示信息不明確，引起用戶誤解。

提示信息一致性，用戶在不同頁面執行相同的操作，提示信息不同。4.開發人員疏忽引起的缺陷

網站在開發的過程中，不斷的追加新需求，或調整。開發人員修復或修改問題時，有時疏忽沒對相關聯的地址進行修改驗證。導致因修改修復問題而引入更多的問題。

5.開發版本的控制

在測試一個版本(代理商版)，發現問題重復出現，還會引入新的bug,開發人員修改的問題時，提交的版本相互覆蓋。引起上一個版本已關閉的問題，在下一版本重復出現。

4.建議

在項目開始的時候，應該制定相應的標準，編碼標準，需求變更標準等，開發和測試人員嚴格按照標準進行，可以在后期減少因為開發，測試不一致而導致的問題，同時可以降低溝通成本。

發布版本的時候，正確布置測試環境，減少因為測試環境，測試數據庫數據的問題而出現的無效bug。

開發人員解決bug的時候，填寫bug原因以及解決方式，方便bug的跟蹤。開發人員在開發版本上發現bug，可以通知測試人員，因為開發人員發現的bug很有可能在測試版本上出現，而測試人員和開發人員的思路不同，有可能測試人員沒有發現該bug，而且，這樣可以保證發現的bug都能夠被跟蹤。

做好版本的控制，從開發版本，測試版本做好每個環節的版本控制。

第五篇：淺談Web應用服務器測試

淺談Web應用服務器測試

作者：中國軟件評測中心 2002年11月

隨著Internet 的發展壯大，新的開發模式也應運而生，即所謂的B/S（瀏覽器/服務器）結構、瘦客戶機模式。為了方便的開發、部署、運行和管理基于三層、多層結構的應用，需要 以Web的低層技術為基礎，規劃一個整體的應用框架，提供相應的支撐平臺，這一支撐平臺實 際上是基于Internet的中間件，即應用服務器。

應用服務器通過把用戶接口、商業邏輯和后臺服務分割開來，向開發者提供一種創建、部 署和維護企業規模的Web應用的模塊化方式，從而對要轉向Web的用戶提供了高性能多線程的環 境。

考慮到web應用服務器的以上應用背景和產品特點，把為功能度、性能、兼容性、安全可 靠性作為重點測試方向，并且引用SUN Mircrosystems公司的J2EE標準作為參考標準。

一、功能測試

功能測試的主要目的是驗證一款產品是否是一個符合J2EE標準的企業級web應用服務器。測試前，應針對J2EE標準中的JSP、SERVLET、JDBC、EJB等主要功能編寫測試用例。測試 用例應盡量覆蓋典型的應用和操作，以此來證明一款產品符合J2EE標準中提到的功能。特別是 功能度測試項目，應遵循開發廠商提供的用戶手冊或程序員手冊中有關功能部分的描述作為依 據具體制定。

二、性能測試

性能測試的主要目的是考查在大壓力和大數據量情況下，應用服務器最大處理能力和系統 響應時間，同時考查不同壓力情況下應用服務器處理能力和系統響應時間。

測試過程中，首先通過JDBC接口與數據庫進行連接，根據被測系統的應用環境和實際情況 制定與之相適應的案例數據庫。然后使用功能測試中用到的JSP、Servlet和EJB測試程序，通 過Web Application Stress Tool1.1錄制相應的測試腳本，模擬在多用戶并發情況下數據庫的 插入、更新、查詢，并記錄成功點擊次數、點擊率等相關參數。最后通過遠程監控系統對Web 應用服務器的CPU占有率、內存進行實時監控，通過對上述數據的匯總分析，得出功能服務器 的性能。

三、兼容性測試

兼容性部分的測試應分成兩部分來考察：即硬件兼容性和軟件兼容性。

硬件兼容性主要驗證Web應用服務器的硬件配置要求。測試中，可以根據廠商提供的安裝 手冊承諾的配置信息，來驗證功能服務器的硬件兼容性。

軟件兼容性考察的方面較多，主要包括：系統兼容性、數據庫兼容性、Web服務器兼容 性、開發工具兼容性、與其它中間件產品的兼容性、J2EE組件的兼容性等多個方面。

四、安全可靠性測試

安全可靠性測試除了要考察用戶權限限制、輸入數據有效性檢查等基本內容，還應著重考 察在大壓力和大數據量情況下系統的穩定性，以及驗證系統的SSL認證加密機制是否有效等多 個方面。