答案：原則上不是。

測試用例是為了指導測試執行工作，如果沒有測試用例，那麼測試的執行更多是通過瞎猜或經驗的方式開展。

但是很多時候，受限於項目的緊迫程度，測試很多時候為了折中，只能選擇開發剛交付就投入到測試工作當中。這種做法是非常危險的，因為沒有任何的指導，你甚至都不知道問題是否真的是問題？

磨刀不誤砍柴工，如果實在受限於條件，我們可以選擇腦圖的方式，或者選擇黑盒測試方法，快速檢索出測試點和測試因子，進行概要測試分析，得出測試的重點與核心。

如果根據需求文檔寫，一般會先寫測試要點，就是比較粗略的。

通常情況會根據軟體程序，邊操作邊寫。

為什麼會這樣呢，主要是因為開發出來的軟體程序有時候和原來的需求設計文檔差比較多，

所以會等待開發好後，邊操作邊寫，不用前期寫好後，又進行修改。

但是有些情況還是在程序開發完成前，先寫好用例，這種一般需求設計文檔已經評審確定下來，

基本不會太大變化，而且先初步寫好，後續開發好了就可以根據用例開始執行測試，縮短後期測試時間。

一、通用測試用例八要素

1、用例編號;

2、測試項目;

3、測試標題;

4、重要級別;

5、預置條件;

6、測試輸入;

7、操作步驟;

8、預期輸出

二、具體分析通用測試用例八要素

1、用例編號

一般是數字和字元組合成的字元串，可以包括(下劃線、單詞縮寫、數字等等)，但是需要注意的是，盡量不要寫漢語拼音，因為拼音的意義可能有好幾種，有可能會導致亂碼;

用例編號具有唯一性和易識別性。(比如說我們唯一標識一個人：中國-上海市-xx區xx號-xx樓--xx室-xxx.這樣標識的話就具有唯一性了。)

不同階段的測試用例的用例編號有不同的規則：

(1)系統測試用例：產品編號-ST-系統測試項名-系統測試子項名-XXX

(2)集成測試用例：產品編號-IT-系統測試項名-系統測試子項名-XXX

(3)單元測試用例：產品編號-UT-系統測試項名-系統測試子項名-XXX

**其中產品編號也叫項目標識，每個公司都有若干不同的項目或者產品，如何來區分它們呢?這就需要有產品編號了，每個公司都有自己的一套定義產品編號的規則，並且每個現有產品的編號已經制定好了，直接拿過來用就可以了。

**產品編號後的ST、IT、UT分別對應系統測試階段、集成測試階段、單元測試階段。實際工作中有些公司會將產品編號以及測試階段省略。

**測試階段後面就是測試項目名了，對應的是較大較系統的測試點。

**測試項目名後面就是測試子項目名，有些測試是沒有子項目名的，只有當測試項力度比較大的時候才會有成都市子項(比如說：我們要測試用戶能否成功登錄這個功能，那我們就可以分為很多個子項，qq登錄、郵箱登錄等等)。

**測試子項名後面就是具體的用例編號了，可以是數字：01、001、002等等。

2、測試項目

測試項目對應的就是測試用例中的子項名。

(1)系統測試用例：對應一個功能點(功能測試)、性能指標(性能測試)、界面中控制項(GUI測試)等等。

(2)集成測試用例：對應集成後的模塊功能或者介面功能。

(3)單元測試用例：對應函數名。

3、測試標題

測試標題考慮的是如何來完成測試項目，或者說從哪個角度來對測試項目進行測試，有的公司也取名為測試目的。

測試標題一定要簡單、概要;體現測試的出發點和關注點。

4、重要級別

用例的重要級別一般分成三個級別：高、中、低。

高級別：對應保證系統基本功能、核心業務、重要特性、實際使用頻率比較高的用例;

中級別：對應重要程度介於高和低之間的測試用例;

低級別：對應實際使用頻率不高，對系統業務功能影響比較大的模塊或功能的測試用例。

**舉個手機的例子：**

(1)高級別需求：正常通話功能、簡訊功能;

(2)中級別需求：拍照、聯繫人、MP3;

(3)低級別需求：計步、收音機等等。

還需注意的是：針對**正常情況**的測試用例的重要級別比針對**異常情況**的測試用例的重要級別要高。

5、預置條件

測試用例在執行前需要滿足一些前提條件，否則測試用例是無法執行的，這些前提條件就是預置條件。

預置條件分為兩種情況：

(1)環境的設置。

例如：測試word打開文件的功能，預置條件就是：需要提前準備被打開的文件;

例如：登錄成功的預置條件就是：該用戶名已經註冊過了。

例如：購買商品成功的預置條件就是：後臺已經配置好商品、發貨區域、以及支付方式了。

(2)先要運行的其他用例，有些操作系統會比較複雜，如果都是從最開始的操作開始會導致用例寫起來比較麻煩，這樣可以在預置條件中設定要先運行的測試用例，後面的用例只需要寫後續的操作就可以了。

例如：對自動取款機進行測試，有針對的輸入賬戶信息的測試，有對輸入取錢金額的測試，後者的預置條件就可以寫成輸入正確賬戶信息的測試用例。

註：具體預置條件的設置不同的公司會有自己的規定，比如有的公司是不允許第二種情況出現的。

6、測試輸入

用例執行過程中需要加工的外部信息，根據軟體測試用例的具體情況，有手工輸入、文件、資料庫記錄等。

禁止過多描述性語言，若為文件，會有提示選擇路徑，最好寫具體，讓別人易懂易操作。

7、操作步驟

明確描述測試執行過程中具體的操作步驟，以方便測試執行人員可以根據該操作步驟完成測試用例執行。

8、預期輸出

預期輸出是測試用例中非常重要的一部分，預期輸出可以檢驗被測對象是否正常工作，如果我們的預期輸出寫的不完整不全面，整個測試用例就會受到影響。

我們在寫預期輸出的時候可以從以下三個方面來考慮：

(1)界面顯示：在操作步驟完成之後，界面會有顯示;比如說我們測試用戶登錄功能，界面可能會顯示登錄成功或者登錄失敗。

(2)資料庫的變化：在操作步驟完成之後，資料庫中的記錄會發生相應的變化，比如刪除功能的測試，點擊刪除後，資料庫中該記錄會被刪除。

(3)相關信息的變化：在操作步驟執行完成後，一些和被測對象相關的信息會發生變化，比如：註銷功能的測試，點擊註銷後，以前能訪問的頁面將無法再訪問.

先設計測試用例，然後根據測試用例執行測試。除了按照測試用例按部就班的執行測試外，在不影響測試目標，測試時間充裕的情況下，還可以進行探索性測試，創造性的執行測試用例，如果發現了新的問題，那麼在測試結束後，可以把這部分補充到測試用例庫中。另外，軟體在其生命週期中會因需求變動而頻繁地被修改和不斷推出新的版本，修改後的或者新版本的軟體會添加一些新的功能或者在軟體功能上產生某些變化，這就需要不斷的維護更新測試用例庫，這是一個不間斷的過程。
按照規範，肯定是測試前寫的，如果要求嚴格一些，測試案例也同樣要審批之後，才能進入執行階段

計算機軟體測試規範GB/T 15532-2008 http://www.csres.com/detail/190821.html

實際執行當中，就看情況了，公司比較重視，要求比較嚴，那肯定是測試前寫；公司不重視，根本沒給測試留下足夠的時間，或者組織混亂，那別說測試後寫案例了，不寫的都有
首先要明確測試用例是幹什麼用的？如果公司為了應付客戶那麼可以在測試之後設計。如果為了更好的保證項目的質量，以及積累相應的經驗的話 那就是在測試之前設計。
看你的測試用例是指什麼用例，一般是先設計測試用例，然後編寫用例，之後執行用例。不過有些組織會先進行第一次手工用例執行，得到執行結果後，再進行自動化用例的編寫的。
不是，應該是測試執行之前寫的。
當然不是，是在拿到需求，分析後寫的。而且一定是在測試執行前寫的。不然你按照什麼執行呢？只有粗略的測試思路就直接執行測試很容易會有遺漏。建議看看測試基礎相關書籍。

推薦閱讀：
相關文章