【本篇是《敏捷測試理論以及實踐》第六篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇）】
2. 編碼階段：
完成了需求設計階段，就要開始進入編碼階段了，雖然說開發與測試需要同步的，但是功能還沒做完也沒法同步去測吧，不過還是有事做的，就是可以同步開始寫測試用例，這個就用到DevTest工具了。DevTest主要用於管理測試用例，以及根據測試用例來進行在不同環境下、不同時間下和不同的範圍裏進行的手動測試與自動測試，並且可以生成報表供評估測試質量和產品質量。
也許有人有疑問，敏捷測試還需要測試用例？我的答案還是“是”又“不是”，
先說“不是”，對於敏捷測試本身而言，我們實際新功能測試中其實沒有用到測試用例，完全是根據設計文檔來進行測試的（也許又有人來問敏捷好像不需要測試文檔，這個在這裏不多說，詳見我另外一篇文章《結合工具來實現敏捷開發》），所以這個時候是不需要測試用例的；
而爲什麼又說“是”呢？因爲敏捷在不同的公司不同的情況可以有不同的實現方式，我們公司不是做項目的而是做產品的，也就是說像微軟的Windows一樣，我們公司的產品也是1.0，2.0這樣做下去，現在已經9.0了，在這期間，或多或少有很多功能是在不同版本里都有的，特別是那些基本功能，爲了測試新功能是否破壞原有功能，我們需要測試這些老功能是否能正常工作，也許有人說，那我只要在測試新功能時測一下老功能就行了，測試用例也不需要吧？是的，也許你們公司不需要，但是對於我們公司而言，特別對於9.0而言，之前所有版本的功能都是老功能，之前的老功能有幾百個，幾千個，你能在測試新功能時測一下嗎？很顯然，這個是很難做到的，新功能做完時，一般情況，測試人員會檢查是否能正常工作，是否對一些基本功能沒影響，至於對其他看起來不怎麼搭嘎的功能其實不太會去關注，而且時間上也不允許。這樣子的話，測試用例就顯得很重要了，因爲測試用例從本質上來說就是介紹需要測試的功能點以及怎麼去測試它們，把每個版本的每個的功能點都通過測試用例的方式保存下來，測試時想漏掉一個測試點都難。所以測試新功能時沒測到的地方，都可以在用測試用例生成測試任務時重新覆蓋全面，不過這一步由於測試覆蓋面太廣，也就意味着所花時間會很多，所以一般情況下，一部分測試點會用自動化測試工具跑掉，另一部分只能人工來跑的也只在最後系統測試的時候做掉。
看了這個“是”與“不是”，大家應該知道我們公司的“敏捷測試”其實是結合了敏捷測試與傳統測試，也即是兼顧速度與質量，所以有時候我們稱之爲有我們公司特色的敏捷測試，呵呵。
在寫測試用例的時候，測試人員需要和設計人員進行大量的溝通，以徹底理解這個功能爲接下來的實際測試做好準備，“溝通”在敏捷裏是一個重要的原則，在實際工作，我們也真正體驗到它的好處，只有通過溝通，幾個部門之間對於產品纔有一個認識高度上統一，才能設計出、開發出、測試出一個好的產品來。不過這點，我覺得大家也只能真正通過實踐才能體驗，我說得太多，其實也沒法讓大家信服的。
3. 敏捷測試階段：
好了，寫完測試用例了，開發也做完幾個功能了，咱們也可以開始測試了，《結合工具來實現敏捷開發》裏也講過，我們公司是採用Scrum方式的，所以會生成很多迭代週期（Sprint），每個迭代週期中會從Backlog裏分配一些Story來做，咱們測的也就是做好的Story，其實也就是功能點了。
這部分工作主要在DevTrack中完成，
DevTrack的主要用於開發完成功能點編碼以及測試人員完成敏捷測試。當需求設計完成後，項目經理會通過DevSpec/DevPlan來分配開發任務給相應的開發人員，並且同時生成敏捷測試任務，而開發一旦完成功能以後，就會在DevTrack中把相應的敏捷測試任務打到“可測試”狀態，這樣子，測試人員就開始進行測試了，測試完了，就把任務關掉，這個功能點就算測試完成了，項目經理會通過檢查測試任務是否已經關掉來判斷這個功能是否已經完成。
由於之前測試人員已經把當前迭代週期中的功能點寫成測試用例了，對於做好的功能點其實已經從理論上很瞭解了，所以測試起來就“輕車熟路”了。測試總會發現Bug，但是Bug有嚴重和不嚴重之分，我們現在處理Bug的原則是，對於影響到這個功能讓客戶評估的Bug都必須在這個迭代週期和下個迭代週期中修復，這些Bug可能包括報錯，功能徹底沒法工作，也可能包括一些頁面上的美觀，因爲我們的產品會定期給客戶做評估，以讓客戶看看做完的功能是否符合他們的要求，所以對於做好的功能點起碼需要能讓客戶能用起來，所以客戶會最直接用到的看到的地方就需要優先處理掉。而對於其他普通的Bug，DevTrack會有專門的一個文件夾保存，這些Bug會在Release之前通過優先級來一一進行修復，有些實在優先級很低的或者暫時不能完成的可能就會推遲到下個版本再做或者直接就不修了，因爲有時候修一個Bug可能會帶來一些意想不到的問題，如果可修可不修的Bug，就不需要冒影響產品質量的風險去修了。
不知道大家有沒有注意到，上面說了Bug需要在這個迭代週期與下個迭代週期中修復，爲什麼不在這個迭代週期中修復呢，其實是這樣的，因爲測試總是在開發後面開始的，如果一個功能點在一個迭代週期的後期完成，從時間上可能測試無法在這個迭代中完成，但是迭代週期的時間又不是想改就可以改的，所以這種情況下，我們就會在下個迭代週期中把這個功能點測完。不過一般情況下，我們還是建議不要延遲到下個迭代週期中完成，因爲一個迭代完成後，我們會給一個Build給客戶做評估，如果有沒測試完的功能，可能就有一些潛在的影響客戶使用的Bug，這樣子對銷售就會產生不好的影響。所以，解決的方法就是一個功能點開發完成就必須馬上讓測試測，發現Bug馬上修復，如果有功能點到了迭代末期才做好，則已經Check In代碼確保沒有嚴重Bug（主要是表明和這個功能最基本的使用），沒有Check In 代碼的就等到下一個迭代週期再Check In代碼，測試也推遲到下個迭代中測試。
就這樣子，迭代週期一個個進行中，開發做了一個個的功能點，然後測試就會把這些測完，在這個週期中，開發與測試的工作量都會在DevTrack中被記錄，主要是花費時間與剩餘時間，從而得到了產品未來的一個進度趨勢圖，也就是所謂的燃盡圖。
4. 需求變更：
敏捷是歡迎變更的，客戶有啥想法可以隨時提出隨時改進，我們公司的產品是定期給客戶一個Build來進行評估的，所以客戶經常會要求做一些更改，對於還沒有測的功能點稍微好一點，因爲只要改設計文檔，但是對於已經做完或者正在做的，已經測完或者正在測的呢？答案當然是也得更改，做好的重做，測好的做完重測，對於瀑布模型來說，這個也許是難以想象的，但是對於敏捷來說，這個是家常便飯了。
在實際操作中，我們可能會用到一個DevSpec的功能，這個功能比較不錯，所以我單獨提出來說一下。有些時候，如果一個功能已經在測試了，如果突然有了改動，而這個改動也已經做完了，如何通知測試人員重新測一下呢？口頭通知？Email？其實都可以，只是有些時候，改動太多，需要知會的人太多，或者改功能的人不知道要通知哪些人，那怎麼辦？DevSpec有個功能可以自動提醒跟這個功能點有關任何開發、測試人員，讓他們知道他們做的事情有改變了。
（未完待續）
