1、了解軟體的原始需求（測試目的）
在編寫乙個軟體或者模組的測試用例時候，一定要明白這個功能的原始需求，也就是軟體的使用者（客戶）的需求。理解原始需求後，編寫的測試用例才更有目的性。
2、熟悉軟體的功能需求（測試點）
這個功能需求是指軟體的細化需求點，這個一般在需求文件裡面都會體現。這裡要做的是把 「粗略」的需求，細化成乙個個小需求點。熟悉功能需求後，要知道軟體是怎麼使用的，這也才能覆蓋到各種操作。
總之，測試用例一定要全部覆蓋所有的需求點，這是最基本的一點。
3、熟悉軟體的實現原理（測試點）
在理解原始需求和軟體的功能需求後，根據需求編寫的測試用例，基本上都能覆蓋得比較全面了。
在此基礎上，熟悉軟體的實現原理，理解軟體的內部處理。
（1）熟悉原理的過程是進一步深入熟悉軟體的過程。如果單單是從需求點上面覆蓋案例，測試用例只能覆蓋「表面」的一層。一些內部的處理流程也許沒有覆蓋到，而這些沒有覆蓋到的**很可能就是乙個風險點。
（2）熟悉模組原理後，還有一點就是易於分析軟體模組的關聯性。乙個大型的軟體，都是一些小模組的組合而成。軟體越是大型，耦合就越大，「互相影響」就會越多，若設計用例單單從模組本身考慮的話，很可能就會對其他模組造成風險。
4、使用者場景和網上問題（測試點）
從使用者的使用場景考慮，這在一些網路裝置比較重要，比如軟體後期在一些真實的使用環境中使用。
還要就是從一些網上問題總結出來的，那些地方容易出錯，在設計案例的時候需要考慮進去 。
5、測試用例的框架
乙個測試用例的框架體現了乙個測試人員在設計測試用例的整體思路。框架也是從大到小劃分下來，可以是：
ui介面，功能，容錯，相容，效能等幾大類，每個大類在根據軟體的邏輯等進行劃分成小類，最後細分到測試點。
6、測試步驟（測試技巧方法）
前面4點都是從測試點的角度考慮，測試用例在完成測試點外，接下來就是測試步驟和測試結果啦。
測試用例可以寫的很詳細，也可以寫的比較簡單。這要看公司的要求，有些公司要求測試步驟很細很細，包括測試結果和測試步驟一一對應。
要求測試步驟寫的很詳細的公司，一般是怕執行人員的執行力不到位，導致沒有理解案例的目的，導致漏測。一般出現在新員工對軟體系統的不熟悉。
如果測試步驟寫的很詳細的話，會很耗時間，而且過於詳細的會限制執行人員的思維。個人認為測試用例的重點在於測試點上。
7、測試用例的一些思路
在設計測試用例中，通常較多使用的是邊界值，等價類，通過和不通過測試。下面從單個模組或者單個功能點考慮：（結合一些網上文章的觀點）
（1）ui介面：易用性，提示資訊，整體布局，按鈕圖示，色彩，中英文標點錯別字。
（2）資料的多樣性：有效資料，合法的無效資料（邊界值），非法的異常資料，產生錯誤輸出的合法資料組合等各種資料的組合。
（4）容量測試
（5）使用者許可權：使用許可權，各種操作的許可權。
（6）公升級安裝解除安裝：平滑公升級
（7）日誌相關（包括除錯日誌）
（8）軟體功能的邏輯劃分：功能上劃分未能覆蓋的**邏輯，可以新增白盒灰盒用例。
（9）可靠性，容錯性
（10）相容性：瀏覽器，系統，支撐軟體。
（11）安全性
（12）效能（這裡的效能是指，單個模組或者子系統的效能）
總之測試用例首先要能覆蓋所有功能需求點，然後搞懂軟體處理邏輯，可以找開發一起看測試用例，把沒有覆蓋到的**流程相應的用例補充，至此，用例基本不會出現基本功能的問題。
在此基礎上，可以進行一些可靠性，容錯性，相容性等用例的設計，測試下軟體的穩定性。
軟體測試如何設計測試用例
測試用例編寫是軟體測試的基本技能 也有很多人認為測試用例是軟體測試的核心 軟體測試中最重要的是設計和生成有效的測試用例 測試用例是測試工作的指導，是軟體測試的必須遵守的準則。乙份漂亮的測試用例不僅僅是設計思路的優秀體現，更是便於流轉和執行，具有可讀性 傳遞性。1 指導測試的實施 測試用例主要適用於整...
軟體測試用例設計方法
1.概述 grenford j.myers在 the art of software testing 一書中提出 乙個好的測試用例是指很可能找到迄今為止尚未發現的錯誤的測試，由此可見測試用例設計工作在整個測試過程中的地位，我們不能只憑藉一些主觀或直觀的想法來設計測試用例，應該要以一些比較成熟的測試用...
軟體測試用例設計方法
一 測試過程中遇到的問題 1.不知道是否較全面的測試了所有內容 2.測試的覆蓋率無法衡量 3.對新版本的重複測試很難實施 4.存在大量冗餘測試影響測試效率。二 等價劃分 分析問題 1.等價類劃分概念 2.等價類 是指某個輸入域的子集合。在該子集合中，各個輸入資料對於揭露程式中 的錯誤都是等效的 3....