“我不想寫測試用例”，又一次聽到一起工作的測試人員這麼對我說。想來“不想”只是客氣，“不要或是不願”才是真正的想法。
  問其原因，羅列了出了一系列的理由
   1. 目前使用的測試用例已經好久沒有發現任何系統缺陷了。
   2. 前兩天沒有按用例執行，直接隨機測試，結果發現了好幾個從來沒過的缺陷。
   3. 測試用例好入不更新，與實際的系統已經相差很遠。
   4. 執行這麼多的用例，我已經沒有時間去做其它型別的測試，每天只是疲於標記通過還是不通過，沒有新意，倦了。
  然後與我溝通是不是可以不寫測試用例。
  我想了想：
   1. 倦了是正常現像也是實情，測試本身就是重複性的工作，從任何一個工作的本身來講，創新只是小部分，多數是按步就搬的執行。
   2. 更新測試用例是每輪測試結整後必須要做的，是測試人員的責任，為什麼不能及時更新，這個需要解決和改進，應該是如何維護測試用例的問題。
   3. 至於隨機測試發現了新的問題，這個就需要考慮測試策略和測試資料的應用，應當是如何提升測試覆蓋率的問題。
  所以，測試用例必須寫，只是有簡單寫和詳細寫的區別。
  如果你是位大牛，系統架構、功能瞭然於胸，測試點、測試資料清清楚楚，執行的不差分毫，那麼你可以不寫測試用例，只要提交詳細的測試報告即可。只是測試報告依然要寫清楚測試了什麼、沒有測試什麼，存在的問題和風險是什麼。

  開始繞圈了，有點死迴圈的意思，到底是寫還是不寫，怎麼寫？讓我們回到紡寫測試用例最初目的，即測試用例設計和使用的原點上來：
  編寫測試用例以覆蓋系統測試需求，理清測試思路。 -- 這是我的理解

  簡單的來說測試用例就是明明白白的為測試人員指明，你要在什麼環境下、用什麼樣的資料做哪些測試、達到什麼效果
  從統計指標上來講，就是用來計算測試覆蓋率：測試用例涉及功能點總量 / 待測試系統功能點總量
  然而，一個突出的現實問題就出現了：

    一個測試功能點從功能實現角度來講會有正常和異常流程

    從使用者操作層面講也同樣有正常操作和異常操作（操作者的習慣林林種種）

    從系統所允許使用的資料來講就會有成千上萬種可能

  因此測試用例的數量按如此測算將會是無窮盡的。還好，測試用例的設計原則給我們提供了一系列測試用例設計方法，可以幫助我們對種種操作進行分類分析、設計對應的測試用例，這裡好像有點面向對像的味道。。。。。。

  >> 測試用例的簡單寫法和詳細寫法
  詳細寫法測試人員都很清楚：序號，測試點概要，測試項，測試環境，測試資料，測試步驟，測試期望結果，設計時間，設計人。。。。。
  簡單寫法呢？解決和描述清楚一個問題：在什麼時間、什麼環境、用什麼樣的資料、驗證什麼樣的功能？結果是什麼樣？對還是不對？原因是什麼？

  簡單說來就是要有足夠詳細的測試功能列表、測試資料，以及測試資料作用於測試功能點上的預期結果。
  這樣的一個測試功能列表（function list）或者我稱之為測試大綱的東東，真正描述起來其實工作量真的不小，需要深思熟慮，需要花費足多的時間才能逐步理清，只是格式相對簡單些。

  >>關於測試用例的維護

  測試人員的基礎工作之一，不必多說，不要覺得費事，這是一種查漏補缺的重要手段，對於長期維護的專案，這將是一筆寶貴的專案財富。在沒有成為大牛之前，把基本功練好。測試保證質量不是一時興起、不是隨隨便便，功夫在平時，維護好測試用例也是維護好自己的測試思想。

  >>關於隨機測試和探索性測試

  隨機測試不是隨便測試，不是所有的人都可以做隨機測試的，如果隨便一個人都可以做隨機測試並且能夠發現足以致命的缺陷，那麼專業的測試人員真的就沒有什麼價值了，反之被測試系統也就無法稱之為合格的系統。

  探索不是憑空想像，而是在前期工作的基礎上的一種分析的深入。探索性測試是基於前期測試的資料，對缺陷的分佈規律、業務邏輯的反覆推演而進行的一種有針對性的測試活動，有一套測試分析方法和測試策略。可以用大資料的思想解釋：不求因果，只看相關性，由此著手，步步深入。

  無論什麼樣的測試活動，都不要忘了反思測試過程、補充測試功能點、測試資料，為自己還不是那麼強的記憶留個記錄，也是為了其它測試留個參考，同時也是保證整個專案的長期有效執行的需要。

-----------------------------------------------------------------------------------------------------------
  停下來，思考才是進步的本質。