【轉】測試流程

標籤：

規範的測試流程                                                                                      　

　

　　放棄上份悠閑的工作，感謝那個帶我入行公司，我想瞭解真正的測試在公作中如何進行的。所以，來到了現在這家公司。我很欣喜的是這測試有自己的團隊，專業（對當時的我來說）的流程，以及與開發等同的地位。

現在的測試流程：

需求分析：

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

需求評審：

　　這裡會叫上所有參與項目人員進行，開發人員、測試人員、QA人員。測試人員提出需求，開發人員考慮功能實現的方案與可行性、當然開發負責也是要參與的。測試人員主要是對需求的理解提出疑問，以便才能根據需求寫用例。QA人員是最終對軟體品質進行驗證的人，所以也需求瞭解需求

開發人員編寫排期：

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

測試計劃排期：

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

編寫測試案例：

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

用例評審：

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

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

提交基準：

    開發人員完成所有功能後，會對自己的功能進行一個自測。自測完成後提交測試人員進行基準。

具體測試流程：

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

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

測試通過：

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

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

 

流程分析：

　　對於剛接觸這個流程的我來說，這個流程是規範的，測試真正融入了整個流程，而且還擔任了很重的角色，從而也有效保證了軟體產品的整體品質。

　　那麼這個流程是不是完美的呢？不，這個項目流程太強化各種文檔。我們來看測試的工作內容，測試計劃、測試案例、測試結論、測試報告、驗收方案、問題的提交跟蹤。其實，我們真用於測試的時間是非常少的，在一周的時間，也許只有一天或不到一天的時間是在進行測試的。測試人員只有在測試的時候才會體現出他的價值。而大部分工作卻不能體現他的價值。

　　當然，我這裡會省略與測試主流程無關的東西，真正的測試工作中瑣事很多。

 

敏捷測試流程                                                                                       

　　

　　下面來看敏捷測試，本人並沒有接觸過敏捷，對敏捷也沒花時間學習與研究。唯一接觸就是聽我們測試經理對測度流程講了兩個半小時，聽講的人很多，我站著聽的。受益匪淺，憑著記憶也簡單談談。 

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

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

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

 

第一階段：

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

第二階段：

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

 

流程分析：

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

但這種流程並非完美，加入一個功能在需求分析階段就是錯誤的，因為它是一個迭代漸進的過程。也只能一路錯下去。

 

2、對測試問題的處理

 

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

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

【轉】測試流程