推薦：想了解一個專案完整測試流程，看這篇文章就OK了

       寫在前面：本文來自真實企業測試人員的工作總結，用一個專案的進行流程為線索，記錄每個階段測試包含的內容及關注點。

<ignore_js_op>

　　專案的測試流程大隻包含的幾個階段：立項、需求評審、用例評審、測試執行、測試報告文件
　　一、立項後測試需要拿到的文件
　　1、需求說明書
　　2、原型圖（及UI圖）
　　3、介面文件
　　4、資料庫字典（表的數量、快取機制）

　　二、需求評審
　　參加人員：開發、測試及需求人員，由需求人員主持講解。
　　為了會議的有效舉行，測試及開發人員需要在會議開始之前熟悉需求文件及原型，將有疑問 的點標註出來在會議中一一確認，對不明確的點要督促開發及需求一併關注，對不能立馬得到肯定回覆的點記錄在一起，會議結束後，郵件整理好發出給各位參與的人員。
　　在專案可控的進度中，需求評審時必要的環節。當然，有些比較小的專案會忽略此階段，個人認為這是非常有必要的環節，這不但減少了後期開發、測試、需求人員的意見分歧，保證專案的進度的必要手段。

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

　　用例功能型別
　　所在就職部門將用例分成7類：
　　1、主流程：該模組實現的主要功能流程。
　　2、備選流：不一定完成執行一個功能，而是終止了流程。
　　3、異常流：由於某些異常原因，使流程的功能無法實現。
　　4、業務規則：必填項，強制的要求。
　　5、正常類：返回功能、必填項輸入範圍、頁面按鈕的切換等。
　　6、異常類：網路異常、返回異常等。
　　7、介面檢查：針對每個頁面的樣式及內容檢查。
　　注：幾個大類中主流程、正常類、異常類、和介面檢查四個大類使用的比較多，一個專案不需要涵蓋所有的用例類別，只需要根據所在專案的實際情況來進行測試用例的分類即可。
　　編寫用例可在TestLink及excel上進行，一般會在TestLink上進行，小專案會比較習慣用excel進行，excel記錄測試用例的欄位有：
　　用例編號、功能模組、功能型別、用例等級、用例描述、前置條件、資料、測試步驟、預期結果、客戶端、執行結果、備註、設計人、執行人等
　　用例編寫注意點：
　　1、儘可能結合用例設計方法設計測試用例
　　2、不要只根據需求文件明確標出的需求編寫用例，還需要多考慮一些衍生的場景；
　　3、用例編寫前，先畫出整個功能的簡要流程圖；
　　4、用例描述簡潔且帶有結果，不要重複贅述；
　　5、用例步驟和預期結果要一致，且一個步驟對應一個預期結果。
　　測試用例的編寫方法
　　1、等價類劃分
　　2、邊界值分析法
　　3、錯誤推斷法
　　4、因果分析法
　　5、場景法

　　四、用例評審
　　參與人員：開發、測試、需求人員、專案經理，由測試人員主導。
　　此環節在開發完成功能之前進行，根據評審時提的點進行用例完善，完善後郵件發給參與人員。
　　在專案組中，更多情況下測試比開發會更瞭解需求，專業決定我們對需求的理解是肯定更接近客戶的，我們的對需求理解後的輸出產物是測試用例，某種意義上講用例是對需求細化的一種。 而開發對需求理解會更偏向於功能實現，產物就是程式。所以開發、測試經常會存在需求理解不一致的情況，開發也不會那麼細緻的去理解需求，這點相信所有的專案經理和需求分析都是有共鳴的：
　　我們做測試用例評審的作用有但不侷限於以下3點：
　　1、統一開發、測試、需求三方對需求的理解
　　2、幫組開發更細緻的去理解需求、同時養成看需求的習慣
　　3、需求分析人員在一定程度上對需求的理解也是有盲點的，通過評審可以挖出這些盲點（需求評審的作用也是一樣）
　　4、測試人員的能力和經驗不一樣，所有用例也會有差異性，通過評審可以指出我們遺漏的場景，從而能更好的保障咱們的專案質量
　　5、在用例評審時，很多互動設計上的問題，前後臺互動的問題等都會暴露
　　6、如果測試用例在開發完成前進行評審，很多時候開發人員即使不去看需求說明書，只要他認真的參加了用例評審會，基本上也不會出現遺漏需求，需求實現偏差太大的情況了.因為你要去每個開發人員那麼仔細的去看需求，短時間內是不太可能的。用例評審是這個過渡期的橋樑。
　　一般可根據計劃時間完成用例編寫，中間會預留1天給他們看需求。在評審每一個模組的用例之前，會明確點名這幾個人要注意，在評審的過程中，問開發一些問題,不是隻單純的講用例,他們可以不看需求，但是我會提問一下,們要同時提升開發人員的參與感。

　　五、測試執行
　　showcase測試：
　　測試到開發的電腦上進行，主要執行一下關鍵測試用例、流程用例，由開發操作，測試人員一起檢視。showcase不通過，則打回，郵件發出。
　　冒煙測試：
　　showcase測試通過後，提交到測試，由測試人員開始大量跑關鍵測試用例。若針對某個模組跑用例時，出現較多問題，則也可重新打回給開發。冒煙測試報告郵件如下欄位：測試模組      是否通過   不通過原因    測試詳情    備註
　　郵件描述大致如下：以下是截止到某個日期，已提交的功能冒煙測試結果，都不通過，詳情如下：
　　ps:冒煙測試不通過的原因基本上都是。。。。。，麻煩大家相互配合，早點修復提測，謝謝~
　　功能測試：
　　功能測試在手工測試中是主要的階段，這個階段主要是全量跑測試用例，提交bug到缺陷管理工具。
　　1、表單測試：
　　a、表單資料的欄位、完整性及表單輸入框的長度限制問題
　　b、一些常理性邏輯驗證，比如：出生日期和職業，工作年限是否恰當，所在地省份城市區域間的匹配等，如果設定使用預設值，也需要測試。
　　2、導航測試：
　　導航測試，就是在不同的頁面跳轉之間，或者按鈕、對話方塊、列表以及視窗等，通過考慮這些因素去判斷一個應用是否易於導航：是否直觀？系統的主要模組是否可以通過主頁訪問或者到達？站點是否需要站內地圖或者搜尋引擎等其他幫助？web系統導航的另外一個重點就是頁面結構、導航、選單、風格等是否一致，確保使用者可以憑藉直覺或者簡單的判斷就可以找到自己想要的內容。
　　3、UI測試：
　　也可以理解為UI測試，其中包括圖片、動畫、邊框、顏色、字型、背景、按鈕等等。
　　注： 其中要考慮的幾個重點，我做了一個大概的總結：
　　a、圖片要有明確的用途，代表；圖片尺寸儘量小，一般採用JPG或者GIF壓縮（即規格大小的限制）
　　b、頁面整體風格是否和系統的用途一致
　　c、背景顏色，字型，搭配是否合理
　　4、內容測試：
　　這個主要用來檢測web系統提供資訊的準確性、相關性。
　　比如：商品的價格，文字描述；資訊的準確性，是否有拼寫錯誤；（這點比較容易忽略，需要多注意）資訊的相關性，比如很多網站的“相關文章列表，視訊列表等”
　　5、整體介面測試
　　a、 這個也就是我們常說的使用者體驗。使用者瀏覽時是否感覺舒適，整體風格等等
　　b、建議一般做一個類似問卷調查的形式，來判定使用者的反饋資訊，最好有終端使用者的參與，可參考類似的筆記哦啊普遍的系統風格是怎樣的，結合實際來考慮本測試系統的風格

　　6、連結測試（平時在測試過程中並不關注，而是在許可權分配的安全測試中比較注重，主要是不同許可權的人分享的連結是否能正確過濾，保證安全）

　　7、輸入框測試
　　在web測試中，我們經常遇到這種輸入框的測試，輸入框測試看似簡單，實際上包含了很多的測試基本的方法，思考邏輯，下面就是我總結出來的一些注意點：
　　1）驗證輸入輸出資訊的一致性
　　2）輸入框前面的文字提示是否正確
　　3）對特殊字元的處理、識別：單雙引號，括號，逗號、分號等等，以及大小寫狀態，半形全形狀態下的情況
　　4）輸入框的大小、長度、邊框等
　　5）不同字元的輸入，以及字元組合情況的處理（數字+字母+字元等）
　　6）對空格、tab換行鍵的處理機制
　　7）密碼輸入框字元星號或者其他星號的轉行，加密
　　8）輸入框輸入字元長度是否有限制
　　9）字元本身顯示的顏色，規格等
　　10）有些輸入框需要加以限制，如輸錯，是否有提示？提示是否簡單合理？
　　11）輸入狀態，某種情況下輸入框出於不可編輯，當再次處於編輯狀態，輸入框的輸入狀態是否有變化？
　　12）輸入型別：是否允許複製黏貼剪下等輸入操作
　　13）關鍵字是否支援萬用字元，以及關鍵字的搜尋能力，敏感字等情況
　　14）輸入框輸入空格的情況
　　15）比如登陸註冊，各項輸入條件的判定：是否輸入，輸入是否正確等

　   使用者許可權測試
　　使用者許可權，顧名思義，就是該賬號擁有哪些執行操作的權利
　　1）給某賬號賦予許可權後，登陸該賬號，檢視是否擁有已賦予的許可權，以及許可權設定是否正確（許可權是否超過或者不足）
　　2）刪除或修改已經登陸並且正在執行操作的賬號許可權，程式能否正確處理，驗證
　　3）重新註冊系統變更登陸身份後再登陸，程式能否正確執行，之前所擁有的許可權能否繼續使用
　　4）在用工作分配或者角色管理情況下，刪除包含使用者的工作組或者角色，程式能否正確處理
　　5）不同許可權賬號登陸同一個系統，許可權範圍是否正確
　　6）能否給資訊為空、長使用者名稱的賬號新增許可權
　　7）是否允許刪除系統管理員或者修改管理員許可權？刪除或者修改後的實際情況
　　8）已登入的使用者能否修改或者刪除自己或者他人的許可權，資訊
　　9）新增使用者（有編號或者標識），不同使用者名稱標識的組合情況下，許可權能否處理正確
　　10）修改使用者許可權或者資訊後，對其他模組是否有影響
　　11）如果修改使用者資訊為和已存在的其他使用者資訊相同，能否修改成功？是否有對應提示？
　　12）修改某些設定，是否會對與該賬號許可權相同或者高於/低於該賬號的其他賬號的許可權造成影響
　　13）同一使用者是否可以同時屬於其他組，各個組的許可權能否交叉？

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

　　相容性測試
　　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注入驗證

　　六、測試報告及操作手冊
　　測試報告每個公司的使用模板可能不盡相同，但是重點都是反映測試結果及測試中出現的bug分配模組，還要關注bug解決的狀態，只要根據模板中的需要去進行統計即可。
　　操作手冊主要是寫給使用該系統的人員看的，要求是具體詳細，什麼角色什麼模組可進行什麼操作的描述要清晰，一步一步配上截圖和文字。