1、了解軟體的原始需求(測試目的)
在編寫乙個軟體或者模組的測試用例時候，一定要明白這個功能的原始需求，也就是軟體的使用者(客戶)的需求。理解原始需求後，編寫的測試用例才更有目的性。
2、熟悉軟體的功能需求(測試點)
這個功能需求是指軟體的細化需求點，這個一般在需求文件裡面都會體現。這裡要做的是把需求穩定的「粗略」的需求，細化成乙個個小需求點。
熟悉功能需求後，要知道軟體是怎麼使用的，這也才能覆蓋到各種操作。
總之，測試用例一定要全部覆蓋所以的需求點，這是最基本的一點。
3、熟悉軟體的實現原理(測試點)
在理解原始需求和軟體的功能需求後，軟體有什麼功能，如何使用就基本上都知道啦。這時候在根據需求編寫測試用例，基本上都能覆蓋的比較全面。
在此基礎上，熟悉軟體的實現原理，理解軟體的內部處理。
(1)熟悉原理的過程是進一步深入熟悉軟體的過程。如果單單是從需求點上面覆蓋案例，測試用例只能覆蓋「表面」的一層。 一些內部的處理流程也許沒有覆蓋到，
而這些沒有覆蓋到的**很可能就是乙個風險點。
(2)熟悉模組原理後，還有一點就是易於分析軟體模組的關聯性。乙個大型的軟體，都是一些小模組的組合而成。軟體越是大型，耦合就越大。「互相影響」就會越多，
設計用例單單是從模組本身考慮的話，很可能就會對其他模組造成風險。
4、使用者場景和網上問題(測試點)
從使用者的使用場景考慮，這些在一些網路裝置比較重要。比如軟體後期在一些真實的使用環境中使用。
還要就是從一些網上問題總結出來的，那些地方容易出錯。在設計案例的時候需要考慮進去
5、測試用例的框架
我覺得乙個測試用例的框架體現了乙個測試人員在設計測試用例的整體思路。框架也是從大到小劃分下來，可以是：
ui介面，功能，容錯，相容，效能等幾大類，每個大類在根據軟體的邏輯等進行劃分成小類，最後細分到測試點。
6、測試步驟(測試技巧方法)
前面4點都是從測試點的角度考慮，測試用例在完成測試點外，下來就是測試步驟和測試結果啦。
測試用例可以寫的很詳細，也可以寫的比較簡單。看公司的要求，有些公司要去測試步驟很細很細，包括測試結果和測試步驟一一對應。
我個人不太認同這種做法，測試用例最重要的我認為是測試點。只要理解了測試目的後，下來的就是測試人員的執行工作啦。如果對一些非常嫻熟的測試人員，他們一般
看測試用例的標題就是知道你測試目的了，具體的操作就是根據他們的測試方法進行測試。如果測試步驟寫的很詳細的話，一會很耗時間。你要考慮到文字語音的描述，以及一些前置步驟的操作，這也會導致案例有時候像個文章，而且過於詳細的會限制執行人員的思維。
要求測試步驟寫的很詳細的公司，一般是怕執行人員的執行力不到位，導致沒有理解案例的目的，導致漏測。一般出現在新員工對軟體系統的不熟悉。
7、測試用例的一些思路
一)從單個模組或者單個功能點考慮
(1)ui介面(易用性，提示資訊，整體布局，色彩，中英文標點錯別字)
(2)資料的多樣性
有效資料
合法的無效資料(邊界值)
非法和異常資料
各種資料的組合
(3)操作多樣性
新增刪除編輯查詢
多使用者的操作
(4)容量測試
(5)使用者許可權(使用許可權)
(6)公升級安裝解除安裝(平滑公升級)
(7)日誌相關(包括除錯日誌)
(8)軟體功能的邏輯劃分
功能上劃分未能覆蓋的**邏輯，可以新增白盒灰盒用例;
(9)關聯的功能
設計關聯的測試的用例
(10)可靠性，容錯性
(11)相容性(瀏覽器，系統)
(12)安全性
(13)效能(這裡的效能是指，單個模組或者子系統的效能)
總之測試用例首先要能覆蓋所有功能需求點，然後搞懂軟體處理邏輯，可以找開發一起看測試用例，把沒有覆蓋到的**流程相應的補充用例。用例覆蓋到這2點基本不會出現基本功能的問題。
在此基礎上，可以進行一些可靠性，容錯性，相容性等用例的設計，測試下軟體的穩定性。
如何寫軟體效能測試用例
由於效能測試與功能測試有很大的區別，所以討論出的結果可能與預先的設想有一定的區別。效能測試的目的 為了驗證系統是否達到使用者提出的效能指標，同時發現系統中存在的效能瓶頸，起到優化系統的目的。使用者對各項指標提出的明確需求 如果使用者沒有提出效能指標則根據使用者需求 測試設計人員的經驗來設計各項測試指...
如何寫介面測試用例（並篩選冒煙測試用例）
關於介面測試用例的等級劃分 1 主體業務功能介面正常典型值用例的優先順序為1 用於冒煙測試的用例 2 各模組主功能的正常典型值用例的優先順序為2 3 除了的正常典型值用例之外的正用例及所有異常用例的優先順序為3 4 可用性測試以及入參預設值以及開發做了限制處理的引數型別 開發自測容易發現的錯誤等測試...
如何寫好測試用例
這裡說的不是設計測試用例的數量，而是測試用例的書寫。我在實習期間對乙個內部使用的工具進行測試，負責增刪改查部分。作為實習生，很想有乙個準確的答案告訴我該怎麼做不該怎麼 應試教育的惡果 但實際工作中確實是乙個人有乙個人的風格，聽多了反而不知道該怎麼做。所以我第一批的tc寫的特別詳細，如 前置條件 en...