第一篇：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都能夠被跟蹤。

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

第二篇：軟件測試總結報告

引言

1.1 編寫目的

編寫該測試總結報告主要有以下幾個目的 1．通過對測試結果的分析，得到對軟件質量的評價

2．分析測試的過程，產品，資源，信息，為以后制定測試計劃提供參考 3．評估測試測試執行和測試計劃是否符合

4.分析系統存在的缺陷，為修復和預防 bug 提供建議

1.2 背景

1.3 用戶群

主要讀者：***項目管理人員 其他讀者：*** 項目相關人員。

1.4 定義

基本功能點測試：等價類劃分法、邊界值法、錯誤推測法、場景法

業務流程測試：根據業務邏輯，構建測試數據，執行業務流程，查看執行結果與預期是否一致 界面易用性測試：根據界面測試規范及日常使用習慣，提出軟件的非功能實現問題

回歸測試：對已修復的問題，根據測試出該錯誤的用例，重新執行該用例，驗證問題是否真正被修復，以及是否又引起了其它錯誤

1.5 測試對象

對綜合管理系統進行全新測試，主要進行功能測試、系統測試

1.6 測試階段

第一階段：對主業務邏輯及功能進行測試 第二階段：對所有業務邏輯及功能進行深入測試 第三階段：回歸測試

1.7 測試工具

BugFree缺陷管理工具

1.8 參考資料

《***功能描述》 《***數據字典》 《***測試計劃》 《***測試用例》 《***項目計劃》 測試概要

***系統測試從 2012年7月25日到2012年10月12日基本結束，歷時近70個工作日。后續還有一些掃尾的工作，又增加一些工作時日。是一項花費大量人力物力的項目。

***通過BugFree缺陷管理工具進行缺陷跟蹤管理，在bugfree中有詳細的測試用例以及用例執行情況記錄

2.1 進度回顧

2.2 測試執行

此次測試嚴格按照項目計劃和測試計劃執行，按時完成了測試計劃規定的測試對象的測試。針對測試計劃規定的測試策略，在測試執行中都有體現，在測試執行過程中，依據測試計劃和測試用例，對系統進行了完整的測試、2.3 測試用例

測試環境與方法

3.1 軟硬件環境

3.2 測試方法和工具 測試結果

4.1 Bug 引入階段

4.2 Bug 引入原因 測試覆蓋分析

1.此次測試的重點在在于對功能的測試，特別是V2.0新增功能的測試； 2.***完成在常見的操作環境下的測試，因此具有良好的兼容性。

3.本次此時的目的除了基本的功能測試外，重點突出對系統易用性的測試，力圖使系統更加的人性化，操作更加簡單，易懂。測試結果和建議

6.1 測試結論

1.***的測試工作已基本結束，功能測試目標也已完成，剩下部分報表的設計需要繼續完善。

2.本次測試從功能性，易用性，兼容性等多個方面進行測試，力圖在滿足客戶需求的基礎上操作更加簡捷，人性化。6.2 改進建議

1.測試過程中遇到的最大問題是需求的不確定性和需求的變更。前期由于開發人員和測試人員對一些需求的理解不一致，或是在需求文檔中需求的定義不明確，大家根據自己的理解開展工作，繼而在后期工作中產生一些不必要的bug;除此之外，由于在前期，沒有對客戶的需求進行較為準確的界定，在開發過程中，客戶提出一些新的要求，而這些要求和其他功能具有關聯性，需求做改動，開發和測試也進行改動，比較顯著地例子是在開發中后期要求在一個關聯性強的表中增加一個字段，從而引起一系列重復的測試。因此我認為在開發前期要反復確定需求，并制定需求變更標準，避免在開發過程中出現重復，返工的現象。

2.本次測試由于主要是手工測試，因此未能實現對一些功能的進行大量數據操作的測試

3.系統目前比較明顯的缺陷是報表打開速度比較慢，這個嚴重影響了系統的性能，是需要研究改進的部分。

第三篇：《軟件測試技術》課程總結報告

《軟件測試技術》課程總結報告

班級：姓名：學號：

一、課程概述

二、課程實訓項目

三、課程知識點總結

四、收獲和體會

第四篇：web測試心得

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

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

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

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

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

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

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

2、購物車的測試

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

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

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

3、支付流程測試

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

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

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

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

當網站某個模塊涉及的數據傳遞比較多而且比較復雜時，一定要搞清楚數據是怎么傳遞的，因為這是最容易出現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認證加密機制是否有效等多 個方面。