5、傳統測試階段
當開發完成了所有的功能點，測試那個時候也差不多完成了這些功能點的測試，我們就會有乙個階段性的最終版給客戶評估，讓客戶看看需要的功能是不是都已經可以了，如果覺得沒什麼問題，一般情況下就不進行功能新增與更改了。（當然，真的要更改我們還是會歡迎的，不過一般客戶也知道，頻繁的更改不能保證產品的質量，所以到最後他們一般有不緊急的更改也會要求放在下乙個版本裡的）
到目前為止，真正意義上的敏捷測試階段其實已經完成了，要開始進入一些傳統的測試了，比如系統測試，效能測試，壓力測試等。這些就會用到之前說的devtest裡管理的測試用例，通過這些測試用例，我們會生成測試任務，然後通過手工和自動的方式，把這些任務完成，當然，可能要進行幾輪，第一輪測試最仔細，覆蓋面最大，所以時間也最長，第二輪主要是對開發修bug的確認以及可能影響到的功能的測試，最後還有一輪驗收測試，主要對基本的功能進行測試，確保不會出現明顯的問題。
這些測試都完成以後，差不多產品也就可以發布了，當然能不能發布，領導們還是會有乙個會議研究通過的，不過也就是通過 devtrack 和 devtest 來匯出一些報表看看測試情況來了解產品質量。
以上差不多就是我們公司現在的乙個流程，從嚴格意義上來說，不是完全的敏捷測試，只是算一部分，但是如果從以前的瀑布來看看，已經算很敏捷了。而且，從現在這個流程分析，如果把那些傳統意義上的測試繼續敏捷化，我們覺得對產品的質量沒法保證，所以基本上，目前這個模式，可以算是我們公司特色的敏捷測試了，之後應該不太會有大的更改了。
接下來我再總結一下我們公司的模式，以及補充一些之前沒提到的，因為之前寫得太急，有時候很難想得太全。
我們公司測試模式按照順序主要有以下這麼幾步組成：
1）需求階段測試研究設計方案是否符合要求
2）開發編碼期間完成測試用例
3）開發完成乙個功能的編碼，測試就需要開始測試，並且確保能在乙個迭代週期中完成測試，並且確認嚴重bug的修復
4）所有迭代週期完成後，開始進入整合測試，系統測試，驗收測試以及壓力測試，效能測試
差不多測試需要參與的工作就是這幾步了，下面就是有一些細節點討論一下，我會以問答形式來介紹：
（1）問：發現了很多bug，測試人員怎麼知道哪些bug要馬上修，哪些可以推遲修呢？
答：首先，我們會規定什麼樣子的bug需要什麼樣的優先順序，比如報錯優先順序就會比較高，每個測試人員都有這麼乙個文件讓他們來判斷這個 bug 是什麼級別。其次，我們會有專門的人員對這些bug進行二次過濾，由他們來覺得這個bug是否需要在這個迭代週期中進行修復，這種專門的人員的能力需要很高，因為他們需要能了解這個bug的重要性以及這個bug修復起來所需人力物力是否能在這個迭代中解決，所以一般這個角色會有測試主管或者專案經理來承擔。
（2）問：整個測試期間，就專職的測試人員參與測試就行了嗎？
答：不是的，首先開發肯定需要進行單元測試；然後設計人員和專案經理也要參與測試，因為只有他們最清楚這個功能設計的初衷，才能真正知道現在做完的是不是真的符合當初的初衷；再次，客戶也會參與測試，因為產品說到底最終是給客戶使用的，他們當然想拿到乙個他們滿意的產品，所以我們會定期給客戶版本，讓他們對做好的功能點進行簡單的試用，讓他們來看看產品是否符合他們的需要，這樣就是最直接的使用者體驗了，發現的問題也是最真實的。
（3）問：測試過程中是否需要開會？
答：需要，測試人員也會有每日立會，跟開發差不多，也是介紹，昨天做了什麼，今天要做什麼，之前碰到什麼問題。會議效果很好，首先讓大家知道其他人在測啥，然後如果有問題的話，大家一起討論就可以共同進步。另外測試也需要有反思會，看看這一輪發生的問題，為什麼有些bug沒有找到之類的。
（4）問：敏捷是否需要特別的測試技術？
答：不需要，敏捷只是一種思想，有一些價值觀，它不會教你用什麼方法去測試乙個產品，只會教你以怎麼樣的一種態度去做測試，以怎麼樣的時間安排去開展測試。
（5）問：敏捷是否還是需要回歸測試？
答：需要，回歸測試仍然屬於乙個比較重要的環節，不管是敏捷還是傳統的測試，只是由於敏捷測試中對時間的要求越來越高，使得本來需要大量時間的回歸測試越來越難實施，所以目前的趨勢是盡可能把回歸測試用自動化測試來實現。對於我們公司而言，這也是乙個方向，有些部分也在開始，但是由於產品邏輯比較複雜，很多功能有自動化測試實現會比較麻煩，所以現在我們的回歸測試有相當一部分還是人工的方式，當然最終必然是會大部分採用自動化測試的。
（6）問：對於重複的bug，怎麼去處理？
答：其實我也諮詢過不少公司，很多公司是不允許重複提交bug的，所以提交之前需要先去確認是否其他人提交過，我相信這個確認過程應該會花費不少時間，不過對於開發而言應該會減少時間，因為不會出現重複的bug；當然也有一些公司允許重複提交的bug，原因也很簡單，覺得對於bug而言，只要是必須修的，發現了就得提，別人提過當然最好，但是就怕別人沒提過，你卻認為提過就不提了，最後客戶發現就慘了。所謂「寧可錯殺一千，不可放過乙個」就是這個道理了，呵呵。我們公司是允許提重複bug的，當然是在不知道有其他人提過的前提的，你如果已經知道別人提過了，當然就不能再去提了。
敏捷測試差不多就講到這裡了，也許有人清楚有人迷惑，水平有限，也沒法講得太好，望見諒。如有問題，可以私聊。謝謝大家一直看完！
（全文完）
敏捷測試理論以及實踐 2
所謂的v模型，其實是對瀑布模型的一種修改，也算乙個change吧，詳見下圖 由於瀑布模型對於軟體的需求分析與設計階段考慮不足，導致可能會出現嚴重的設計問題，最後交付到客戶手裡才會被發現，所以v模型就考慮到這點，針對開發的各個過程都會有相應的測試環節，比如使用者需求會對應驗收測試，需求分析和系統設計會...
敏捷測試理論以及實踐 3
本篇是 敏捷 測試理論以及實踐 第三篇，第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇 現在先來總結一下到底上面說的模型存在著哪些問題 1.客戶生氣地說 這個產品好像不是我們想要的吧！早知你們給我這樣子的產品，我才不會下單了，你們也早點跟我說這個產品是這樣子，到現在才給我看，浪費我時間，精力...
敏捷測試理論以及實踐 4
本篇是 敏捷 測試理論以及實踐 第四篇，第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇 上面已經談到了準敏捷測試模式了，離咱們所說的敏捷測試已經無限接近了，但是要了解真正的敏捷測試，還是需要回到敏捷開發上來講，前面一開始已經說過，敏捷測試嚴格上來說其實是屬於敏捷開發的一部分，所以敏捷開發的價...