李嫚

摘 要：近年來，敏捷化開發(fā)方式的流行，使得敏捷測試應運而生。它應用新的測試流程、方法和實踐，精剪并改進傳統(tǒng)的測試流程，如減少測試用例設計，增加與產品設計人員的交流。本文根據在敏捷化開發(fā)項目組做測試工作的經歷，介紹在敏捷開發(fā)過程中的對于測試的一些體會和經驗。

關鍵詞：敏捷測試；軟件測試；測試執(zhí)行

1 敏捷測試人員的定位

敏捷化開發(fā)近年來逐漸引起廣泛關注，它是一種遞增式的，持續(xù)迭代和不斷調整的開發(fā)模式，它可以應對快速變化的需求。通過不斷增量開發(fā)和持續(xù)集成我們逐漸建立起軟件系統(tǒng)，可以看到系統(tǒng)的成長。敏捷測試是適應敏捷開發(fā)方法而采用的新的測試流程。在敏捷開發(fā)模式中，迭代周期短，需求變化快，敏捷測試總概括起來可以說是對原有功能的回歸測試和對新功能的驗收測試，根據系統(tǒng)的持續(xù)集成持續(xù)地對軟件質量信息進行反饋。

敏捷中測試人員又叫QA（質量保證）。因此，從項目一開始就需要讓全員達成一致：關注質量，隨時構建質量，形成零缺陷文化。從用戶角度出發(fā)關注用戶使用，引導開發(fā)人員能夠從用戶的角度去思考、設計和實現軟件，測試人員可以通過架構預演等方式，從整體上把握產品，及時提出架構上的問題，以及一些組件化開發(fā)的共享。測試人員需要對用戶故事及時反饋，以便團隊的及時改進以及持續(xù)改進，與開發(fā)緊密合作，形成技能互補，避免開發(fā)老是測試不出問題現象，以及測試不充分的情況。

2 敏捷測試的各個階段

針對敏捷開發(fā)方法的敏捷測試不同于以往針對傳統(tǒng)開發(fā)模式的測試，在敏捷團隊中，測試是整個項目組的指向，它告訴大家現在到哪了，正在往哪個方向走，使得項目組基于這些可靠的信息作出正確的決定。不僅是測試員要保證質量，而是整個項目組的每一個人都要對質量負責。測試員不跟開發(fā)人員糾纏錯誤，而是幫助他們找到目標，共同為達到項目的最終目標而努力。敏捷測試也需要高度迭代工作、頻繁得到客戶的反饋，需要動態(tài)調整測試計劃、測試的執(zhí)行，并且，敏捷測試人員參與到了更多的敏捷開發(fā)活動中，積極的影響了團隊做出的決定和計劃。

2.1 驗證需求和設計

需求和設計具體來說一般包括：（1）由項目經理根據需求文檔而編寫的功能設計文檔；（2）由開發(fā)人員根據功能文檔而編寫設計文檔。作為測試人員，審核重點是檢查文檔對用戶需求定義的完整性、嚴密性和功能設計的可測性。

在測試初期，測試人員要學會做靜態(tài)測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一用戶積極參與項目和系統(tǒng)的需求分析，設計和開發(fā)。積極地參與前期工作，并迅速反饋給設計和開發(fā)其靜態(tài)測試結果。要盡早的開始測試，不要等待到功能完全做好才開始測試。

2.2 測試計劃和測試用例

在敏捷開發(fā)的過程中由于是根據每個用戶故事來估算時間的。開發(fā)人員將對本次迭代所需要的完成的用戶故事進行評估。開發(fā)人員可以和客戶直接溝通，來確定每個用戶故事的優(yōu)先級。測試人員根據已審核通過的需求和設計編制測試計劃，設計測試用例。在前面提到的三種文檔中，功能設計文檔是主要依據。測試的這兩個文檔也要被項目經理和開發(fā)人員審核。

為使開發(fā)人員能參與到測試用例的審閱中來并讓開發(fā)人員迅速地了解測試的重點并給出相應的意見和建議，以保證測試用例的質量和可行性，確保測試工作的順利進行，測試人員在出測試用例的同時，應出一份測試用例映射，其中注明測試用例已覆蓋了哪些產品功能，具體每個產品功能對應的測試用例編號，這樣在對測試用例進行審閱的時候，能夠對測試用例的覆蓋率一目了然，對覆蓋率不足的地方能夠及時給出意見。

2.3 測試執(zhí)行

在敏捷方法中，測試有兩種：單元測試和接收測試。單元測試是由開發(fā)人員來完成的，接收測試是由客戶代表來完成。由于我們客戶無法在現場，我們采取了，開發(fā)人員做單元測試，測試人員做驗證測試，最后由客戶進行接收測試。在每個版本發(fā)布給客戶之前必須由測試人員進行測試，發(fā)布版本之后由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下一個發(fā)布完成。

為方便衡量項目的進度，測試可每天測試完畢后提供測試的Bug趨勢，即將每天新生成的Bug數和每天被解決的Bug數標成一個趨勢圖表。一般在項目的開始階段新生Bug數曲線會呈上升趨勢，到項目中后期被解決Bug數曲線會趨于上升，而新生Bug數曲線應下降，到項目最后，兩條曲線都趨向于零。

在執(zhí)行測試階段中，測試人員需要對已有的測試用例進行及時的維護。通常以下兩種情況下要新增一些測試用例：一是對于當初測試設計不周全的領域，二是對于外部的Bug，比如從客戶報告來的，沒有被現有測試用例所覆蓋。當產品的功能設計出現更改時，所涉及的測試用例也要相應地修改，使測試用例保持和現有的功能需求同步。

為更好地保證軟件質量，規(guī)避風險，必須加強對中間版本的控制。例如，客戶要求或者計劃周五要提交版本，則周三一定要提交一個中間過程的版本進行測試，也就是控制中間版本，避免所有的工作都壓到后期最緊急的時候去完成。以前的項目中出現過項目前期很輕松，到后期Bug越來越多，開發(fā)人員和測試人員都異常忙碌，經常加班的情況。為減少后期工作量，規(guī)避風險，建議開發(fā)每天做一個Build，或者按照完成一個功能特性就進行一次Build，針對這個功能特性進行測試，這樣就可以有效避免后期Bug越來越多的狀況發(fā)生，后期工作量也就會相應減少，項目的質量也會更有保證。在每次發(fā)布版本之前，測試人員要根據待發(fā)布的版本情況編寫版本說明，使客戶對發(fā)布的版本情況一目了然。版本說明主要包括三方面的內容：已經修復的上個版本中存在的Bug，新的功能，此版本尚存在哪些比較大的問題。

在每日立會上，測試人員可以簡潔地講述一下當天測試的重點部分，以及項目中存在哪些嚴重的Bug，讓開發(fā)人員了解當天測試的重點是什么，并提出自己的意見和建議。這樣加強了開發(fā)與測試人員的交流和溝通，使測試工作能夠更加有效，更加順利地開展。

2.4 需求管理

采用敏捷開發(fā)模式的項目中，客戶對于需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個項目進行過程中，對不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應的歷史記錄，可將每次的變更整理記錄到需求跟蹤文檔中，并使該文檔始終保持最新更新的狀態(tài)，與需求的變化保持同步，方便后期的管理和維護工作。

2.5 清理Bug

在項目開發(fā)的末期，可以開展“Bug大掃除”活動。劃出一個專門的時間段，在這期間所有參與項目的人員，集中全部精力，搜尋項目的Bug。注意以下要點：（1）盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經理，開發(fā)人員甚至于高層管理人員都應參加。目的是要集思廣益；（2）要鼓勵各部門，領域交叉搜索，因為新的思路和視角通常有助于發(fā)現更多的Bug；（3）為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發(fā)現Bug最多，發(fā)現最嚴重Bug的個人，給以物質和精神獎勵。（4）可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。