敏捷測試的挑戰

　　測試員應該自動化可接受性測試，使用與開發環境一樣的編程語言來編寫可接受性測試的代碼，重用單元測試的框架，使軟件更加可測。

　　利用“灰盒”測試。設法弄清楚系統各模塊之間的關系，分析變更的影響，看什么是需要測試的，什么是可以不測試的。弄清楚bug，bug的表面現象是什么?產生bug的根本原因是什么?弄清楚風險，使用解決風險的測試策略，調整測試目標。

　　敏捷測試的挑戰之六：我們還需要bug跟蹤系統嗎?

　　有些人說敏捷團隊不需要跟蹤bug，只需要把發現的bug盡快修正就行了。

　　這種做法只適用于開發過程的測試，如果是一個完整迭代的測試，你就需要bug跟蹤系統，因為有些bug不是在這個迭代馬上修改的。

　　敏捷測試的挑戰之七：用什么質量標準來度量敏捷項目?

　　其中一個最好的質量標準是發布后逃逸的bug數量。不辛的是，這是個事后的衡量標準。

　　采用每個迭代后計算逃逸bug數量的方法能標識代碼的質量。

　　我們還可以從bug學習到很多東西：

　　1、 是否有些類型的bug在可接受性測試中發現的，其實是可以在單元測試就發現呢?如果是，把它加入到單元測試。

　　2、 我們是否能讓bug的發現過程或bug的診斷更簡單?

　　3、 我們是否能讓程序員不那么容易犯這種普通的錯誤?

　　敏捷測試的挑戰之七：回歸測試

　　伴隨著頻繁的迭代，我們需要頻繁地重新測試，單元測試是不足夠的。我們怎樣有效地進行用戶層面的回歸測試呢?

　　你不一定需要在每次的迭代都做完整的回歸測試�？梢悦總�迭代運行一部分的測試。需要某種程度上的用戶層次的自動化回歸測試。

　　敏捷測試的挑戰之七：回歸測試工具

　　大部分的商業測試工具在敏捷環境下都不是很好用。大部分有這些缺點：

　　1、 指定的語言

　　大部分商業測試工具會指定某種語言，例如：WinRunner(TSL)、SilkTest(4test)、Robot(Test Basic)，但是一些新的工具也開始使用標準語言，例如：Astra QuickTest(VB Script)，XDE Tester(Java)

文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/