上面已經談到了準
敏捷測試
模式了，離咱們所說的敏捷測試已經無限接近了，但是要了解真正的敏捷測試，還是需要回到敏捷開發上來講，前面一開始已經說過，敏捷測試嚴格上來說其實是屬於敏捷開發的一部分，所以敏捷開發的價值觀也會同樣適用於敏捷測試，那麼敏捷有哪些價值觀呢？總共是五個，分別是簡單、溝通、反饋、勇氣、謙遜。
光看這五個詞，我想大部分人可能會暈乎了，不知所云的，難道敏捷就五個詞能概括了？就像電影裡出現的武功秘籍一樣，一招就乙個圖，我們看了根本就不知道是啥，人家一看就能煉成神功了。
其實呢，這幾個價值觀並不是教你怎麼去實現敏捷，而是教你用一種什麼樣的態度去對待開發：要時刻想著最簡單的方法去處理需要解決的問題，要經常與和開發/客戶溝通，對於積極對待反饋，要有勇氣去做決策，對團隊各個成員都要尊重。這麼幾個價值觀，對於你去初次理解敏捷而言，我相信幾乎沒有用處，甚至會讓你覺得很迷茫，到底敏捷是啥，但是一旦當你已經真正理解了敏捷的時候，你就會發現，誒，的確是這樣子的，說得很好！（哲學上說，事物的發展總是需要經歷否定之否定階段，對知識的理解也是一樣，一開始看一下概念覺得很簡單，覺得自己已經理解了（肯定）；深入下去，發現問題越來越多，覺得自己沒辦法去理解（否定）；到最後經過不斷地思索與實踐，終於徹底理解後，你就會覺得一開始那些簡單的概念很精闢，就應該那麼簡單！（否定之否定=肯定））
不過相對於當初的先行者而言，我們又是幸運的，因為很多前輩已經幫我們理解了這些價值觀，並且研究出了很多實現的方式， 但是我們也不能去奉行拿來主義，畢竟是人家想出來的，是基於人家的實際情況，對於我們的情況不一定會適合，最好的辦法就是取其精華，去其糟粕，結合實際，加以改進。
接下來我就開始講什麼是真正的敏捷測試模式和我們公司怎麼結合它來取其精華，去其糟粕，結合實際，加以改進。
當然這個所謂的真正的敏捷測試模式也是業內主流的模式，我們公司的實際運用中還是有所區別的，下面都會提到。
跟前面講到的準敏捷測試相比，真正的敏捷測試其實也只是加以改進和豐富，所以與客戶的溝通、積極響應需求的變更、以及開發與測試的同步，這些都還是存在的，當然敏捷測試改進和增加了許多地方，主要有：
1、過程需要實現迭代：每個迭代週期需要完成一定量的功能，沒有完成的功能不能check in**，這些功能需要經過嚴格測試，並且開發需要修復主要的嚴重bug，這樣子在最後就得到乙個可以工作的並且相對穩定的build，這個迭代週期就算完了，然後開始下乙個迭代週期。這樣就類似與我們修路一樣，修路的話需要打好幾層地基，每層地基打嚴實後，再鋪上面一層，這樣子即使最上層破了，只要修一下最上層就好了，不會影響到下面層的質量，如果是最下面那層沒打嚴的話，一出問題每層都會損壞，要修的話，要全部扒掉這麼多層地基才能修好。所以迭代對於測試的要求就特別高了，因為只有把這個迭代的主要bug找到並修好，下面的迭代週期才能不受影響，才能確保以後出現的問題不用「打到最底層」才能被修好，「打到最底層」意味著就是人力，物力，時間以及最重要的產品的質量！
下面是乙個迭代的簡單示意圖，應該可以理解的，就不多講了。
2、測試不單單要和客戶溝通，也要跟公司裡的人經常進行溝通，因為乙個公司的所有人其實都只有乙個共同目標，就是把公司發展好，這樣子其他的比如自己的發展，待遇等等才有可能實現。那麼體現在實際的工作中就是：
a）測試需要完全理解需求講的知識點，不懂或者有疑慮要及時跟設計溝通，這樣子可以讓你更好地理解需求，甚至幫助設計人員發現錯誤；
b）測試人員需要經常跟開發人員溝通，看看做的功能，修的bug主要會影響哪些其他模組，主要出現問題的原因是什麼，怎麼弄可以最快速度重複出bug來，這樣子就幫助自己掌握測試的方向以及幫助開發快速修復bug以及避免以後出現類似bug。
c）測試也需要跟測試人員之間進行溝通，來探索怎麼能發現有質量的bug，怎麼能覆蓋到很多的測試點，怎麼解決自己沒辦法解決的問題，幫助他人也幫助自己。（每日立會是其中乙個好辦法）
d）測試還需要跟自己溝通，不斷地經常反思自己的優點和缺點，反思團隊的優點和缺點，反思公司的優點和缺點，大膽提出和實施改進意見，為以後更好地開展工作做準備。（反思會是一種辦法）
溝通，只有溝通才能了解雙方的想法，才能及時消除前進中的阻力和困難，讓大家在同一方向上用同乙個信念前進。
3、建立有效的監測機制：這裡所謂的檢測機制主要有兩點，乙個是對測試的監測，另外乙個就是對產品的監測。對於測試的監測主要在於檢查測試的覆蓋面是否全面，發現的bug與測試覆蓋面的一些對比資料，這些有助於提高測試的覆蓋面從而提高bug發現率；而對於產品的監測就是主要有兩點，一點就是做功能和修bug的進度是否是可控的，可預判的；另一點就是發現bug的情況，也就是產品的質量是怎樣的，質量發展的趨勢是怎樣的。
我主要想補充的是這麼三點，當然要是我想到其它的，我還是會修改這篇文章的。看過網上也有很多人來寫關於敏捷測試的一些文章，很多都是國外英文解釋的標準中文翻譯，當然也有很多是自己的一些想法，所以遠近高低各不同，不過既然敏捷只是一種思想，也就不會拘泥於何種實現方式，所以各人有不同想法都ok的。其實說的再過一點，只要你自己認為你的方法是敏捷的，那你就可以認為是敏捷的，不用關心人家怎麼想，人家的方法不一定適合你的，你只要有辦法能在正確的時間交付正確的產品，那就ok了。
所以我接下來就會按照我們公司的流程來實際介紹一下敏捷測試在我們公司的實現，中間可能會有一些地方為主流敏捷測試所不容的，但是我覺得他們比較符合我們公司的實際，如果大家有不同的意見或者更好的方法，我也會悉心接受。
（未完待續）
敏捷測試理論以及實踐 4
本篇是 敏捷 測試理論以及實踐 第四篇，第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇 上面已經談到了準敏捷測試模式了，離咱們所說的敏捷測試已經無限接近了，但是要了解真正的敏捷測試，還是需要回到敏捷開發上來講，前面一開始已經說過，敏捷測試嚴格上來說其實是屬於敏捷開發的一部分，所以敏捷開發的價...
敏捷測試理論以及實踐 2
所謂的v模型，其實是對瀑布模型的一種修改，也算乙個change吧，詳見下圖 由於瀑布模型對於軟體的需求分析與設計階段考慮不足，導致可能會出現嚴重的設計問題，最後交付到客戶手裡才會被發現，所以v模型就考慮到這點，針對開發的各個過程都會有相應的測試環節，比如使用者需求會對應驗收測試，需求分析和系統設計會...
敏捷測試理論以及實踐 3
本篇是 敏捷 測試理論以及實踐 第三篇，第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇 現在先來總結一下到底上面說的模型存在著哪些問題 1.客戶生氣地說 這個產品好像不是我們想要的吧！早知你們給我這樣子的產品，我才不會下單了，你們也早點跟我說這個產品是這樣子，到現在才給我看，浪費我時間，精力...