規範測試流程

　　需求分析：

　　需求分析由產品人員制定，他們要做的不是一份簡單的文件，而是細化每一個功能的細節，每一個按鈕的位置，對於稍大或複雜一點的需求都進行建模。

　　需求評審：

　　需求評審（產品需求人員、開發人員、測試人員、設計人員）前期需求進入會大大增加測試人員對產品的功能的整體把握，現在測試人員擔任的是測試和產品體驗員的身份。測試人員提出需求，開發人員考慮功能實現的方案與可行性、當然開發負責也是要參與的。測試人員主要是對需求的理解提出疑問，以便才能根據需求寫用例。QA人員是最終對軟體質量進行驗證的人，所以也需求瞭解需求

　　開發人員編寫排期：

　　開發人員需求根據需求功能點進行排期。然後將開計劃轉交給測試人員。

　　測試計劃排期：

　　測試人員根據開發計劃，對測試具體測試時間，也就是開發功能完成後的時間，進行幾輪測試等。然後，把專案的開發與測試計劃傳送給各部門負責人及參與專案的所有人員。

　　編寫測試用例：

　　根據詳細的需求分檔，開始進行用例的編寫。

　　【開發人員寫開發計劃--》測試人員編寫測試計劃--》郵件通知所有人員及部門負責人。】

　　用例評審：

　　在用例進行評審之間，先以郵件形式將用例傳送給相關人員，以便他們事先了解用例對哪些功能進行驗證以及驗證的細節。

　　然後，測試人員組進行用例評審，開發人員對用例與實際功能不符合有哪些，產品人員對會通過用例對功能的具體實現進行把握等等。

　　【測試用例評審（產品需求人員、開發人員、測試人員、QA人員）】

　　提交基線：

　　開發人員完成所有功能後，會對自己的功能進行一個自測。自測完成後提交測試人員進行基線。【開發程式碼及自測---》編寫測試用例】

　　具體測試流程：

　　開發人員對於基到測試線的功能進行測式，發現的問題通過缺陷管理工具進行反饋，開發人員對問題進行修復，然後，準備第二輪測試。

　　測試人員完成第一輪測試後，需要寫測試結論，發到相關人員。然後對基線後的第二輪進行測試，第二輪會對第一輪中發現的問題進行重點回歸。

　　缺陷管理：

　　使用bug缺陷管理工具，redmine專案管理，通過測試對發現的問題提交到redmine上並進行跟蹤。視情況可以將比較簡單的bug直接對接開發人員，通過當面交流的方式闡明簡單bug的問題所在，提高開發人員修復bug的效率，同時要在redmine上做好bug記錄，釋出測試新的版本的時候複測問題。

　　測試通過：

　　經過兩到三輪或四輪的測試後，直到沒發現新的問題，或暫時無法解決，或不緊急的問題。通過上級確認，可以通過。編寫測試報告與驗收方案。

　　驗收方案是交由QA進行驗證的。在現公司的流程中是將測試與QA分開的，測試人員重點關注的是功能是否可以正常執行。QA關注的是整個流程的質量以及終端使用者的質量。有些公司QA與測試是不區分的，但這對測試的要求會更高，除了關心功能，還需要關心整體流程與質量。

　　上線後測試：

　　產品上線後需要再次測試產品的功能性，確保釋出線上的環境配置正確，產品功能流暢。這是我們一個面向大眾使用者的網站，給於測試人員的定位是測試員兼使用者體驗員，測試員將發現的bug和體驗問題提交到缺陷管理系統，由經理對問題進行分析，指派開發人員解決。定期對系統進行更新。（測試人員以使用者的角度出發體驗功能完整性和功能流暢度以及功能的體驗，為產品的長期發展起到一個促進的作用！）

　　敏捷測試流程

　　前面講的第一種流程，還是第二種流程都是瀑布式的，嚴格來說第一種簡陋的都不能稱為瀑布式，對於一個三個月的專案說，產品把需求分析完了給開發，然後產品就沒事兒了；開發開發完成之後給測試，然後開發人員也不忙了。測試完成之後上線。那麼在產品分析的階段，開發和測試都是沒事幹的（這裡只對單一專案）。開發階段，產品和測試也基本沒事兒。同樣在測試階段，產品與開發也是沒什麼事兒的。

　　敏捷測試的一個核心是迭代，在每個時間點上，所有專案人員都是有事可做的。

　　1、下面是我理解中的敏捷測試流程圖：

　　第一階段：

　　通過上面的流程圖，對於一個月的需求分析，在敏捷中，可能三五天就確定下來。這個需求定得會很模糊，但整體框架確定。產品對其中某一模組功能確認，開發人員開始對確認的功能編碼，開發人員編碼的過程中，測試進行功能分解，因為根據模糊的需求很難寫出具體的用例，所以，只能儘量對功能進行分析得細些，標註需要驗證的內容。

　　第二階段：

　　開發完成後交給測試人員進行測試，開發人員繼續開發新的功能。那麼測試人員發現的問題怎麼辦呢？會從開發團隊中抽出一個人員來用於解決測試發現的問題。但開發進度並沒有因為測試而停止。

　　流程分析：

　　在這個流程中弱化了文件，強調了各個人員的溝通，通過這種迭代的方式，三個月的專案，可以能兩個月和兩個半月就會完成。

　　2、對測試問題的處理

　　上面的圖更能清晰看出對問題的處理過程。

　　第一塊麵板中是開發人員未實現的功能，第二塊面板中是開發完成功能，測試人員對其進行測試，發現不通過的就放回未開發的面板中，測試通過的將放到第三塊面板中。

　　需要說明的是，敏捷測試在國外很流程，在國內，雷聲大雨點小，推行的人很多，真正有公司引入的不多。我們所在公司千差萬別，測試流程也可能有很大的不同。