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