敏捷測試和傳統測試方法

4

沒有「敏捷測試」這樣的事情，但是通常作爲敏捷方法的關鍵組件提供的東西是unit testing，它早於敏捷。這與「傳統的結構化測試」有何不同，取決於你的意思。

在敏捷和單元測試的背景下可能會導致您的困惑的其他事情：Test driven development和continuous integration。

來源

2012-09-28 22:28:07 jrajav

+1

我完全同意。我會說沒有區別，因爲'敏捷'是一種合作態度。問題在於代碼是否編寫完成，然後投向質量保證部門以「他們和我們」的態度進行測試，或者是否有態度編寫能夠發揮作用的軟件並發現需要什麼。 –

+0

這與敏捷無關，更多與專業自豪感和良好的測試習慣有關。無論您是使用TDD還是CI，或者您的團隊是否敏捷，都應該確保代碼正常工作並且質量很好。 TDD和CI當然使這更容易！ – jrajav

1

一個敏捷項目通常會更加強調自動化測試，用於集成和驗收測試以及單元測試，因爲手動測試很快變得太慢而無法頻繁發佈。

TDD方式從「測試，以發現缺陷」走向「測試作爲設計技術」改變的重點。

的mindet可能非常不同 - 敏捷項目中使用測試，以實現快速重構與變革 - 你可以作出重大改變，而不用擔心因爲測試會告訴你什麼是工作。傳統項目害怕變化;他們的測試可能不會以相同的方式進行組織，並且可能會抑制變化。

來源

2012-09-28 22:35:56 DNA

+1

我並不完全同意[剛剛被刪除的評論！] - 我認爲TDD的主要好處是它會促使您編寫更多可測試的代碼。一般來說，更多可測試的代碼也是其他方式的更好的代碼。換句話說，可測試性不會與其他非功能性要求相沖突。它與他們和諧相處。 TDD *是在編寫使用該接口的代碼之前設計接口的一種方法。在紙上設計界面只能帶你到目前爲止，沒有不成比例的努力。 – DNA

1

這取決於，當然，你如何定義「傳統的結構化測試」和「敏捷測試」 ......

這是我一直傾向於與測試，以觀察其對最有效的敏捷團隊我已經看到。

沒有一個單獨的測試組。測試人員在開發團隊中工作 - 不能與其分開。
測試是一個持續的過程，在整個開發過程中都會發生 - 而不是在開發後的單獨階段發生。
測試由整個團隊完成，而不僅僅由測試人員完成。最明顯的例子就是TDD產生的測試 - 但它也發生在其他地方（例如，產品所有者經常參與幫助定義圍繞故事進行的更高級別驗收測試）。
測試人員是整個團隊測試的教育者和推動者，而不是控制所有測試的瓶頸。
測試人員和非測試人員之間的關係往往是更多的合作/合議而不是敵對。
通常我會發現測試人員在敏捷團隊中獲得更多尊重。
測試人員在此過程中涉及的時間更早，因此更容易確保生產的系統易於測試。

來源

2012-09-29 21:41:15 adrianh

+0

也許作爲一個補充：因爲在一個敏捷團隊中，您比傳統開發人員提供的次數要多，所以測試功能更加複雜。它們特別包括自動化任務以獲得更快的結果。 –

0

我要說的到，包括測試軟件的實際件可以是相當類似的。

最大的區別是，這樣你到達那裏。通常在敏捷的環境中，您可以快速處理生產相關性的小型開發工作。這可以是從一個月到兩週的任何時間。

這些小故事和更快的期限需要更多的重量輕的要求和更小的碎片的發展是由整個團隊決定。測試人員沒有時間花時間撰寫測試策略文檔。較小的迭代允許測試人員專注於僅測試。

鼓勵大家在同一頁面上通常會減少返工量。由於每個人都在研究較小的部分，通常軟件的構建和部署更頻繁。這導致對建造良好的CI環境的強烈關注。 CI是600頁的話題，所以我會留給你進一步研究。

對我來說，最大的不同在於團隊的心態。每個人都在一起合作發佈軟件。敏捷在消除開發者與測試者的距離方面做得很好。而不是爭論誰是過錯（測試不好，代碼不好，需求不好等）。小組一起工作來解決問題。公司必須通過消除缺陷計數或其他阻止團隊工作的統計數據來鼓勵這種情況自然發生。

來源

2012-10-01 01:17:24

0

您所遵循的方法論，產品質量的基本原理都是一樣的。從瀑布到敏捷的變化在於，測試在sprint的早期開始以及如何執行測試。隨着TDD等實踐的進行，測試的重點也有所改善。

從單元測試到系統測試和驗收測試，所有這些測試都以新的方式進行。例如：現在，在開發過程中，Tester可以參與像'show me sessions'這樣的會議，他可以提供早期反饋。

在sprint中工作已經促使我們在演示之前的每個週期和驗收測試中進行迴歸測試。所以事情如何從敏捷變爲瀑布（結構化測試）

來源

2012-11-28 09:28:14

敏捷測試和傳統測試方法

回答

相關問題