最近一直在想
敏捷測試如何實施的事情，敏捷測試在敏捷開發(fā)中貫穿始末，涉及到了多種角色的參與：客戶、開發(fā)、設(shè)計、專職測試等等，每個角色承擔(dān)著不同的測試任務(wù)，客戶與設(shè)計可以進行驗證需求實現(xiàn)的測試，而開發(fā)進行
單元測試，專職測試人員進行詳細測試。
我們這里主要是來談?wù)剬Ｂ殰y試人員如何開展敏捷測試，其實這個問題也是很多軟件公司在研究的問題，我們公司也在摸索之中，今天就來介紹一下目前的一些情況。
首先介紹我們公司的情況，我們自己開發(fā)產(chǎn)品，大致主要有二條產(chǎn)品線，一條用敏捷方式，另外一條還是用傳統(tǒng)的瀑布方式，今天當(dāng)然是介紹敏捷那條產(chǎn)品線。
在敏捷中，測試是從頭到尾一直參與的，而對于專職測試人員該從何時開始介入測試呢？各個公司都有自己的想法，對于我們公司而言，當(dāng)一個功能已經(jīng)設(shè)計好并且決定在這個迭代周期中開發(fā)時，測試人員就應(yīng)該開始介入了。
怎么介入呢？
1、先從設(shè)計文檔著手，參考客戶需求看看設(shè)計文檔是否已經(jīng)實現(xiàn)客戶的要求，對有疑問的地方與設(shè)計人員溝通清楚。當(dāng)搞清楚整個設(shè)計思路以后，用腦中已經(jīng)存在著的這個概念功能來寫測試用例。
這個測試用例需要共享給設(shè)計人員與開發(fā)，特別是給開發(fā)人員，因為他們開發(fā)的時候就能參照到這些測試點，避免出現(xiàn)未考慮到的地方。
2、當(dāng)開發(fā)人員開發(fā)完成后，測試人員開始測試前或者測試中，需要進行討論會，討論什么呢，討論這個功能的測試覆蓋點。之前測試用例已經(jīng)寫完了，但是這個 測試用例是基于一個想象中的功能的，實際的功能怎么樣子，誰都不知道。而現(xiàn)在實際功能做出來了，對于一個測試人員而言，就能得到基本的測試點了。而開討論 會的目的就是盡可能全的把測試點覆蓋，畢竟一個人的思維總是有局限性的，眾人拾柴火焰高。
不過，在敏捷中，功能是不定時做完的，可能今天做完2個，明天又做完3個，后天可能一個都沒有，所以這種討論會不是固定間隔的，一般情況下，累積幾個功能以后開一個討論會。
開討論會之前必須做好準備工作，也就是參與者需要提前看過這個會議中需要討論的功能，可以會前給大家一個小時或者半個小時研究一下。而在會議中，功能的實際測試者需要將大家對于這個功能的討論測試點記下來，之后更新之前寫好的測試用例。
通過這個討論會的方式，可以有效地提高測試覆蓋面，從而提高產(chǎn)品質(zhì)量。
當(dāng)一個功能開發(fā)完成以后，測試人員就可以開始按照設(shè)計完成的測試用例來進行測試了。在測試過程中，我們也需要注意很多地方：
1、首先，雖然測試可以根據(jù)測試用例來測，但是一個產(chǎn)品如果需要覆蓋很多環(huán)境，比如數(shù)據(jù)庫，瀏覽器，操作系統(tǒng)等， 你要全部覆蓋到，我相信幾個Sprint都沒法測完，所以怎么解決的呢？我們是按照迭代測試的方式來解決，簡單而言，就是把一個功能的測試分成幾輪，第一 輪可能在SQL+IE+Win7上測，第二輪呢，則在Oracle+Firefox+W2008上測，第三輪。。。。。。這個方法相對于我們現(xiàn)在的人力資 源來說比較合適，因為理論上你要測試全的話，測試的組合個數(shù)就是各個環(huán)境個數(shù)乘在一起，DB（SQL+Oracle+Access）×瀏覽器 （IE+Firefox+Chrome）×操作系統(tǒng)（Win7+W2008+W2003）=27，這個是窮盡測試，的確可以測得很全，但是耗費的資源太 多，一般都不太可能采用。我們實際測的時候，只需要考慮三個組合： SQL+IE+Win7，Oracle+Firefox+W2008， Access+Chrome+W2003，這種方式有個好處就是既覆蓋了所有測試點，又兼顧了時間與人力資源。
2、既然只有三個組合，那為什么還要分成不同的輪次測同一個功能呢？這個里是很有考慮的，首先，我們測試第一輪的時候，必然會發(fā)現(xiàn)Bug， 開發(fā)修Bug可能會導(dǎo)致其他Bug產(chǎn)生，這些需要我們再做回歸測試；第二，敏捷歡迎變更，功能的變更是家常便飯，所以一旦一個已經(jīng)做完的功能發(fā)生變更，就 需要我們重新測試過；第三，對于一個功能的測試，我們知道每個人總是有思維定式，如果能有不同人來測試同一個功能，可能會發(fā)現(xiàn)很多不一樣的Bug。基于這 些方面的考慮，我們設(shè)計了一個功能需要經(jīng)過起碼三輪的測試，第一輪是最主要的測試，測試完畢這個功能就應(yīng)該是基本可用了，后面兩輪屬于回歸測試，確保修復(fù) Bug和做過變更過的功能依然可靠，并且用不同人的角度來測試同一個功能。
3、分成三輪，其實還有另外一個也很重要的考慮，由于是敏捷 方式，所以對于時間的把握很重要，我們希望每個Sprint都能產(chǎn)生一個可用的產(chǎn)品，可以讓客戶來體驗新做的功能，而測試往往是個攔路虎，因為既然要測， 我們就像測得仔細，覆蓋很多地方，那這個就需要時間，時間是敏捷的敵人，所以我們就在想，既要能快速得到Build，讓客戶去看，又要保證質(zhì)量，只能采用 分步的方式來做，先在最常用的環(huán)境里進行測試，保證基本功能正常，可以給客戶評估測試，然后接下來再通過幾輪測試保證這個功能的質(zhì)量。
采用了這種方式來進行敏捷測試，其實給整個測試團隊帶來了很大的壓力，我們需要更快的反應(yīng)速度，更高的責(zé)任感，更強的掌控能力，一旦某一環(huán)失控，之后都是 一個連環(huán)失控的局面，比如這個Sprint有功能來不及測完，下一個Sprint已經(jīng)開始，新的功能又開始過來，你得先測完上個Sprint的，因為有客 戶等著看，但是這個Sprint又在大量累計功能，最后越堆越多，而且在測試理論上，Bug如果在早期發(fā)現(xiàn)，修復(fù)成本最低，一旦早期沒有發(fā)現(xiàn)，之后又在 Bug的基礎(chǔ)上做了其他功能，最后導(dǎo)致了連環(huán)Bug，修復(fù)成本會高得離譜。所以如果更高的要求能帶來產(chǎn)品更好的質(zhì)量，當(dāng)然是很值得的，而且對于員工個人能 力的提高也非常有幫助。
敏捷測試的實踐其實很多公司都在研究，但是真正能成功的可能還不多，其實我們已經(jīng)試驗過很多方法，這次也是一個經(jīng)驗總結(jié)后的繼續(xù)嘗試，相信很快能找到敏捷測試的真諦。