測試用例首先來自於對於需求的分析，是否能為測試挑選最合適或最關鍵的需求，關係到專案的成敗。
思考方法1：正反面思考法
為每個測試需求至少編制兩個測試用例：正面測試用例& 負面測試用例
正面測試用例：用於證明該需求已經滿足； 負面測試用例：反映某個無法接受、反常或意外的條件或資料，用於論證只有在所需條件下才能夠滿足該需求
基本流：是經過用例的最簡單的路徑
備選流：在某個特定條件下執行
前置條件是執行用例之前必須存在的系統狀態，後置條件是用例一執行完畢後系統可能處於的一組狀態。
針對不同的被測專案(或程式,軟體),可能都有不同的方式.因為專案不同,可能遍寫的用例的覆蓋程式,詳細程式等都不同.評審指標也不同.
好的用例可以使測試完整,完善,提高專案質量.
有時候,"以偏概全"未必是壞事.用例的評審,除了按基本業務流過一遍後,最重要的應該結合專案的風險(系統,安全,應用風險)等,對用例進行審核
測試用例的優先級別
首先，你必須確定什麼是你優先順序別的型別和其暗示著什麼。就我們的目的來說， 我們將用乙個假設開始，那就是我們可能發現的缺陷的嚴重程度和那些相應測試用例的優先級別之間是平行的。
1 –小版本確認測試（build verification tests (bvts)：也叫做「冒煙測試」，一組你想先執行的以確定這個給出的小版本是否可以測試的測試用例。如果你不能訪問每乙個功能區域或執行其他測試用例依賴的基本操作，那麼在執行這個優先的測試用例之前，試圖做其他任何的測試都是沒有意義的，因為他們大多數肯定要失敗。
2 – 高（highs）：最常執行以保證功能性是穩定的，目標的行為和能力可以正常的工作，和重要的錯誤和邊界被測試的測試用例的集合。
3 – 中（mediums）：這是使給出的功能區域或功能變得更詳細，檢查功能的多數方面包括邊界，錯誤和配置測試的測試用例
4 – 低（lows）：這是通常最少被執行的測試用例。但這並不意味著這些測試都不重要，只是說他們在專案的生命期間裡不是常常被執行，例如gui，錯誤資訊，可用性，壓力和效能測試。
我們將測試用例分成4類：bvts，高，中和低。現在的問題是將測試用例分到不同的優先級別裡。畢竟，優先級別將指出哪些測試用例被認為是需要更頻繁的執行的，哪些又不是。
本文出自 「ghost」 部落格，請務必保留此出處
軟體測試一般流程
拿到測試文件，熟悉業務需求 分析 測試範圍 處理分支 需求業務的場景 明確隱式需求 明確其功能對應的輸入 處理 輸出 了解測試需求是什麼 決定如何測試 測試環境 人員 時間 使用工具 測試需求收集 需求的正確性 必要性 優先順序 明確性 可測性 完整性 一致性 可修改性 測試型別劃分 功能測試 易用...
軟體測試的一般方法
一般說到程式猿大家能想到的就是一線的開發人員，覺得他們的日程就是 敲敲敲 殊不知在產品一線還有另外一群人，他們做著和開發人員一樣的事情，他們就是測試人員。測試人員的工作跟開發人員差不多，人稱 點點點 至於二者孰輕孰重，有人形象的比喻開發和測試就好比人的兩條腿，時而交替時而並行地推動者專案前進。這裡，...
軟體測試的重要環節 Bug管理的一般流程
軟體測試的主要目的在於發現軟體存在的錯誤 bug 對於如何處理測試中發現的錯誤，將直接影響到測試的效果。只有正確 迅速 準確地處理這些錯誤，才能消除軟體錯誤，保證要發布的軟體符合需求設計的目標。在實際軟體測試過程中，對於每個bug都要經過測試 確認 修復 驗證等的管理過程，這是軟體測試的重要環節。錯...