測試用例設(shè)計步驟

一、需求文檔分析

1、文檔閱讀

切忌不閱讀需求文檔，上來直接寫用例，至少讀3遍文檔。

細(xì)致理解功能設(shè)計意圖和設(shè)計思路。

避免粗略理解帶來的用例遺漏。

一些重要數(shù)據(jù)可能隱藏在不起眼的語句中。

加深對功能的理解，否則隨著時間推移，可能會遺忘很多內(nèi)容。

2、功能細(xì)節(jié)溝通探討

不明白的地方需要及時確認(rèn)，切忌腦補想當(dāng)然。

盡早確認(rèn)細(xì)節(jié)，最好在開始寫之前就確認(rèn)完畢。

關(guān)注需求變更，需求變更后，一定要跟程序和策劃確認(rèn)。

3、邏輯梳理

文檔不一定是按照流程順序?qū)懙?#xff0c;而且經(jīng)常存在功能交叉的地方。

梳理出框架后，逐步細(xì)化。

4、功能拓展思考

· 設(shè)計缺陷思考

· 測試難點思考(領(lǐng)取獎勵后刷新)

· 關(guān)聯(lián)度思考(領(lǐng)取道具存儲位置、道具重復(fù)問題)

· 特殊情況思考(領(lǐng)取道具過程中斷網(wǎng)斷電情況)

5、兼容相關(guān)思考

· 版本兼容(一種服務(wù)器兩種版本中的交互)

· 功能兼容(老功能基礎(chǔ)上增加新的內(nèi)容)

· 操作系統(tǒng)版本兼容

· 分辨率兼容

二、功能模塊劃分

1、功能模塊劃分原則

· 高內(nèi)聚、低耦合

· 重整體、清局部

2、模塊劃分方法

功能流程法：將功能的基本流程畫出來，根據(jù)流程的每個大的環(huán)節(jié)進(jìn)行模塊劃分，然后再細(xì)化和查漏補缺。

層次劃分法：按照邏輯層次逐層細(xì)化出模塊的過程，比較適用于UI劃分，大的系統(tǒng)模塊劃分等。

類型劃分法：按照功能包含內(nèi)容的不同類型進(jìn)行劃分。

注：

· 不同的劃分法適用不同的場景，要具體問題具體分析 有時候一個功能需要結(jié)合多種方法進(jìn)行劃分。

· 劃分方法不重要，劃分原則更重要一些。

· 劃分完畢后，要結(jié)合需求文檔重新梳理，確保模塊清晰、覆蓋完整。

三、測試用例編寫

1、格式

清晰的格式為何如此重要：

讓用例的脈絡(luò)更清晰明了 。

方便需求變化后的更新維護(hù) 。

方便執(zhí)行人員快速入手。

首頁內(nèi)容

· 用例名稱

· 用例對應(yīng)的游戲版本

· 編寫人、修改日期、修改備注

· 需求文檔的鏈接或地址

正文頁內(nèi)容

· 功能邏輯圖(如果有)

· 用例id

· 模塊功能名稱

· 測試先決條件

· 輸入信息

· 輸出結(jié)果

· 備注信息

注：

盡量保證邏輯清晰。

盡量保證一個輸入只對應(yīng)一個輸出。

保證每次更新用例后都有明確的記錄標(biāo)注。

盡量保證一個用例內(nèi)格式統(tǒng)一。

2、常用的測試用例編寫方法

(1)等價類

等價類：指的是一個輸入集合內(nèi)，任何輸入數(shù)據(jù)對于輸出的驗證來講都是等效的，此刻我們就可以選取少量代表性的測試數(shù)據(jù)來代表整體數(shù)據(jù)。

有效等價類：是對輸出來講有意義的輸入集合，可以驗證程序的正常功能和流程。

無效等價類：是對輸出無意義的輸入組合，用于驗證非正常流程輸入對輸出的影響。

(2)邊界值

邊界值：對輸入或輸出的邊界值進(jìn)行分析的一種方法。

邊界值的確定：一般選取正好等于，剛剛小于和剛剛大于3種情況作為測試數(shù)據(jù)。

通常適用的范疇：數(shù)值測試、字符串測試、數(shù)據(jù)類型測試等。

(3)因果圖&判定表

因果圖：簡單的來說就是輸入與輸出之間因果關(guān)系的一種關(guān)系圖。

判定表：可以通過因果圖來生成的一種結(jié)果判定表。

因果圖常常與判定表一起使用，通過因果圖生成判定表，通過判定表來書寫測試用例。

3、測試用例編寫注意事項

輸入條件要單一明確，盡量不用容易引起誤解的詞，比如：可能、大概等。

輸出要判斷且明確，最好不用“顯示正確”這種詞匯。

測試步驟要可執(zhí)行。

保持盡量稿的覆蓋度。

能抽象的盡量抽象出來，避免無意義的冗余。

四、測試用例整理與維護(hù)

需求變化后需要及時更新老的測試用例，并寫清修改情況的備注(修改內(nèi)容，產(chǎn)品和開發(fā)負(fù)責(zé)人。

測試用例應(yīng)該盡量避免冗余，如果遇到重復(fù)的用例，需要根據(jù)實際情況進(jìn)行修改。

注意測試用例的備份，寫完后最好自己本地也備份一份，避免線上被人誤刪。

五、BUG的界定標(biāo)準(zhǔn)

1、與需求設(shè)計不符

2、違背常識

六、BUG的生命周期

· 發(fā)現(xiàn)bug

· 提交給開發(fā)

· 開發(fā)修復(fù)

· 測試驗證

· 通過后關(guān)閉/不通過繼續(xù)指派給開發(fā)

· 上線前回歸

七、BUG的等級劃分

P0：致命錯誤，需要立即修復(fù)，如宕機、重啟性報錯等。

P1：嚴(yán)重錯誤，需要緊急修復(fù)，如功能流程錯誤、數(shù)值錯誤等。

P2：一般錯誤，允許一段時間內(nèi)修復(fù)，如功能的簡單錯誤、界面錯誤等。

P3：無關(guān)緊要的錯誤，允許延期修復(fù)，如文字錯誤、某個像素點缺失等等。

八、BUG的提報標(biāo)準(zhǔn)

標(biāo)題：【模塊名稱】+簡短描述。

測試環(huán)境：表明測試用的版本，系統(tǒng)，服務(wù)器，賬號等。

描述：bug的詳細(xì)描述。

重新步驟：重現(xiàn)bug的詳細(xì)流程步驟及復(fù)現(xiàn)概率。

期望結(jié)果：希望bug修復(fù)后的結(jié)果 。

備注：log，截圖等。

九、BUG的提報標(biāo)注——一個bug例子

標(biāo)題：[士兵]打開士兵技能升級頁面報錯。

測試環(huán)境：內(nèi)網(wǎng)測試服，v1.1.0版本，IOS系統(tǒng)，賬號：zjf01。

詳細(xì)描述：當(dāng)我們在游戲中打開士兵升級頁面時，系統(tǒng)提示報錯信息。

重現(xiàn)步驟：(1)進(jìn)入游戲；(2)打開士兵技能升級頁面；(3)系統(tǒng)報錯。

期望結(jié)果：能夠正常升級士兵技能，打開升級頁面不報錯。

備注：報錯信息見下面的截圖

十、BUG的驗證標(biāo)準(zhǔn)

嚴(yán)格按照復(fù)現(xiàn)步驟驗證。

去除測試環(huán)境的影響。

驗證標(biāo)注：需要注明驗證的版本、服務(wù)器等。

十一、BUG的驗證標(biāo)準(zhǔn)

拓展：是否對其它功能有影響，做簡單回歸。

注意點：驗證不能只看前端展現(xiàn)，更應(yīng)關(guān)注后端數(shù)據(jù)。

十二、BUG的跟蹤與推動

每個人都有責(zé)任跟蹤自己的bug的修復(fù)狀態(tài)。

及時與開發(fā)溝通，了解修復(fù)狀態(tài)并提供修復(fù)過程中的支持。

久不修復(fù)的bug需要與開發(fā)和上級確認(rèn)如何處理。

Bug修復(fù)后，需要及時驗證。

十三、BUG的數(shù)據(jù)分析

本文內(nèi)容不用于商業(yè)目的，如涉及知識產(chǎn)權(quán)問題，請權(quán)利人聯(lián)系51Testing小編(021-64471599-8017)，我們將立即處理

總結(jié)

以上是生活随笔為你收集整理的软件测试找游戏bug,游戏测试用例及游戏测试bug详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。