聽一個在微軟工作的朋友說，他們每天寫完的代碼，在晚上下班之前都要check到一起，執行一遍用例，當然都是自動執行的，那個地方出現了錯誤會紅燈提示，所以這個用例一定是事先寫好的。
聽一個在比較大的公司（1000多人）的朋友說，他們公司經常后補用例的。
我一直在百十人的小公司工作，領導心緒來潮的時候要求寫用例，可是多數情況是可寫可不寫的，而且對質量，形勢也沒有什么要求。
對于寫用例的認識，我經歷了這樣一個過程，一開始是很形式化的，質量也很一般，回想一下跟現在的新人寫的一樣，所以覺得毫無用途，所以后來就不怎么寫了�？墒敲鎸π马椖康臅r候，問題出現了，無論在測試之前你多么的了解需求，業務，在提交測試的時候，很是會有覆蓋不全的情況，我們的大腦畢竟不是電腦，我們在測試一個新系統的時候，不可能在到腦中勾畫出每一個小功能，甚至每一個表單的所有分支，所以我開始寫用例了，對任何一個小功能都是以流程的方式，每一步有多少個分支都清晰的列出來，我覺得效果非常好，按照這個測試完成之后，晚上睡覺都安穩多了，這是自己給自己的保證。這個用例可以說是一個很詳細的用例了，只適合新項目的新版本測試，回歸的時候就沒有這個必要了，這樣不符合性價比。那時候，我們的回歸都是憑著大腦測試的，沒有感覺到任何問題，只是在牽涉到流程性比較強的項目時才寫一些流程用例（包括正常流程和常見異常流程）�？墒乾F在，我在新的公司工作一年多了，問題出現了，項目特別多，差不多有十幾二十個，由于測試的人少，每個項目都要測試，所以在回歸測試的時候經常會搞不清狀況，記不清業務要求等（也許是我老了，記憶力不好了：（）而且公司客戶是比較強硬的那種，公司領導是認為測試過的東西就不應該有問題的那種，所以搞得自己經常提心吊膽，生怕給客戶的東西出現問題。這時候，我發現了回歸測試用例的重要性，以前沒有寫過，有個大概的概念就是寫個簡單的流程，回歸的時候執行一下就行了，在一開始的實施過程中發現了問題，寫的過于簡單還是讓我在回歸的時候無從下手，在思考與實踐中，我自認為自己找到了一種不錯的編寫方式：為了保證質量，回歸在功能上要覆蓋所有的功能按鈕，這部分在寫用例的時候要每個操作寫一個用例（簡單說excel的一行），操作結果中記錄該操作應該返回的界面，一定要一個操作對應一個結果，這樣才具有可操作性。在每條用例的后面設置“通過”和“不通過”的按鈕，這樣回歸的時候就輕松了，過一個勾一個，在測試幾乎沒有改動的地方時，簡直是休息，哈哈。當然也不要忽視業務流程，權限等方面的測試，可以另起文檔，以自己比較喜歡的方式編輯就ok了！
文章來源于領測軟件測試網 http://www.kjueaiud.com/