敏捷測試的挑戰

什么是敏捷開發？         敏捷開發是遞增式的、迭代的、不斷調整的開發模式。我們逐漸地建立起軟件系統，能看到系統在成長，能展示進度。通過多次發布或項目的階段檢查點，每一次都比上一次靠近目標。迭代包括需求的開發和測試，典型的迭代周期是2周。目標隨著從上一次的迭代中學到的東西、反饋以及商業機會而調整。           在敏捷開發中，工作被分解成“故事”，也叫特性或用例，組合成任務分派給不同的程序員。定義好接受標準，開發直到單元測試和接受測試通過才算完成。           敏捷開發講求合作，結對進行編程，避免個人擁有專門的知識，代碼屬于項目組共有。           在敏捷開發中不存在回退，講究持續地集成，單元測試（通常使用測試驅動的開發方式），持續地進行回歸測試。   為什么以前的開發模式不再適用？         以前的開發模式要求有詳細的測試計劃，但是缺乏足夠的時間來寫，而且測試計劃受很多因素的影響經常改變。           以前的開發過程會專門留出一個階段來測試，但是你不能定義進入和退出的標準，測試階段會隨之而過。           以前的開發模式強調變更控制，但是現在的軟件需求變更非常頻繁，變更成了家常便飯。           以前的開發模式要求測試要對軟件做出權威的判斷，但是測試很難做出權威的關于軟件正確性的判斷。   測試的作用         有價值的東西有么提供產品，要么提供服務。那么測試提供什么產品或服務呢？有人認為測試提供調試通過的、經過測試的軟件。這是錯誤的回答。測試不提供產品，測試提供信息，關于開發過程中的軟件的狀態的信息，以便基于這些信息做出決定。   敏捷測試的挑戰之一：測試員是否不再需要了？         既然有開發人員做單元測試了，我們還需要測試員嗎？有些項目團隊采用了敏捷開發方式后把測試員都給解雇了，然后過了不久他們就后悔了。         測試可以是除QA或測試員外的人來做，例如業務分析員，有些項目團隊讓開發人員來做接受性測試。           但是有專門的測試員帶來兩個好處： 1、 專注于用戶使用而不是軟件的技術實現 2、 專注于發現軟件的錯誤而不是證明完整性   敏捷測試的挑戰之二：測試不完整的軟件         頻繁的迭代產生的測試版本很多時候是不完整的，測試員如何測試這些不完整的代碼呢？           “故事”應該從業務價值方面來定義。一個“故事”應該在一個迭代周期內完成。好的“故事”是不容易定義出來的，但是差的故事對測試人員的影響比對開發人員的影響還要大。有時候測試人員需要幫助定義“故事”。   敏捷測試的挑戰之三：可接受性測試是否過于簡單了？         測試人員如果只是做可接受性測試，只是驗證“故事”是否完整，豈不是太簡單了？這樣怎么能做好測試呢？           其實，每一個迭代都需要額外的測試，而不僅僅是局限于驗證“故事”的完整性。                    在迭代測試中還要按需進行下面類型的測試 ：         探索性測試：同時學習系統、計劃和執行測試，尋找bug、遺漏的特性和改進的機會。         組合交互測試：專注于特性之間的交互。         場景測試：模擬真實世界的場景進行測試。         疲勞測試：長時間地執行軟件         業務循環測試：基于月末、季度末等業務循環的邊界來執行場景         壓力測試：對系統施加強大的壓力進行測試   敏捷測試的挑戰之四：把測試員作為項目組的一部分         把測試員作為項目組中的一員不是犧牲了他們作為一個組織的完整性嗎？           測試員一直被認為是受壓迫的對象，經常坐在一起互相訴苦、互相支持?，F在是時候結束這種情況了。測試員應該跟開發人員和分析師坐在一起，當項目組中有更多的正式或非正式的溝通時才有可能達到敏捷。   敏捷測試的挑戰之五：測試什么時候完成？         沒有專門分配的時間來完成測試，我們怎么知道什么時候測試應該結束？         敏捷測試員需要根據項目和產品的風險來調整測試?；旧蠝y試的優先級應該跟“故事”的優先級一致。BUG列表也提供了測試完整性的提示。           一個好的測試員是永遠都能找到需要完成的測試來做的。           為什么需要跟開發人員結對進行測試呢？因為開發人員對潛在的錯誤有一定的洞察力，測試員對約束和錯誤的時機有一定的洞察力。而他們在一起能使自動化測試更加成功。           測試員應該自動化可接受性測試，使用與開發環境一樣的編程語言來編寫可接受性測試的代碼，重用單元測試的框架，使軟件更加可測。           利用“灰盒”測試。設法弄清楚系統各模塊之間的關系，分析變更的影響，看什么是需要測試的，什么是可以不測試的。弄清楚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.stickyminds.com/se/S2326.asp 2、 與源代碼控制的結合不好
        很多工具沒有與源代碼控制工具集成，使用臨時文件和目錄（WinRunner），
        關鍵信息存儲在Repositories中，例如Rational 3、 很難與持續集成配合使用
        缺乏外部調用的API，不允許作為一個庫被使用，因此很難與持續集成整合在一起。一些新的工具則有所改進，例如TestComplete 4、 不能在所有機器上部署（受License限制）
        受限制的、昂貴的License，使得很多開發人員不能例如工具運行測試         這些問題使得他們對于整個團隊來講不夠實用。敏捷團隊傾向于構建自己的測試工具和利用開源工具。開源測試工具
        現在已經出現很多開源的測試工具，支持windows、Java、Web等平臺，現在大部分都集中在web平臺，例如:HttpUnit、WTR等。

原文轉自：http://www.anti-gravitydesign.com