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

? ? ?書寫測試用例目的，是為了能有依有據(jù)的驗證需求，側(cè)重于用戶使用過程中的涉及到的需求點，非驗證此段代碼，簡而言之，避免以下誤區(qū)：

【過于關(guān)心bug數(shù)目】bug是驗證需求過程中的產(chǎn)物，非目標(biāo)，不能說 驗證中發(fā)現(xiàn)bug越多，QA業(yè)績就好

【設(shè)計過于復(fù)雜用例】用例目的，驗證『實際用戶使用過程』是否有問題，提前掃雷，避免上線后用戶使用出現(xiàn)問題；不要跑偏至『找出這部分代碼所有錯誤』

【代碼依據(jù)需求來實現(xiàn)】1.我們讓它做的它必須會做。2.我們不讓它做的它必須不會做

一、測試前的準(zhǔn)備：

1.了解同類競品

2.仔細(xì)閱讀PRD、交互、視覺圖

二、case設(shè)計

1.拆分功能點

1）基本功能，主要指app是否覆蓋所有功能

分清模塊→ 考慮自己寫出初步checklist，避免漏測

考慮橫豎屏切換，不過很多app現(xiàn)在只支持豎屏

各類元素：btn、link、下拉框、輸入框、彈框

2）系統(tǒng)交互:電話短信干擾，低電量提醒，push提醒，usb數(shù)據(jù)線插拔提醒，充電提醒等

3）測試小點：流程中銜接點到底顯示什么、流程中斷后顯示什么、意外掉線—>重登—>頁面如何顯示

比如【使用工具】xmind

①盡量畫出每個分支一個方塊（操作/結(jié)果）+一個菱形（條件）≈一塊 ?#拆分成功能點#

②盡量畫出可能的流程

③流向明確，分清先后

④明確每個判斷的真假條件

⑤更具體描述操作步驟

⑥考慮配置和環(huán)境的影響

及時記錄不明確點 # 比如流程中銜接點到底顯示什么、流程中斷后顯示什么、意外掉線—>重登—>頁面如何顯示#

4）描述準(zhǔn)確、無歧義

描述只對應(yīng)1種執(zhí)行，盡量避免一條描述中包含多種執(zhí)行情況

比如頁面有彈框+蒙層，用例描述『返回操作』的用例涉及以下3種操作

① 點擊彈框『取消』or『返回』btn

② 點擊蒙層

③ 手機(jī)物理返回鍵

2.功能的場景

基于場景的測試用例生成和維護(hù)

1）任何功能，保證基本流和備選流

①基本流，是正常流程（基線baseline）

②備選流，是異常情況/包括不限于失敗情況

③場景主要包括4種主要的類型：正常的用例場景，備選的用例場景，異常的用例場景，假定推測的場景

【舉個栗子】開戶流程設(shè)置交易密碼

正常場景：彈出設(shè)置交易密碼框后，輸入符合要求的+輸入兩次一致密碼

彈出設(shè)置交易密碼框后，點擊返回，返回彈出框前頁面

備選場景：彈出設(shè)置交易密碼框后，點擊手機(jī)物理返回鍵，返回彈出前頁面

異常場景：彈出設(shè)置交易密碼框后，賬號掉線，輸入符合要求的密碼后 → 進(jìn)入登錄頁 →登錄成功后，返回交易密碼框頁面。此時頁面提示賬號重新登錄的信息應(yīng)該消失

推測場景：彈出設(shè)置交易密碼框后，輸入符合要求的密碼 → 確定交易密碼框，點擊返回后 → 彈出退出框 → 取消框，繼續(xù)流程 ，

【問題1】觀察返回哪個頁面？此時應(yīng)該在確認(rèn)交易密碼框

【問題2】此時是否清空輸入呢，一般產(chǎn)品需求沒有說明此點，常識中清空和不清空都有一定合理性，『是否清空』需要及時和產(chǎn)品確認(rèn)

【心得】這是實際測試時發(fā)現(xiàn)的，開發(fā)實現(xiàn)是：確認(rèn)框處返回 →取消返回→返回至 設(shè)置交易密碼框。。。和正常流程背離。實際上，產(chǎn)品需求文檔粒度達(dá)不到這么細(xì)，QA在實際測試中可以積累更多測試點。QA覺得測試到某點好像不對，但需求沒有定、也木有對應(yīng)用例時，容易放過，上線后存在功能隱患。

2）用戶場景中，基本流下+多個備選流組合—>篩選并合并重復(fù)場景—>固定場景（基本流+備選流）

3）經(jīng)驗+探索用例

3.外場（網(wǎng)絡(luò)兼容性）

網(wǎng)絡(luò)切換，網(wǎng)絡(luò)信號強，弱下的app運行情況

4.性能

穩(wěn)定性，兼用型（android碎片化是個難題，bug也多，ios相對bug少），app運行的內(nèi)存消耗和cpu消耗，app后臺長時間運行的耗流量，耗電量。

推薦testin這個第三方平臺，對android兼用性測試比較有幫助。

5.用例優(yōu)先級和復(fù)用率

設(shè)計用例=公共case+半公共case+專項case

6. 易用性

面是否吸引人、容易理解。界面整潔、簡單。無錯別字。點擊范圍確定等。這部分測試中，如果測試認(rèn)為有不合理的地方通常會提交需求bug。

三、實際現(xiàn)狀

1.實際用例設(shè)計現(xiàn)狀

1）閱讀需求—>拆分需求點 —> 離散用例點

2）閱讀需求和實際測試，人思維是連續(xù)。導(dǎo)致設(shè)計和回想需求，都是很痛苦過程，遺漏或者反饋閱讀片面需求，導(dǎo)致用例冗余或者缺失

2.調(diào)整方法--設(shè)計場景

如果基于場景作為設(shè)計用例切入點，則

若first time 就基于用戶的使用場景進(jìn)行推演，將各種用戶路徑繪制成一幅完整的業(yè)務(wù)流程圖（想象用戶角度實際操作），這幅圖中可能有若干個開始結(jié)點和若干個結(jié)束結(jié)點（每個結(jié)點可以是程序的某個狀態(tài)，流程中的某個步驟，網(wǎng)站的某個頁面，等等），那么從每個開始結(jié)點到每個結(jié)束結(jié)點間的所有路徑，就是所有可能的場景了

3.用例場景

1）在圖中找出強連通分量，把強連通分量當(dāng)做一個節(jié)點處理

2）組成一幅新的圖

3）在新圖中找出起點和終點

4）對每對起點和終點都尋找存在多少條路徑并記錄

設(shè)計思路：1??誰 2??做什么 3??結(jié)果是什么，進(jìn)行排列組合

四、測試用例_高質(zhì)量進(jìn)階

1.如何編寫高質(zhì)量的測試用例

1）高質(zhì)量的標(biāo)準(zhǔn)：

1、 覆蓋到所有的業(yè)務(wù)邏輯（包括正常邏輯和異常邏輯）

2、 覆蓋到所有的典型用戶場景

3、 覆蓋到所有的需求點

4、 測試目標(biāo)明確，并且測試步驟能夠最快的達(dá)到測試目的或者測試時間很短

5、 沒有冗余的用例

6、 測試用例能夠直接附帶測試策略，該模塊的策略指定人和用例執(zhí)行人能夠非常清楚

7、易讀性，非書寫者也能讀懂，并100%執(zhí)行

2）我們應(yīng)該 to do

1、優(yōu)先完成業(yè)務(wù)邏輯圖，需要在測試的角度上面去畫邏輯圖，包括數(shù)據(jù)流完整的輸入和輸出過程，并且自己能夠理解為什么這樣處理

2、根據(jù)自己的理解分析每個邏輯的處理是否完善，是否有沒有覆蓋到的地方，并提交缺陷預(yù)防bug

3、根據(jù)邏輯編寫測試用例，保證每個邏輯都能夠有對應(yīng)的用例覆蓋

4、編寫邏輯用例的過程中思考如何去改進(jìn)該用例的測試過程，比如：接口測試，自動化測試，腳本。并且，能夠及時讓研發(fā)提供對應(yīng)的接口和調(diào)試方法

5、用例要按照10分鐘原則，即保證10分鐘內(nèi)能夠執(zhí)行完成

6、包含測試數(shù)據(jù)，達(dá)到最大執(zhí)行力，無須另外造數(shù)據(jù)

【舉個栗子】比如以下用例嚴(yán)格來說是錯誤的

輸入正確的用戶名

輸入正確的密碼

點擊登錄

登錄成功

因為用戶名和密碼，執(zhí)行者還需要造數(shù)據(jù)，所以不合適，可以修改為：

注冊成功一個賬號

輸入正確的用戶名: admin

輸入正確的密碼:123456

點擊登錄

登錄成功，跳轉(zhuǎn)到主頁，url為:http://www.XXX.com,看到用戶名顯示:oooo

含有測試數(shù)據(jù)的用例，能更大程度上提高覆蓋率（使用最少case達(dá)到覆蓋目的）

【舉個栗子】比如最常見最熟悉的輸入框測試，需求『測試一個輸入框，要求長度是6到12位字母或者數(shù)字』，測試思路有

輸入1到5位數(shù)字；輸入1到5位小寫字母 ；輸入1到5位大寫字母

一條case平價代替：『輸入Aa812』

輸入12位小寫字母；輸入12位大寫字母 ；輸入12位數(shù)字 ；輸入12位，包含數(shù)字、大小寫字母

一條case平價代替：『輸入12位aaaaaaaZ8888』