遊戲軟體功能測試用例編寫

　　一、遊戲軟體與通用軟體的區別

　　a）通用軟體的需求明確，遊戲軟體需求理想化

　　i. 通用軟體中使用者每步操作的預期結果都是明確且有規範可參考的，而網遊中並不是所有的需求都有一個明確的預期結果，拿技能平衡性來說，我們所謂的平衡也只是相對的平衡，而非絕對的平衡。沒有什麼明確的參考參數。只能根據以往遊戲的經驗獲得一個感知的結果。

　　ii. 網路遊戲中的某些功能是有預期結果可參考的。例如組隊、交易，而另外一些帶有策劃創意的功能，卻是根據策劃個人的理解，來確定其預期結果的。人的思考力都是有限的，所以不能保證在他的創意中會考慮到各種各樣複雜的細節。也不能夠保證這個創意就可以完全被使用者所接受。

　　當你作為遊戲測試人員時，很多時候你需要做的不僅僅是驗證功能。也需要協助開發人員和使用者找到一個互相容忍的平衡點。遊戲軟體的測試員帶有對策劃需求的懷疑，力求通過自己的努力在玩家和開發人員之間將可能產生的矛盾減小。

　　b）通用軟體開發過程中需求變更少，遊戲軟體開發過程中需求便更快

　　i. 通用軟體的使用人群和軟體的功能針對性，決定軟體從開始製作就很少再有新的需求變更。而遊戲軟體，為了滿足玩家對遊戲的認可度，策劃需要不斷的揣摩玩家的喜好，進行遊戲功能的改進。加之網遊製作本身就是一個龐大複雜的工程，開發人員不可能做到在開發的前期，就對遊戲架構及擴充性做出最好的評估。所以導致為了滿足使用者的需求而不斷的進行一些基礎架構的修改，基礎架構的修改必然導致某些功能的顛覆。所以就出現了，遊戲開發過程中的一個惡性迴圈，當基礎架構修改到滿意了，玩家的需求又有了新的變化，隨之而來的又要進行新的調整，再進行新的修改。最終導致了遊戲軟體的開發週期不斷加長。任何一個有經驗的團隊，對於每一個影響基礎的改動都應該做出正確的評估。

　　二、網遊有哪些測試內容

　　a）效能

　　i. 用戶端效能

　　ii. 伺服器端效能

　　1、伺服器

　　2、資料庫

　　iii. 網路

　　b）功能

　　i. 從運行完game.exe開啟遊戲介面後可進行的各種操作、玩法

　　ii. 介面

　　iii. 音樂

　　c）自動化

　　i. 測試工作組織實施中需要的工具、軟體、平台的開發

　　ii. 自動化的迴歸測試作用：遊戲中基礎的、變動不大的、出錯率高的、可進行checklist重複測試的功能、效能等自動化是一個好方法

　　iii. 任何時候自動化都取代不了人腦，它只是將一些重複性的勞動從我們測試人員身上去掉，讓我們有更多的時間做更有意義的事情，如果你覺得你做一件事情是重複的，且有規律可行的，不防考慮自動化。

　　三、遊戲中針對功能性測試測試案例編寫淺談

　　先瞭解下遊戲中有哪些功能：

　　a）遊戲發開中的功能有哪些

　　i. 不同的遊戲對於功能的劃分不同，但是目前主流一些功能劃分中有以下內容：

　　1、基礎操作
　　2、Npc
　　3、地圖
　　4、裝備
　　5、劇情
　　6、技能
　　7、人際
　　8、PVP
　　9、……

　　這樣我們很簡單的將整個遊戲的功能進行了劃分，劃分完畢，下來的工作就是針對某個功能的測試了。很多人都問過一個問題，遊戲測試中測試案例到底有什麼用。下面繼續~

　　b）遊戲測試的測試案例有什麼作用

　　i. 測試執行過程中，按照用例指示的操作檢查操作結果是否正確，記錄測試過程中發現的bug

　　ii. 按照用例的執行結果確認功能的通過與否，也有的按照用例的覆蓋率來確定單服測試的通過與否

　　iii. 便於迴歸測試的執行

　　這樣講應該比較明白了吧。

　　c）測試案例應該包括什麼——測試執行過程中所需的所有資訊，舉例說明下。例如：

　　i. 表頭：功能名稱、案例編寫人員、編寫時間、測試人員、測試時間

　　ii. 本文：功能點、測試點、測試輸入、預期結果、實際結果

　　iii. 用例執行結果統計

　　d）功能點模組化理念

　　都知道一個複雜龐大的系統，程式在實現時會將其分成若干模組按照模組功能優先順序進行實現。我們測試過程中也採用這種方法，將複雜的功能點按照實現功能進行分類，分類後的測試點，再進行分類，直至細分成為一條條用例。就像庖丁解牛那樣。

　　按照等價類別劃分法，將同一判斷條件的測試點組成一個集，在這個條件基礎上再次判斷的條件，我們假設它已經成立。這樣在用例設計過程中就需要測試人員清楚的知道，哪些條件是一類需優先確認的，哪些是以這類條件為基礎的。我們最終形成的測試案例一定確保的是一條用例只檢查一個測試點。

　　這樣設計也有另外一個好處，如果一條用例不能走通，其它的還可以繼續檢測，經常會遇到測試過程中由於一個bug，導致測試工作停滯。現在這樣子我們就可以採取指令碼調試，或者其它方法跳過有bug的測試內容，繼續進行其它測試點的測試了。

　　e）情境測試法協助功能點細分

　　遊戲測試中，情境測試方法是經常用到的一種方法，什麼是情境測試法，及按照功能設計要求，在腦中類比出來的一個功能使用時的操作流程。按照每步操作的針對點，將針對點劃分為所用例設計時的小功能點。劃分時需每步針對點的各種檢查點分到該功能點內設計為該功能點的檢查點。再根據檢查點進行測試輸入（及操作過程）的編寫。用例編寫過程中的思考方式就如上了。講起來比較抽象，希望對大家有所協助。

　　f）用例的設計原則——一直有人問到底要詳細到什麼程度

　　i. 我們不期待用例編寫到任何人都可以執行，也沒有這個必要

　　ii. 我們針對的是網遊的測試人員，至少是玩過網遊的人，這些人對於遊戲中的基礎設定都有認識，我們不可能對著一個不知道任務介面是什麼的人大講怎麼測試工作。所以我們用例編寫的原則就是針對我們測試組內的測試人員。

　　iii. 但是，請不要簡略到別的測試人員看不懂，特別是當你是專職的用例編寫人員時，編寫時請多考慮下語言描述的方式。請讓你的同伴可以看懂，你所要表達的意思。

　　iv. 用例是沒有固定格式的，它的主要原則就是，測試中所需所有資訊，我通過你的文檔都能夠擷取到。所以不要再執著的像別人要模板。模板你自己都可以設計，發揮你的創意。

　　四、編寫過程注意事項

　　與設計人員的溝通

　　拿到一份文檔時請不要急於編寫，在這之前很多事情需要做，請先將文檔閱讀至少三遍，然後思考下，你自己大腦中是否有你所看文檔功能點的一個流程圖，當確認已經準備好了。開始設計用例，用例設計的過程就是與設計人員不斷溝通，深入瞭解功能的過程。你會發現，或許跟你之前流程圖中想像的並不完全一樣。這個時候不必驚訝，去找他們核對就好。不怕發現問題，就怕沒有發現問題，最終做了很多無用功。編寫過程中發現的沒有預期結果的內容，請及時與策劃人員、程式人員核對，必須三方核對。核對完畢提醒策劃人員及時更新設計案，提醒程式人員設計案新修改內容。這樣你會發現，設計測試案例過程的本身就是發現策劃案不完善的過程。

　　請運用你的思維，採用邊界法、等價類別劃分法、錯誤推斷法、以及以往的經驗，將每一個測試點的所有需檢查點進行充分的設計。發揮你的主動性，和測試組內其它人探討你認為可能存在風險的測試點，以便得到更多有價值的資訊。