敏捷軟件測試常見的七個誤區

　　敏捷軟件開發是從1990年代開始逐漸引起廣泛關注的一種新型軟件開發方法，是能夠應對快速變化的需求的一種軟件開發能力，它作為一種新型的開發模式，被越來越多地應用到軟件項目中。

　　敏捷軟件測試指的是在敏捷軟件開發過程中跟質量相關的一系列活動，和傳統意義上的軟件測試有很多區別，因為敏捷軟件測試的概念一直比較模糊，所以經常會有人走入誤區，我曾經在瀑布型的軟件開發模式下做過幾年的測試人員，所以在剛剛接觸敏捷項目的時候也曾有過一些誤解，但是在敏捷軟件開發團隊工作將近 5年后，對很多問題有了新的認識，以下針對幾個常見的誤區和大家分享一下我的理解。

　　不需要測試策略

　　測試策略關注的是目標和方法，即怎樣在限定的時間內有效利用有限的資源達到提前制定的目標，一般制定測試策略時會首先明確測試目標，然后確定需要哪些測試類型，各種測試類型所占的大概比例，選擇測試框架，最后規劃一下軟件發布前需要經歷哪些測試階段。

　　很多人認為，敏捷軟件開發以用戶故事為單元，是不是集中精力在用戶故事測試就足夠了?是不是根本不需要考慮測試策略?

　　其實這是一個很大的誤解，因為敏捷軟件開發通常都是迭代式的發布，周期比較短，資源非常有限，這就更需要我們統籌規劃，小到一個用戶故事，大到一個完整的用戶特性，都需要考慮怎么合理利用測試資源，所以敏捷項目是非常需要測試策略的。

　　具體到實際項目中，通常團隊會在項目初期(迭代0)制定測試策略，明確目標(包括功能性需求的目標以及非功能性需求的目標)，然后確定在開發階段需要添加哪些自動化測試(包括單元測試，接口測試，契約測試，集成測試，系統級別的UI的用戶場景測試)，并規定這些測試的大概比率(符合測試金字塔)，選擇自動化測試框架(比如XUnit)以及需要哪些手動測試(包括探索性測試，可用性測試等)，還要規劃每個發布周期需要進行的測試階段(比如新功能測試，回歸測試等)，之后測試策略會對敏捷團隊的開發及測試起到非常重要的指導作用，當然，每個團隊因為項目的不同策略也會不同。

　　下圖就是一個簡單的敏捷測試策略介紹:

　　不需要測試文檔

　　測試文檔通常包括測試計劃，測試用例，測試報告，測試缺陷等文檔以及相對應的可以指導測試的一部分需求文檔。

　　很多人會認為，敏捷軟件測試是不需要文檔的，敏捷宣言中有一句“工作的軟件 高于 詳盡的文檔”，盡管敏捷宣言最后提到了“右項也有價值，我們更重視左項的價值”，但人們往往會忽視右項的內容，導致在很多剛開始實施敏捷開發的團隊中完全否定了測試文檔的作用。

　　首先不可否認，在實際的敏捷項目中，確實很少見傳統意義上的正式的專門的需求文檔和測試文檔，但這并不代表敏捷項目沒有文檔，比如用戶故事本身就是需求的載體，用戶故事中的驗收條件就是敏捷測試文檔的一部分， 另外很多敏捷軟件項目都會采用BDD的方式進行開發，將測試用例用業務人員能夠看懂的自然語言描述，并結合自動化實現，形成一個融需求和測試為一體的文檔，而且為了應對敏捷軟件測試變化快文檔更新不及時導致的問題，很多敏捷項目都在使用Living document。

　　純自動化測試 or 純手動測試

　　有些剛接觸敏捷的人認為敏捷軟件開發發布周期很短， 測試人員根本沒有時間做手動測試， 所以應該采用純自動化測試。

　　也有一些人認為，敏捷開發強調快速響應變化，如果投入成本在自動化測試上，那么肯定會導致維護自動化測試帶來的資源浪費，所以應該采用純手動測試。

　　這是兩種極端的誤解，雖然這兩種觀點所考慮到的難點確實存在， 因為在敏捷軟件開發過程中， 迭代通常比較短，確實不會預留足夠多的時間來做手動測試， 所以必須要有足夠多的自動化測試來保障。

　　然而因為測試代碼本身可能存在缺陷，而且有很多部分難以被自動化測試覆蓋(比如界面的測試，可用性測試，探索性測試等)，所以敏捷測試也同樣離不開手動測試。

原文轉自：http://insights.thoughtworkers.org/agile-testing-misunderstanding/?utm_source=tuicool&utm_medium=referral