-
游戲開發(fā)團隊及開發(fā)流程
查看全部 -
安全測試
查看全部 -
兼容測試
查看全部 -
游戲測試，iOS和安卓端性能測試小工具
查看全部 -
總體 制作人 負責提出目標 策劃 負責將制作人提出的目標細化進行具體拆分 例如 打boss應該掉落多少道具 升級需要多少經(jīng)驗等等 程序猿 負責將這些做成程序 分為前端和后端和開發(fā) 。前端即平常看到的特效之類的，后端為數(shù)據(jù)管理之類的。 美工 畫畫的 測試 分六種 安全測試 ui測試 等等等等查看全部
-
1、游戲開發(fā)團隊：制作人、策劃、程序、美術、測試
2、測試分類：功能測試、性能測試、壓力測試、兼容測試、自動化測試、安全測試
3、游戲開發(fā)流程：
制作人：指定項目目標，規(guī)劃
策劃：講項目目標拆解成細致的需求，丙烯畫成文案
測試、程序、美術：將需求用代碼和美術資源實現(xiàn)出來，測試寫測試用例
測試：對項目的各個方面質(zhì)量控制，將發(fā)現(xiàn)的缺陷反饋結果
查看全部 -
BUG詳解
發(fā)現(xiàn)BUG僅僅是測試工作的開始
BUG的界定標準：與需求設計不符；違背常識
BUG的生命周期：發(fā)現(xiàn)bug；提交給開發(fā)；開發(fā)修復；測試驗證（不通過繼續(xù)指派給開發(fā)）；通過后關閉；上線前回歸
BUG的等級劃分：
P0：致命錯誤，需要立即修復，如宕機、重啟性報錯等；
P1：嚴重錯誤，需要緊急修復，如功能流程錯誤、數(shù)值錯誤等；
P2：一般錯誤，允許一段時間內(nèi)修復，如功能的簡單錯誤、界面錯誤等；
P3：無關緊要的錯誤，允許延期修復，如文字錯誤、某個像素點缺失等等
bug的報錯標準
標題：[模塊名稱]+簡短描述
測試環(huán)境：標明測試用的版本，系統(tǒng)，服務器，賬號等
描述：BUG的詳細描述
重現(xiàn)步驟：重現(xiàn)bug的詳細流程步驟及復現(xiàn)概率
期望結果：希望bug修復后的結果
備注：log，截圖等
bug舉例：
標題：〔士兵〕打開士兵技能升級頁面報錯
測試環(huán)境:內(nèi)網(wǎng)測試服，V1.1.0版本，iOS系統(tǒng)，賬號：ykl02
詳細描述：當我們在游戲中打開士兵升級頁面時，系統(tǒng)提示報錯信息
重現(xiàn)步驟:1、進入游戲。2、打開士兵技能升級頁面。3、系統(tǒng)報錯。
期望結果：能夠正常升級士兵技能，打開升級頁面不報錯
備注：報錯信息見下面截圖
BUG的驗證標準：
嚴格按照復現(xiàn)步驟驗證；
去除測試環(huán)境的影響，盡量使用提交BUG時的注明的環(huán)境；
驗證標注：需要注明驗證驗證的版本、服務器等
拓展：是否對其它功能有影響，做簡單回歸
注意點：驗證不能只看前端展現(xiàn)，更應關注后端數(shù)據(jù)
（比如購買道具，花了100，但是只扣了50；如果修復之后，前端確實顯示扣了100，但是數(shù)據(jù)庫中只扣了50，這就是“BUG的偽修復”）
BUG的跟蹤與推動：
每個人都有責任跟蹤自己的bug的修復狀態(tài)；
及時與開發(fā)溝通，了解修復狀態(tài)并提供修復過程中的支持；
久不修復的bug需要與開發(fā)和上級（需求人員）確認如何處理；
bug修復后，需要及時驗證
BUG的數(shù)據(jù)分析：
根據(jù)bug優(yōu)先級看各個優(yōu)先級的bug數(shù)量；
根據(jù)項目人員看各個開發(fā)人員的bug數(shù)量；
根據(jù)功能模塊看各個模塊的bug數(shù)量
查看全部 -
測試用例編寫
格式：清晰的格式很重要
首頁內(nèi)容：（用例關鍵信息）用例名稱；游戲版本；編寫人，編寫日期，備注；修改人，修改日期、修改備注；需求文檔的鏈接或地址
正文頁內(nèi)容：功能邏輯圖（若有，便于理解）、用例id、模塊名稱、測試先決條件（入口）、輸入信息、輸出結果、備注信息
注意事項：用例有清晰的邏輯、一個輸入只對應一個輸出、保證每次更新用例后都有明確的記錄標注、保證格式一致
常用編寫方法
等價類：一個輸入集合內(nèi)，任何輸入數(shù)據(jù)對于輸出的驗證來講都是等效的，所以選取少量代表性測試數(shù)據(jù)代表整個數(shù)據(jù)
有效等價類：是對輸出來講有意義的輸入集合，可以驗證程序的正常功能和流程
無效等價類：是對輸出來講無意義的輸入集合，驗證特殊情況
邊界值：對于輸入或輸出的邊界值進行分析
邊界值的確定：一般選取正好等于，剛剛小于和剛剛大于3種情況作為測試數(shù)據(jù)
適用：數(shù)值測試、字符串測試、數(shù)據(jù)類型測試等
因果圖：輸入與輸出之間因果關系的一種關系圖
適用于：輸入條件較為復雜，存在多種可能組合（笛卡爾積）的情況
方法：識別出因（所有輸入）、中間節(jié)點、果（所有輸出），并且根據(jù)關系連接起來
判定表：可以通過因果圖來生成的一種結果判定表格（因、中間節(jié)點、果，01表示是否存在）
因果圖常常與判定表一起使用，通過因果圖生成判定表，通過判定表來書寫測試用例
注意事項
輸入條件單一明確，不用容易引起誤解的詞，比如可能大概等
輸出要可判斷且明確，不用顯示正確這種詞匯
測試步驟要可執(zhí)行
保證盡量高的覆蓋度
能抽象合并的盡量抽象合并，避免無意義的冗余
測試用例整理與維護
需求變化后及時更新并備注修改情況（修改內(nèi)容、產(chǎn)品和開發(fā)負責人）
遇到冗余的測試用例，根據(jù)實際情況及時修改
注意測試用例的備份，在公司服務器上寫完后本地也備份一份，避免被人線上誤刪除
?0
采集?0
游戲測試入門
難度入門
時長?2小時35分
人數(shù)18129
評分9.8?
通過本課程的學習，大家首先會認識到游戲開發(fā)團隊及流程，然后明白游戲測試主要工作內(nèi)容，游戲測試基本工作流程，并學會需求文檔分析，功能模塊劃分以及游戲測試用例之用例編寫，整理與維護，接著你會了解到什么是Bug，如何鑒定Bug，以及如何在Mac環(huán)境下對弱網(wǎng)進行測試，最后你會學習到游戲客戶端性能測試（安卓，IOS）以及游戲接口測試，希望通過這門課程的學習，能讓你進入你期待的游戲測試領域。
ervinzhang軟件測試工程師微信公眾號&知乎專欄：游戲測試風云錄，
查看全部 -
功能模塊劃分
劃分原則：（博主自己的總結，不存在與任何軟件測試書籍中）
1、高內(nèi)聚，低耦合：模塊內(nèi)關聯(lián)度高；模塊間關聯(lián)度低，無法合并成一個模塊
比如一個貨幣購買的功能，月卡的購買和普通貨幣的購買可以劃分成兩個單獨的模塊，因為兩者幾乎不存在任何關聯(lián)度，購買其中任何一個模塊不會對另一個模塊產(chǎn)生影響，符合低耦合的原則；
如果就月卡的購買進行分拆的話，顯然沒必要繼續(xù)劃分成功能和UI兩個模塊，因為月卡的購買流程非常簡單，而且功能之間的關聯(lián)度非常高，符合高內(nèi)聚的原則。
2、重整體，輕局部：功能整體上關注模塊構成、邏輯和覆蓋范圍，不用糾結較為具體的細節(jié)
還是以貨幣的購買功能為例，整體上可以劃分為UI、購買與領取、特殊情況等大模塊，或許也可以劃分成一些子模塊；不用太關注細節(jié)，比如頁面上顯示的倒計時、UI按鈕的位置等等
劃分方法：（博主自己的總結，不存在與任何軟件測試書籍中）
1、功能流程法（小系統(tǒng)）：將功能的基本流程畫出來，根據(jù)流程的每個大的環(huán)節(jié)進行模塊劃分，然后再細化和查漏補缺
（銀行取錢模塊劃分：插卡 -- 輸密碼 -- 輸入金額 --取錢 -- 退卡）
2、層次劃分法（大系統(tǒng)）：按照邏輯層次逐層細化出模塊，直至不能劃分
（dota游戲模塊劃分：見截圖）
3、類型劃分法：按照功能內(nèi)容的不同類型進行劃分（如按照道具的不同類型進行劃分）
注意點
不同方法適用于不同場景
有時候一個功能要結合多種方法進行劃分
劃分方法不重要，原則更重要
劃分完成后，結合需求文檔重新梳理，確保模塊清晰、覆蓋完整、符合需求設計
查看全部 -
游戲測試流程
查看全部 -
游戲測試
查看全部 -
游戲測試用例01 - 設計步驟
需求文檔分析、功能模塊劃分、測試用例編寫、測試用例整理與維護
需求文檔分析：文檔閱讀、功能細節(jié)溝通探討、邏輯梳理、功能拓展思考、兼容相關思考
文檔閱讀：切忌不閱讀需求文檔，上來直接寫用例，至少讀3遍文檔
細致理解功能設計意圖和設計思路
避免粗略理解帶來的用例遺漏，保證測試用例的覆蓋度
重要數(shù)據(jù)可能隱藏在不起眼的語句中
加深對功能的記憶，以免遺忘功能細節(jié)
思考功能有沒有更好的實現(xiàn)方式
細節(jié)溝通探討：
不明白的地方及時溝通，切忌腦補
盡早確認所有細節(jié)，最好在開始寫之前就確認完畢
關注需求變更，需求變更后，一定要跟程序和策劃確認
邏輯梳理：
文檔不一定按照流程順序?qū)?，而且?jīng)常存在功能交叉的地方，最好自己梳理邏輯
首先梳理出框架，然后梳理出細節(jié)
功能拓展思考：
設計缺陷思考（領取道具：數(shù)量、種類）
測試難點思考（領取道具：如何測試其刷新（調(diào)整服務器時間或修改配置））
關聯(lián)度思考（領取道具：道具存儲）
特殊情況思考（領取道具時斷電斷網(wǎng)服務器維護等特殊情況）
兼容相關思考：
版本兼容，同時存在多個版本時的兼容（交互是否有問題）
功能兼容，老功能中添加新內(nèi)容（例如添加有不同屬性的英雄）
操作系統(tǒng)版本兼容，不同操作系統(tǒng)版本
分辨率兼容
查看全部 -
游戲測試主要內(nèi)容（本節(jié)課主要以手游為例）：
功能測試、性能測試、壓力測試、兼容測試、安全測試、接口測試、日志測試、弱網(wǎng)測試、gm工具測試、SDK測試
功能測試：
功能測試是游戲測試中最常見的模式，主要測試方法為黑盒測試；
功能測試主要用來驗證功能是否符合需求設計；
功能測試主要考慮功能正確性，而不考慮游戲底層結構及代碼錯誤；
功能測試通常從界面著手開始測試，盡量模擬用戶可能出現(xiàn)的操作。
客戶端性能測試：
客戶端CPU使用率，客戶端內(nèi)存占有率，客戶端網(wǎng)絡流量使用情況，客戶端耗電量，客戶端幀頻（FPS）
使用工具：
ios常用工具：xcode自帶的instrument
安卓常用工具：emmage和gt
服務端壓力測試：
服務器CPU使用率、服務器內(nèi)存占用率、系統(tǒng)吞吐量（TPS）、事務響應時間、事務成功率
兼容測試：
機型適配測試、操作系統(tǒng)兼容測試、屏幕分辨率兼容測試、游戲版本兼容測試
安全測試：
內(nèi)存修改測試、客戶端加密測試、客戶端反編譯測試、網(wǎng)絡安全測試
接口測試：
服務器各個接口數(shù)據(jù)測試，主要通過工具來實現(xiàn)（比如用性能測試工具Jmeter只發(fā)送一個數(shù)據(jù)包）
接口安全測試，重復發(fā)送請求，查看接口處理情況
日志測試：
客戶端日志、服務端日志
弱網(wǎng)測試：
不同網(wǎng)絡情況，游戲的運行情況，如edge、2g、3g、4g情況
不同丟包率情況下游戲的運行情況
通過工具設置網(wǎng)絡代理來實現(xiàn)，常用的fiddler（windows）、network link conditioner（MAC）
gm工具測試：
測試gm工具的功能實現(xiàn)，需要關注工具的設置是否在游戲中起作用
測試gm工具的數(shù)據(jù)讀取、存儲
SDK測試
用戶數(shù)據(jù)測試；充值、消費測試；與各個渠道對接測試
查看全部 -
BUG詳解
發(fā)現(xiàn)BUG僅僅是測試工作的開始
BUG的界定標準：與需求設計不符；違背常識
BUG的生命周期：發(fā)現(xiàn)bug；提交給開發(fā)；開發(fā)修復；測試驗證（不通過繼續(xù)指派給開發(fā)）；通過后關閉；上線前回歸
BUG的等級劃分：
P0：致命錯誤，需要立即修復，如宕機、重啟性報錯等；
P1：嚴重錯誤，需要緊急修復，如功能流程錯誤、數(shù)值錯誤等；
P2：一般錯誤，允許一段時間內(nèi)修復，如功能的簡單錯誤、界面錯誤等；
P3：無關緊要的錯誤，允許延期修復，如文字錯誤、某個像素點缺失等等
bug的報錯標準
標題：[模塊名稱]+簡短描述
測試環(huán)境：標明測試用的版本，系統(tǒng)，服務器，賬號等
描述：BUG的詳細描述
重現(xiàn)步驟：重現(xiàn)bug的詳細流程步驟及復現(xiàn)概率
期望結果：希望bug修復后的結果
備注：log，截圖等
bug舉例：
標題：〔士兵〕打開士兵技能升級頁面報錯
測試環(huán)境:內(nèi)網(wǎng)測試服，V1.1.0版本，iOS系統(tǒng)，賬號：ykl02
詳細描述：當我們在游戲中打開士兵升級頁面時，系統(tǒng)提示報錯信息
重現(xiàn)步驟:1、進入游戲。2、打開士兵技能升級頁面。3、系統(tǒng)報錯。
期望結果：能夠正常升級士兵技能，打開升級頁面不報錯
備注：報錯信息見下面截圖
BUG的驗證標準：
嚴格按照復現(xiàn)步驟驗證；
去除測試環(huán)境的影響，盡量使用提交BUG時的注明的環(huán)境；
驗證標注：需要注明驗證驗證的版本、服務器等
拓展：是否對其它功能有影響，做簡單回歸
注意點：驗證不能只看前端展現(xiàn)，更應關注后端數(shù)據(jù)
（比如購買道具，花了100，但是只扣了50；如果修復之后，前端確實顯示扣了100，但是數(shù)據(jù)庫中只扣了50，這就是“BUG的偽修復”）
BUG的跟蹤與推動：
每個人都有責任跟蹤自己的bug的修復狀態(tài)；
及時與開發(fā)溝通，了解修復狀態(tài)并提供修復過程中的支持；
久不修復的bug需要與開發(fā)和上級（需求人員）確認如何處理；
bug修復后，需要及時驗證
BUG的數(shù)據(jù)分析：
根據(jù)bug優(yōu)先級看各個優(yōu)先級的bug數(shù)量；
根據(jù)項目人員看各個開發(fā)人員的bug數(shù)量；
根據(jù)功能模塊看各個模塊的bug數(shù)量
查看全部 -
測試用例編寫
格式：清晰的格式很重要
首頁內(nèi)容：（用例關鍵信息）用例名稱；游戲版本；編寫人，編寫日期，備注；修改人，修改日期、修改備注；需求文檔的鏈接或地址
正文頁內(nèi)容：功能邏輯圖（若有，便于理解）、用例id、模塊名稱、測試先決條件（入口）、輸入信息、輸出結果、備注信息
注意事項：用例有清晰的邏輯、一個輸入只對應一個輸出、保證每次更新用例后都有明確的記錄標注、保證格式一致
常用編寫方法
等價類：一個輸入集合內(nèi)，任何輸入數(shù)據(jù)對于輸出的驗證來講都是等效的，所以選取少量代表性測試數(shù)據(jù)代表整個數(shù)據(jù)
有效等價類：是對輸出來講有意義的輸入集合，可以驗證程序的正常功能和流程
無效等價類：是對輸出來講無意義的輸入集合，驗證特殊情況
邊界值：對于輸入或輸出的邊界值進行分析
邊界值的確定：一般選取正好等于，剛剛小于和剛剛大于3種情況作為測試數(shù)據(jù)
適用：數(shù)值測試、字符串測試、數(shù)據(jù)類型測試等
因果圖：輸入與輸出之間因果關系的一種關系圖
適用于：輸入條件較為復雜，存在多種可能組合（笛卡爾積）的情況
方法：識別出因（所有輸入）、中間節(jié)點、果（所有輸出），并且根據(jù)關系連接起來
判定表：可以通過因果圖來生成的一種結果判定表格（因、中間節(jié)點、果，01表示是否存在）
因果圖常常與判定表一起使用，通過因果圖生成判定表，通過判定表來書寫測試用例
注意事項
輸入條件單一明確，不用容易引起誤解的詞，比如可能大概等
輸出要可判斷且明確，不用顯示正確這種詞匯
測試步驟要可執(zhí)行
保證盡量高的覆蓋度
能抽象合并的盡量抽象合并，避免無意義的冗余
測試用例整理與維護
需求變化后及時更新并備注修改情況（修改內(nèi)容、產(chǎn)品和開發(fā)負責人）
遇到冗余的測試用例，根據(jù)實際情況及時修改
注意測試用例的備份，在公司服務器上寫完后本地也備份一份，避免被人線上誤刪除
查看全部
舉報