測試用例是測試執行的指導；是測試執行的實體，是測試方法、測試質量、測試覆蓋率的重要依據和表現形式；是團隊內部交流以及交叉測試的依據，便於測試工作的跟蹤管理，包括測試執行的進度跟蹤，測試質量的跟蹤，以及測試人員的工作量的跟蹤和考覈；在測試執行工作開展前完成測試用例的編寫，可以避免測試工作開展的盲目性；測試用例是說服用戶相信產品質量的最佳依據，同時也可以提供給客戶作爲項目驗收的依據。以上可以看出測試用例在整個測試工作中的地位和作用，以下編寫了關於如何寫好測試用例的一些個人建議：
1、要參與需求評審，評審需求的過程實際也是熟悉業務需求的過程。只有對業務比較熟悉了，才能更好的，更充分的設計出高質量的測試用例。
2、要多閱讀文檔，其中包括產品策劃書、規格說明書、需求文檔，接口文檔等，我們可以收集一切相關的文檔來幫助理解所要測試的產品需要完成的目標。
3、儘量多參加項目組內的會議。比如需求討論、設計討論、計劃討論等會議，這樣在討論過程中也能加深對產品的理解。
4、要善於溝通，多和客戶、開發、測試人員進行溝通。遇到不明確的問題、有疑問的需求，可以諮詢項目負責人或者客戶等。這樣才能提前解決需求理解偏差等。
5、測試用例名稱，也叫測試用例標題，一定要寫得簡潔、明瞭，需要用概括的語言描述該用例的出發點和關注點，使得測試人員第一眼看到測試用例名稱就能夠明白測試用例的目的。用例名稱中一般要求不能存在假設性的語句，並且原則上每個用例的名稱不能重複。
6、預置條件要明確，包括測試環境、測試數據、測試場景。因爲許多BUG只有在特定的環境、特定的場景下纔可以重現。沒有正確的前提條件，就無法進行後面的測試步驟或無法得到預期的結果。
7、測試步驟描述要簡單、清晰，並且要清楚每一個步驟的描述，我們平常的鼠標和鍵盤的每一動作都代表一個操作步驟。比如：第一步，輸入用戶姓名；第二步，輸入登錄密碼；第三步，用戶點擊登錄。步驟寫的明確時就利於提高用例的可操作性。
8、用例的預期結果要完整而且清晰，並且要將各個輸出的結果寫出來，包括：返回值的內容、數據庫相關字段的記錄、界面的響應結果、輸出結果的規則符合度、日誌的檢查和對其它業務影響的檢查。
9、測試用例級別要劃分清楚，這樣在測試執行時有主次之分。
10、測試用例的劃分也要單一，一個測試用例只檢查功能點的一種情況。一個用例檢查的情況太多，會導致用例的目的不明確。而且這樣組織用例，有利於需求覆蓋率的統計。一個功能點我們測試了哪些情況，以及哪些功能點我們在重點測試，一目瞭然。
11、評審用例很關鍵，因爲經過測試用例的評審可以發現：用例設計的結構安排是否清晰、合理；是否覆蓋所有的需求功能點；是否存在冗餘的用例；是否具有很好的可執行性；是否存在對需求理解上的差異等。評審需要項目經理、需求分析人員、架構設計人員、開發人員和測試人員都參與，也需要客戶方的開發人員和測試人員。
12、召開測試用例評審會議，在會議上大家可以提問互答，對模糊不清的地方可以進行討論。這樣可以站在不同的角度，站在很多人的思維和思考方式下設計用例。
13、站在用戶的角度來設計用例，以用戶的使用邏輯及操作習慣爲出發點，從用戶實際可能的操作場景考慮，一定要脫離系統提供功能。
14、測試用例需要不斷更新和維護，不要認爲測試用例的設計是一個階段，測試用例的設計也需要迭代，在軟件開發的不同的階段都要回來重新審視和完善測試用例。並且需要在測試執行時利用發散思維不斷的構造和完善測試用例。
總的來說，寫出好的測試用例需要我們不斷的積累和完善，需要我們不斷的在工作中去總結。寫出好的測試用例沒有簡單的公式或規定可以遵循。即使是多年以來在測試方面感興趣的人也很難做到這一點。