測試用例編寫說明 1
一、 什麼是測試用例 1
二、 我們的測試原則 1
三、 理解設計 1
四、 構造測試用例的框架 2
五、 充實用例內容 2
六、 可玩性測試部分 3
七、 易用性測試部分 3
八、 後續維護更新 4
一、 什麼是測試用例
為測試遊戲中某乙個或一組特定功能而制訂的測試方法，通常是關於該功能中若干測試點的集合。
我們的測試用例與軟體工程行業略有些不同，我們將一組測試點的集合放進乙個excel文件中，然後將這個文件稱為乙個測試用例。
二、 我們的測試原則
測試人員對自己的定位應該是把關人，不僅檢查製作質量是否合乎設計和有無錯誤，同時還要考慮設計質量，包括邏輯合理性、可玩性、數值平衡等方面，以及提示資訊、學習門檻、操作便捷性等影響使用感受的其它因素。
因此，測試主要有三個目地：檢驗功能正確、檢驗設計合理、檢驗使用感受。
在測試中，測試在檢驗、試用功能的同時，還需要有積極主動的心態，去思考功能系統中的各個元素、各個數值實際所起到的作用，以及它的價值，這些和設計定位是否一致、各組成部分之間的設計有無衝突、實際執行是否能達到設計目地。
所有這些考慮，都應將其記錄下來，向策劃反饋、溝通，盡量能夠說服策劃，或被策劃說服，盡量少留「保留意見」這樣的分歧。
只有收集衝突觀點，並且將其解決，才能排除設計盲點、照顧更大群體、做出最好的遊戲。
三、 理解設計
編寫測試用例之前，要明確該功能的設計，在腦中構造出這個設計的基本框架與內容。這樣編寫出來的用例才能做到測試條理清晰、減少測試漏洞。
為達到這個目地，我們使用功能覆蓋法與路徑分析法相結合的測試方法。
● 功能覆蓋法就是全面列舉系統所表現出來以及自己能想得到的各個細節，並逐一進行測試。這種方法直觀簡單，但不容易保證測試的全面性。
● 路徑分析法是從設計核心思想出發，按照系統流程與設計框架進行功能劃分。這樣脈絡清晰的方式可以較好地保證測試思路清晰，但需要對設計有較深的理解。
為保證達到目標，我們使用如下步驟與方法來理解功能設計：
1、 確認設計者（策劃負責人）、實現者（程式負責人），並在測試用例的表頭部分寫明。
a) 如果有多個策劃合作設計，或分塊由不同程式實現，或責任人發生了轉移，應在負責人後註明其負責的部分。
2、 明確策劃負責人之後，向其索要設計文件，並且盡可能地多利用策劃溝通、交流、測試實見等各種方式加強對該功能系統的了解。
3、 將各個方面收集掌握的資訊，在腦中、草稿紙或草稿文件中還原出基本設計模型。並與策劃溝通核對所還原的設計模型正確、無偏差、無遺漏。
a) 遊戲中大部分表現都是由規則驅動的。
b) 乙個系統中最根本的思路、最核心的規則通常可以用很少的幾句話表述出來。
c) 系統中每乙個模組（功能塊）都是為一定的目地而存在，都將為豐富、完善、保護系統本身而起到一定的作用。
四、 構造測試用例的框架
按設計的脈絡，把系統進行功能塊劃分，將整個系統拆分為多個功能塊。這樣就形成了測試用例的基本框架。
● 乙個良好的設計結構中，通常功能塊本身就已經有了良好的劃分。
● 劃分時要注意不遺漏、不交叉。功能塊劃分不清晰的部分往往最終就會成為測試盲點。
● 除了功能塊劃分之外，測試用例框架中還可以包含公共條件型別、關注點型別、功能與列舉型別等其它不同劃分。根據具體系統而實際選擇，或雙重劃分方式進行展開來構造用例的框架。
這個階段完成時，需要上傳測試用例，以便及時審核，發現問題時也便於修改調整。
五、 充實用例內容
在框架的基礎上繼續細化，盡可能將功能塊中的所有細節、邊界、條件都列舉出來，最終形成完善的測試用例。
用例中功能塊的細則大體上可以分為條件功能型，與元素列舉型兩大類：
1、 條件功能型：由規則得出結果，在某個（某些）條件下成功完成功能，而另一些條件下提示不可完成功能。包括遊戲中大部分具體操作如購買道具、使用技能等等。
a) 這類功能以邊界檢查為主。檢驗在正確條件下系統完成了它所應該做的事情，以及在錯誤條件下系統沒有做它所不應該做的事情。
b) 要考慮到各種可能的條件。例如乙個金錢輸入框，要確認以下合法與非法的輸入：0、負數、小數、超過身上攜帶有的金錢、超過設計上限、剛好達到身上攜帶金錢、剛好達到設計上限、公式、字母、漢字、特殊符號，以及不輸入直接點確定、輸入後點取消等各種邊界。
2、 列舉元素型：許多系統為了豐富而使用了大量列舉元素（如生活技能產出的各種裝備、遊戲中存在的各種野外常規小怪等）。這些列舉元素規則都完全相同，而在輸入不同時產生不同的結果。
測試時根據具體情況決定是逐個列舉全部測試或是抽查結合直接檢查策劃配置表的方式進行測試。
a) 這類功能需要為每個元素都進行一次相關測試點的驗證。確保每乙個元素的相關所有資訊全部正確無誤。
b) 可以複製貼上，不要嫌麻煩。
c) 列舉時要注意各個元素有無和其它元素所不同的特例。有的話要單獨寫測試點，並且高亮顯示出來。
● 由統一的公式規則演化出來多個元素的可以直接檢查邊界條件即可。
● 由列舉（逐個填表）產生的多個元素，如果數量很多，且影響範圍較小、bug級別較低，可以進行抽查。（如劇情任務的任務文字等）
● 由列舉產生的多個元素，如果影響範圍較大、bug級別較高的，必須進行遍歷全部測試。（如生活技能產品等）
● 不管哪種型別，都需要考慮各種資源（模型、貼圖、動作、特效、音效等）與提示資訊。
六、 可玩性測試部分
可玩性是針對策劃設計的把關，目地是檢驗這種設計在遊戲推出之後它能足夠好玩，能起到預期的作用。
絕大部分系統都是由策劃為了好玩的目地而設計（包括好友、郵件等通常稱為基礎功能的系統），只有極少數純功能性質的部分是完全沒有可玩性概念的。
通常可玩性設計需要進行以下幾個步驟：
1、 在理解設計結構的基礎上，進一步理解策劃做這種設計的意圖目地，以及對這種設計將要起到什麼樣作用的期望。並填寫到用例中。
2、 解析系統設計中的每乙個組成部分（功能塊），並理解策劃期望這個功能塊的作用目地。並填寫到用例中。
3、 系統中的各個條件、操作、數值是否會產生不良感受，為每乙個功能塊考慮是否有進行此項評估的必要，若有則填寫到用例中。
在可玩性測試部分，需要注意幾點：
● 注意，用例中的可玩性測試，是考察點，而不是考察結果。所以應該把所有認為值得進行考察的內容都寫進來，而不是僅僅記錄有問題的部分。
● 可玩性測試是乙個主觀測試，它經常會沒有客觀量化的標準，而是以自己感覺是否合適、是否舒服為依據。
● 乙個設計在很多時候並沒有絕對的好壞，而是在價效比、優缺點之間進行取捨。所以在感受到缺點時，應該與策劃溝通，但不應該固執已見。
七、 易用性測試部分
遊戲軟體是軟體工程的乙個分支，但遊戲軟體的特殊目地、特殊使用者群等差異使得我們會更加注重軟體的易用性。易用性測試主要包括：容易理解、容易學習、方便操作、吸引使用者、依從於主體風格與標準。
在我們已經有了各個功能部分的邊界、細節之後，系統功能整體層面的易用性考慮主要有以下幾個方面：
● 容易學習、理解、上手：乙個一無所知的新玩家是否能順利知道並掌握該功能。功能的學習模組是否足夠傻瓜化。（不要高估玩家的智商和求知慾）
● 介面清晰、方便、統一：介面的排版、布局、分組、分級是否足夠清晰。（不要挑戰玩家的忍耐力和觀察力）
● 操作方便順手符合習慣：操作盡量考慮到一鼠走天下的低操作玩家和左右開弓的強操作玩家的差異，並且與windows以及其它遊戲一致。能單個操作解決的不要用多個操作，能單鍵放得下的不要設計成組合鍵。
等等。（不要期望玩家為了你而改變自己的操作習慣）
● 提示清晰、細緻、統一：這個數字或符號代表著什麼？我正在做的操作將會導致什麼結果？
破壞性的操作是否有足夠強烈的警告？這兩個詞是指的同乙個東西嗎？等等。
（不要指望玩家能記得所有細節，更不要逼著他去用猜的）
● 世界觀統一且符合常理：同一陣營的角色們大方向應該統一而不是製造混亂認知、遊戲內的道德觀應該與現實社會相一致等等。（不要讓玩家忍受價值觀相悖的不適感，更不要逼迫玩家為了乙個遊戲而改變他的人生價值觀）
八、 後續維護更新
● 當設計或實現發生改變時，需要更新測試用例。
● 每一次進行測試時，要思考有沒有遺漏的測試點，尤其是細節邊界部分。發現的遺漏要及時更新進用例中。
測試用例說明
測試用例設計 百科名片 測試用例就是乙個文件，描述輸入 動作 或者時間和乙個期望的結果，其目的是確定應用程式的某個特性是否正常的工作。目錄定義 測試用例的基本格式 1.用例編號 2.測試標題 3.重要級別 4.測試輸入 5.操作步驟 6.預期結果 軟體測試用例 重用同型別專案的測試用例 利用已有的軟...
編寫測試用例方法心得體會
由安博測試空間技術中心提供 blueski推薦 2006 7 29 出處 csdn blog 作者 微風拂面 編寫背景 一直以來都不太想把技術方面的文章寫出來給大家看，乙個是怕寫作功底不好誤導哪些剛入門的測試同行，自己的表達能力有限，另一方面怕有的同行拿出去炒作，再者測試 論壇上關於測試用例的資料已...
編寫測試用例時,需要注意的事項
測試用例設計的粒度需要考慮幾方面的因素 1 復用率 如果隨著產品不停得公升級，需要設計的詳細些，追求一勞永逸 僅使用一兩次，則沒有必要設計的過於詳細 2 專案進展 專案時間如果允許可以設計的詳細些，反之則能執行即可 3 使用物件 測試用例如果供多人使用，尤其讓後參加測試的工程師來執行，則需要設計的詳...