QA 測試用例設計

一、【

flash

遊戲測試設計】

此款遊戲的需求不算太複雜，既沒有多種模式的選擇（水果忍者遊戲），也沒有多種關卡設計（祖瑪遊戲），在測試時偏重操作性及資料正確性。進行功能測試用例編寫之前，首先進行測試用例設計：

『

首先是基本功能的驗證

』測試用例首先應該對基本功能進行覆蓋，基本功能就是能保證玩家能夠進行乙個完整的流程操作，即啟動—開始—退出三個基本步驟，然後再根據每一步進行測試項分解：

每個測試項有相應的測試點，比如遊戲啟動測試項，其測試點根據圖示、顯示方式、啟動時間、按鍵操作分類後進行測試內容細化：

測試項

測試內容

遊戲圖示

圖示的大小符合需求中的設計

圖案跟需求說明書的原型一致

介面顯示

在不同的解析度下顯示全屏

啟動成功後，游標模型顯示正確

啟動項檢查

啟動時間不超過需求中規定的約束值

啟動成功後，遊戲的程序名沒有錯誤

按鍵操作

啟動過程中通過功能鍵強制中斷

其他的測試點的細則不一一枚舉，根據遊戲中的實際情況進行細化。

『

每個介面的測試

』基本功能雖然能保證遊戲的操作流程正常，但對於遊戲內容的正確性是無法保證的，介面也是玩家在體驗過程中會關注的內容，因此對於遊戲內容的檢查首先應該根據各個介面進行下手，其中每個介面的跳轉路徑測試，也保證除基本流程之外的分支流程能夠正確，其測試項有：

『

遊戲元素的細分

』介面只是遊戲內容的一小部分，實際上遊戲內容遠不止繁多的介面，通常還有角色人物、道具、音效、成績、獎懲規則等元素。此款遊戲沒有生命值的需求，所以獎懲規則沒有在測試設計中考慮，根據遊戲元素整理的測試項如下：

『

占用資源的關注

』遊戲的資源占用也屬於功能測試的重要內容，測試結果需要在測試報告中記錄，通常都是記錄遊戲的

cpu占用及記憶體消耗，需要注意的是這兩項數值都是實時變化的，因此需要記錄的資料需要進行篩選，選擇重要的初始值和峰值進行記錄。

如何才能得到這兩類資料的峰值？這需要設計合理的測試場景：1）

cpu占用理論上是遊戲執行緒越多，讀寫資料操作越頻繁，則

cpu占用的數值就越高，因此

cpu占用的峰值測試場景為玩家操作頻繁的介面中。

2）記憶體消耗則是根據遊戲在執行時載入的資源多少來決定的，因此理論上玩家玩的時間越長，載入的介面、元素越多，記憶體的消耗就越大，因此峰值的測試場景需要盡量遍歷所有介面、接觸到所有道具，測試時間也需要在

4個小時以上。

『

異常場景設計

』異常場景的是對測試用例覆蓋率最有效的補充，往往最容易暴露問題的就是異常的操作或環境。用例的設計需要考慮遊戲與系統如何進行資料互動、遊戲採用框架以及哪些資料需要跟其他軟體進行傳遞的。

測試的flash

遊戲執行在

linux

環境，與底層系統的互動涉及到運算元據和玩家成績：運算元據（角色在遊戲中的左右移動）是通過

pipe

管道與底層系統進行互動，玩家成績（最高高度和最大得分）的則是通過

scroe.xml

檔案進行儲存。因此異常場景的測試項有：

此款遊戲的測試用例設計思路已經基本完成，然後就需要對每個測試項進行測試點的細化，最後執行測試進行功能驗證了。

後記：是否完成了功能驗證，就意味著遊戲沒有嚴重問題？實際上這款遊戲上線之後，根據伺服器的一段時間日誌統計，並沒有多少玩家去玩，雖然遊戲不存在影響執行問題，但此款遊戲在市場上表現並不成功，我們忽視了遊戲開發環節中一項重要的工作，那就是使用者體驗測試，在完成遊戲功能測試之後，應該在公司內部或現網試執行階段進行遊戲體驗，收集和篩選反饋建議，檢視遊戲哪些內容需要豐富以增加使用者粘度、是否存在捷徑可以刻意降低遊戲難度、哪些元素缺少吸引需要去掉等。遊戲不像商業軟體，有特定的使用者和明確的需求，遊戲應該注重使用者粘性，這樣就需要考慮使用者體驗、遊戲平衡、玩家成就感等內容，因此測試時也需要重點考慮這些。

QA 測試用例設計

測試用例設計

測試用例設計

測試用例設計

相關推薦