? ? ? ? 網上查找了很多關于測試用例重要性的文章，答案都不盡人意要么太理論化了，讓人看了顯得生硬，看完一頭霧水；要么太過時了（不知道停留在那個年代的認識）。筆者很想系統的認識一下測試用例，所以寫了這篇文章：

軟件測試的工作，都少不了寫用例的時候，我想大部分的用例都是在產品需求出來一部份之后就已經開始了，因為這個時候，已經有了寫測試用例的依據。有了大致需求之后對編寫用例來說一般只是一個開始，我們還需要更多的信息，比如UE（用戶交互設計稿）、UI（用戶界面設計圖）、需求的描述、產品大綱，功能模塊圖來提供更多的信息來完善用例。往往產品在開始設計的時候，正是用例生命周期的開始。為什么這么說呢，在以下的文章當中，我們讓他慢慢的浮現出來：

? ? ? ? 我們有時候很困惑，為什么要寫測試用例，測試用例對后來的測試到底起到了什么作用？有時我們甚至懷疑，項目測試中是否需要測試用例。好，我先舉個測試用例的運用場景。

? ? ? ? 假設，這里新成立了一家新公司叫“豆比科技”，他們自己設計了一款軟件產品“逗你妹”。產品的需求，用戶交互，設計圖，各個功能模塊的詳細描述都有了，產品開始投入到開發當中。而開發好的產品肯定是有很多問題的，必須要又人來保障產品的質量。

? ? ? ? 那么誰來保障產品的質量呢，首先，產品可以做這事，因為產品是他們設計的，他們需要對產品負責，但是產品們都很忙，因為他們需要制定產品的戰略規劃，功能的設計等；設計可以做這事，因為UI是他們設計的，他們對UI最了解，但是設計們也很忙，因為他們需要更多的時間來調整UI；開發們也可以做測試，因為產品是他們開發的，有什么bug他們第一時間知道，但是開發們也很忙，他們在忙著實現各種復雜的功能模塊，忙得焦頭爛額；他們都騰不出時間做這事兒，于是就需要交給專門的測試來進行了。而測試既不是產品的規劃者，也不是產品的設計者，更不是產品的開發者，可以說測試對產品完全就是局外人（恰恰相反，測試是對產品最了解的人，產品有哪些功能，哪些bug，如何高效的操作，如何解決某些問題這些都是測試最了解的，甚至測試可以扮演一個超級客服的角色，這些我都到“測試人員的自我修養”中來解釋）；那么測初步要測試該產品就只能建立在對需求，設計，交互等方面入手了。于是測試需要向產品，設計要相關的文檔 ，熟悉產品的各個模塊。

? ? ? ? 但是即使測試熟悉了，一旦產品開發出來，測試拿到參評就開始使用找bug嗎，我想即使測試熟悉了產品，在測試的過程中肯定對產品的功能有所遺忘，即使是熟悉過文檔，由于一款產品的功能模塊實在太多；如果測試只是憑著對需求文檔的熟悉度，就開始亂點，沒有計劃沒有目標開始測試，到頭來自己做過哪些操作都忘記了，更別談測試效率，能把測試工作做好了。所以在產品的規劃設計階段，測試就 已經開始參與到產品中來，開始熟悉產品，收集各種文檔整理成一些操作步驟，這樣就形成了測試用例，于是用例的生命周期就開始了。所以用例的第一個作用就是，把產品需求轉換為一種可操作的步驟，方便以后有步驟有計劃的進行測試。而在這樣的轉換過程中，由于這種很強操作的邏輯在進行，往往測試能發現產品中設計的bug，因為在設計用例的過程中，實際上是在腦海中模擬使用產品；所以，在寫用例的過程實際上就是對產需求進行測試的一個過程。所以寫用例的第二個作用就是驗證產品的需求是否合理。如果發現產品需求不合理，或需求有矛盾的地方，甚至不明確的地方，這時候我們的用例進行不下去了；因為我們寫的前一個步驟可能有多個結果，那么產品要的是那個結果呢，或者那幾個結果呢。于是我們需要找產品確認；產品一看，這確實需要優化，或需要考慮或者需要想出更好的方案。所以這里又體現了測試用例的第三個作用：監督產品對需求做出更加詳細的設計。而當產品想出好的方案之后，給了測試回復，于是測試把他寫進測試文檔。這有體現了測試用例的第四個作用：記錄產品的設計細節，保障以后的查閱。而測試有了這樣一個與產品溝通的過程，對該模塊有了更深的印象，這里體香了測試用例的第五個作用：加深測試人員對產品的認識和印象。當產品開發出來了，測試這邊的準備也差不多了，于是測試人員開始按照測試用例的描述測試，每過完一個用例標記完成；這樣測試也知道自己做過哪些操作，避免沒有目的隨機測試，并且通過測試用例的執行條數，大致了解該模塊的測試進度，這又體現了測試用例的第六個作用：反應測試進度。而測試人員在執行用例的過程中往往會突然發現當初設計的用例步驟中，還可以做這樣一個操作，于是發現了bug，這又體現了測試用例的第七個作用：幫助發現拓展測試范圍，擴大測試覆蓋面，發現軟件中潛藏的缺陷。

? ? ? ? 好了到這個時候，測試用例已經成長為一個青壯年啦。軟件測試的過程中，我們按照測試用例描述的執行，大致能確定測試的進度。在測試的過程中，我們會發現bug，而這個bug也許沒有在測試用例里面有步驟描述，但考慮到他也許會在以后的版本中復現，于是我們把它的步驟整理出來，形成一個新的用例，以放便測試他是否會在以后的版本中出現，這里又體現了測試用例的另外一個作用：方便回歸測試，復查bug是否還會出現。

? ? ? ? 軟件版本上線后，由于用戶的各種使用習慣，以及各式各樣的使用場景，以及各式各樣的終端環境，會出現一些測試過程中沒有發現的bug，大致這樣的bug對產品的影響比較小，但也是產品的優化點。在第一個版本發布之后，由于用戶的使用反饋，以及產品對用戶操作行為的統計，產品有了更好的方案，或是產品要嘗試新的東西，于是需求開始變動。需求的變動導致測試用例部分失效，于是測試需要更新測試用例，刪除無效用例。這體現了測試用例的一個缺陷：增加了測試的維護成本。有時候由于產品上線的時間比較緊，寫用例會花掉很多時間，而相對的給測試的時間就少了，這有體現了測試用例的另外一個缺陷：消耗了時間成本。往往在這樣的情況下，為了避免測試時間不夠用，我們會花很短的時間列出重要的測試點開始測試。為了避免漏測，我們會參考以前相關模塊的測試用例進行。這體現了測試用例的又一個優點：為緊急情況下的測試提供參考信息。

? ? ? ? 好了說道這里，繼續。產品測試的過程中總會少不了人員的變動問題。而新人進來大多不熟悉產品，而讓他們根據以前的需求測試，肯定會漏測。因為產品在上線過程中已經經歷了需求變化，而且也發現了很多潛在的問題，新人肯定是不能從產品需求以及產品中看到這些。所以他們需要測試用例來輔助測試，了解以前出現的潛在的問題，更加熟悉的了解產品以及他的測試；這里再增加一條測試用例的作用：培訓新人，節省對新人的指導時間。為什么說這節省了對新人的指導時間呢，因為新人看到產品往往會有很多不理解的地方，所以他們回經常去問“前輩們”，而如果前輩們安排她們執行維護好的測試用例，那么很多問題就在執行測試用例過程中就解決了，所以問的問題就會減少，就節約了對他們的指導時間。

? ? ? ? 而我們看看現在的手機外包測試。

? ? ? ? 我們知道手機的有些功能在好多年以內一般不會變化，特別是同一系列的手機。比如短信、通話、藍牙、手機記事本、收音機、錄音機等等。而測試這些手機功能的人也不是固定不變的，因為人員的流動性，一旦人員流走，那么就很少有人熟悉這些功能的測試；他會出哪些問題，哪些行為是多余的功能，哪些功能不正確這些都需要熟悉的人才能執行測試。公司很聰明，在長期的經營當中他知道會發生這樣的事情，于是他們把手機容易出現問題的地方，或以前就有問題的地方，或是剛開始設計的一些信息都整理成一個個可以操作的文檔，記錄下來，這就形成了我們看到的測試用例。那么新來的員工就有了測試的依據，他們往往會被分到一些測試用例去執行，一方面的原因是測試產品是都符合文檔的描述，另一方面讓新來的員工熟悉產品，以及產品測試的大致步驟。

? ? ? ? 因此測試用例的目的對新人來說，提高了新人的測試效率，并且起到培訓新人的作用。

? ? ? ? 假如一款產品停止維護了，那么所有的測試用例隨之失效，到此測試用例的生命周期結束。而新起一款產品，新的生命周期又開始了。所以，測試用例伴隨著整個產品的生命周期。

? ? ? ? 文章寫道這里，我們來總結一下測試用例的優點與缺點：

優點：

1、???????????????把產品需求轉換為一種可操作的步驟，方便以后有步驟有計劃的進行測試。

2、???????????????驗證產品的需求是否合理

3、???????????????監督產品對需求做出更加詳細的設計

4、???????????????記錄產品的設計細節，保障以后的查閱

5、???????????????加深測試人員對產品的認識和印象

6、???????????????反應測試進度

7、???????????????幫助發現拓展測試范圍，擴大測試覆蓋面，發現軟件中潛藏的缺陷

8、???????????????方便回歸測試，復查bug是否還會出現

9、???????????????為緊急情況下的測試提供參考信息

10、???????????培訓新人，提高新人測試效率，節省對新人的指導時間

缺點：

1、 增加了測試的維護成本

2、 消耗了時間成本

?

文末，如果大家有更好的觀點，多多交流。

總結

以上是生活随笔為你收集整理的论测试用例的重要性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。