測試人員最熟悉的是用例了。為什麼寫用例呢？用例中有哪些規律可循呢？下面分享幾點自己心得。

     書寫測試用例目的，是為了能有依有據的驗證需求，側重於使用者使用過程中的涉及到的需求點，非驗證此段程式碼，簡而言之，避免以下誤區：

【過於關心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』