 |
VOOZH | about |
|
VOOZH | about |
對于敏捷 測試 ，可定義如下：
項目中使用敏捷技術的相關測試實踐， 開發 作為測試的顧客，強調測試先行的設計理念。在敏捷 開發 中，測試被整合到整個開發的生命周期中。
敏捷測試
敏捷將被越來越多的人所接受，這很容易理解，如果從開發者和用戶的角度去看的話。
對於用戶，他們不願意花費大量的時間被人盤問關於整個系統的 需求 和過程，而且需要評審大量的規格說明，而且開發團隊可能會在後期拿著這些規格說明來與他們"對質"。
對於開發人員，他們希望發揮自己的想像空間和創意，不願意遵循規格說明的約束，尤其是在他們看到有更好的解決方案的時候。
然而，對於QA人員來說，敏捷意味著什麼呢?敏捷會給他們帶來諸多不便。在理想的世界裡，他們會獲取一個"已完成"的產品來針對規格說明進行驗證。現實中，他們被要求對"正在移動"的目標進行驗證，這是違背直覺的。這意味著一些技術和 自動化 的使用變得困難，需要新的測試方式。
所有敏捷方法都有一個共同點，就是它們對QA角色造成影響。
隨著TDD(Test Driven Development)的出現，有人開始質疑QA存在的必要性(既然TDD的關鍵就是測試)。但是，最重要的問題是QA需要直接全程參與到敏捷過程中，作為團隊的整體對測試進行設計，與此同時，需要應對需求和解決方案的不斷演變。
QA需要知道敏捷方法論的真正影響，對業界關于敏捷測試的各種"神話"作出正確的詮釋和回應，以下列舉了10大著名的"神話"：
神話1："你只需要單元測試就行了—TDD的測試是足夠的"
這顯然是不對的。即使是狂熱的敏捷開發者也意識到需要包括很多其他的測試技術。例如，Scott W . Ambler就在他的FLOOT(Full Life Cycle -Oriented Testing)方法論中列舉了21種不同的測試技術，包括 白盒 測試、黑盒測試、 回歸 測試、壓力測試和用戶驗收測試(User Acceptance Testing。
TDD中的程式設計師依賴這些測試來驗證他們代碼的正確性。如果需求(或者說 測試 用例 )沒有被正確地描述，那麼你可能構建了足夠健壯的代碼，但是不能滿足目標。
因此，大部分敏捷項目包括調查性質的測試(黑盒)，用於補充白盒的測試。好的調查性質的測試能儘早揭露開發人員遺漏的問題。
神話2："你可以重用單元測試來構建回歸測試套件"
有些TDD的追捧者提出傳統的測試不再需要，因為每一行代碼都有相應的單元測試用例了;他們認為，通過重新組合單元測試，可以替代從用戶驗收測試到回歸測試的所有測試類型。
雖然這聽起來很誘人，但是這不現實，因為：TDD中開發的白盒的單元測試的粒度和目標與黑盒測試有所區別。
單元測試的總體目標是用於證明代碼是如預期般工作的，而回歸測試的目的是確保修改的代碼不會引起非預期的結果。兩者存在的意義是不一樣的，例如，"檢查某個屬性的日期格式是正確的"，就與"對於給定的輸入，檢查其值具有預期的日期"不一樣。
神話3："我們不再需要 測試人員 、或者自動化工具"
專業的測試人員履行了不一樣的職責，與開發同僚們一樣是不可或缺的項目組角色之一。
不得不承認：傳統的自動化測試工具並沒有像廠商們所鼓吹的那樣神奇。但是這不意味著我們要放棄自動化工具，我們仍然期待更多更好的自動化工具的出現。
神話4："有了單元測試，手工測試就沒有存在的必要性了"
手工測試時重複性的勞動，代價高、繁瑣、容易出錯。然而，雖然TDD能減少一定量的手工功能測試，它並不能廢除進一步的黑盒測試的需要(無論是手工的還是自動化的)。
通過自動化的捕獲測試人員的操作過程，並且將他們的鍵盤和滑鼠點擊事件文檔化，測試人員可以把更多的時間放在有趣的、增值的活動上，例如測試那些自動化很難實現，或者是根本不可能實現的複雜測試場景。雖然通過手工測試尋找 bug 是一個耗時的、代價高昂的過程，但是如果不採用這種手段而遺漏了 BUG ，代價會更高。
神話5："不再需要用戶驗收測試"
在敏捷開發中，用戶驗收測試通常用於與顧客一起解決"不正確的需求"的問題，而不是用於糾正功能問題。
當用戶最初定義需求時，他們是基於自己的初始想法和願景來定義的。當他們看到"活生生的"真正的系統後，他們總是會有不同的、額外的需求。雖然敏捷方法可以減少這種情況發生的頻率，但是也不可能杜絕，因此也就不可避免地需要用戶驗收測試。
神話6："自動化是不可能的"
在敏捷項目的早期階段開展自動化測試通常是很困難的，但是隨著系統的演進，某些方面穩定下來之後就可以開始實施自動化測試了。
洞悉自動化測試開展的正確時機並不容易，因此，使用某些技術，讓早期的手工測試可以順利過渡到自動化測試是很關鍵的。如果早期的測試設計和手工測試可以被很好地記錄下來，以備重用的話，後面的自動化測試將大大受益。
神話7："開發人員擁有足夠的測試技巧"
如果測試是很容易的，那麼每個人都可以做，則每次我們都可以發布和交付優質的代碼。一個獨立的測試組的目標是作為第三方、能夠從全局出發、驗證和確認軟體功能的質量。而開發人員趨向於證明系統是正常工作的。一個好的測試者會傾向於"假設"某些場景的出現，再加上業務用戶的測試，則確保系統滿足預期目的將變得容易。
雖然可能引起很多開發人員的爭辯，但是事實上很多開發人員不願意花很多時間去先寫測試，然後開發代碼來證明測試通過了。
神話8："單元測試就是設計規格說明書"
無論你採用哪一種開發模式，在開發代碼之前你都必須對需求進行思考。雖然TDD的單元測試產物可以讓我們理解相當一部分的設計規格說明，但是仍然存在差距。
定義測試用例用於檢查需求並不是新鮮事。不管你採用的是什麼開發模式，最重要的是針對每一項需求提出這樣的問題"我將如何測試它？"，這樣你的測試用例是在落實到代碼之前就被充分考慮過的，而不是等待將來的"重構"。
神話9："TDD適用於任何項目"
隨著項目規模的擴大，執行測試所需要的時間也在增加。這可以通過劃分項目和測試範圍來解決。但是無論如何都會導致測試運行的頻率不一致，這樣就需要測試的計劃和測試執行的管理，因此，除了白盒測試，我們還需要考慮以下幾種測試：
集成測試 - "我需要運行哪些測試來確保新的代碼與其關聯的代碼有效地工作在一起？"
系統測試 - "新的代碼在系統層面的功能是夠正確，與其他系統工作在一起的流程是否正確?"
回歸測試 - "我需要隔多久運行一次回歸測試來確保新的代碼沒有造成非預期的影響？"自動化的回歸測試為敏捷開發提供了一張安全網。
用戶驗收測試- "TDD不僅需要確保某項功能正確地工作了，還要確保它們對於業務用戶來說是可接受的。"
然而，隨著項目組的擴大，測試的"自我文檔化"（self-documenting）不再可接受，因為參與的項目組成員越多，不同的人對需求的不同理解，項目的風險隨之增加。
隨著項目規模增加，需要開發的測試代碼也大大增加，測試代碼的維護工作量也大大增加，對測試自動化的需求也在增加，需要更多的自動化測試用於縮短每個測試周期的時間。
神話10："開發人員和測試人員是水火不相容的"
長久以來，開發和測試之間存在"你我之分"的緊張局面。這其實會是一種"共生共贏"的健康關係，如果能很好地一起正確地工作的話，這種關係可以為顧客產生更高的產品交付質量。
討論的焦點應該集中在：
交付的軟體需要滿足業務目標（滿足需求、按時、控制成本），而不是討論誰擁有哪一部分流程的權責問題。
測試人員在需求收集階段可以做出什麼貢獻？如何讓他們更好地融入到TDD的過程中。
測試人員如何最大化地重用開發過程中產生的各項"資產"？
在TDD中是否有一個"傳統測試人員"的角色？或者他們是否需要像開發人員一樣掌握新的技術來適應新的開發模式？
在新的開發和測試工具中，開發人員和測試人員如何互相找到自己需要的東西？
結論
敏捷項目其實是QA領導敏捷過程的一個絕佳機會；誰是用戶和開發者之間的最佳橋樑，能理解各方面的需要，如何達成以及如何在開發之前就得到保證？
QA除了繼續在確保整個系統的演進滿足業務目標和需求外，應該對"如何"和"結果"兩方面都投入自己的興趣。但是這同時對QA提出了新的要求，他們必須自己"敏捷"起來，拋棄舊的模式，專注於應用新的技術來優化測試的策略。
本文轉自：光環國際