作為軟件測試人員（SQA/SQC），做的最頻繁并且最主要的活動之一就是編寫測試用例了。首先，請記住以下所有的討論都是關于編寫測試用例，而不是設計/定義/確認測試用例（TC）。
這項主要活動有幾個重要的關鍵因素，讓我們先來大概了解一下吧。
A、測試用例要易于定期修改和更新
我們生活在 一個不斷變化的世界，軟件也不能免于變化。需求也是如此，這就直接的影響到了測試用例。不論什么時候，一旦需求發生變化，測試用例就需要更新。然而，并不 是只有需求的變化才會引起測試用例的版本變化和更新。在測試用例執行過程中，腦海中會涌現出許多的想法，單個測試用例的許多子條件會引起更新甚至測試用例 的補充。除此而外，在回歸測試中一些補丁和/或波紋都會需要修訂或是新的測試用例。
B、測試用例要易于分配于執行用例的測試人員
當然了，讓單獨一個測試員執行完所有的測試用例是幾乎不太可能的。正常情況下，一個單獨的應用程序會有幾個測試員分別負責測試不同的模塊，因此，根據他 們自己在應用程序中測試的部分測試用例也會相應的分配開。一些和應用程序集成相關的測試用例有可能會由多人執行而有的則只是由單獨的個人執行。
C、測試用例要易于集群和批處理
屬于一個測試場景的測試用例通常都會要求以一些特定序列或小組格式來執行，這很正常，也是很常見的。可能會有一些測試用例是其他測試用例的先決條件，同 樣的，根據AUT的業務邏輯，一個單獨的測試用例會在幾個測試條件中存在，而一個單獨的測試條件也可能會由多個測試用例組成。
D、測試用例有相互依賴的趨勢
測試用例中一個有趣并且重要的行為就是他們彼此之間是相互依賴的。在具有復雜業務邏輯的中型到大型應用程序中，這種趨勢則更為明顯。任何應用程序中能明 確的觀察到這個行為的最清晰的地方就是，相同甚至不同應用的不同模塊之間的互操作性。簡單的說就是，不管相異模塊或應用程序是在哪里相互依賴的，相同的行 為都體現在了測試用例中。
E、測試用例要易于在開發者間分配（尤其是在測試用例驅動開發環境中）
關于測試用例，重要的一點就是，它并不是只被測試人員使用的。在正常情況下，當開發人員修改bug的時候，他們間接的使用了測試用例來修改問題。同樣 的，如果遵守的是測試用例驅動開發，那么開發員則直接使用了測試用例來構建他們代碼的邏輯并覆蓋測試用例中處理到的所有的場景。
所以，將以上的5點記住，這里給出一些編寫測試用例的建議：
要簡潔但是不能太簡單；要復雜但是又不能太復雜。
這句話似乎是自相矛盾的，但是我發誓并不是如此。走完測試用例的每一步，正確序列和預期結果的正確映射都得要精確，這就是我所說的讓測試用例保持簡單。
而，使其復雜一點實際上指的是測試用例得和測試計劃以及其他測試用例相融合。當需要的時候，參照其他的測試用例，相關工件，GUI等。但是做此事的時候 得均衡一下，不能讓測試人員為完成單個測試場景就來回的搬運大堆的文件。另一方面，不要讓測試人員希望你會壓縮這些測試用例文件。在編寫測試用例的時候， 請時刻記住你或者別人不得不修改并且更新這些測試用例。
測試用例編制完成之后，以一個測試人員的角度再審視一遍：
永遠不要以為你寫完測試場景的最后一個測試用例后就算完事了。回過頭去從開始將所有的測試用例再看一遍，但是不要當自己是個測試用例的編寫者或 測試策劃者，以測試人員的角度審視所有的測試用例。理性的思考并且干運行你的測試用例，評估一下你所提到的每一步都是清晰易懂的，并且預期的結果和這些步 驟也是相協調的。
測試用例中規定的測試數據不僅要對實際的測試人員是可行的，而且也得是依據真實的實時環境的。要確保測試用例中沒有依賴沖突，而且也要確認對于其他測試用例/工件/GUI的所有參考都是精確的，否則測試人員會陷入大麻煩中。
約束測試人員，但同時也讓他們感到容易。
不要把測試數據都留給測試人員，給他們一個輸入的范圍，特別是當執行運算的時候或者是應用程序的行為是取決于輸入的時候。也許你會把測試項目的 值分給他們，但是永遠不要讓他們自己來選擇測試數據項目，因為，有意無意的，他們會使用相同的測試數據因而在執行測試用例的時候一些重要的測試數據會被忽 略掉。
根據測試類別和應用程序的相關領域對測試用例進行組織，這能讓測試人員感到容易一些。清晰的指出哪些測試用例是相互依賴的/或是可批處理的。同樣的，明確的指示出哪些測試用例是獨立的，孤立的，因此，測試人員就可以按照自己的意愿管理他/她的全部測試活動。
成為一個貢獻者
從不接受FS或設計文檔原來的樣子，你的工作不僅僅是將FS瀏覽一遍然后明確測試場景。作為一個和質量相關的資源，你要毫不猶豫的去貢獻。要給 開發人員提建議，特別是在測試用例驅動開發環境中。建議一些下拉列表，日歷控件，選擇列表，單選按鈕，更有意義的信息，警告，提示，可用性的改進等等。
不要忘記最終的用戶
最重要的利益相關者就是將會實際使用AUT的最終的用戶，所以，在編寫測試用例的任何階段都不要忘記他。事實上，在SDLC的任何階段也都不能 忽視最終的用戶，但是目前我只強調和我討論的話題相關的。所以在識別測試場景的時候，不要忽視這些大多情況下被用戶使用的用例，或者是那些甚至不太使用的 業務關鍵用例。把你自己想象成最終的用戶，把所有的測試用例瀏覽一遍，判斷一下你文檔中測試用例執行的實際價值。
總結：
測試用例的編寫是一項會對整個測試階段產生重要影響的活動。這個事實使得測試用例文件編制這個任務變得非常的關鍵并且微妙。所以，編寫測試用例 得先適當的計劃一下，還得非常的具有條理性。編制測試用例文件的人必須記住，這項活動不是為他/她自己而做的，而是為了整個團隊，這個團隊包括了其他測試 人員和開發者，還有那些會被這項工作直接或間接影響到的客戶。
所以，在這項活動進行的過程中必須給予適當的關注。對所有的使用者來說，測試用例文檔必須是很好理解的，方式明確，維護簡單。除此而外，測試用 例文檔必須介紹所有重要的特征，必須覆蓋AUT所有重要的邏輯流，伴隨著實時和實際可接受的輸入。你編寫測試用例的戰略是什么？和我們的讀者分享你的建議 吧~也可把你的問題寫在下面的評論中。