測試老司機淺談軟體靈活測試是否寫測試用例？

件靈活測試是否寫測試用例

靈活測試是否寫測試用例?答案多種化如果是你，你會選用寫還是不用寫呢?

軟體測試時代風起雲湧，問題雖小，意義卻大，讓大家一起學習一起探讨!

經過大家的水深火熱的探讨答案出來了，但是各有各的想法各有各的不同，但我想他們的所想和所論對于大家都是有幫助的，大家可以看一下這個讨論題，希望在技術上能幫到大家一些。

LoveTT ： 我覺得靈活測試不需要寫測試用例;

所謂靈活，就是要快準狠，快速的找到系統中存在的問題，高效率的完成測試任務!

誰來跟我辯論?

傲氣淩雲 ： 我認為需要寫，因為所有的用例都是人類靠思維來編寫的，不是憑空出現的。就算是靈活性測試，也是需要記錄的。

tigerbbs ： 在靈活開發中，測試管理者不可能像傳統的項目測試一樣制定詳細的測試計劃，那怎樣執行測試呢?以下是我總結的一些瑣碎經驗： 在靈活開發中整個團隊都是測試人員，一起需要對産品品質負責，測試管理人員需要指引大家共同測試，需要發動起大家一起執行測試，而不僅僅是測試人員的事情，這同時也要求整個團隊中每個成員對自己的産品了如指掌，測試人員需要共同參與産品的設計和需求分析，在靈活開發中需求在不斷變化，你不可能等着完整的需求文檔進行測試需求分析，當産品定義和需求不斷的細化時，測試分析也要不斷的細化，我很喜歡讓測試人員去繪制業務流程圖，以及整理功能清單進行測試分析，因為在繪制業務流程圖中你可以發現很多的邏輯問題，和産品定義問題，可以即時的和産品定義人員、需求人員進行溝通，立馬改進産品設計，靈活測試中，根據業務流程圖或測試分析圖書寫主要測試用例就行了，你根本就沒有時間能面面俱到去維護那麼的測試用例，更何況需求和産品定義一直在變化一定要自動化測試，自動化測試腳本中要寫好注釋，這是測試用例的展現，也便于讀取在測試之前制定好測試方案，但測試執行的時間很難控制，一定要熟知資料庫。

LoveTT ： 樓上的傲氣淩雲 有點狡辯了，混淆視聽，人類的精髓很多，馬克思主義毛澤東思想，都是人類的精華，但是這些老前輩都還說，具體問題具體分析呢，而你一概而論，我覺得站不住腳!我覺得閣下還是好好看看什麼是靈活開發，和靈活測試再來發表見解吧!否則贻笑大方就不好了!

test110 ： 肯定得寫哈，那是測試的依據。

靈活宣言：

個體和互動比過程和工具更有價值;

能工作的軟體比全面的文檔更有價值;

顧客的協作比合同談判更有價值;

及時響應變更比遵循計劃更有價值。

并非每個企業都能嚴格按靈活的相關開發方法進行項目管理，例如測試驅動、XP、SCRUM等。也并非都需要按這些方式管理才能實作靈活。隻要我們了解了靈活的原則和精髓，我認為很多方法、很多地方都可以應用靈活的思想，實作靈活的管理。

測試用例的設計是其中一項。

測試用例的粒度

測試用例可以寫得很簡單，也可以寫得很複雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的内容，如探索性測試(Exploratory Testing)中的測試設計，僅會指出需要測試産品的哪些要素、需要達到的品質目标、需要使用的測試方法等。而最複雜的測試用例就像飛機維修人員使用的工作指令卡一樣，會指定輸入的每項資料，期待的結果及檢驗的方法，具體到界面元素的操作步驟，指定測試的方法和工具等等。

測試用例寫得過于複雜或過于詳細，會帶來兩個問題：一個是效率問題，一個是維護成本問題。另外，測試用例設計得過于詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思維。

測試用例寫得過于簡單，則可能失去了測試用例的意義。過于簡單的測試用例設計其實并沒有進行“設計”，隻是把需要測試的功能子產品記錄下來而已，它的作用僅僅是在測試過程中作為一個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。測試用例的設計的本質應該是在設計的過程中了解需求，檢驗需求，并把對軟體系統的測試方法的思路記錄下來，以便指導将來的測試。

大多數測試團隊編寫的測試用例的粒度介于兩者之間。而如何把握好粒度是測試用例設計的關鍵，也将影響測試用例設計的效率和效果。我們應該根據項目的實際情況、測試資源情況來決定設計出怎樣粒度的測試用例。

軟體是開發人員需要去努力實作靈活化的對象，而測試用例則是測試人員需要去努力實作靈活化的對象。要想在測試用例的設計方面應用“能工作的軟體比全面的文檔更有價值”這一靈活原則，則關鍵是考慮怎樣使設計出來的測試用例是能有效工作的。

基于需求的測試用例設計

基于需求的用例場景來設計測試用例是最直接有效的方法，因為它直接覆寫了需求，而需求是軟體的根本，驗證對需求的覆寫是軟體測試的根本目的。

要把測試用例當成“活”的文檔(Effective Software Testing ： 50 Specific Ways to Improve Your Testing – Elfriede Dustin)，因為需求是“活”的、善變的。是以在設計測試用例方面應該把靈活的“及時響應變更比遵循計劃更有價值”這一原則。

不要認為測試用例的設計是一個階段，測試用例的設計也需要疊代，在軟體開發的不同的階段都要回來重新審視和完善測試用例。

測試用例的評價

測試用例設計出來了，品質如何，如何提高測試用例設計的品質?就像軟體産品需要通過各種手段來保證品質一樣，測試用例的品質保證也需要綜合使用各種手段和方法。

測試用例的檢查可以有多種方式，但是最靈活的應當屬臨時的同行評審。我認為同行評審，尤其是臨時的同行評審，應該演變成類似結對程式設計一樣的方式。進而展現靈活的“個體和互動比過程和工具更有價值”，要強調測試用例設計者之間的思想碰撞，通過讨論、協作來完成測試用例的設計，原因很簡單，測試用例的目的是盡可能全面地覆寫需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在局限性。是以需要一起設計測試用例。

除了同行評審，還應該盡量引入使用者參與到測試用例的設計中來，讓他們參與評審，進而展現靈活的“顧客的協作比合同談判更有價值”這一原則。這裡顧客的含義比較廣泛，關鍵在于你怎樣定義測試，如果測試是對産品的批判，則顧客應該指最終使用者或顧客代表(在内部可以是市場人員或領域專家);如果測試是指對開發提供幫助和支援，那麼顧客顯然就是程式員了。

是以，參與到測試用例設計和評審中來的人除了測試人員自己和管理層外，還應該包括最終使用者或顧客代表，還有開發人員。

測試用例資料生成的自動化

在測試用例設計方面最有希望實作自動化的，要當屬測試用例資料生成的自動化了。因為設計方面的自動化在可想象的将來估計都很難實作，但是資料則不同，資料的組合、資料的過濾篩選、大批量資料的生成等都是計算機擅長的工作。

很多時候，測試用例的輸入參數有不同的類型、有不同的取值範圍，我們需要得到測試用例的輸入參數的不同組合，以便全面地覆寫各種可能的取值情況。但是全覆寫的值域可能會不可思議地廣泛，我們又需要科學地篩選出一些有代表性的資料，以便減輕測試的工作量。在這方面可利用正交表設計資料或成對組合法設計資料。

可利用一些工具，例如TConfig、PICT等來産生這些資料。

在性能測試、容量測試方面，除了設計好測試用例考慮如何測試外，還要準備好大量的資料。大量資料的準備可以使用多種方式：程式設計生成、SQL語句生成(基于資料庫的資料)、利用工具生成。

工具未必能生成所有滿足要求的資料，但是卻是最快速的，程式設計能生成所有需要的資料，但是可能是最複雜、最慢的方式。是以應該盡量考慮使用一些簡單實用的工具，例如DataFactory等。

seanhe ： 先抛觀點：需要寫測試用例

先看測試用例是什麼，也就是我們打算進行的測試執行的具體内容

測試用例可以分級别：如大綱型、方案型、具體操作資料型，但是根本一點就是要使測試過程有序的進行，盡量少做無必要的重複。

靈活宣言是什麼?擁抱變化

擁抱變化不代表着雜亂無章，代碼即文檔，不代表着代碼沒有注釋，所有人都靠代碼去看邏輯。

靈活下測試是需要規劃的，用例是需要書寫的，但是書寫的用例并不應該是我們通常意義上非常詳盡的測試用例，而可能演變成單元測試架構或者功能自動測試架構，或者測試大綱。

總之，測試過程是需要規劃的，在有效規劃的前提下，盡量少的做無用工作

LoveTT ： 樓上的Test110寫了很多關于測試用例設計的東西，寫道粒度問題!我不知道這些你是從哪裡抄來的，但是我覺得用例這樣寫沒有問題，但是靈活測試作為一種特殊的測試類型如”tigerbbs“所說 因為靈活開發和測試的快捷性和多變性，導緻測試的設計變得困難，或者根本就沒辦法實作”你根本就沒有時間能面面俱到去維護那麼的測試用例，“正如文章中提到，是以我覺得樓上的論據站不住腳，如果說一般的測試類型，應該沒有問題的!

魅力彩虹 ： 我認為測試用例是一定要的，沒有用例怎樣做到快和準?請問LOVETT一個系統中你能記住那裡測過那裡沒有測過?等到新的版本出來，恐怕就會亂套了吧，何來快準狠?靈活有從何展現?

test110 ： CASE也有簡單和複雜呀~~`針對不同的項目也可以具體考慮的，但是肯定是必須寫的

LoveTT ： 樓上的說道用例設計過程中的跟蹤，說道那些是測試了那些是沒有測試，這個我們完全可以通過功能點，或者流程圖等跟蹤方式進行跟蹤，隻要我所有的需求被覆寫被測試，就可以了!

shinnoshi ： 靈活測試需要寫測試用例，既然是靈活測試，就應有與其相襯的靈活測試用例。

靈活測試同樣需要合理的分析，快速、準确并不應建立在毫無條理的測試中。靈活不是抛棄所有隻注重效率。

test110 ： 其實我們在這裡說的都是理論的，老大弄個模拟環境吧 我們實際做下就得了的 我很現實的，實踐才是真知

LoveTT ： 樓上的又在教條主義，和本本主義，你為什麼說測試必須寫測試用例呢!

另外靈活測試作為一種快速的測試方式，我們沒有必要把時間花費到用例設計的過程中，但是我們當然需要設計，但設計的不是測試用例，而是細化的需求!

test110 ： 設計case都是測試流程中的一部分的，我們平時測試項目也是按照流程去測試的，也就是說流程制約着我們去測試的，如果我們把測試流程做得很細化了的，那我們的測試就是很精确的，我們得一步一步的走，設計case必須是測試流程中的一部分

實際還有一個問題的，就是時間!我們在前期就把時間放在case的設計上的，到我們實際測試的時候就會節約很多時間的;如果你一邊測試一邊在自己大腦中設計case肯定會浪費時間的，而且還會造成自己和項目組内的人一種緊張的氣氛。 大家可以對比下的，case在前期設計和在測試過程中設計，那個更節約時間!那個 效率更高的

pi_pi ： 個人覺得不管是為了告訴上司你做了那些東東，還是自己記錄分析自己的測試思路和政策也好，暫且不管用例的簡易複雜程度有多少，這個用例肯定是需要寫的。

魅力彩虹 ： 沒有用例的測試是不可行的，首先你的測試是不是有效的驗證了需求呢?要有一個測試的執行步驟和執行資料，通過評審之後才能夠成為可行的測試。否則隻是個人進行的測試怎樣判定是系統真的有缺陷還是測試的過程或測試的了解存在問題?總不能等到發現問題後再來讨論測試步驟及測試資料你是否合理吧?即使可以，又怎樣能夠正确的描述出當時的操作步驟呢?

angel0527 ： 在對一個系統進行測試之前，都會去找測試點，再從測試點整理出測試用例。隻是所整理使用者的簡單複雜程度不同。

如果不去整理測試用例，就沒有辦法明确是否将該進行測試的點都已經測試完。有可能會做許多重複的工作。這樣就談不上靈活了。

shinnoshi ： 如果說沒有必要寫測試用例，其實最終想說的就是時間，寫測試用例需要時間，需要大量的時間。

其實不然，清晰的了解需求，用簡潔的語言，可以是符号語言，從代碼級出發，與開發同步，直到最終的元件完成。如果說你在開發人員寫代碼的時候都無法利用，那你所謂的時間真的很不夠。随着開發的繼續，反複的回歸測試，如若不是記憶力超群，測試已經達到什麼程度，你能給出一個準确的答案嗎?

https://edu.csdn.net/course/detail/27231

　　LoveTT ： 請16樓的朋友注意，你說的一你們平常的工作，第一點，你們做的不是靈活開發，當然你們也不是靈活測試，你們按部就班沒有問題，但是我們今天的辯題是”靈活測試“作為現在一個新的概念，或者一種新的方法，正在為大家研究，是以你的經驗主義不值得一提

LoveTT ： 一看你就是科班出身，是做品質管理的吧! 什麼事情都看得這個規矩，我覺得規矩沒有錯，但是規矩制約了發展就是錯誤了，你所謂的評審，稽核

LoveTT ： 一看你就是科班出身，是做品質管理的吧!

什麼事情都看得這個規矩，我覺得規矩沒有錯，但是規矩制約了發展就是錯誤了，你所謂的評審，稽核，在一般的測試過程中是沒有問題的，而在靈活測試過程中，他的測試團隊覆寫面很廣，可以快速的識别問題并且修改問題，要是等待你的評審恐怕黃花菜都涼了!

魅力彩虹 ： 樓上LOVETT的觀點我不同意，你老說這個教條，那個是平時的工作，不是做靈活測試。那請問一下你做過靈活測試嗎?你的觀點依據又是什麼呢?

LoveTT ： 根據我這個測試新手孜孜不倦的學習，倒是接觸過一些，記得前幾天IBM剛開了一個什麼大會好像這個論壇中也有報道，我演戲了他的整個靈活開發的過程，以及他的品質控制方法，是以我以此為依據說出上述論斷，大家要是有争議，可以看IBM關于靈活開發的文章

魅力彩虹 ： 評審用例不僅是規矩的問題，用例不去評審就盲目的執行，怎樣保證執行的正确性?發現了BUG怎樣反應給開發人員?有些用例你認為覆寫了需求，你有怎樣知道自己執行的用例真正展現了需求的定義?如果根據個人臨時在大腦中想到的用例來測試系統，測試的有效性和以展現

LoveTT ： 《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》

大家可以看一下這個兩本書!

是以我覺得靈活測試有沒有設計測試用例，要不要評審，這個是兩個概念，樓上的跑題了

傲氣淩雲 ： 但是在你工作中，你可以這麼做嗎?即便是公司就你一個測試人員，也是需要編寫測試用例的。同樣，也就伴随着評審等一系列活動。

shinnoshi ： 靈活是少文檔，少流程，多溝通，使開發與測試更加緊密。不是不需要文檔，不需要流程，不需要測試用例。

請問你提及的測試通過，開發完畢是用什麼來衡量的?

ash ： 靈活的不是反文檔的。

測試用例最終生成也會以文檔資料方式存在，并且是顯性知識，是可以傳播、共享和繼承的。(不清楚看下面解釋)

我們應該清楚文檔的本質是把知識顯性化。在一個項目中存在很多需要溝通的知識，知識具備兩種形态，顯性的和隐性的，傳統的觀念是盡量把隐性知識顯性化，即文檔化，而忽略了這其中的代價(特别是更新同步文檔的代價)。

是以，在實施靈活的時候，需要在團隊内明确哪些知識是必須顯性的，這些知識可以通過文檔交流。哪些知識是可以隐性的，這些知識則完全可以通過口頭的方式進行交流，以達到溝通的最佳效率。

new.bug ： 個人覺得，靈活測試隻是相對而言的，比如讓你測試一個比較複雜的系統，功能很多，那你說不用測試用例怎麼比較有條理的進行測試?

如果你覺的文章閱讀不過瘾，可以檢視詳細的視訊教程

【軟體測試全棧系列課程】請點選我哦…

 https://edu.51cto.com/course/25359.html

【部落客完整視訊課程系列】請點選我哦…

 https://edu.51cto.com/lecturer/13226632.html

【JMETER基礎和實踐課程】請點選我哦…

 https://edu.51cto.com/course/28017.html

【JMETER 性能測試基礎與項目實戰視訊課程】請點選我哦…

 https://edu.51cto.com/course/16055.html

【Jmeter+ant+jenkins接口層性能與自動化測試課程】請點選我哦…

 https://edu.51cto.com/course/19323.html

【零基礎新手入門軟體測試基礎課程】請點選我哦…

 https://edu.51cto.com/course/27846.html

【軟體測試之移動端測試系列課程】請點選我哦…