Web測試

（整理自網絡）

項目的測試流程大隻包含的幾個階段：立項、需求評審、用例評審、測試執行、測試報告文檔

1、立項後測試須要拿到的文檔

一、需求說明書

二、原型圖（及UI圖）

三、接口文檔

四、數據庫字典（表的數量、緩存機制）

2、需求評審

參加人員：開發、測試及需求人員，由需求人員主持講解。

爲了會議的有效舉行，測試及開發人員須要在會議開始以前熟悉需求文檔及原型，將有疑問 的點標註出來在會議中一一確認，對不明確的點要督促開發及需求一併關注，對不能立馬獲得確定回覆的點記錄在一塊兒，會議結束後，郵件整理好發出給各位參與的人員。

在項目可控的進度中，需求評審時必要的環節。固然，有些比較小的項目會忽略此階段，我的認爲這是很是有必要的環節，這不但減小了後期開發、測試、需求人員的意見分歧，保證項目的進度的必要手段。

3、用例編寫（同時根據開發計劃編寫測試計劃）

用例功能類型

所在就任部門將用例分紅7類：

一、主流程：該模塊實現的主要功能流程。

二、備選流：不必定完成執行一個功能，而是終止了流程。

三、異常流：因爲某些異常緣由，使流程的功能沒法實現。

四、業務規則：必填項，強制的要求。

五、正常類：返回功能、必填項輸入範圍、頁面按鈕的切換等。

六、異常類：網絡異常、返回異常等。

七、界面檢查：針對每一個頁面的樣式及內容檢查。

注：幾個大類中主流程、正常類、異常類、和界面檢查四個大類使用的比較多，一個項目不須要涵蓋全部的用例類別，只須要根據所在項目的實際狀況來進行測試用例的分類便可。

編寫用例可在TestLink及excel上進行，通常會在TestLink上進行，小項目會比較習慣用excel進行，excel記錄測試用例的字段有：

用例編號、功能模塊、功能類型、用例等級、用例描述、前置條件、數據、測試步驟、預期結果、客戶端、執行結果、備註、設計人、執行人等

用例編寫注意點：

一、儘量結合用例設計方法設計測試用例

二、不要只根據需求文檔明確標出的需求編寫用例，還須要多考慮一些衍生的場景；

三、用例編寫前，先畫出整個功能的煎藥流程圖；

四、用例描述簡潔且帶有結果，不要重複贅述；

五、用例步驟和預期結果要一致，且一個步驟對應一個預期結果。

測試用例的編寫方法

一、等價類劃分

二、邊界值分析法

三、錯誤推斷法

四、因果分析法

五、場景法

4、用例評審

參與人員：開發、測試、需求人員、項目經理，由測試人員主導。

此環節在開發完成功能以前進行，根據評審時提的點進行用例完善，完善後郵件發給參與人員。

在項目組中，更多狀況下測試比開發會更瞭解需求，專業決定咱們對需求的理解是確定更接近客戶的，咱們的對需求理解後的輸出產物是測試用例，某種意義上講用例是對需求細化的一種。 而開發對需求理解會更偏向於功能實現，產物就是程序。因此開發、測試常常會存在需求理解不一致的狀況，開發也不會那麼細緻的去理解需求，這點相信全部的項目經理和需求分析都是有共鳴的：
咱們作測試用例評審的做用有但不侷限於如下3點：
一、統一開發、測試、需求三方對需求的理解
二、幫組開發更細緻的去理解需求、同時養成看需求的習慣
三、需求分析人員在必定程度上對需求的理解也是有盲點的，經過評審能夠挖出這些盲點（需求評審的做用也是同樣）
四、測試人員的能力和經驗不同，全部用例也會有差別性，經過評審能夠指出咱們遺漏的場景，從而能更好的保障我們的項目質量
五、在用例評審時，不少交互設計上的問題，先後臺交互的問題等都會暴露
六、若是測試用例在開發完成前進行評審，不少時候開發人員即便不去看需求說明書，只要他認真的參加了用例評審會，基本上也不會出現遺漏需求，需求實現誤差太大的狀況了.由於你要去每一個開發人員那麼仔細的去看需求，短期內是不太可能的。用例評審是這個過渡期的橋樑。

通常可根據計劃時間完成用例編寫，中間會預留1天給他們看需求。在評審每個模塊的用例以前，會明確點名這幾我的要注意，在評審的過程當中，問開發一些問題,不是隻單純的講用例,他們能夠不看需求，可是我會提問一下,們要同時提高開發人員的參與感。

5、測試執行

showcase測試：
測試到開發的電腦上進行，主要執行一下關鍵測試用例、流程用例，由開發操做，測試人員一塊兒查看。showcase不經過，則打回，郵件發出。

冒煙測試：
showcase測試經過後，提交到測試，由測試人員開始大量跑關鍵測試用例。若針對某個模塊跑用例時，出現較多問題，則也可從新打回給開發。冒煙測試報告郵件以下字段：測試模塊      是否經過   不經過緣由    測試詳情    備註

郵件描述大體以下：如下是截止到某個日期，已提交的功能冒煙測試結果，都不經過，詳情以下：

ps:冒煙測試不經過的緣由基本上都是。。。。。，麻煩你們相互配合，早點修復提測，謝謝~

功能測試：
功能測試在手工測試中是主要的階段，這個階段主要是全量跑測試用例，提交bug到缺陷管理工具。

一、表單測試：

a、表單數據的字段、完整性及表單輸入框的長度限制問題

b、一些常理性邏輯驗證，好比：出生日期和職業，工做年限是否恰當，所在地省份城市區域間的匹配等，若是設定使用默認值，也須要測試。

二、導航測試：

導航測試，就是在不一樣的頁面跳轉之間，或者按鈕、對話框、列表以及窗口等，經過考慮這些因素去判斷一個應用是否易於導航：是否直觀？系統的主要模塊是否能夠經過主頁訪問或者到達？站點是否須要站內地圖或者搜索引擎等其餘幫助？web系統導航的另一個重點就是頁面結構、導航、菜單、風格等是否一致，確保用戶能夠憑藉直覺或者簡單的判斷就能夠找到本身想要的內容。（參考博客http://www.cnblogs.com/imyalost/p/5622867.html）

三、UI測試：

 也能夠理解爲UI測試，其中包括圖片、動畫、邊框、顏色、字體、背景、按鈕等等。

注： 其中要考慮的幾個重點，我作了一個大概的總結：

a、圖片要有明確的用途，表明；圖片尺寸儘可能小，通常採用JPG或者GIF壓縮（即規格大小的限制）

 b、頁面總體風格是否和系統的用途一致

 c、背景顏色，字體，搭配是否合理

四、內容測試：

這個主要用來檢測web系統提供信息的準確性、相關性。

好比：商品的價格，文字描述；信息的準確性，是否有拼寫錯誤；（這點比較容易忽略，須要多注意）信息的相關性，好比不少網站的「相關文章列表，視頻列表等」

五、總體界面測試

a、 這個也就是咱們常說的用戶體驗。用戶瀏覽時是否感受溫馨，總體風格等等

b、建議通常作一個相似問卷調查的形式，來斷定用戶的反饋信息，最好有最終用戶的參與，可參考相似的筆記哦啊廣泛的系統風格是怎樣的，結合實際來考慮本測試系統的風格

六、連接測試（平時在測試過程當中並不關注，而是在權限分配的安全測試中比較注重，主要是不一樣權限的人分享的連接是否能正確過濾，保證安全）

七、輸入框測試（粘貼博客http://www.cnblogs.com/imyalost/p/5622867.html）

在web測試中，咱們常常遇到這種輸入框的測試，輸入框測試看似簡單，實際上包含了不少的測試基本的方法，思考邏輯，下面就是我總結出來的一些注意點：

       1）驗證輸入輸出信息的一致性

       2）輸入框前面的文字提示是否正確

       3）對特殊字符的處理、識別：單雙引號，括號，逗號、分號等等，以及大小寫狀態，半角全角狀態下的狀況

       4）輸入框的大小、長度、邊框等

       5）不一樣字符的輸入，以及字符組合狀況的處理（數字+字母+字符等）

       6）對空格、tab換行鍵的處理機制

       7）密碼輸入框字符星號或者其餘星號的轉行，加密

       8）輸入框輸入字符長度是否有限制

       9）字符自己顯示的顏色，規格等

       10）有些輸入框須要加以限制，如輸錯，是否有提示？提示是否簡單合理？

       11）輸入狀態，某種狀況下輸入框出於不可編輯，當再次處於編輯狀態，輸入框的輸入狀態是否有變化？

       12）輸入類型：是否容許複製黏貼剪切等輸入操做

       13）關鍵字是否支持通配符，以及關鍵字的搜索能力，敏感字等狀況

       14）輸入框輸入空格的狀況

       15）好比登錄註冊，各項輸入條件的斷定：是否輸入，輸入是否正確等

八、用戶權限測試（粘貼博客http://www.cnblogs.com/imyalost/p/5622867.html）

用戶權限，顧名思義，就是該帳號擁有哪些執行操做的權利

       1）給某帳號賦予權限後，登錄該帳號，查看是否擁有已賦予的權限，以及權限設置是否正確（權限是否超過或者不足）

       2）刪除或修改已經登錄而且正在執行操做的帳號權限，程序可否正確處理，驗證

       3）從新註冊系統變動登錄身份後再登錄，程序可否正確執行，以前所擁有的權限可否繼續使用

       4）在用工做分配或者角色管理狀況下，刪除包含用戶的工做組或者角色，程序可否正確處理

       5）不一樣權限帳號登錄同一個系統，權限範圍是否正確

       6）可否給信息爲空、長用戶名的帳號添加權限

       7）是否容許刪除系統管理員或者修改管理員權限？刪除或者修改後的實際狀況

       8）已登陸的用戶可否修改或者刪除本身或者他人的權限，信息

       9）添加用戶（有編號或者標識），不一樣用戶名標識的組合狀況下，權限可否處理正確

       10）修改用戶權限或者信息後，對其餘模塊是否有影響

       11）若是修改用戶信息爲和已存在的其餘用戶信息相同，可否修改爲功？是否有對應提示？

       12）修改某些設置，是否會對與該帳號權限相同或者高於/低於該帳號的其餘帳號的權限形成影響

       13）同一用戶是否能夠同時屬於其餘組，各個組的權限可否交叉？

迴歸測試：

迴歸測試書要是根據在測試執行過程當中記錄的bug及執行失敗的用例來進行的，根據記錄的bug進行驗證是否已經修改更新好，必要時，根據bug量的多少來評估是否須要從新跑一下系統的流程。

兼容性測試：（參考博客http://www.cnblogs.com/imyalost/p/5622867.html）

a、平臺兼容

在有不少的操做系統，好比Windows、Unix、Linux、macintosh等；用戶使用哪一個系統取決於用戶，所以，系統兼容測試就頗有必要了。

 b、瀏覽器兼容

  瀏覽器是web客戶端最核心的組件，不一樣的瀏覽器，對Java，JavaScript，css或者HTML的規格都有不一樣的支持；

 另外，採用的框架和結構風格在不一樣瀏覽器中也存在不一樣的顯示甚至不顯示，不一樣的瀏覽器對安全性的設置也是不一樣的。

 測試瀏覽器兼容，有個方法就是建立一個兼容性矩陣，來測試不一樣廠商不一樣版本的瀏覽器兼容。

  好比測試IE瀏覽器，能夠經過一個叫作IEtester的工具來測試兼容，或者能夠經過F12控制檯來切換瀏覽器版原本測試兼容之前一些前端元素的顯示等

  鑑於國內市場瀏覽器不少，好比360、搜狗，搜狐、QQ瀏覽器等，這些本土的瀏覽器基本都採用的IE瀏覽器內核的雙核配置

安全測試：

安全測試的主要區域有如下幾點：

a、如今不少web應用系統都採用先註冊後登陸的方式，所以，測試用戶名和密碼的有效無效性，注意大小寫敏感，次數限制，是否能夠不登陸而瀏覽某些頁面等

b、是否有超時限制，連接分享，cookie劫持

c、測試用戶操做時相關信息是否寫入了日誌文件、是否可追蹤等

d、若是使用了安全套字，須要測試加密是否正確，加密先後的信息完整性，正確性

e、沒有通過受權，是否能夠在服務器端或者前端放置和編輯腳本的問題

f、輸入框的SQL注入驗證

6、測試報告及操做手冊

測試報告每一個公司的使用模板可能不盡相同，可是重點都是反映測試結果及測試中出現的bug分配模塊，還要關注bug解決的狀態，只要根據模板中的須要去進行統計便可。

操做手冊主要是寫給使用該系統的人員看的，要求是具體詳細，什麼角色什麼模塊可進行什麼操做的描述要清晰，一步一步配上截圖和文字。