第一篇:web測試心得
做電子商務網(wǎng)站測試已經(jīng)一個月了,這一個月基本上是熟悉網(wǎng)站產(chǎn)品和流程的一個過程,對網(wǎng)站的各個部分基本上都進行了一次測試,感覺電子商務網(wǎng)站主要注意以下幾點:
1、注冊和登錄模塊的測試
在測試該部分時,給我印象最深的就是:
1)注冊成功,但登陸失?。鹤詴r,密碼設置為一些特殊的符號,比如:空格、%等,但登錄時,失敗。
后來經(jīng)開發(fā)人反映出現(xiàn)這樣的問題,原因是:在登錄模塊,對密碼設置了一些限定。
2)登錄時,沒區(qū)分大小寫,就是說,用小寫字母注冊的,登錄時,用相應的大寫字母登錄也能成功。
出現(xiàn)問題的原因:登錄時,沒用MD5加密進行驗證
2、購物車的測試
1)測試產(chǎn)品能否放入購物車中
2)當某種產(chǎn)品有購物數(shù)量限制時,超過這一數(shù)值,能否也能放入購物車中
3)購物車中的購物限制是否正確
3、支付流程測試
1)購物車中的產(chǎn)品能否正常支付
2)當支付完成,不等頁面跳轉,直接關閉瀏覽器,數(shù)據(jù)傳遞是否正確
3)當支付完成,等待頁面跳轉,跳轉到得頁面是否正確
4、網(wǎng)站某個模塊間的數(shù)據(jù)傳遞是否正確
當網(wǎng)站某個模塊涉及的數(shù)據(jù)傳遞比較多而且比較復雜時,一定要搞清楚數(shù)據(jù)是怎么傳遞的,因為這是最容易出現(xiàn)bug的地方。比如:下拉菜單的數(shù)據(jù)沒有傳遞過來,或傳遞過來了,但不正確,這時就要靜下心來,慢慢濾清思考,耐心去測試。
最后一點就是,在購買的過程中,也要考慮到并發(fā),比如,當某種產(chǎn)品只剩一件了,這時兩個用戶或更多同時并發(fā)點擊該產(chǎn)品,放入購物車中,那么在多個用戶同時點擊這個只剩一件的產(chǎn)品時,系統(tǒng)是否有相應的提示,或是,該產(chǎn)品能否都放入不同用戶的購物車中,我上周測試的過程中,該問題是存在的,等待明天程序的解答和修改。
第二篇:WEB測試總結
WEB測試總結(架構,設計)精華部分
1、總計架構測試
1)瘦客戶端,業(yè)務邏輯規(guī)則多數(shù)在服務器端執(zhí)行。如新聞站點、門戶網(wǎng)站、信息發(fā)布網(wǎng)站等。
2)胖客戶端,安全性要求較高、交互操作頻繁、業(yè)務邏輯復雜。銀行系統(tǒng)、網(wǎng)絡游戲、網(wǎng)上辦公系統(tǒng)等。
2、Web架構組成部分是否滿足需求
成本、功能、安全性要求、容量要求、傳輸實時性。
3、服務器配置分布是否滿足要求
Web服務器、應用服務器、數(shù)據(jù)庫服務器可以分布在不同物理機器上也可以分布相同的物理機器上,一般優(yōu)先考慮獨立數(shù)據(jù)庫服務器,Web服務器、應用服務器可以在相同的機器上。
4、客戶端設計測試
1)功能設置測試:信息服務、辦公自動化、Internet支持; 2)信息組織結構測試:線性結構、分層結構、非線性結構; 3)頁面設計測試:a.頁面一致性測試
b.用戶界面友好性及導航直觀性測試;、c.是否適合多種瀏覽器; d.頁文件的命名; e.頁面布局技術。
5、服務器端設計測試
1)容量規(guī)劃測試:點擊率、延遲和流量、服務器資源;
2)系統(tǒng)安全測試:a.常識性安全策略,取消不必要的協(xié)議、控制寫權限、取消服務器目錄瀏覽屬性、記錄日志等; b.使用加密技術;
c.構造防火墻,網(wǎng)絡級、應用級、電路級; d.構建網(wǎng)絡防毒體系。3)數(shù)據(jù)庫設計測試。
6、Web開發(fā)測試
1)源代碼分析,主要是使用檢查工具來完成; 2)鏈接測試,主要借助工具來完成; 3)框架測試:a.自動調整窗口大??; b.是否提供滾動條;
c.打開新頁面是否正常。4)表格測試,隨窗體變化自動調整大??; 5)圖形測試:a.顏色飽和度及對比度; b.鏈接標識;
c.圖形顯示是否正確。
1、與一般應用軟件相比,Web測試有以下區(qū)別:
第一、Web測試的側重點是性能、安全、易用性、兼容
第二、測試工具有所不同,如鏈接測試、表單測試、界面測試
2、功能測試
一、客戶端的選擇,優(yōu)先測試流行的客戶客戶端;
二、客戶端瀏覽器的配置
三、客戶端的顯示設置
四、內容測試
3、鏈接測試
一、該鏈接將用戶帶到它所說明的地方
二、被鏈接的頁面是存在的
三、保證沒有孤立頁面
工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等
4、鏈接測試工具的優(yōu)勢:
一、簡單易用
二、在實現(xiàn)上采用多線程技術,檢查速度特別快;
三、對斷開的鏈接可以再次測試,可以避免誤判;
四、沒有檢查鏈接的數(shù)量限制,只受系統(tǒng)資源的約束;
五、可以分析Web應用的結構;
六、檢查結果可以分類查看,自動生成HTML格式的報告;
5、Web應用鏈接主要測試點如下
一、測試內部鏈接和外部鏈接中成功和失敗的鏈接點,以及應用中不被其他鏈接調用的頁面;
二、測試鏈接中新網(wǎng)頁、老網(wǎng)頁、慢網(wǎng)頁以及丟失的圖象標題標簽和屬性標簽等;
三、分析Web應用的結構是否合理,包括顯示和某個URL相關的鏈接以及按照標題、描述、作者、大小、最后修改時間、類型為URL鏈接分類等。
6、易用性測試
易用性測試要考慮以下幾個方面: 1)用戶的計算機使用經(jīng)驗;
2)用戶對瀏覽器以及Web的使用經(jīng)驗; 3)用戶的業(yè)務專業(yè)知識。
7、Web系統(tǒng)的易用性測試分為三個方面: 1)界面測試
2)輔助功能測試 3)圖形測試
一、界面測試要考慮以下幾個問題 A.WEB應用系統(tǒng)的最終用戶群是誰? B.WEB應用界面的設計策略是什么? C.頁面中各元素布局的協(xié)調性 a.各元素位置的協(xié)調性 b.各元素顏色的協(xié)調性
c.各元素大小比例的協(xié)調性 D.不同頁面風格的統(tǒng)一性
E.用戶在界面中操作的便利性 F.界面動態(tài)操作測試
a.屏幕分辯率設置的影響
b.瀏覽窗口最大化/最小化的影響 c.選定目標元素的置中與縮放
二、輔助功能測試 A.使用說明,這個沒有多大意義,WEB網(wǎng)頁按F1彈出來的頁面都是IE的幫助頁面,除非有特定的幫助說明內容; B.導航功能 C.站點地圖
D.幫助,這個沒有多大意義,WEB網(wǎng)頁按F1彈出來的頁面都是IE的幫助頁面,除非有特定的幫助說明內容;
第三篇:Web測試工具小結
Web測試工具小結
單元測試方面:(對開發(fā)人員比較有用)J-Unit工具。
功能測試方面:E-test是個不錯的選擇,功能很強大,由于不是采用Post URL的方式回放腳本,所以可以支持多內碼的測試數(shù)據(jù)(當然要程序支持)。基本上可以應付大部分的Web Site。
如果只是利用腳本回放代替手工勞動,或者做對頁面響應數(shù)的性能測試,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等
代碼靜態(tài)度量分析質量檢查工具: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等。
數(shù)據(jù)庫測試工具:TestBytes
黑盒測試工具:QACenter、SQATeamTest,Rational Viaual Test。
回歸測試工具:Rational TeamTest,WinRunner(MI公司)
WEB系統(tǒng)測試工具:TEST,Workberch,Web Appication Stress Tool(WAS)
白盒測試工具:Numega、PuRe、軟件糾錯工具(Rational Purity)。
嵌入式測試工具:Logiscope(靜態(tài)測試工具)、CodeTest。
系統(tǒng)負荷測試工具:RationalPerformance
涵蓋測試工具范圍評估工具
軟件性能測試工具:LoadRunner(MI產(chǎn)品)、Rational Visual Qantify
測試管理工具:TestDirector(MI產(chǎn)品支持整個生命周期中測試流程管理)
第四篇: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嚴重程度
測試發(fā)現(xiàn)的bug主要集中在次要功能和輕微,屬于一般性的缺陷,但測試的時候出現(xiàn)了37個主邏輯級別的bug,以及嚴重級別的2個.XXX管理平臺
1.2 BUG問題分布狀況
由上圖可以看出,主要為代碼錯誤占36%,以及標準規(guī)范的問題占35%,界面優(yōu)化占17%,設計缺陷占9%,其他占2%
XXX管理平臺
2.測試結論
2.1界面測試
網(wǎng)站系統(tǒng)實現(xiàn)與設計稿一致。站點的導航條位置,導航的內容布局,首頁呈現(xiàn)的樣式與需求一致。網(wǎng)站的界面符合標準和規(guī)范,直觀性強。
2.2功能測試
分不同賬號 總權限賬號,以及店長賬號分別進行功能測試。1:鏈接測試無問題,不存在死鏈接,測試鏈接都存在.2:對頁面各個不同數(shù)據(jù)的測試,主要的出入庫,銷售報表,訂單查看管理等一一對應,不存在數(shù)據(jù)有誤差的問題.2.3兼容性測試(Windows下)測試總的瀏覽器包括:360極速瀏覽器,火狐瀏覽器,谷歌瀏覽器,IE瀏覽器,測試通過,主要邏輯以及次要功能都沒問題,因為瀏覽器的不同,導致界面瀏覽不一定相同,例如有的界面瀏覽頁面顯示正常,有的界面顯示不一樣。
2.4易用性
網(wǎng)站實現(xiàn)了如下易用性: 1.輸入限制的正確性
2.輸入限制提示信息的正確性,可理解性,一致性 3.界面排版美觀
4.web應用系統(tǒng)易于導航,直觀
5.web應用系統(tǒng)的頁面結構、導航、菜單、連接的風格一致
XXX管理平臺
2.5 負載/壓力測試
主要測試了壓了測試: 測試
結
果
60秒內發(fā)請求,一次1000個請求,總共請求了2230個請求,成功了2208個失敗兩個 1:每個請求用時30ms(吞吐量)2:服務器收到請求,響應頁面要花費的時間:332ms 3: 并發(fā)的每個請求平均消耗時間 :33.ms 4:請求一共花了:72s
XXX管理平臺
第一個1000個人同時發(fā)出1000個請求 總共1004個請求失敗4個,成功1000 1:每個請求用時9ms(吞吐量)2:服務器收到請求,響應頁面要花費的時間:109128ms 3: 并發(fā)的每個請求平均消耗時間 :109.ms 4:請求一共花了:109s
1:如上圖當同時在線人數(shù)達到45時候,服務器崩潰,導致成功率一直下降到達40%,直到結束總請求達到:26796.平均每個請求響應時間為281ms,系統(tǒng)吞吐量(tps)20.89/s.因為系統(tǒng)被困導致數(shù)據(jù)反映不準.3.軟件問題總結與分析
從測試過程中發(fā)現(xiàn)bug的嚴重程度與分布狀況來看,引起缺陷主要有以下幾方面:
1.沒有需求文檔
需求文檔只是個大綱的形式,沒有詳細的需求文檔。沒有相應的輸入輸出字段限制及統(tǒng)一的字段名稱,使得開發(fā)人員根據(jù)需求進行設計時,沒有考慮相關功能的關聯(lián)性。在沒有詳細需求的指引下,開發(fā)人員根據(jù)自己的經(jīng)驗進行設計,負著不同模塊開發(fā)的人員沒有統(tǒng)一設計。在測試過程中,需求相關聯(lián)的問題表現(xiàn)出來,及風格統(tǒng)一的問題。例外沒有需求文檔導致測試,無法根據(jù)需求文檔來進行用例的設計,只有靠自己自己測試經(jīng)驗來測試排除BUG.2.功能性錯誤
在測試的過程中,部分功能沒有現(xiàn)實,導致部分模塊無法進行功能的測試。功能實現(xiàn)錯誤,在功能模塊的開發(fā)時,是進行先開發(fā)后調整的策略,沒有具體的需求文檔,部分模塊的功能實現(xiàn)有所偏差。
3.頁面設計易用性缺陷 頁面輸入字段限制不統(tǒng)一,系統(tǒng)中多個頁面存在相同的字段,但用戶輸入相
XXX管理平臺
同的數(shù)據(jù),提示輸入的限制不相同,沒有統(tǒng)一輸入字段的限制。
提示信息錯誤,不同模塊相同結果的提示信息不一致,用戶操作后,相應的提示信息不明確,引起用戶誤解。
提示信息一致性,用戶在不同頁面執(zhí)行相同的操作,提示信息不同。4.開發(fā)人員疏忽引起的缺陷
網(wǎng)站在開發(fā)的過程中,不斷的追加新需求,或調整。開發(fā)人員修復或修改問題時,有時疏忽沒對相關聯(lián)的地址進行修改驗證。導致因修改修復問題而引入更多的問題。
5.開發(fā)版本的控制
在測試一個版本(代理商版),發(fā)現(xiàn)問題重復出現(xiàn),還會引入新的bug,開發(fā)人員修改的問題時,提交的版本相互覆蓋。引起上一個版本已關閉的問題,在下一版本重復出現(xiàn)。
4.建議
在項目開始的時候,應該制定相應的標準,編碼標準,需求變更標準等,開發(fā)和測試人員嚴格按照標準進行,可以在后期減少因為開發(fā),測試不一致而導致的問題,同時可以降低溝通成本。
發(fā)布版本的時候,正確布置測試環(huán)境,減少因為測試環(huán)境,測試數(shù)據(jù)庫數(shù)據(jù)的問題而出現(xiàn)的無效bug。
開發(fā)人員解決bug的時候,填寫bug原因以及解決方式,方便bug的跟蹤。開發(fā)人員在開發(fā)版本上發(fā)現(xiàn)bug,可以通知測試人員,因為開發(fā)人員發(fā)現(xiàn)的bug很有可能在測試版本上出現(xiàn),而測試人員和開發(fā)人員的思路不同,有可能測試人員沒有發(fā)現(xiàn)該bug,而且,這樣可以保證發(fā)現(xiàn)的bug都能夠被跟蹤。
做好版本的控制,從開發(fā)版本,測試版本做好每個環(huán)節(jié)的版本控制。
第五篇:淺談Web應用服務器測試
淺談Web應用服務器測試
作者:中國軟件評測中心 2002年11月
隨著Internet 的發(fā)展壯大,新的開發(fā)模式也應運而生,即所謂的B/S(瀏覽器/服務器)結構、瘦客戶機模式。為了方便的開發(fā)、部署、運行和管理基于三層、多層結構的應用,需要 以Web的低層技術為基礎,規(guī)劃一個整體的應用框架,提供相應的支撐平臺,這一支撐平臺實 際上是基于Internet的中間件,即應用服務器。
應用服務器通過把用戶接口、商業(yè)邏輯和后臺服務分割開來,向開發(fā)者提供一種創(chuàng)建、部 署和維護企業(yè)規(guī)模的Web應用的模塊化方式,從而對要轉向Web的用戶提供了高性能多線程的環(huán) 境。
考慮到web應用服務器的以上應用背景和產(chǎn)品特點,把為功能度、性能、兼容性、安全可 靠性作為重點測試方向,并且引用SUN Mircrosystems公司的J2EE標準作為參考標準。
一、功能測試
功能測試的主要目的是驗證一款產(chǎn)品是否是一個符合J2EE標準的企業(yè)級web應用服務器。測試前,應針對J2EE標準中的JSP、SERVLET、JDBC、EJB等主要功能編寫測試用例。測試 用例應盡量覆蓋典型的應用和操作,以此來證明一款產(chǎn)品符合J2EE標準中提到的功能。特別是 功能度測試項目,應遵循開發(fā)廠商提供的用戶手冊或程序員手冊中有關功能部分的描述作為依 據(jù)具體制定。
二、性能測試
性能測試的主要目的是考查在大壓力和大數(shù)據(jù)量情況下,應用服務器最大處理能力和系統(tǒng) 響應時間,同時考查不同壓力情況下應用服務器處理能力和系統(tǒng)響應時間。
測試過程中,首先通過JDBC接口與數(shù)據(jù)庫進行連接,根據(jù)被測系統(tǒng)的應用環(huán)境和實際情況 制定與之相適應的案例數(shù)據(jù)庫。然后使用功能測試中用到的JSP、Servlet和EJB測試程序,通 過Web Application Stress Tool1.1錄制相應的測試腳本,模擬在多用戶并發(fā)情況下數(shù)據(jù)庫的 插入、更新、查詢,并記錄成功點擊次數(shù)、點擊率等相關參數(shù)。最后通過遠程監(jiān)控系統(tǒng)對Web 應用服務器的CPU占有率、內存進行實時監(jiān)控,通過對上述數(shù)據(jù)的匯總分析,得出功能服務器 的性能。
三、兼容性測試
兼容性部分的測試應分成兩部分來考察:即硬件兼容性和軟件兼容性。
硬件兼容性主要驗證Web應用服務器的硬件配置要求。測試中,可以根據(jù)廠商提供的安裝 手冊承諾的配置信息,來驗證功能服務器的硬件兼容性。
軟件兼容性考察的方面較多,主要包括:系統(tǒng)兼容性、數(shù)據(jù)庫兼容性、Web服務器兼容 性、開發(fā)工具兼容性、與其它中間件產(chǎn)品的兼容性、J2EE組件的兼容性等多個方面。
四、安全可靠性測試
安全可靠性測試除了要考察用戶權限限制、輸入數(shù)據(jù)有效性檢查等基本內容,還應著重考 察在大壓力和大數(shù)據(jù)量情況下系統(tǒng)的穩(wěn)定性,以及驗證系統(tǒng)的SSL認證加密機制是否有效等多 個方面。