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