概論
文章中提到的東西都是工作中實踐過的經驗,並不保證全面性.
web測試一般包含如下內容:
功能測試
效能測試
使用者介面測試
相容性測試
安全性測試
其實這只是大概的區分,各種不同的類別的測試之間其實是有很多交集的.比如:
以上的五項內容中的每一項都可以是乙個大的主題做深入的分析.
另外,對於所有的web測試人員來說,學會使用firebug以及fiddler這樣的抓包工具絕對是必不可少的。這些工具的使用應該始終貫穿的測試工作之中
一.功能測試
對於一般被測試的軟體,我可以用"樹"來比喻乙個軟體.一顆樹有主幹,分支和葉子.主幹和分支代表軟體的流程,葉子代表軟體的區域性步驟(頁面). 我們測試軟體的時候既要保證軟體的流程正確,也要保證組成流程的各個分支步驟頁面的正確性.
拿**來購物來說,我們可以把登入頁面,購物車頁面之類的當成是葉子,完成乙個購物流程,當成乙個主幹或者分支. 軟體就是由這很多的葉子以及相對少一些的分支組成.
經典的教科書上往往會介紹如下功能測試測試用例的設計方法:
當我們測試單個頁面的時候,往往會用到這些方法.但是這些方法只是測試到了軟體的區域性.
除此之外,我們還要考慮被測試軟體的工作流程,保證所有的提供給使用者的工作流程都可以跑通,這個時候,探索式測試可以派上用場.有時候,我們還需要化流程圖來輔助測試.
關於探索式測試,詳見探索式測試讀書筆記一文
另外，還有更重要的幾點：
每當開啟頁面或者提交資料的時候，多開啟fiddler或者firebug看看到底傳送了哪些http請求,以及關鍵請求的http response是什麼.
當發現功能異常之後,根據我們用fiddler看到的資料,往往可以自己判斷問題到底是出在前台的js還是後台service. 關於fiddler,詳見fiddler小結一文
有空多看看系統的日誌,**能找到一些隱藏在頁面之外的異常
當我們在頁面上完成了一些功能之後,要徹底明白系統背後(資料庫)到底完成了什麼東西,我們提交的資料到底被儲存到**去了
綜上所述,我們做功能測試的總體思路是從 點(樹葉)->面(主幹,分支)->後台(根)
二.效能測試
效能測試主要要從前端和後台兩個角度去理解,我們可以首先使用fiddler去大概判斷**的效能問題是出在前台還是後台.
如果http請求的大部分時間是花在html,css,js之類的靜態資源載入上,那麼基本是前台效能有問題.如果某個後台的service特別費時,那麼後台必定存在效能問題
前台效能
除了用fiddler看效能外,我們可以使用yahoo的firefox yslow外掛程式去檢測前端的效能.此外,關於前端效能具體的優化策略,可以參閱,其中主要涉及到http協議和瀏覽器快取機制
詳見web前端優化14條原則一文
後台效能
對於大部分測試工程師來說是很難直接去優化後台效能的,但是依然能去發現一些有意義的線索
總之,做效能測試絕對不是簡單地直接拿loadrunner或者jmeter去錄製一下指令碼,然後執行,分析結果.這一切的前提應該是充分了解了被測試系統的前台跟後台的效能
三.使用者介面測試
這點關注不多，主要如下：
四,相容性測試
主要考慮如下幾個因素組合：
五.安全性測試
安全性測試主要知道有如下幾點:
sql注入:後台使用preparedstatement去處理sql
xss攻擊:這個問題非常複雜.學習中..
做為乙個測試工程師,我覺得應該記住如下3點:
接下去舉一些實際的例子:
隱藏的按鈕
當我們用firebug看頁面的html的時候,往往能找到一些隱藏的內容,比如某個元素的 class="gradient hide",或者類似的東西.當我們直接修改掉這些屬性之後,這些隱藏的東西就會在頁面上暴露出來,對系統的安全造成隱患.
另外如果有某些值也可能會儲存在隱藏域中
disabled按鈕
與隱藏的按鈕類似,頁面上經常有些可見但是灰調的按鈕,也可以嘗試改變他的屬性,讓它變成可以觸發的,或許會有所發現
不該被訪問的url
後台service
如果**後台的service能**捉到,而且又沒有許可權控制,那將是災難性的
joda datetime測試心得
有些業務邏輯是基於時間的,測試起來比較麻煩,如果用joda datetime就很容易了 比如 在new report中有這樣的邏輯 public report double energytotal,double outputenergy,double outputpower,string clien...
paypal sandbox 測試心得
註冊乙個developer帳號a後，paypal會建議你建兩個test account，乙個buyer，乙個seller。這沒什麼。但是如果你想測試乙個買，乙個賣的流程，只用乙個帳號是做不了的。你需要再申請乙個新的developer帳號b，再建test account。用a的buyer去買b的sel...
測試小白的測試心得
1 測試用例是測試工作的核心，寫測試用例的時候建議先提取測試點，再編寫測試用例。清晰且不容易遺漏。寫測試用例的過程中要不斷的調整，之前用例覆蓋到的測試點可以不寫，覆蓋率全且避免重複 2 測試資料要盡量真實。3 測試時考慮到了別人沒有考慮到的問題點，最好要去一一和產品確認溝通過 或者是發現了設計上有不...