冒煙測試、回歸測試、滲透測試、黑盒測試、白盒測試、灰盒測試 1、測試方案：寫明將要如何進行測試的文檔，包括測試計劃、測試環境、測試數據、測試工具、測試方法、風險依賴等方面。 2、測試方案參考目錄（可根據項目或產品需要適當刪減） （1）功能測試、模塊1、模塊2、模塊3、接口測試、測試內容 （2）包含系統的哪些模塊哪些方面（功能、性能、數據）、測試范圍、測試環境 、測試工具 、測試數據、測試方法 、測試人力資源安排、測試進度安排、測試輸出 、風險分析 、硬件環境、軟件環境、借助到的一些測試瀏覽器兼容性工具、自動化測試工具、性能測試工具 （3）黑盒測試、白盒測試、冒煙測試、驗收測試、包含哪些文檔、報告等、一般有：測試計劃、測試方案、系統評測報告、缺陷報告等、系統上線后可能會出現的問題，一些現在尚未解決的bug，各種使用環境可能出現的問題等； （4）編寫目的、讀者對象、項目背景、測試目標、參考資料、概述 、測試計劃 、集成測試用例 、系統測試用例 、性能測試 **一、立項后測試需要拿到的文檔** 1、需求說明書 2、原型圖（及UI圖） 3、接口文檔 4、數據庫字典（表的數量、緩存機制） **二、需求評審** **三、用例編寫（同時根據開發計劃編寫測試計劃）** **用例功能類型** 所在就職部門將用例分成7類： 1、主流程：該模塊實現的主要功能流程。 2、備選流：不一定完成執行一個功能，而是終止了流程。 3、異常流：由于某些異常原因，使流程的功能無法實現。 4、業務規則：必填項，強制的要求。 5、正常類：返回功能、必填項輸入范圍、頁面按鈕的切換等。 6、異常類：網絡異常、返回異常等。 7、界面檢查：針對每個頁面的樣式及內容檢查。 **測試用例的編寫方法** 1、等價類劃分 2、邊界值分析法 3、錯誤推斷法 4、因果分析法 5、場景法 **五、測試執行** **showcase測試：**測試到開發的電腦上進行，主要執行一下關鍵測試用例、流程用例，由開發操作，測試人員一起查看。showcase不通過，則打回，郵件發出。 **冒煙測試：**showcase測試通過后，提交到測試，由測試人員開始大量跑關鍵測試用例。若針對某個模塊跑用例時，出現較多問題，則也可重新打回給開發。冒煙測試報告郵件如下字段：測試模塊 是否通過 不通過原因 測試詳情 備注 郵件描述大致如下：以下是截止到某個日期，已提交的功能冒煙測試結果，都不通過，詳情如下： ps:冒煙測試不通過的原因基本上都是。。。。。，麻煩大家相互配合，早點修復提測，謝謝~ **功能測試：**功能測試在手工測試中是主要的階段，這個階段主要是全量跑測試用例，提交bug到缺陷管理工具。 1、表單測試： a、表單數據的字段、完整性及表單輸入框的長度限制問題 b、一些常理性邏輯驗證，比如：出生日期和職業，工作年限是否恰當，所在地省份城市區域間的匹配等，如果設定使用默認值，也需要測試。 2、導航測試： 導航測試，就是在不同的頁面跳轉之間，或者按鈕、對話框、列表以及窗口等，通過考慮這些因素去判斷一個應用是否易于導航：是否直觀？系統的主要模塊是否可以通過主頁訪問或者到達？站點是否需要站內地圖或者搜索引擎等其他幫助？web系統導航的另外一個重點就是頁面結構、導航、菜單、風格等是否一致，確保用戶可以憑借直覺或者簡單的判斷就可以找到自己想要的內容。（參考博客[http://www.cnblogs.com/imyalost/p/5622867.html](http://www.cnblogs.com/imyalost/p/5622867.html)） 3、UI測試： 也可以理解為UI測試，其中包括圖片、動畫、邊框、顏色、字體、背景、按鈕等等。 注： 其中要考慮的幾個重點，我做了一個大概的總結： a、圖片要有明確的用途，代表；圖片尺寸盡量小，一般采用JPG或者GIF壓縮（即規格大小的限制） b、頁面整體風格是否和系統的用途一致 c、背景顏色，字體，搭配是否合理 4、內容測試： 這個主要用來檢測web系統提供信息的準確性、相關性。 比如：商品的價格，文字描述；信息的準確性，是否有拼寫錯誤；（這點比較容易忽略，需要多注意）信息的相關性，比如很多網站的“相關文章列表，視頻列表等” 5、整體界面測試 a、 這個也就是我們常說的用戶體驗。用戶瀏覽時是否感覺舒適，整體風格等等 b、建議一般做一個類似問卷調查的形式，來判定用戶的反饋信息，最好有最終用戶的參與，可參考類似的筆記哦啊普遍的系統風格是怎樣的，結合實際來考慮本測試系統的風格 6、鏈接測試（平時在測試過程中并不關注，而是在權限分配的安全測試中比較注重，主要是不同權限的人分享的鏈接是否能正確過濾，保證安全） 7、輸入框測試（粘貼博客[http://www.cnblogs.com/imyalost/p/5622867.html](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）比如登陸注冊，各項輸入條件的判定：是否輸入，輸入是否正確等 8、用戶權限測試（粘貼博客[http://www.cnblogs.com/imyalost/p/5622867.html](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](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注入驗證