測試實例
步驟1：用例劃分
1.按系統模塊劃分
2.按性質分類劃分
3.按關聯緊密程度劃分
1.按系統模塊劃分
一般設計比較好的系統軟件，都會把功能進行分類，並以模塊的方式佈局在用戶界面上，如圖：【目標管理】，【課程管理】，【學員管理】，大模塊下再分小模塊，比如【課程管理】模塊又分【課程列表】，【項目資源管理】。
用例劃分：針對每個模塊、子模塊或子模塊的模塊設計用例
優點：容易展開，簡單明瞭
缺點：
1.業務邏輯容易被忽視。模塊與模塊之間往往是關聯的。
2.容易忽略非UI功能的測試，比如安裝測試
舉例：數據庫審計系統，【規則模塊】，【對象模塊】
【規則模塊】：存放規則，比如操作表名xx的規則
【對象模塊】：存放對象，比如表名對象，操作方式對象
關聯：規則引用對象
業務流程：客戶操作->產生瀏覽數據->系統捕獲數據->檢測操作對象與規則引用的對象->如果對象匹配則觸發規則並執行規則中指定的動作
單獨測兩個模塊可能都沒問題，但是結合起來，在【對象模塊】中把【規則模塊】中規則正在引用的對象刪除，那結果會咋樣？難說吧
2.按性質分類劃分
用例劃分：兼容性測試，壓力測試，安裝測試，容量測試，可靠性…
好處：對按模塊劃分的有效補充。
3.按關聯緊密程度劃分
用例劃分：也是按模塊劃分，區別是把關聯比較緊密的模塊歸到某個模塊
好處：有利於任務分配，減少人力資源的重複投入
舉例：手機在線教育APP應用，打開應用有我的課程，我的筆記，我的問題等模塊，其中，我的筆記，筆記記錄來自課程模塊，觀看課件學習時進行提交的。
如果按模塊來，測試我的筆記的人需要去觀看課件並提交筆記，而測試課件觀看的人又要測提交筆記，很明顯的，「提交筆記」重複投入了勞力。如果把提交筆記歸到我的筆記模塊，這樣按模塊分配用例，分配給同一個人去測，這就減少了交叉，減少重複的勞動
步驟2：用例設計
1、設計思想
2、用例編寫
1、設計思想
a) 測試點來源與定位
來源
測試點來源：一、顯式需求 二、隱式需求。一個需求點可以對應多個測試點
定位測試點
測試點其實也就是測試目的。用例定義了「怎麼測」，而測試點則定義了「爲何測」，所以，設計前必須明白測試點是什麼，且一個用例僅對應一個測試點。
理由：便於統計，測試用例對整個測試過程的質量控制和評估有很重要的意義：
一、測試需求覆蓋率分析。如果一個用例包含幾個測試點，那麼不利於需求覆蓋分析
二、用例成功率分析。一個用例中有多個測試點，肯定會造成用例數量減少，用例失敗率大大增多，那麼你做的用例成功率還有什麼意義？
三、缺陷分析。如果用例失敗了，就生成一個缺陷。如果一個用例中寫了多個測試點，迴歸的時候如果有指定迴歸用例，那用例中那些些與缺陷不相關的測試點也可能也被迴歸，增加工作量。
以下3點想法幫助你更好的定位測試點
1.站在用戶使用角度來考慮，看你定位的「測試點」是否有實際意義
2.考慮你定位的「測試點」的完成能否標誌着用戶實際業務流程的一個階段性結束？
3.考慮你定位的「測試點」的完成，是否可以爲其他用戶或業務提供輸入數據，以供完成下面的工作？
綜合2-3點：劃清界線，點到即止
例子：QQ郵箱註冊
如上圖，單獨把任意一個選框拿出來併爲其設計一個用例，站在用戶角度來看，都無實際意義。用戶關注的是我填寫完資料並點擊註冊，能生成一個可用帳號，爲登錄功能提供輸入數據。所以設計用例時，這裏的測試目的應該定位爲帳號註冊，而不是某個選框的特性測試。那輸入框的特性，比如上述咋辦？這個就是方法問題了，類似這樣的，可以考慮用場景法來設計。
舉例：音樂臺音樂短片 撲克牌花式技巧演示"五個竅門」視頻播放
操作流程：點擊 撲克牌花式技巧演示"五個竅門」視頻連接，自動打開視頻播放界面，邊緩衝，以邊播放，播放完成，出現上述界面，給出「重播」按鈕提示。
不考慮試測試點粒度和分割(1條用例)：
1.點擊視頻連接--打開視頻播放界面
2.查看打開的播放器界面--一邊進行視頻緩衝，一邊自動播放緩衝好的視頻部分
3.等待播放結束，查看播放器界面--出現重播按鈕和推薦短片
4.點擊重播按鈕--重新播放已緩衝完成的視頻
考慮試測試點粒度和分割(2條用例)：
用例1：在線視頻播放功能
1.點擊視頻連接--打開視頻播放界面
2.查看打開的播放器界面--視頻以邊緩衝，一邊自動播放
3.等待播放結束，查看播放器界面--出現重播按鈕和推薦短片
用例2：視頻重播功能
1.打開視頻進行播放直到播放結束，查看播放器界面--出現重播按鈕和推薦短片
2.點擊重播按鈕--重新播放打開的視頻
這裏用例操作過程似乎有點冗餘，但是從測試目的考慮是允許的：對用例2來說，步驟1可看成是爲測試重播而必須經過的一條路線，不是測試重點，而對用例1而言，用例2中的步驟1則是測試重點。進一步，結束播放時的畫面還有推薦視頻。對這個設計用例，模仿用例2也顯得很容易，思路清晰。
舉例：在線教育系統，手機端離線視頻學習
操作流程：網絡連接下，下載課件視頻，網絡斷開下，查看打開視頻學習，提交離線筆記，新增待同步學識記錄。網絡連接，點擊同步學識記錄按鈕進行服務端與手機端的同步。
從以上3點想法來考慮，可定位以下兩個測試點：
1.保存離線筆記
2.同步離線筆記
可能有人會覺得，以上2個測試點也可以合併在一起。對的，但是你再結合一個用例對應一個測試點就好理解爲何不合並了。
備註：用例是死的，人是活的，例中所舉的例子都存在一定的冗餘，執行的時候可以考慮執適當的用例執行順序來減少操作冗餘。
舉例：教師端學員信息修改
點擊修改，彈出修改界面，繼續點擊單位，出現如圖界面
點擊修改界面中的【單位】設置框，彈出的是一個單位搜索和選擇對話框，如果不獨立出來，對搜索框的準確性驗證也加到修改功能的用例裏，用例會顯得龐大，而且測試點不單一，咋辦？
單獨出來，目的就是對其搜索或展示數據(單位)準確性，找不到單位聯繫客服等功能驗證，比如，是否錯亂，是否少了等進行驗證，是有意義的，因爲這個測試點的輸出數據爲這個資料修改模塊提供了輸入數據，使其可往下執行。而修改中則僅關注單位選擇作用。
b）分離測試數據與測試邏輯（步驟）
方法：將用例中的一些輸入、輸出等作爲參數，數據則單獨列出，在執行時選擇相應的數據執行。
理由：爲什麼要參數化？
a 、沒有將測試數據和測試邏輯分開的測試用例可能顯得非常龐大，不利於測試員理解，導致難以控制和執行；
b 、通過將用例參數化，可以簡化用例，使測試用例邏輯清晰，數據不邏輯的關係明瞭，易於理解；
c 、有利於提高測試用例的重用；
選擇參數化內容
測試用例中需要通過使用不同數據來重複執行測試的部分；
包括：
a、輸入（數據或操作等）
b、輸出（結果數據或預期結果等）
舉例
例一：系統登陸
測試數據
當然，這裏的案例也存在不妥的地方，也就說包含了多個測試點，另外，要是再加個驗證碼，那就更不妥了。。。
c) 依據業務邏輯進行設計
（關於業務邏輯的詳細說明可參考另一文檔）
舉例說明什麼是業務邏輯：
網上購物
業務流程：用戶登錄-選擇商品-結算-下訂單-付款-確認收貨，這是一個流程
業務規則：當用戶下單付款後必須通知賣家，有顧客光臨
業務實體：訂單信息，包含購買物品，買家，金額等
業務實體完整性：如：訂單信息中，買家不可少，物品id不能爲空
根據上述，可以得出優先級：業務流程>業務規則>實體完整性
當然這順序不是絕對的。
思想：
根據80/20原則，百分之80的用戶只使用了產品20%的核心功能，測試要多站在用戶角度進行模擬測試，有些測試站在測試的角度看是有意義的，站在用戶的角度看卻沒多大意義，因爲有些類似邊界值的數據用戶極少或根本不會用。（注意我這裏的用詞），所以要保證基本的核心功能可用。這樣寫出來的用例優先級也比較好分，一目瞭然