測試人員最熟悉的是用例了。爲什麼寫用例呢？用例中有哪些規律可循呢？下面分享幾點自己心得。
書寫測試用例目的，是爲了能有依有據的驗證需求，側重於用戶使用過程中的涉及到的需求點，非驗證此段代碼，簡而言之，避免以下誤區：
【過於關心bug數目】bug是驗證需求過程中的產物，非目標，不能說 驗證中發現bug越多，QA業績就好
【設計過於複雜用例】用例目的，驗證『實際用戶使用過程』是否有問題，提前掃雷，避免上線後用戶使用出現問題；不要跑偏至『找出這部分代碼所有錯誤』
【代碼依據需求來實現】1.我們讓它做的它必須會做。2.我們不讓它做的它必須不會做
一、測試前的準備：
1.瞭解同類競品
2.仔細閱讀PRD、交互、視覺圖
二、case設計
1.拆分功能點
1）基本功能，主要指app是否覆蓋所有功能
分清模塊→ 考慮自己寫出初步checklist，避免漏測
考慮橫豎屏切換，不過很多app現在只支持豎屏
各類元素：btn、link、下拉框、輸入框、彈框
2）系統交互:電話短信干擾，低電量提醒，push提醒，usb數據線插拔提醒，充電提醒等
3）測試小點：流程中銜接點到底顯示什麼、流程中斷後顯示什麼、意外掉線—>重登—>頁面如何顯示
比如【使用工具】xmind
①儘量畫出每個分支一個方塊（操作/結果）+一個菱形（條件）≈一塊 #拆分成功能點#
②儘量畫出可能的流程
③流向明確，分清先後
④明確每個判斷的真假條件
⑤更具體描述操作步驟
⑥考慮配置和環境的影響
及時記錄不明確點 # 比如流程中銜接點到底顯示什麼、流程中斷後顯示什麼、意外掉線—>重登—>頁面如何顯示#
4）描述準確、無歧義
描述只對應1種執行，儘量避免一條描述中包含多種執行情況
比如頁面有彈框+蒙層，用例描述『返回操作』的用例涉及以下3種操作
① 點擊彈框『取消』or『返回』btn
② 點擊蒙層
③ 手機物理返回鍵
2.功能的場景
基於場景的測試用例生成和維護
1）任何功能，保證基本流和備選流
①基本流，是正常流程（基線baseline）
②備選流，是異常情況/包括不限於失敗情況
③場景主要包括4種主要的類型：正常的用例場景，備選的用例場景，異常的用例場景，假定推測的場景
【舉個栗子】開戶流程設置交易密碼
正常場景：彈出設置交易密碼框後，輸入符合要求的+輸入兩次一致密碼
彈出設置交易密碼框後，點擊返回，返回彈出框前頁面
備選場景：彈出設置交易密碼框後，點擊手機物理返回鍵，返回彈出前頁面
異常場景：彈出設置交易密碼框後，賬號掉線，輸入符合要求的密碼後 → 進入登錄頁 →登錄成功後，返回交易密碼框頁面。此時頁面提示賬號重新登錄的信息應該消失
推測場景：彈出設置交易密碼框後，輸入符合要求的密碼 → 確定交易密碼框，點擊返回後 → 彈出退出框 → 取消框，繼續流程 ，
【問題1】觀察返回哪個頁面？此時應該在確認交易密碼框
【問題2】此時是否清空輸入呢，一般產品需求沒有說明此點，常識中清空和不清空都有一定合理性，『是否清空』需要及時和產品確認
【心得】這是實際測試時發現的，開發實現是：確認框處返回 →取消返回→返回至 設置交易密碼框。。。和正常流程背離。實際上，產品需求文檔粒度達不到這麼細，QA在實際測試中可以積累更多測試點。QA覺得測試到某點好像不對，但需求沒有定、也木有對應用例時，容易放過，上線後存在功能隱患。
2）用戶場景中，基本流下+多個備選流組合—>篩選併合並重復場景—>固定場景（基本流+備選流）
3）經驗+探索用例
3.外場（網絡兼容性）
網絡切換，網絡信號強，弱下的app運行情況
4.性能
穩定性，兼用型（android碎片化是個難題，bug也多，ios相對bug少），app運行的內存消耗和cpu消耗，app後臺長時間運行的耗流量，耗電量。
推薦testin這個第三方平臺，對android兼用性測試比較有幫助。
5.用例優先級和複用率
設計用例=公共case+半公共case+專項case
6. 易用性
面是否吸引人、容易理解。界面整潔、簡單。無錯別字。點擊範圍確定等。這部分測試中，如果測試認爲有不合理的地方通常會提交需求bug。
三、實際現狀
1.實際用例設計現狀
1）閱讀需求—>拆分需求點 —> 離散用例點
2）閱讀需求和實際測試，人思維是連續。導致設計和回想需求，都是很痛苦過程，遺漏或者反饋閱讀片面需求，導致用例冗餘或者缺失
2.調整方法--設計場景
如果基於場景作爲設計用例切入點，則
若first time 就基於用戶的使用場景進行推演，將各種用戶路徑繪製成一幅完整的業務流程圖（想象用戶角度實際操作），這幅圖中可能有若干個開始結點和若干個結束結點（每個結點可以是程序的某個狀態，流程中的某個步驟，網站的某個頁面，等等），那麼從每個開始結點到每個結束結點間的所有路徑，就是所有可能的場景了
3.用例場景
1）在圖中找出強連通分量，把強連通分量當做一個節點處理
2）組成一幅新的圖
3）在新圖中找出起點和終點
4）對每對起點和終點都尋找存在多少條路徑並記錄
設計思路：1⃣️誰 2⃣️做什麼 3⃣️結果是什麼，進行排列組合
四、測試用例_高質量進階
1.如何編寫高質量的測試用例
1）高質量的標準：
1、 覆蓋到所有的業務邏輯（包括正常邏輯和異常邏輯）
2、 覆蓋到所有的典型用戶場景
3、 覆蓋到所有的需求點
4、 測試目標明確，並且測試步驟能夠最快的達到測試目的或者測試時間很短
5、 沒有冗餘的用例
6、 測試用例能夠直接附帶測試策略，該模塊的策略指定人和用例執行人能夠非常清楚
7、易讀性，非書寫者也能讀懂，並100%執行
2）我們應該 to do
1、優先完成業務邏輯圖，需要在測試的角度上面去畫邏輯圖，包括數據流完整的輸入和輸出過程，並且自己能夠理解爲什麼這樣處理
2、根據自己的理解分析每個邏輯的處理是否完善，是否有沒有覆蓋到的地方，並提交缺陷預防bug
3、根據邏輯編寫測試用例，保證每個邏輯都能夠有對應的用例覆蓋
4、編寫邏輯用例的過程中思考如何去改進該用例的測試過程，比如：接口測試，自動化測試，腳本。並且，能夠及時讓研發提供對應的接口和調試方法
5、用例要按照10分鐘原則，即保證10分鐘內能夠執行完成
6、包含測試數據，達到最大執行力，無須另外造數據
【舉個栗子】比如以下用例嚴格來說是錯誤的
輸入正確的用戶名
輸入正確的密碼
點擊登錄
登錄成功
因爲用戶名和密碼，執行者還需要造數據，所以不合適，可以修改爲：
註冊成功一個賬號
輸入正確的用戶名: admin
輸入正確的密碼:123456
點擊登錄
登錄成功，跳轉到主頁，url爲:http://www.XXX.com,看到用戶名顯示:oooo
含有測試數據的用例，能更大程度上提高覆蓋率（使用最少case達到覆蓋目的）
【舉個栗子】比如最常見最熟悉的輸入框測試，需求『測試一個輸入框，要求長度是6到12位字母或者數字』，測試思路有
輸入1到5位數字；輸入1到5位小寫字母 ；輸入1到5位大寫字母
一條case平價代替：『輸入Aa812』
輸入12位小寫字母；輸入12位大寫字母 ；輸入12位數字 ；輸入12位，包含數字、大小寫字母
一條case平價代替：『輸入12位aaaaaaaZ8888』
作者：李睿怡原文鏈接：http://www.jianshu.com/p/99ecd9dc9d85
著作權歸作者所有，轉載請聯繫作者獲得授權，並標註“簡書作者”。