原文：http://www.cnblogs.com/fnng/archive/2012/08/04/2622463.html

        工作兩年了，我一直希望讓自己每年對測試的理解更深入一層。工作一年的時候我寫了《談軟體測試---一年工作總結》 ，談輪了自己對各種測試的理解，這一年來，雖然對那些理概念的有所加強，自我感覺沒有什麼質的變化。前些天聽我們公司的一位測試經理講《敏捷測試》豁然開朗。他在學造飛機，而我一直在學造飛機裡的一個發動機。我從來沒想過，一個完整飛機的架構應該是怎樣的。

　　如果想讓測試在公司的專案中發揮出它最大的價值，並不是招兩個測試技術高手，或引入幾個測試技術，而是測試技術對專案流程的滲透，以及測試流程的改進與完善。雖然，當然測試行業前景樂觀，許多中小企業也都在引入測試，但一百個公司就有一百種測試，每個公司對測試的看法不同，公司對測試的定位也不完全一樣。本人前後經歷兩個公司，以自己的拙見淺談一下對測試流程的看法。

 這幾天整理思路，回顧了前兩份測試工作的流程與架構。

簡陋的測試流程                                                                                     

　　先說筆者入職的第一個家公司，筆者是第一個入職的專職測試人員，相信一兩個測試的公司還是不少的，入職後各種專案都在進行當中，上面給我的定位是並沒完全融入到專案中去。而通過指派任務的方式。

下面是簡陋的流程圖：

需求分析與架構設計：

　　我們做的是某一移動公司內部使用的專案，需求分析與架構全部由專案經理完成，之後由專案經理給具體某個開發人員分配任務，具體對某個功能模組的實現。這個對專案經理的經驗與技術要求很高，他既然擔任了需求分析師，又擔任架構師的角色。

程式設計師編碼：

　　因為我們開發語言用的是JAVA 語言，IDE用myeclipse 中自帶的CVS版本管理工具，開發人員完成程式碼後，提交到版本庫中。

測試：

　　筆者入職後的第一個任務是搭建缺陷管理工具，禪道專案管理，通過推廣對發現的問題進行跟蹤。後來正明效果並不好，因為對於一個六七人的開發團隊專案，開發人員更喜歡測試人員能當面反饋，這樣更能提高效率。對一個小bug 通過當面交流的方式就可以將問題修復。

　　對於當時的環境，並沒有測試線。開發人員在本機上將專案進行部署執行。測試人員通過區域網訪問開發人員的機子進行訪問。或在測試人員本機上進行部署測試。這也是一個致命的缺點。因為開發人員測試人員使用的電腦存在太多不穩定性，這些都會造成問題的出現，有時候難以判定是系統問題還是環境問題。

上線：

　　經過測試人員測試通過後，開發人員部署上線。

A程式設計師流程

　　你會發現在流程圖中，A程式設計師是先發上線之後，再進行測試。這是我們一個面向大眾使用者的網站，上面給於測試人員的定位是測試員兼使用者體驗員，測試員將發現的bug和體驗問題提交到缺陷管理系統，由經理對問題進行分析，指派開發人員解決。定期對系統進行更新。

流程分析：

　　這個流程唯一的優點，就是能快速的發現並修復問題。

　　缺點就非常多了，相信許多小軟體公司也有類似的流程。

　　這個流程中，專案經理是核心，專案經理也確實是有多年開發與專案經驗的牛人，他喜歡不定期分享上些前沿的技術。我很崇拜他。

　　對於測試來說，需求很不明確，測試文件與用例也是可有可無的產物，沒有需求文件，或非常簡陋，根據需求文件根本無法編寫用例。筆者只能收集一些通用的測試用例，如登入、檔案上傳下載、列表翻頁、日期選擇、輸入框驗證、搜尋等有一些“通用型”用例，以便在測試過程中做參考。功能測試的多了，拿到一個功能，測試思路也就出來了。

規範的測試流程                                                                                      　

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

現在的測試流程：

需求分析：

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

需求評審：

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

開發人員編寫排期：

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

測試計劃排期：

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

編寫測試用例：

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

用例評審：

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

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

提交基線：

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

具體測試流程：

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

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

測試通過：

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

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

流程分析：

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

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

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

敏捷測試流程                                                                                       

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

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

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

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

第一階段：

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

第二階段：

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

流程分析：

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

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

2、對測試問題的處理

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

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

      需要說明的是，敏捷測試在國外很流程，在內容，雷聲大雨點小，推行的人很多，真正有公司引入的不多。我們所在公司千差萬別，測試流程也可能有很大的不同。對於已經工作兩年一個測試員來說，從來沒關注過測試流程與結構應該是個悲劇。我希望不被思想侷限，所以，努力衝破一個又一個的侷限。