如何開展系統測試用例的設計?實際工作中大概是這樣的：
1、分析需求。
2、劃分測試模塊。
3、針對各測試模塊，依次開展測試設計。
流程本身好理解，同一份需求，不同的人設計出的用例質量可能差別很大。
最近一個月連續組織或參與了多次測試用例評審，涉及多個產品，提出了一些意見，也反思了一下設計過程。偶有一些想法，暫且稱之為“系統測試用例設計要注意的問題”，整理如下：
1、“分析需求”階段
(1)理解需求。[1]理解需求要從理解商業模式(或者盈利模式)入手，只有站在這個高度才可能真正理解需求為什么要如此這般設計。比如XX產品的“隱藏撥號”功能，評審時有人就是想不通為什么要這么設計，當提醒她盈利模式的時候問題變得豁然開朗。[2]理解需求要熟知產品功能的業務邏輯，再說電話功能，有一路通話、多路通話、電話會議等業務，這些業務有什么區別?如何開通?如何使用?[3]理解需求要弄清楚產品功能相關的業務背景知識，比如電話功能，要從技術上了解電話功能的實現原理。[4]理解需求要學會拿它與其它同類產品對比，或參考自己有使用經驗的同類產品，通過對比或參照來啟發自己理解需求的靈感和深度。
(2)分析需求。關鍵是把握需求中的關鍵點，比如：[1]哪些需求是產品特色、哪些需求是產品的主干功能、哪些需求是產品開發的難點?特色和主干功能是測試的重點，從技術實現上講，開發難點往往是容易出紕漏的地方。[2]需求有無優先級區分?一般說，產品立項時會從開發實現先后順序上對需求進行級別定義，測試時也需要據此對測試設計或測試執行的順序進行級別區分。[3]不同的主干/分支/節點，可能在業務邏輯上有著緊密的關聯，只是產品定義人員在規劃功能列表時考慮問題的角度不同，但無論如何在需求分析階段我們要能識別出來，以便于測試模塊的劃分。
(3)還原真實的需求。feature list的質量不總是如你所愿，我們需要在理解和分析需求的基礎上學會還原真實的需求。[1]細化需求�？傆幸恍┕δ茉O計過于粗燥，描述不構具體，雖然需求沒寫出來，但我們要有自己的一本明白帳。[2]拆分需求。有一些功能點被羅列在一個分支下，這可能讓你覺得別扭，明明無關卻被拼湊到一起，與其這樣不如拆分開理解對待。[3]重組需求。業務邏輯上有著緊密關聯的需求可能被分散到不同的分支，不如把它們合并到一起進行重組。[4]修正需求。錯誤的、不當的需求描述，需要進行修正。
2、“劃分測試模塊”階段
需求有著自己的組織結構劃分，測試同樣也需要有模塊劃分，劃分的原則有：
(1)減少用例設計冗余度。
(2)加強用例執行期間的關聯度。
需求分析階段我們提到“不同的主干/分支/節點，可能在業務邏輯上有著緊密的關聯”，盡管我們會去還原真實的需求，但往往還是要保持需求的原樣，在這種情況下我們可以通過測試模塊劃分的方法把它們重組到一起，避免重復的用例設計，也方便把用例執行期間的測試區域控制在一個盡可能小的范圍內，避免來回重復切換影響操作效率。
3、“用例設計”階段
這個階段，用例設計的方法固然重要，但除了運用這些方法，我們更加不能忽略對于測試點的考慮。比如：XX應用程序的版本自動升級功能，其下列出“登陸版本服務器、檢查版本更新情況、自動下載和安裝新版本”幾個子功能，如果一上來就盲目套用測試設計方法，往往會有遺漏。不妨先思考下版本自動升級功能大概有哪些測試點：
* 取得更新功能的權限(要登陸才行)
* 更新檢查功能(要實現如何判別有新版本發布)
* 從服務器取版本規則(當前所用版本比較低，已累計有多個新版本發布?取哪個?)
* 版本更新狀態管理(已更新、取消更新， 版本存儲等)
* 版本更新后原有版本的用戶數據管理(注冊數據，登陸配置，用戶配置，用戶數據/緩存數據)
* 更新后的版本標識正確性檢查(版本號等軟件產品標識)
* 安裝更新包后如何處理安裝包
* 安裝更新包的過程是否產生垃圾文件
文章來源于領測軟件測試網 http://www.kjueaiud.com/
