首先，測試用例和測試工作本身是不斷完善的，在開發過程的初期，可以認為是需求階段，或者沒有規範需求工作的設計階段。如果有乙個比較明確的需求文件，可以在這個階段檢查完了需求文件以後開始設計測試用例。這裡，
對於需求文件的檢查主要是兩個方面：
1.檢查需求文件描述的正確性，愚以為測試人員要對於真實的系統所涉及的業務非常熟悉，比如乙個簡單的財務軟體，那麼測試人員本身就要對會計工作熟悉，財務制度熟悉，在檢查需求
文件的時候不要迷信所謂的「都是使用者真實的需求」，這裡存在兩個問題，一是使用者是否真的能正確地描述自己的需求，二是需求人員是否真的能正確地理解需求。另外，還有乙個使用者的需求是否符合行業規範的問題，如果不符
合，那麼是否要確認——這裡存在乙個隱患，使用者可能會在開發的後期突然要求他們自己要走行業規範，讓你的需求變動，所以要事先明確好。
2.檢查需求文件描述的準確性。主要是考慮文件中是否存在描述的模糊的地方，對於自己不清楚的問題一定要明確。這個時候是要保證需求的可測試性——我得意思是說保證需求是可以完全為測試工作服務的。
那麼在檢查完了需求之後，就可以開始設計測試用例了，愚以為，在這個階段因為沒有開始設計工作，所以對於測試用例的考慮不能僅僅從介面出發——雖然rup中對於用例的要求有這一項。因而測試用例的設計應該從業務角
度出發，從實際業務出發來設計測試用例。當然，在測試用例的描述時，要盡量考慮怎樣同應用程式脫離開而仍然具有有效性。
當然，這個階段所實現的測試用例是不過完善的，只能涵蓋某些內容，但是我認為這些用例不僅僅全部都是功能測試用例，而且在整個專案中都將有效。
不過，當缺少需求文件時，那就要發揮測試人員自己的能動性了，要主動的工作，而不是被動的等待。要自己嘗試著去熟悉實際業務，要盡量通過自己所能想到的方法來開展工作。
相信學過馬克思哲學的朋友都知道什麼是客觀性和主觀能動性吧。
當然，在設計階段和最後的編碼階段，都還可以繼續新增、修改或者剔除掉部分測試用例，使之更加完善。
jackei by 2004-01-09
開展軟體測試工作的前期準備
隨手記錄，零零散散，個人思考積累。1.明確測試目的 範圍 週期，做好方案計畫 目的明確，階段清晰，才能事半功倍。2.向使用者介紹本輪測試可能產生的影響 1 安全滲透測試，可能會損壞資料，影響服務的正常提供 2 效能測試，服務可能宕機 3.觀察伺服器資源使用情況 如果要測試乙個執行中的軟體系統，提前了...
單元測試階段的測試工作量自動預估
編者按 為提高軟體開發管理能力，oem和零部件 商對aspice關注和認可程度越來越高，aspice的落地成為大家亟需解決的要點。那麼在aspice中，如何合理估算單元測試階段工作量和迭代更新wbs呢？單元測試工具tessy日前宣布，在其新版本中加入了自動預估測試工作量的功能。該功能可應用在aspi...
測試工作小結
從 dev轉做 tester 一段時間了，稍微總結一下。首先說tester 的思維方式與 dev完全不同，我一度經常陷入到原來 dev的考慮問題的老路上去，對一些缺陷總是覺得不安，但實際上軟體產品總是有缺陷的，只要它達到可接受的質量程度就行了。我做tester 的工作主要是 get cases 通常...