(2)、完整業務流程的測試
我們都知道測試用例的設計是從點、線、面三個層次去考慮的。完整的一個功能項是線，其中的某個按鈕是點，多個相關功能結合成完整業務流就是面。從實際來看這類用例往往被我們忽略。
事實上目前公司的軟件本來都是業務型應用軟件，將各種功能從業務流中切割出來單獨寫用例，肯定也會有涉及到整體流程的情況。若不加以區分，將細節與全局攪在一起，不僅思路混亂，也容易考慮不周。因此在系統測試階段，建議用例設計要有分有合，針對具體功能的就只圍著這個功能轉：而在業務流程測試項中，再完全從整體的業務流角度出發去考慮用例，這樣不僅不容易產生疏漏，用例閱讀與執行也更清楚。
(3)、某種特定情況下的系統運行
這類用例的設計往往與系統實際業務情況密不可分。比如財務軟件，通常需要在月尾一天、月頭一天、年尾一天、年頭一天，對所有相關功能中的日期處理進行測試;又比如WIN 2000環境開發測試的系統，要測試在98、XP、2003等操作系統下是否能運行自如;再有如存在大量動態圖片視頻等的網頁，在普通網速下的展現速度等等�？傊褪且M可能從實際應用的角度出發考慮，來進行測試補充。
(4)、其它相關系統
即指在當前項目中直接使用的其它成果，包括公司自有的系統模塊、組件、函數;以及購買或免費得到的一些功能組件。對這些內容需要預先與開發組長等討論清楚，是否需要測試。若時間緊張或其它原因決定不測的，應在測試計劃中說明。若需要測試的，則具體可根據實際情況來設計，可以是通過系統某個功能的測試來涉及，此時就不需要單獨劃分測試項;若相對比較獨立的，也可以通過單獨的測試項來對其專門進行測試。
(5)、除功能測試外的其它測試類型
包括可靠性、安全性、恢復性、配置安裝測試等等，這些測試類型都是一個單獨的測試項。
所謂好的開始是成功的一半，保證測試項劃分的完整、合理、正確，會直接影響到本次測試的成效。通常建議該階段工作要花1-2天的時間來考慮，并要在測試過程中隨著對軟件的深入了解，不斷進行調整補充�？汕f不要認為把分析設計中的功能模型圖搬搬過來就可以了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/