5、傳統(tǒng)測試階段
當開發(fā)完成了所有的功能點，測試那個時候也差不多完成了這些功能點的測試，我們就會有一個階段性的最終版給客戶評估，讓客戶看看需要的功能是不是都已經(jīng)可以了，如果覺得沒什么問題，一般情況下就不進行功能添加與更改了。（當然，真的要更改我們還是會歡迎的，不過一般客戶也知道，頻繁的更改不能保證產(chǎn)品的質(zhì)量，所以到最后他們一般有不緊急的更改也會要求放在下一個版本里的）
到目前為止，真正意義上的敏捷測試階段其實已經(jīng)完成了，要開始進入一些傳統(tǒng)的測試了，比如系統(tǒng)測試，性能測試，壓力測試等。這些就會用到之前說的DevTest里管理的測試用例，通過這些測試用例，我們會生成測試任務(wù)，然后通過手工和自動的方式，把這些任務(wù)完成，當然，可能要進行幾輪，第一輪測試最仔細，覆蓋面最大，所以時間也最長，第二輪主要是對開發(fā)修Bug的確認以及可能影響到的功能的測試，最后還有一輪驗收測試，主要對基本的功能進行測試，確保不會出現(xiàn)明顯的問題。
這些測試都完成以后，差不多產(chǎn)品也就可以發(fā)布了，當然能不能發(fā)布，領(lǐng)導們還是會有一個會議研究通過的，不過也就是通過 DevTrack 和 DevTest 來導出一些報表看看測試情況來了解產(chǎn)品質(zhì)量。
以上差不多就是我們公司現(xiàn)在的一個流程，從嚴格意義上來說，不是完全的敏捷測試，只是算一部分，但是如果從以前的瀑布來看看，已經(jīng)算很敏捷了。而且，從現(xiàn)在這個流程分析，如果把那些傳統(tǒng)意義上的測試繼續(xù)敏捷化，我們覺得對產(chǎn)品的質(zhì)量沒法保證，所以基本上，目前這個模式，可以算是我們公司特色的敏捷測試了，之后應(yīng)該不太會有大的更改了。
接下來我再總結(jié)一下我們公司的模式，以及補充一些之前沒提到的，因為之前寫得太急，有時候很難想得太全。
我們公司測試模式按照順序主要有以下這么幾步組成：
1）需求階段測試研究設(shè)計方案是否符合要求
2）開發(fā)編碼期間完成測試用例
3）開發(fā)完成一個功能的編碼，測試就需要開始測試，并且確保能在一個迭代周期中完成測試，并且確認嚴重Bug的修復
4）所有迭代周期完成后，開始進入集成測試，系統(tǒng)測試，驗收測試以及壓力測試，性能測試
差不多測試需要參與的工作就是這幾步了，下面就是有一些細節(jié)點討論一下，我會以問答形式來介紹：
（1）問：發(fā)現(xiàn)了很多Bug，測試人員怎么知道哪些Bug要馬上修，哪些可以推遲修呢？
答：首先，我們會規(guī)定什么樣子的Bug需要什么樣的優(yōu)先級，比如報錯優(yōu)先級就會比較高，每個測試人員都有這么一個文檔讓他們來判斷這個 Bug 是什么級別。其次，我們會有專門的人員對這些Bug進行二次過濾，由他們來覺得這個Bug是否需要在這個迭代周期中進行修復，這種專門的人員的能力需要很高，因為他們需要能了解這個Bug的重要性以及這個Bug修復起來所需人力物力是否能在這個迭代中解決，所以一般這個角色會有測試主管或者項目經(jīng)理來承擔。
（2）問：整個測試期間，就專職的測試人員參與測試就行了嗎？
答：不是的，首先開發(fā)肯定需要進行單元測試；然后設(shè)計人員和項目經(jīng)理也要參與測試，因為只有他們最清楚這個功能設(shè)計的初衷，才能真正知道現(xiàn)在做完的是不是真的符合當初的初衷；再次，客戶也會參與測試，因為產(chǎn)品說到底最終是給客戶使用的，他們當然想拿到一個他們滿意的產(chǎn)品，所以我們會定期給客戶版本，讓他們對做好的功能點進行簡單的試用，讓他們來看看產(chǎn)品是否符合他們的需要，這樣就是最直接的用戶體驗了，發(fā)現(xiàn)的問題也是最真實的。
（3）問：測試過程中是否需要開會？
答：需要，測試人員也會有每日立會，跟開發(fā)差不多，也是介紹，昨天做了什么，今天要做什么，之前碰到什么問題。會議效果很好，首先讓大家知道其他人在測啥，然后如果有問題的話，大家一起討論就可以共同進步。另外測試也需要有反思會，看看這一輪發(fā)生的問題，為什么有些Bug沒有找到之類的。
（4）問：敏捷是否需要特別的測試技術(shù)？
答：不需要，敏捷只是一種思想，有一些價值觀，它不會教你用什么方法去測試一個產(chǎn)品，只會教你以怎么樣的一種態(tài)度去做測試，以怎么樣的時間安排去開展測試。
（5）問：敏捷是否還是需要回歸測試？
答：需要，回歸測試仍然屬于一個比較重要的環(huán)節(jié)，不管是敏捷還是傳統(tǒng)的測試，只是由于敏捷測試中對時間的要求越來越高，使得本來需要大量時間的回歸測試越來越難實施，所以目前的趨勢是盡可能把回歸測試用自動化測試來實現(xiàn)。對于我們公司而言，這也是一個方向，有些部分也在開始，但是由于產(chǎn)品邏輯比較復雜，很多功能有自動化測試實現(xiàn)會比較麻煩，所以現(xiàn)在我們的回歸測試有相當一部分還是人工的方式，當然最終必然是會大部分采用自動化測試的。
（6）問：對于重復的Bug，怎么去處理？
答：其實我也咨詢過不少公司，很多公司是不允許重復提交Bug的，所以提交之前需要先去確認是否其他人提交過，我相信這個確認過程應(yīng)該會花費不少時間，不過對于開發(fā)而言應(yīng)該會減少時間，因為不會出現(xiàn)重復的Bug；當然也有一些公司允許重復提交的Bug，原因也很簡單，覺得對于Bug而言，只要是必須修的，發(fā)現(xiàn)了就得提，別人提過當然最好，但是就怕別人沒提過，你卻認為提過就不提了，最后客戶發(fā)現(xiàn)就慘了。所謂“寧可錯殺一千，不可放過一個”就是這個道理了，呵呵。我們公司是允許提重復Bug的，當然是在不知道有其他人提過的前提的，你如果已經(jīng)知道別人提過了，當然就不能再去提了。
敏捷測試差不多就講到這里了，也許有人清楚有人迷惑，水平有限，也沒法講得太好，望見諒。如有問題，可以私聊。謝謝大家一直看完！
（全文完）