LoveTT : 樓上的Test110寫了很多關于測試用例設計的東西,寫道粒度問題!我不知道這些你是從哪里抄來的,但是我覺得用例這樣寫沒有問題,但是敏捷測試作為一種特殊的測試類型如”tigerbbs“所說 因為敏捷開發和測試的快捷性和多變性,導致測試的設計變得困難,或者根本就沒辦法實現”你根本就沒有時間能面面俱到去維護那么的測試用例,“正如文章中提到,所以我覺得樓上的論據站不住腳,如果說一般的測試類型,應該沒有問題的!
魅力彩虹 : 我認為測試用例是一定要的,沒有用例怎樣做到快和準?請問LOVETT一個系統中你能記住那里測過那里沒有測過?等到新的版本出來,恐怕就會亂套了吧,何來快準狠?敏捷有從何體現?
test110 : CASE也有簡單和復雜呀~~`針對不同的項目也可以具體考慮的,但是肯定是必須寫的
LoveTT : 樓上的說道用例設計過程中的跟蹤,說道那些是測試了那些是沒有測試,這個我們完全可以通過功能點,或者流程圖等跟蹤方式進行跟蹤,只要我所有的需求被覆蓋被測試,就可以了!
shinnoshi : 敏捷測試需要寫測試用例,既然是敏捷測試,就應有與其相襯的敏捷測試用例。
敏捷測試同樣需要合理的分析,快速、準確并不應建立在毫無條理的測試中。敏捷不是拋棄所有只注重效率。
test110 : 其實我們在這里說的都是理論的,老大弄個模擬環境吧 我們實際做下就得了的 我很現實的,實踐才是真知
LoveTT : 樓上的又在教條主義,和本本主義,你為什么說測試必須寫測試用例呢!
另外敏捷測試作為一種快速的測試方式,我們沒有必要把時間花費到用例設計的過程中,但是我們當然需要設計,但設計的不是測試用例,而是細化的需求!
test110 : 設計case都是測試流程中的一部分的,我們平時測試項目也是按照流程去測試的,也就是說流程制約著我們去測試的,如果我們把測試流程做得很細化了的,那我們的測試就是很精確的,我們得一步一步的走,設計case必須是測試流程中的一部分
實際還有一個問題的,就是時間!我們在前期就把時間放在case的設計上的,到我們實際測試的時候就會節約很多時間的;如果你一邊測試一邊在自己大腦中設計case肯定會浪費時間的,而且還會造成自己和項目組內的人一種緊張的氣氛。 大家可以對比下的,case在前期設計和在測試過程中設計,那個更節約時間!那個 效率更高的
pi_pi : 個人覺得不管是為了告訴領導你做了那些東東,還是自己記錄分析自己的測試思路和策略也好,暫且不管用例的簡易復雜程度有多少,這個用例肯定是需要寫的。
魅力彩虹 : 沒有用例的測試是不可行的,首先你的測試是不是有效的驗證了需求呢?要有一個測試的執行步驟和執行數據,通過評審之后才能夠成為可行的測試。否則只是個人進行的測試怎樣判定是系統真的有缺陷還是測試的過程或測試的理解存在問題?總不能等到發現問題后再來討論測試步驟及測試數據你是否合理吧?即使可以,又怎樣能夠正確的描述出當時的操作步驟呢?
angel0527 : 在對一個系統進行測試之前,都會去找測試點,再從測試點整理出測試用例。只是所整理用戶的簡單復雜程度不同。
如果不去整理測試用例,就沒有辦法明確是否將該進行測試的點都已經測試完。有可能會做許多重復的工作。這樣就談不上敏捷了。
shinnoshi : 如果說沒有必要寫測試用例,其實最終想說的就是時間,寫測試用例需要時間,需要大量的時間。
其實不然,清晰的了解需求,用簡潔的語言,可以是符號語言,從代碼級出發,與開發同步,直到最終的組件完成。如果說你在開發人員寫代碼的時候都無法利用,那你所謂的時間真的很不夠。隨著開發的繼續,反復的回歸測試,如若不是記憶力超群,測試已經達到什么程度,你能給出一個準確的答案嗎?
LoveTT : 請16樓的朋友注意,你說的一你們平常的工作,第一點,你們做的不是敏捷開發,當然你們也不是敏捷測試,你們按部就班沒有問題,但是我們今天的辯題是”敏捷測試“作為現在一個新的概念,或者一種新的方法,正在為大家研究,所以你的經驗主義不值得一提
appoint : 測試肯定要用到測試用例。敏捷開發是靠測試來驅動開發,測試通過了開發就完成了。所以支持正方觀點
原文轉自:http://www.uml.org.cn/Test/20112235.asp