【本篇是《敏捷測試理論以及實踐》第一篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇）】
前言：
關於敏捷測試這塊內容，本來之前一直想寫的，但是自己一直覺得還沒法歸納得很好，不過最近有個客戶到我們公司來拜訪時，也提到了他們公司要把測試這塊工作弄好的事情，談了幾個小時，相互交流了一下意見，總算雙方都有點收穫，所以接下來幾天想結合我們公司的實際情況介紹一下敏捷測試的一些相關知識，當然咱的想法也並非很權威啦，僅供參考。
正文：
談到敏捷測試，可能有些人不一定聽到過，不過很多人應該聽到過敏捷開發吧，其實從廣義來講，測試也是屬於開發過程的一部分，測試完成以後開發過程纔算真正完成，所以敏捷測試其實也可以算是敏捷開發的一部分，之所以大家不怎麼關注，一方面國內對測試行業的關注度遠遠低於開發行業，第二個方面其實也跟第一個相關，就是敏捷開發先流行起來，再加上國內的開發、測試比例，所以敏捷測試這個概念就顯得不怎麼流行了。不過，情況也在慢慢變化，從我瞭解到的情況看，越來越多公司已經在關注這一塊了。
大家在百度上搜索一把，可以看到敏捷測試的標準定義：
首先敏捷測試(Agile testing)是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。
敏捷測試是遵循敏捷宣言的一種測試實踐：
1、強調從客戶的角度，即是從使用系統的用戶的角度，來測試系統。
2、重點關注持續迭代的測試新開發的功能，而不再強調傳統測試過程中嚴格的測試階段。
3、建議儘早開始測試，一旦系統某個層面可測，比如提供了模塊功能，就要開始模塊層面的單元測試，同時隨着測試深入，持續進行迴歸測試保證之前測試過內容的正確性。
稍微研究一把，大家就會知道，雖然加個敏捷兩字，其實測試還是原來的測試，以前大家在軟件工程裏提到各種測試方法（等價類劃分法、邊界值分析法等等）、測試分類（白盒、黑盒等等）還是繼續適用的，所以放心，如果你是測試工程師，不懂敏捷測試理論也不會讓你丟了測試工作的，你只要能發現Bug，發現好Bug，發現很多Bug就Ok了。當然對於測試主管甚至再高層就不這麼想了，呵呵，爲啥原因呢，下面會慢慢爲您解答。
那既然測試還是原來的測試，那還要敏捷測試幹嘛呢，其實跟敏捷開發一樣，敏捷測試你也需要從它的發展來理解它。很久很久以前（當然，也不是太久，也就是上個世紀的事情），即使在國外也還沉醉在瀑布開發中，所以在那個時候，測試呢，就一直躲在開發過程的最後，產品開發完成了以後，就開始大規模測試，測試完成，軟件就發佈了，就像練功夫一樣，一氣呵成，打完收工。
當然，後來發生的事情，我們現在也早已知曉，（唉，歷史啊歷史，人就像歷史長河中的一滴水，如果不能揚名，那唯一結果就是被蒸發被遺忘，悲哉！（感慨一下先！））：
一開始的軟件一個軟盤就能搞定，沒有多少代碼量，所以出問題的機率就不高，測試放在最後一點問題都沒有，但是隨着軟件越來越龐大，大家就慢慢發現問題了，如果一開始設計有問題，或者有重要功能做錯了而直接影響到其他相關功能也出錯，這類事情只能在最後的測試階段才能被發現，雖然說測試就是爲了發現Bug，但是這類問題發現得太晚帶來最直接的結果就是代碼需要大改，時間需要延期，成本需要增加，下面這個圖就可以看出來，一個Bug發現的越早修復的成本越小，爲什麼呢，因爲你想好了，一個Bug其實也就是一些代碼，剛寫的時候，它可能比較獨立，或者只跟少數幾個其他功能有關，也相對好找，但是一旦到了中後期，這部分代碼可能被其他很多功能調用，你修了這個地方，那個地方調用時可能就會出問題，所以你就得把相關地方都去看一遍，如果漏了一個地方，不好意思，可能是個大Bug，所以你需要花費大量時間，體力，財力去修復，如果你在剛做完的時候就發現了，輕車熟路馬上就可以改完，五分鐘的事情。
我們公司以前（大約2006年之前）也是採用瀑布模型來開發產品的，所以測試當然也是瀑布測試了，對於測試人員來說，最直接的現象就是，平常很空，開發完成的時候就忙得要死，一輪接着一輪的測試周期，所以經常連着幾周都在測試，經常加班；而開發呢，開發時很忙，測試時更忙，因爲一方面有大量Bug過來，另一方面很多Bug都是很早之前產生的，要修復起來特別麻煩，還得去查原來的代碼，焦頭爛額的，更鬱悶的是，經常發現有些功能沒做對，不是客戶所要的。所以也許開發過程就一個月，但是測試過程卻花了兩個月，最後到頭來，客戶說，這個產品不是我們想要的。
痛定思痛，做些改變吧，奧巴馬都說了，We need CHANGE，所以大家就想啊想，想出一個V模型來，什麼是V模型呢，且聽下回分解。
(未完待續)
