論測試用例的重要性
軟件測試的工作，都少不了寫用例的時候，我想大部分的用例都是在產品需求出來一部份之後就已經開始了，因為這個時候，已經有了寫測試用例的依據。有了大致需求之後對編寫用例來說一般只是一個開始，我們還需要更多的信息，比如UE（用戶交互設計稿）、UI（用戶界面設計圖）、需求的描述、產品大綱，功能模塊圖來提供更多的信息來完善用例。往往產品在開始設計的時候，正是用例生命周期的開始。為什麽這麽說呢，在以下的文章當中，我們讓他慢慢的浮現出來：
我們有時候很困惑，為什麽要寫測試用例，測試用例對後來的測試到底起到了什麽作用？有時我們甚至懷疑，項目測試中是否需要測試用例。好，我先舉個測試用例的運用場景。
假設，這裏新成立了一家新公司叫“豆比科技”，他們自己設計了一款軟件產品“逗你”。產品的需求，用戶交互，設計圖，各個功能模塊的詳細描述都有了，產品開始投入到開發當中。而開發好的產品肯定是有很多問題的，必須要又人來保障產品的質量。
那麽誰來保障產品的質量呢，首先，產品可以做這事，因為產品是他們設計的，他們需要對產品負責，但是產品們都很忙，因為他們需要制定產品的戰略規劃，功能的設計等；設計可以做這事，因為UI是他們設計的，他們對UI最了解，但是設計們也很忙，因為他們需要更多的時間來調整UI；開發們也可以做測試，因為產品是他們開發的，有什麽bug他們第一時間知道，但是開發們也很忙，他們在忙著實現各種復雜的功能模塊，忙得焦頭爛額；他們都騰不出時間做這事兒，於是就需要交給專門的測試來進行了。而測試既不是產品的規劃者，也不是產品的設計者，更不是產品的開發者，可以說測試對產品完全就是局外人（恰恰相反，測試是對產品最了解的人，產品有哪些功能，哪些bug，如何高效的操作，如何解決某些問題這些都是測試最了解的，甚至測試可以扮演一個超級客服的角色，這些我都到“測試人員的自我修養”中來解釋）；那麽測初步要測試該產品就只能建立在對需求，設計，交互等方面入手了。於是測試需要向產品，設計要相關的文檔 ，熟悉產品的各個模塊。
但是即使測試熟悉了，一旦產品開發出來，測試拿到參評就開始使用找bug嗎，我想即使測試熟悉了產品，在測試的過程中肯定對產品的功能有所遺忘，即使是熟悉過文檔，由於一款產品的功能模塊實在太多；如果測試只是憑著對需求文檔的熟悉度，就開始亂點，沒有計劃沒有目標開始測試，到頭來自己做過哪些操作都忘記了，更別談測試效率，能把測試工作做好了。所以在產品的規劃設計階段，測試就 已經開始參與到產品中來，開始熟悉產品，收集各種文檔整理成一些操作步驟，這樣就形成了測試用例，於是用例的生命周期就開始了。 所以用例的第一個作用就是，把產品需求轉換為一種可操作的步驟，方便以後有步驟有計劃的進行測試。而在這樣的轉換過程中，由於這種很強操作的邏輯在進行，往往測試能發現產品中設計的bug，因為在設計用例的過程中，實際上是在腦海中模擬使用產品；所以，在寫用例的過程實際上就是對產需求進行測試的一個過程。 所以寫用例的第二個作用就是驗證產品的需求是否合理。
好了到這個時候，測試用例已經成長為一個青壯年啦。軟件測試的過程中，我們按照測試用例描述的執行，大致能確定測試的進度。在測試的過程中，我們會發現bug，而這個bug也許沒有在測試用例裏面有步驟描述，但考慮到他也許會在以後的版本中復現，於是我們把它的步驟整理出來，形成一個新的用例，以放便測試他是否會在以後的版本中出現，這裏又體現了測試用例的另外一個作用：方便回歸測試，復查bug是否還會出現。
軟件版本上線後，由於用戶的各種使用習慣，以及各式各樣的使用場景，以及各式各樣的終端環境，會出現一些測試過程中沒有發現的bug，大致這樣的bug對產品的影響比較小，但也是產品的優化點。在第一個版本發布之後，由於用戶的使用反饋，以及產品對用戶操作行為的統計，產品有了更好的方案，或是產品要嘗試新的東西，於是需求開始變動。需求的變動導致測試用例部分失效，於是測試需要更新測試用例，刪除無效用例。這體現了測試用例的一個缺陷： 增加了測試的維護成本。有時候由於產品上線的時間比較緊，寫用例會花掉很多時間，而相對的給測試的時間就少了，這有體現了測試用例的另外一個缺陷： 消耗了時間成本。往往在這樣的情況下，為了避免測試時間不夠用，我們會花很短的時間列出重要的測試點開始測試。為了避免漏測，我們會參考以前相關模塊的測試用例進行。這體現了測試用例的又一個優點： 為緊急情況下的測試提供參考信息。
好了說道這裏，繼續。產品測試的過程中總會少不了人員的變動問題。而新人進來大多不熟悉產品，而讓他們根據以前的需求測試，肯定會漏測。因為產品在上線過程中已經經歷了需求變化，而且也發現了很多潛在的問題，新人肯定是不能從產品需求以及產品中看到這些。所以他們需要測試用例來輔助測試，了解以前出現的潛在的問題，更加熟悉的了解產品以及他的測試；這裏再增加一條測試用例的作用：培訓新人，節省對新人的指導時間。為什麽說這節省了對新人的指導時間呢，因為新人看到產品往往會有很多不理解的地方，所以他們回經常去問“前輩們”，而如果前輩們安排她們執行維護好的測試用例，那麽很多問題就在執行測試用例過程中就解決了，所以問的問題就會減少，就節約了對他們的指導時間。
而我們看看現在的手機外包測試。
我們知道手機的有些功能在好多年以內一般不會變化，特別是同一系列的手機。比如短信、通話、藍牙、手機記事本、收音機、錄音機等等。而測試這些手機功能的人也不是固定不變的，因為人員的流動性，一旦人員流走，那麽就很少有人熟悉這些功能的測試；他會出哪些問題，哪些行為是多余的功能，哪些功能不正確這些都需要熟悉的人才能執行測試。公司很聰明，在長期的經營當中他知道會發生這樣的事情，於是他們把手機容易出現問題的地方，或以前就有問題的地方，或是剛開始設計的一些信息都整理成一個個可以操作的文檔，記錄下來，這就形成了我們看到的測試用例。那麽新來的員工就有了測試的依據，他們往往會被分到一些測試用例去執行，一方面的原因是測試產品是都符合文檔的描述，另一方面讓新來的員工熟悉產品，以及產品測試的大致步驟。
因此測試用例的目的對新人來說，提高了新人的測試效率，並且起到培訓新人的作用。
假如一款產品停止維護了，那麽所有的測試用例隨之失效，到此測試用例的生命周期結束。而新起一款產品，新的生命周期又開始了。所以，測試用例伴隨著整個產品的生命周期。
文章寫道這裏，我們來總結一下測試用例的優點與缺點：
優點：
1、 把產品需求轉換為一種可操作的步驟，方便以後有步驟有計劃的進行測試。
2、 驗證產品的需求是否合理
3、 監督產品對需求做出更加詳細的設計
4、 記錄產品的設計細節，保障以後的查閱
5、 加深測試人員對產品的認識和印象
6、 反應測試進度
7、 幫助發現拓展測試範圍，擴大測試覆蓋面，發現軟件中潛藏的缺陷
8、 方便回歸測試，復查bug是否還會出現
9、 為緊急情況下的測試提供參考信息
10、 培訓新人，提高新人測試效率，節省對新人的指導時間
缺點：
1、 增加了測試的維護成本
2、 消耗了時間成本
文末，如果大家有更好的觀點，多多交流。
論測試用例的重要性