亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

客戶端性能測試指標

我們該關注哪些指標?

CPU 內存 FPS

客戶端性能測試指標-CPU

這裡指的是遊戲所占用的CPU占用率

拋開場景談CPU性能無意義

android設備，建議90%的場景CPU占用小於60%

ios設備，建議90%的場景占用小於80%

游戲接口測試

什么是接口？代碼暴露出一部分屬性或方法

常見的接口分類 1.程序自身內部的模塊接口 2.程序暴露給其他程序調用的接口

弱網測試要解決的問題：1、網絡信號差的情況下，對游戲運行的影響2、高丟包率的網絡環境，對游戲的影響3、不同網絡信號之間切換時，對游戲運行的影響4、短線重連對游戲運行的影響5、前后端數據一致的問題

BUG詳解（發現BUG僅僅是測試工作的開始）

BUG 的界定標準；1.與需求設計不符 2.違背常識

測試用例編寫
1.格式

一個清晰的格式為何重要？

a·首頁內容：（用例關鍵信息）1.用例名稱，2.用例對應的游戲版本，3.編寫人，編寫日期備注，3.修改人，修改日期、修改備注4.需求文檔的鏈接地址

b·正文頁內容：1功能邏輯圖（若有，便于理解）、2用例id、3模塊名稱、4測試先決條件（入口）、5輸入信息6、輸出結果、7備注信息

c·關于格式的注意事項：1用例有清晰的邏輯2、一個輸入只對應一個輸出、3保證每次更新用例后都有明確的記錄標注4、保證格式一致
2.常用編寫方法
a·等價類：一個輸入集合內，任何輸入數據對于輸出的驗證來講都是等效的，所以選取少量代表性測試數據代表整個數據
有效等價類：有意義的輸入集合，可以驗證程序的正常功能和流程
無效等價類：無意義的輸入集合，驗證特殊情況

b·邊界值：1.對于輸入或輸出的邊界值進行分析2.邊界值的確定；一般選取正好等于，剛剛小于和剛剛大于3種情況做為測試數據4·適用范疇：數值測試、字符串測試、數據類型測試等

c·因果圖：1·輸入與輸出之間因果關系的一種關系圖
適用于：輸入條件較為復雜，存在多種可能組合（笛卡爾積）的情況
方法：識別出因（所有輸入）、中間節點、果（所有輸出），并且根據關系連接起來
2·判定表：可以通過因果圖來生成的一種結果判定表格（因、中間節點、果，01表示是否存在）

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

3·

4.注意事項
輸入條件單一明確，不用容易引起誤解的詞，比如可能大概等
輸出要可判斷且明確，不用顯示正確這種詞匯
測試步驟要可執行
保證盡量高的覆蓋度
能抽象合并的盡量抽象合并，避免無意義的冗余
5·測試用例整理與維護
需求變化后及時更新并備注修改情況（修改內容、產品和開發負責人）
遇到冗余的測試用例，如果遇到重復用例，根據實際情況及時修改
注意測試用例的備份

功能模塊劃分

（1）劃分原則：（博主自己的總結，不存在與任何軟件測試書籍中）

1、高內聚，低耦合：模塊內關聯度高；模塊間關聯度低，無法合并成一個模塊

比如一個貨幣購買的功能，月卡的購買和普通貨幣的購買可以劃分成兩個單獨的模塊，因為兩者幾乎不存在任何關聯度，購買其中任何一個模塊不會對另一個模塊產生影響，符合低耦合的原則；

如果就月卡的購買進行分拆的話，顯然沒必要繼續劃分成功能和UI兩個模塊，因為月卡的購買流程非常簡單，而且功能之間的關聯度非常高，符合高內聚的原則。

2、重整體，輕局部：功能整體上關注模塊構成、邏輯和覆蓋范圍，輕局部不用糾結較為具體的細節

還是以貨幣的購買功能為例，整體上可以劃分為UI、購買與領取、特殊情況等大模塊，或許也可以劃分成一些子模塊；不用太關注細節，比如頁面上顯示的倒計時、UI按鈕的位置等等

（2）劃分方法：（博主自己的總結，不存在與任何軟件測試書籍中）

1、功能流程法（小系統）：將功能的基本流程畫出來，根據流程的每個大的環節進行模塊劃分，然后再細化和查漏補缺

舉例;（銀行取錢模塊劃分：插卡 -- 輸密碼 -- 輸入金額 --取錢 -- 退卡）

2、層次劃分法（大系統）：按照邏輯層次逐層細化出模塊，比較適用于UI劃分，大的系統模塊劃分等

（dota游戲模塊劃分：見截圖）

3、類型劃分法：按照功能內容的不同類型進行劃分（如按照道具的不同類型進行劃分）

注意點

不同方法適用于不同場景 具體問題具體分析

有時候一個功能要結合多種方法進行劃分

劃分方法不重要，劃分原則更重要

劃分完成后，結合需求文檔重新梳理，確保模塊清晰、覆蓋完整、符合需求設計

游戲測試基本流程（6個環節）：

1.功能需求會議——>2.測試用例編寫——> 3.冒煙測試——>4.詳細測試——>5.回歸測試——>6.Checklist檢查

（1）功能需求會議(一般策劃人員開)：1.測試人員需了解需求內容，2.提出可能存在的風險點，3.思考功能的測試重點和難點，如需工具輔助，需提出開發要求，4.思考可以優化的地方，并提出導論。

（2）測試用例編寫：1.根據需求書寫測試用例，2.關注功能邏輯實現，3.考慮各種特殊情況（如邊界值，網絡中斷，進程中斷等），4.關注需求變更情況，需要及時調整測試用例。

（3）冒煙測試（不能完全發現bug,特點是快速過一遍功能，把明顯的bug告訴開發人員）：1.詳細測試前的一個小環節，2.快速發現比較明顯的bug3.快速確保主邏輯流程跑通，4.快速明確功能開展狀態（比如是否有明顯的功能缺失或者配置是否配全等等）

（4）詳細測試：1.細致的測試每個邏輯分支、資源、配置，2.盡量模擬玩家的每一種操作可能3.，測試異常情況（如斷網，斷電，事件中斷、進程中斷等），4.測試數據讀取、存儲、網絡等內容。5.測試該功能對其他功能影響

（5）回歸測試：1.測試已經被修復的內容，2.需求調整后的內容，3.再次詳細測試各邏輯分支。

（6）checklist（檢查點，快速，不細測，可有可無，發布版本時測試）：1.簡要快速的檢查功能的主要邏輯點，2.檢查與該功能有關聯的任何其他功能點。

1、游戲開發團隊：制作人、策劃、程序、美術、測試

bug的生命周期

Bug的提報標準?

• 

• 注意點

優先級P0 致命? ?立即修復

? ? ? ? ? p1 嚴重? ?緊急修復

????????? p2 一般? ?允許一段時間內修復

? ? ? ? ? p3 提示? ?允許延期修復

bug的提報標準

需求文檔分析

功能模塊劃分

測試用例編寫

測試用例整理與維護

文檔閱讀

細節溝通探討

邏輯梳理

功能拓展思考

兼容相關思考

游戲測試基本流程

測試工作人員

功能會議

測試用例書寫

冒煙測試

詳細測試

回歸測試

checklist檢查

弱網測試

edge， 2g ，3g， 4g

不同丟包概率的情況

工具? fiddler? , network link conditioner(xcode提供的工具)

gm工具測試

測試gm工具的功能實現

測試gm工具的數據方面

sdk測試

用戶數據測試

充值消費測試

各個渠道對接測試（日志數據，前后端數據對應）

功能測試

性能測試

壓力測試

兼容測試

安全測試

接口測試

日志測試

弱網測試

gm測試

sdk測試

事務成功率，響應時間

兼容性測試

壓力測試

性能測試

功能測試

游戲版本兼容測試

操作系統兼容測試

屏幕分辨率測試

安全測試

內存修改測試

加密測試

反編譯測試

網絡安全測試? ?明文or密文傳輸? ??

接口測試??

日志測試

客戶端測試日志? ?服務器測試日志