測試用例（test case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求，通俗的講：就是把我們測試系統的操作步驟用按照一定的格式用文字描述出來。
理清思路是我們認為最重要的一點，有的系統本來就是乙個大而複雜的專案，我們需要把專案功能細分，根據每乙個功能通過編寫用例的方式來整理我們測試系統的思路，避免遺漏掉要測試的功能點。
通過編寫測試用例，執行測試用例，我們可以很清楚的知道我們的測試進度，方便跟蹤我們的測試進度。
首先我們的系統不是測一遍就完了的，我們需要在開發環境上測試，測試環境上還要進行回歸，其次還有可能涉及到合併測試，而且也有可能會有不同的人在不同的階段進行測試，那麼我們就需要測試用例來規範和指導我們的測試行為。
在我們所做專案的各個版本中，也許會有很多功能是相同或相近的，我們對這類功能設計了測試用例，便於以後我們遇到類似功能的時候可以做參考依據。
另外如果產品發布後出現了發布缺陷，測試用例也是分析發布後缺陷的依據之一。
在測試需求分析階段，我們只有需求文件，所以編寫測試用例的唯一依據就是需求文件，因此在進行用例編寫之前一定要進行需求分析，需求分析的主要工作就是：了解需求的整個實現背景；分析需求的合理性；明確需求的範圍，挖掘需求文件中隱藏的需求；在通過需求交底的過程，確定開發的初步實現思路和方法，隨著測試需求分析的深入，列出需求的框架，包括測試範圍即各個功能點，測試的場景等；確定一些測試可以提前介入的工作等；需要說明的是對於需求中的問題一定要記錄下來，找需求確認，需求漏掉的或者存在問題的地方，開發和測試更容易漏掉，而且遺漏的需求很有可能會使得專案整體業務邏輯發生變化，一定要及時提前確認。
得到了需求的各個測試點後，應該先將這些測試點簡單的分配一下優等級，一般分為高中低三個優先順序，我認為得到優先順序後可以讓需求用例的設計更有側重和著重點。
根據測試需求分析得到的需求框架，梳理細化測試點，這裡的測試點雖然粗，但是不應該有遺漏，這是進行測試點細化的前提。根據測試點，細化出具體的測試用例，要注意各個點的組合測試的情況，還要注意各個測試點的反向測試的情況。
在細化測試點的時候，我們可以要參考以前寫好的公共測試用例，甚至可以直接引用，這樣既可以避免一些不必要的時間浪費，但是參考不等於照搬，在引用的同時，也一定要思考本次需求自己特有的測試點。
另外需要考慮的就是測試點細化到什麼程度的問題，也就是乙個度的問題，我們要把握好測試點細化的乙個度的問題，太粗的測試點沒有指導意義，太細的測試點容易讓我們糾的太細，忽略整體的測試，反而也起不到乙個指導的效果，所以一定要把握好測試點細化的度。
需求分析和用例編寫階段，是主要的細化用例時間，這段時間的目標是梳理出可指導執行測試的用例，但是需求會有變動，需求會有維護，用例也一樣，所以用例是需要持續維護的， 所以在需求變動的同時，我們也要及時維護測試用例，否則的話，測試用例很可能成為乙個錯誤的指導。
另外測試用例完成後就會進入乙個用例評審的階段，在用例評審階段，會有用例評審人，針對你的用例作出的評審，主要檢查你的用例是否有測試點遺漏，場景遺漏，測試case描述模糊，測試結果輸出模糊等問題，針對用例評審人提出的問題，我們也要及時的更改我們的用例。
什麼是通用測試用例呢？我理解的通用測試用例就是：專案中或者跨專案中很多的公用業務，固化模組，這些功能基本上是趨於穩定不變的，因此可以梳理出通用的比較全面的測試點，作為指導和規範業務和模組的規範，這些生成的規範即通用的測試用例。當我們針對某一模組或者業務持續維護時，就發現我們需要持續維護這的用例，就會發現有些用例業務類似、執行步驟一致、驗證項屬性一致等等，這個時候通過梳理業務的通用屬性，通用用例梳理梳理成章。所以說，通用的測試用例是乙個對用例不斷維護的產出，因此我們在測試軟體維護的過程中一定要及時的更新通用測試用例，對後面的測試和用例維護有乙個很大的指導作用。
任何系統都有大的業務背景，只要熟悉了業務知識才能更有效的使用系統。
任何系統在使用過程中，都有乙個熟悉的過程，對系統越熟悉，越容易發現系統問題和業務問題。
作為測試人員如果想提公升測試用例的編寫能力，首先應該做到的就是站在客戶的角度分析客戶需要什麼和客戶想要什麼，客戶不想要什麼，也就是所謂的客戶的使用場景，這樣有利於我們更好的挖掘和思考隱含的需求。至於這個需求該不該做，那是需求人員的職責，這個需求做起來復不複雜那是開發人員的事情，作為測試人員需要考慮的事就是你所設計的正向和反向測試用例是不是使用者常用到的場景，以及一些客戶基本不會用到的場景有哪些。
我們知道乙個人做乙個工作時間越久，也就是我們說的經驗越豐富，可能這個思維方式就會越被限定住。比如，測試的統計表多了，當拿到乙個新增的統計表的時候，首先想到的是公用用例上所列的測試點基本上就是最全的了，我都不用思考，直接用就行了。
其實這是乙個誤區，公用用例的目的是幫助我們減少一些不必要的內耗，但是我們的思維不要被它所限定，如果公用用例中某個點是錯的，那我們豈不要一錯再錯了。所以作為乙個測試人員如果想要提公升自己的測試用例設計能力，一定要多思考，不要被這種慣性思維束縛，不要被所謂的經驗束縛。
基於以上四點我們還要做到善於總結，樂於分享，把經常見到的用例設計的誤區和一些好的用例設計，和用例設計習慣分享給周圍的小夥伴，這樣可以集眾人之所長，不斷提公升我們的用例設計能力。
本文出自：
軟體測試如何設計測試用例
測試用例編寫是軟體測試的基本技能 也有很多人認為測試用例是軟體測試的核心 軟體測試中最重要的是設計和生成有效的測試用例 測試用例是測試工作的指導，是軟體測試的必須遵守的準則。乙份漂亮的測試用例不僅僅是設計思路的優秀體現，更是便於流轉和執行，具有可讀性 傳遞性。1 指導測試的實施 測試用例主要適用於整...
軟體測試用例設計方法
1.概述 grenford j.myers在 the art of software testing 一書中提出 乙個好的測試用例是指很可能找到迄今為止尚未發現的錯誤的測試，由此可見測試用例設計工作在整個測試過程中的地位，我們不能只憑藉一些主觀或直觀的想法來設計測試用例，應該要以一些比較成熟的測試用...
軟體測試用例設計心得
1 了解軟體的原始需求 測試目的 在編寫乙個軟體或者模組的測試用例時候，一定要明白這個功能的原始需求，也就是軟體的使用者 客戶 的需求。理解原始需求後，編寫的測試用例才更有目的性。2 熟悉軟體的功能需求 測試點 這個功能需求是指軟體的細化需求點，這個一般在需求文件裡面都會體現。這裡要做的是把 粗略 ...