規範測試流程

規範測試流程

需求分析
  需求分析由產品人員制定,他們要作的不是一份簡單的文檔,而是細化每個功能的細節,每個按鈕的位置,對於稍大或複雜一點的需求都進行建模。
需求評審
  需求評審(產品需求人員、開發人員、測試人員、設計人員)前期需求進入會大大增長測試人員對產品的功能的總體把握,如今測試人員擔任的是測試和產品體驗員的身份。測試人員提出需求,開發人員考慮功能實現的方案與可行性、固然開發負責也是要參與的。測試人員主要是對需求的理解提出疑問,以便才能根據需求寫用例。QA人員是最終對軟件質量進行驗證的人,因此也需求瞭解需求
開發人員編寫排期
  開發人員需求根據需求功能點進行排期。而後將開計劃轉交給測試人員。
測試計劃排期
測試人員根據開發計劃,對測試具體測試時間,也就是開發功能完成後的時間,進行幾輪測試等。而後,把項目的開發與測試計劃發送給各部門負責人及參與項目的全部人員。
編寫測試用例
     根據詳細的需求分檔,開始進行用例的編寫。
   開發人員寫開發計劃--》測試人員編寫測試計劃--》郵件通知全部人員及部門負責人
用例評審
      在用例進行評審之間,先以郵件形式將用例發送給相關人員,以便他們事先了解用例對哪些功能進行驗證以及驗證的細節。
而後,測試人員組進行用例評審,開發人員對用例與實際功能不符合有哪些,產品人員對會經過用例對功能的具體實現進行把握等等。
測試用例評審(產品需求人員、開發人員、測試人員、QA人員)
提交基線
      開發人員完成全部功能後,會對本身的功能進行一個自測。自測完成後提交測試人員進行基線。開發代碼及自測---》編寫測試用例
具體測試流程
      開發人員對於基到測試線的功能進行測式,發現的問題經過缺陷管理工具進行反饋,開發人員對問題進行修復,而後,準備第二輪測試
測試人員完成第一輪測試後,須要寫測試結論,發到相關人員。而後對基線後的第二輪進行測試,第二輪會對第一輪中發現的問題進行重點回歸。
缺陷管理:
     使用bug缺陷管理工具,redmine項目管理,經過測試對發現的問題提交到redmine上並進行跟蹤。視狀況能夠將比較簡單的bug直接對接開發人員,經過當面交流的方式闡明簡單bug的問題所在提升開發人員修復bug的效率,同時要在redmine上作好bug記錄,發佈測試新的版本的時候複測問題。
測試經過
  通過兩到三輪或四輪的測試後,直到沒發現新的問題,或暫時沒法解決,或不緊急的問題。經過上級確認,能夠經過。編寫測試報告與驗收方案。
  驗收方案是交由QA進行驗證的。在現公司的流程中是將測試與QA分開的,測試人員重點關注的是功能是否能夠正常運行。QA關注的是整個流程的質量以及最終用戶的質量。有些公司QA與測試是不區分的,但這對測試的要求會更高,除了關心功能,還須要關心總體流程與質量。
 上線後測試:
    產品上線後須要再次測試產品的功能性,確保發佈線上的環境配置正確,產品功能流暢。這是咱們一個面向大衆用戶的網站,給於測試人員的定位是測試員兼用戶體驗員,測試員將發現的bug和體驗問題提交到缺陷管理系統,由經理對問題進行分析,指派開發人員解決。按期對系統進行更新。(測試人員以用戶的角度出發體驗功能完整性和功能流暢度以及功能的體驗,爲產品的長期發展起到一個促進的做用!
 
 
敏捷測試流程
  
  
  前面講的第一種流程,仍是第二種流程都是瀑布式的,嚴格來講第一種簡陋的都不能稱爲瀑布式,對於一個三個月的項目說,產品把需求分析完了給開發,而後產品就沒事兒了;開發開發完成以後給測試,而後開發人員也不忙了。測試完成以後上線。那麼在產品分析的階段,開發和測試都是沒事幹的(這裏只對單一項目)。開發階段,產品和測試也基本沒事兒。一樣在測試階段,產品與開發也是沒什麼事兒的。
  敏捷測試的一個核心是迭代,在每一個時間點上,全部項目人員都是有事可作的。
一、下面是我理解中的敏捷測試流程圖:
第一階段
  經過上面的流程圖,對於一個月的需求分析,在敏捷中,可能三五天就肯定下來。這個需求定得會很模糊,但總體框架肯定。產品對其中某一模塊功能確認,開發人員開始對確認的功能編碼,開發人員編碼的過程當中,測試進行功能分解,由於根據模糊的需求很難寫出具體的用例,因此,只能儘可能對功能進行分析得細些,標註須要驗證的內容。
第二階段
  開發完成後交給測試人員進行測試,開發人員繼續開發新的功能。那麼測試人員發現的問題怎麼辦呢?會從開發團隊中抽出一我的員來用於解決測試發現的問題。但開發進度並無由於測試而中止。
 
流程分析:
  在這個流程中弱化了文檔,強調了各我的員的溝通,經過這種迭代的方式,三個月的項目,能夠能兩個月和兩個半月就會完成。
二、對測試問題的處理
上面的圖更能清晰看出對問題的處理過程。
  第一塊麪板中是開發人員未實現的功能,第二塊面板中是開發完成功能,測試人員對其進行測試,發現不經過的就放回未開發的面板中,測試經過的將放到第三塊面板中。
      須要說明的是,敏捷測試在國外很流程,在國內,雷聲大雨點小,推行的人不少,真正有公司引入的很少。咱們所在公司千差萬別,測試流程也可能有很大的不一樣。
相關文章
相關標籤/搜索