游戲測試用例怎麼寫

『壹』 什麼是測試用例如何設計測試用例

測試用例是將軟體測試的行為活動做一個科學化的組織歸納，目的是能夠將鏈轎軟體測試的行為轉化成可管理的模式，同時測試用例皮或也是將測試具體量化的方法之一，不同類別的軟體，測試用例是不同的。不同於諸如系統，工具，控制，游戲軟體，管理軟體的用戶需求更加不同的趨勢。

測試用例常見的設計方燃喚伍法有：

1、等價類劃分法，就是將測試的范圍劃分成幾個互不相交的子集，他們的並集是全集，從每個子集選出若干個有代表性的值作為測試用例。

2、邊界值分析法，即針對各種邊界情況設計測試用例。

3、錯誤推測法，在測試程序時，人們可以根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。

4、判定表法，又稱為策略表，基於策略表的測試，是功能測試中最嚴密的測試方法。該方法適合於邏輯判斷復雜的場景，通過窮舉條件獲得結果，對結果再進行優化合並，會得到一個判斷清晰的策略表。

5、正交實驗法。

『貳』 測試用例是根據什麼來寫的

目前沒有經典的定義。
比較通常的說法山森是：指對一項逗旅畝特定的軟體產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。

不同類別的軟體，測試用例是不同的。不同於諸如系統、工具、控制、游戲軟體，管理軟體的用戶需求更加不統一，變化更大、更快。筆者主要從事企鎮臘業管理軟體的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨於是針對軟體產品的功能、業務規則和業務處理所設計的測試方案。對軟體的每個特定功能或運行操作路徑的測試構成了一個個測試用例。

『叄』 回合制游戲戰斗系統測試用例

你弊慶這要求的范圍也太大了，一個游戲測試用例包括人物，技能，界面，常用功能，性能等等測試用例。我估計你想要的就是回合制游戲中的回合制戰斗這塊用例吧。
回合制游戲與普通2D,3D游戲不同的是戰斗場景的切換，這點需要重點考慮。
大概的測試點：
1.場景切換後人物信息復制
2.場景切換前後並鍵功能互斥
3.新場景中的信息調用
4.場景切換前後狀態存儲
5.新場景中所有人物信息與戰斗狀態的同步
6.不同場景內外人物交租蔽握互
暫時想到的就是這么多，其他的你應該與你們策劃與程序討論，一個游戲測試的測試用例需要與策劃、程序多次討論才能定型

『肆』 測試用例是什麼意思

問題一：什麼是測試用例 一個測試用例描述了針對某個目標對程序進行測試所採用的一組實際輸入、程序執行條件、測試步驟和預期的輸出，以核實某個程序或其中的特定路徑是否滿足特定需求。由於程序輸入的范圍會非常大，因此會導致一個軟體可選的測試用例數目巨大（甚至是無窮的）。這時，需要恰當地設計和選擇測試用例集，以在限定的資源和時間內，盡可能地暴露軟體中的錯誤。因此，測試用例集的設計通常被認為是測試中最重要、也是最困難的方面。由於實際測試中使用的測試用例集的輸入范圍只是程序輸入的子集，因此即使軟體通過了測試，也無法保證程序一定是正確的。這說明測試本身是不完全的，不能證明程序無錯。人們認為，軟體測試活動從未間斷，只是在軟體交付用戶使用後，將由用戶扮演測試角色而已。 對每個測試用例都需要給出具體描述，表1給出了一個測試用例模版示例。 表1 測試用例模版用例標識：對該測試用例賦予一個唯一標大改識用例開發者：誰編寫的本用例 用例開發日期：編寫用例的日期測試項：描述將被測試的具體特徵、代碼模塊等對象測試輸入：測試時為滾大判程序提供的輸入數據前提條件：執行測試時系統應處於的狀態或要滿足的條件等環境要求：執行測試所需的軟硬體環境、測試工具、人員等測試步驟：(1)……；（例如，點擊「文件」菜單中的「新建」菜單項） (2)……；（例如，在「test case」目錄下選擇「test5.dat」文件）……預期輸出：希望程序運行得到的結果 用例之間的依賴性：該測試用例依賴或受影響的其它測試用例 當測試用例數量多時，文檔化的工作量就比較大。這時，模版內容在實際測試中可以根據需要進行簡化，例如把各個測試用例所共有的內容單獨列出來（如環境要求），並把所有測試用例用一張表格描述出來。

問題二：軟體測試用例的依據是什麼 1、軟體的需求文檔，開發的開發文檔（如果有）（功能相關）
2、根據產品具體的使用環境設計相關用例（兼容性相關）
3、根據目標用戶的特點設計用例（用戶體驗相關）
4、根據相關公司標准和業界、國際標准設計測試用例（性能。安全相關）

問題三：什麼是測試用例？ 測試用例（Test Case）是將軟體測試的行為活動做一個科學化的組織歸納，目的是能夠將軟體測試的行為轉化成可管理的模式；同時測試用例也是將測試具體量化的方法之一，不同類別的軟體，測試用例是不同的。不同於諸如系統、工具、控制、游戲軟體，管理軟體的用戶需求更加不同的趨勢。
要使最終用戶對軟體感到滿意，最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實並確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式並由不同的測試員來實施。例如，執行軟體以便驗證它的功能和性能，這項操作可能由某個測試員採用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場佔有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。
既然可能無法（或不必負責）核實所有的需求，那麼是否能為測試挑選最適合或最關鍵的需求則關繫到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。
我們公司於上使用日事清來進行編輯測試用例，同時執行測試用例，並取得不錯的成效。日事清是專業的企業管理軟體，可自動生成工作總結，進行日程計劃、團隊協作。
也可以算個人，也可以算企業，以為既可以管理個人的個人日程也可以管理整個團隊裡面的日程。

問題四：測試用例和用例規程有什麼區別 首先說,測試文檔與測試用例不是一個概念. 測試文檔包括整個測試過程中的測試計劃,測試方案,測試用例,測試規程,測試記錄,測試報告,缺陷報告等仿羨.所有文檔,每個文檔所涉及內容不同. 而測試用例主要根據方案中的測試方法設計的測試執行步驟及預期結果,

問題五：什麼是測試用例 不知道你是否了解測試用例的基本設計方法，包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交分析……剛進入軟體測試，你說根據設計出的圖來寫測試用例更好一點，那你就用這種方法也行，主要目的是測到盡可能多的情況。用例來自需求，回歸需求

問題六：什麼是測試用例 什麼是測試腳本 兩者的關系是什麼 測試需求是主要是整理測試焦點（包括一些界面、輸入域、業務流程、數據等），並明確測試焦點的優先順序，為測試用例的設計提供測試所需的功能點信息。測試需求的分析也會體現用例設計方法，有的測試需求分析文檔中也會指導性的明確焦點的測試用例設計方法。 可以說，測試需求是告訴你要測什麼，而測試用例是告訴你怎麼測。 好的測試需求能發現需求中顯性和隱性的測試焦點，從而能更好的指導測試用例的設計，能更好的提高被測模塊整體功能的覆蓋率。 測試需求分析會根據不同階段的測試類型會有不同的側重點。我是做系統測試的，主要注重系統或軟體是否滿足用戶需求的情況。平時做測試需求時會比較明確系統的功能模塊和測試點明細整理，也會把測試案例設計方法同時加入到分析文檔中。

問題七：軟體測試中，測試用例里的測試結果P/F，這「P/F」指的是什麼？ P pass 通過
F Fail 失敗

問題八：什麼樣的用例是好的測試用例 1、用例覆蓋程度
毫無疑問，這一點應該是最重要的，無需多說，覆蓋率最大化是一套測試用例的最重要評價標准，如果漏測就杯具了。2、用例是否已經達到工作量最小化
在滿足用例覆蓋程度最大化的前提下，應該盡量減小執行用例所需要的工作量。這些方面的方法有不少，如條件覆蓋，分支覆蓋，正交覆蓋等方法。面對不同的測試對象，也有不同的方法來保證：對於網頁背後的php邏輯，可以通過在網頁上測試後，用一些工具比如xdebug來統計代碼覆蓋率；對於向外提供介面的server
，採用的方式就是分析在外面暴露的介面設計用例，大致的通過介面參數來估計一下分支判斷的情況。
3、用例的分類以及描述是否足夠清晰
用例的分類，在這里是指相同類型的用例是否放在一起了。例如：介面類的用例，參數的取值范圍是1-3，但是現在卻傳入4；數據類用例，狀態機現在位於狀態2，卻要求狀態跳轉到無法到達的4；邏輯類用例，正常功能的產出等。將相同類型的用例放在一起，有助於理清思路，清楚了解用例設計是否完備。
用例的描述，是指描述的清晰程度是否能夠形成文檔。例如上面參數取值范圍的例子，用例這樣寫：「傳入錯誤的值」或者「傳入非1-3的值」，明顯沒有寫成「傳入值4」有效。這與寫程序一樣，總是寫閉區間的范圍而不是開區間。4、用例是否表明了測試目的
寫明用例的測試目的，對文檔的易於理解性和工作交接的好處不言而喻，現代軟體工程不可能只有一個人在做事情，項目於人員的變動也是難免的。在過程中留下足夠的信息，可以在後續工作提高很多效率。5、測試用例的易於維護性
如果被測對象有所升級，測試用例的說明或者腳本是不是容易維護呢？例如在有狀態機的情況下，測試用例之間是相互依賴的（即需要一定的執行順序），這樣被依賴的用例修改後，後端不需要同步根據修改。而如果用例之間沒有相互依賴關系（如用例是自己造的數據，不是依賴於前端的產出），可能一旦有變化，就需要修改這兩個。當然，這兩種情況不能絕對的說哪種好，是需要看實際使用時候的情況進行取捨的。

問題九：軟體測試用例中報告結果的N/A是什麼意思？ CMCC測試用例中的N/A，是指沒有條件或者環境去測這一條CASE，比如某一條case需要某種輔助工具去測試，而這種輔助工具沒有，那就是N/A。總之是不用測或者是沒有測的意思

『伍』 測試游戲道具的後台管理怎麼寫用例

最經典的莫過於三角形的案例，先寫代碼，再寫測試案例！！！！測試工程師必備知識！

三角形設計測試用例的問題在面試的時候經常遇到。
假設輸入三個整數a、b、c分別作為三邊的邊長構成三角形。通過程序判定所構成的三角形的類型，當此三角形為一般三角形、等腰三角形及等邊三角形時！要求畫出程序的流程圖和時序圖，並且用自己熟悉的一種語言實現這個功仿做能！我在網上搜索了一下發現已經有好多文章，不過發現很少有寫出程序的，其實用java語言也可以實現，流程圖和程序圖參考的網上的。

三角形設計測試用例的問題在面試的時候經常遇到。

假設輸入三個整數a、b、c分別作為三邊的邊長構成三角形。通過程序判定所構成的三角形的類型，當此三角形為一般三角形、等腰三角形及等邊三角形時！要求畫出程序的流程圖和時序圖，並且用自己熟悉的一種語言實現這個功能！我在網上搜索了一下發現已經有好多文章，不過發現很少有寫出程序的，其實用java語言也可以實現，流程圖和程序圖參考的網上的。

數握程序如下：

package sanj;
/**
*
* @author xingzunxi
*/
import java.io.*;
class sanj{
public static int a,b,c;
public static void main(String arg[]) throws IOException{
try{
BufferedReader stdin=new BufferedReader(new InputStreamReader(System.in)); //接收鍵值
System.out.println("輸薯大慶入三邊值，每個值輸入後回車");
System.out.println("請輸入:");
a=Integer.valueOf(stdin.readLine());
b=Integer.valueOf(stdin.readLine());
c=Integer.valueOf(stdin.readLine());
}catch(IOException e){
System.out.println("出現異常!");
System.exit(0);
}
if(a b

『陸』 怎麼編寫王者榮耀背包的測試用例

沒辦法看到王者榮耀的策劃案，不過背包用例不外乎幾種操作，我對著背包界面寫了個大概的檢查點，實際上全部內容擴展出來應該有100多條，請根據實際情況增補。

1. 背包界面的基本展示，進入、返回。

2. 左側的7個標簽：全部、最近獲得、道具、禮包、體驗卡、前森局內表現、銘文，這些分類按鈕是否能正常點擊切換，每個物品的類別是否基搜正確。點全部是不是所有物品都顯示了，每個類型的該出現在哪的就出現在哪，某個分類里不應該出現其他分類的東西。

3. 背包中每頁顯示多少個物品，背包為空的時候進入退出是否正常，少於一頁是否能正常顯示，多於一頁是否能正常翻頁。

4. 背包中有多個物品種類時，排序是否正常（慧鋒畝要和策劃、開發確認默認的排序是什麼），反復進入、退出、用掉一兩種物品，排序是否會亂。
   

5. 獲得一個物品，檢查這個物品是否正常放入背包，是否正確排序。在王者榮耀中，能夠獲得的物品包括：銘文、皮膚碎皮、英雄碎片、英雄體驗卡、皮膚體驗卡、雙倍金幣卡、雙倍經驗卡、改名卡、活動道具（喇叭、優惠券、限時播報和回城效果），每種寫一條用例。

6. 使用一個物品，這個物品還有剩餘，檢查物品數量是否-1。（以上所有物品都用一遍）

7. 使用一個物品，這個物品全部被用完了，檢查背包內的物品是否消失，排在後一位的物品是否自動填補這個物品的空位。

8. 批量使用物品，但是不用完，檢查物品數量，檢查該物品的效果是否生效。

9. 批量使用物品，當某種物品用完時，排在後一位的物品是否自動填補空位。

10. 出售一個物品、批量賣出物品，照著使用物品的用例，把使用換成賣出再測一遍。

11. 當物品是銘文時，裝備、卸下、分解銘文，檢查背包里的銘文內容是否正常變化。

12. 物品疊加上限（如果有），這個要找開發確認，每一格最多疊加多少個，如果玩家有生之年能疊到上限，那麼測一下達到上限時，再獲得一個會怎樣，是另開一格疊加，還是不再獲得，必須用掉才能獲得。（總之要有個處理方案，不能崩了客戶端）

13. 接上，物品疊加到上限後，用掉或賣掉幾個，再重新獲得，能不能正常疊加。

14. 背包上限（如果有），同樣找開發確認，背包一共有多少個格子，現有的道具種類能不能塞滿格子，如果能塞滿，那麼測一下背包格子塞滿的時候，再獲得一種物品會怎樣，是不是能正常提示背包滿了？

15. 接上，背包滿了之後，用掉或賣掉一種物品，再獲得這種物品或者其他物品，是不是能正常獲得了。

『柒』 如何養成一套編寫游戲測試用例的邏輯

整個邏輯式便為假的情況，就要求（）里態猜的內容是真.}
這個例子里邊。
其實，要想讓一個因式的MCDC達到100%，基本也就達到要求了吧。
至於你說的基路徑測試，如：
if(a講起來不太好講。會不會測試工具？比如testbed之類的，簡單的測試只要求讓每一個分支的真、假兩種情況都得到測試就行了，例如，已經有「a;b」為真脊閉豎;b c==d) {.、是假都得到測試，我的理解是;c==d、MCDC等達到100%;b且c==d（用例1）;能夠分別決定上述邏輯式的真假，接著上面的兩個測試用例，可以看到「c==d」這個因式的修正判定已經到100%了，因為它的真假在上面2個測試用例中已經直接決定了上述邏輯式的真假，在用例1中，它為真，整個邏輯式為真；在用例2中，它為假，整個邏輯式為假。所以現在就需要讓a..？
我將我的理解說一下;b，讓此因式唯一決定最終結果就行了..：alt;b且c==d（用例3）。至此，只要讓語句覆蓋率以及分支覆蓋率，但是如果要求比較高的話;b的修正判定達到100%。用例1中，MCDC均達到100%，我不是太明確是什麼意思，要想讓分支覆蓋達到100%，簡單點兒說，這是一個測試用例；然後令櫻大a;b且c!=d（用例2）。
這樣分支覆蓋已經達到100%，比方說，在c==d的情況下，就要求修正條件判定覆蓋（MCDC）達到100%，只要讓邏輯式中的其他因式不影響最終結果，就是讓每一個條件判定中的因式唯一決定邏輯值的真假，這里就是說讓a，可以讓a。記住這一點就行了，多練練。邏輯覆蓋如果MCDC達到100%，這樣，應該會更加直觀。
加油：
從邏輯覆蓋來講，你沒完成一個測試用例，它都可以給你每種覆蓋率的值，也可以給你展示測試用例已經走過的路徑，整個邏輯式為真的情況，所以就要找出一個「a;b」為假，所謂的基路徑應該不成問題了吧。
如果會用工具的話、

『捌』 測試用例是什麼意思

什麼是測試用例
一個測試用例描述了針對某個目標對程序進行測試所採用的一組實際輸入、程序執行條件、測試步驟和預期的輸出，以核實某個程序或其中的特定路徑是否滿足特定需求。由於程序輸入的范圍會非常大，因此會導致一個軟體可選的測試用例數目巨大（甚至是無窮的）。這時，需要恰當地設計和選擇測試用例集，以在限定的資源和時間內，盡可能地暴露軟體中的錯誤。因此，測試用例集的設計通常被認為是測試中最重要、也是最困難的方面。由於實際測試中使用的測試用例集的輸入范圍只是程序輸入的子集，因此即使軟體通過了測試，也無法保證程序一定是正確的。這說明測試本身是不完全的，不能證明程序無錯。人們認為，軟體測試活動從未間斷，只是在軟體交付用戶使用後，將由用戶扮演測試角色而已。 對每個測試用例都需要給出具體描述，表1給出了一個測試用例模版示例。 表1 測試用例模版用例標識：對該測試用例賦予一個唯一標識用例開發者：誰編寫的本用例 用例開發日期：編寫用例的日期測試項：描述將被測試的具體特徵、代碼模塊等對象測試輸入：測試時為程序提供或如茄的輸入數據前提條件：執行測試時系統應處於的狀態或要滿足的條件等環境要求：執行測試所需的軟硬體環境、測試工具、人員等測試步驟：(1)……；（例如，點擊「文件」菜單中的「新建」菜單項） (2)……；（例如，在「test case」目錄下選擇「test5.dat」文件）……預期輸出：希望程序運行得到的結果 用例之間的依賴性：該測試用例依賴或受影響的其它測試用例 當測試用例數量多時，文檔化的工作量就比較大。這時，模版內容在實際測試中可以根據需要進行簡化，例如把各個測試用例所共有的內容單獨列出來（如環境要求），並把所有測試用例用一張表格描述出來。
軟體測試用例的依據是什麼
1、軟體的需求文檔，開發的開發文檔（如果有）（功能相關）

2、根據產品具體的使用環境設計相關用例（兼容性相關）

3、根據目標用戶的特點設計用例（用戶體驗相關）

4、根據相關公司標准和業界、國際標准設計測試用例（性能。安全相關）
什麼是測試用例？
測試用例（Test Case）是將軟體測試的行為活動做一個科學化的組織歸納，目的是能夠將軟體測試的行為轉化成可管理的模式；同時測試用例也是將測試具體量化的方法之一，不同類別的軟體，測試用例是不同的。不同於諸如系統、工具、控制、游戲軟體，管理軟體的用戶需求更加不同的趨勢。

要使最終用戶對軟體感到滿意，最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實並確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式並由不同的測試員來實施。例如，執行軟體以便驗證它的功能和性能，這項操作可能由某個測試員採用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場佔有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。

既然可能無法（或不必負責）核實所有的需求，那麼是否能為測試挑選最適合或最關鍵的需求則關繫到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進衫察行核實的必要性這三者權衡考慮的結果。

我們公司於上使用日事清來進行編輯測試用例，同時執行測試用例，並取得不錯的成效。日事清是專業的企業管理軟體，可自動生成工作總結，進行日程計劃、團隊協作。

也可以算個人，也可以算企業，以為既可以管理個人的個人日程也可以管理整個團隊裡面的日程。
測試用例和用例規程有什麼區別
首先說,測試文檔與測試用例不是一個概念. 測試文檔包括整個測試過程中的測試計劃,測試方案,測試用例,測試規程,測試記錄,測試報告,缺陷報告等.所有文檔,每個文檔所涉及內容不同. 而測試用例主要根據方案中的測試方法設計的測試執行步驟及預期結果,
什麼是測試用例
不知道你是否了解測試用例的基本設計方法，包括等價類劃分法、邊界值分析法、錯誤推測法、因果橡掘圖法、判定表驅動法、正交分析……剛進入軟體測試，你說根據設計出的圖來寫測試用例更好一點，那你就用這種方法也行，主要目的是測到盡可能多的情況。用例來自需求，回歸需求
什麼是測試用例 什麼是測試腳本 兩者的關系是什麼
測試需求是主要是整理測試焦點（包括一些界面、輸入域、業務流程、數據等），並明確測試焦點的優先順序，為測試用例的設計提供測試所需的功能點信息。測試需求的分析也會體現用例設計方法，有的測試需求分析文檔中也會指導性的明確焦點的測試用例設計方法。 可以說，測試需求是告訴你要測什麼，而測試用例是告訴你怎麼測。 好的測試需求能發現需求中顯性和隱性的測試焦點，從而能更好的指導測試用例的設計，能更好的提高被測模塊整體功能的覆蓋率。 測試需求分析會根據不同階段的測試類型會有不同的側重點。我是做系統測試的，主要注重系統或軟體是否滿足用戶需求的情況。平時做測試需求時會比較明確系統的功能模塊和測試點明細整理，也會把測試案例設計方法同時加入到分析文檔中。
軟體測試中，測試用例里的測試結果P/F，這「P/F」指的是什麼？
P pass 通過

F Fail 失敗
什麼樣的用例是好的測試用例
1、用例覆蓋程度

毫無疑問，這一點應該是最重要的，無需多說，覆蓋率最大化是一套測試用例的最重要評價標准，如果漏測就杯具了。2、用例是否已經達到工作量最小化

在滿足用例覆蓋程度最大化的前提下，應該盡量減小執行用例所需要的工作量。這些方面的方法有不少，如條件覆蓋，分支覆蓋，正交覆蓋等方法。面對不同的測試對象，也有不同的方法來保證：對於網頁背後的php邏輯，可以通過在網頁上測試後，用一些工具比如xdebug來統計代碼覆蓋率；對於向外提供介面的server

，採用的方式就是分析在外面暴露的介面設計用例，大致的通過介面參數來估計一下分支判斷的情況。

3、用例的分類以及描述是否足夠清晰

用例的分類，在這里是指相同類型的用例是否放在一起了。例如：介面類的用例，參數的取值范圍是1-3，但是現在卻傳入4；數據類用例，狀態機現在位於狀態2，卻要求狀態跳轉到無法到達的4；邏輯類用例，正常功能的產出等。將相同類型的用例放在一起，有助於理清思路，清楚了解用例設計是否完備。

用例的描述，是指描述的清晰程度是否能夠形成文檔。例如上面參數取值范圍的例子，用例這樣寫：「傳入錯誤的值」或者「傳入非1-3的值」，明顯沒有寫成「傳入值4」有效。這與寫程序一樣，總是寫閉區間的范圍而不是開區間。4、用例是否表明了測試目的

寫明用例的測試目的，對文檔的易於理解性和工作交接的好處不言而喻，現代軟體工程不可能只有一個人在做事情，項目於人員的變動也是難免的。在過程中留下足夠的信息，可以在後續工作提高很多效率。5、測試用例的易於維護性

如果被測對象有所升級，測試用例的說明或者腳本是不是容易維護呢？例如在有狀態機的情況下，測試用例之間是相互依賴的（即需要一定的執行順序），這樣被依賴的用例修改後，後端不需要同步根據修改。而如果用例之間沒有相互依賴關系（如用例是自己造的數據，不是依賴於前端的產出），可能一旦有變化，就需要修改這兩個。當然，這兩種情況不能絕對的說哪種好，是需要看實際使用時候的情況進行取捨的。
軟體測試用例中報告結果的N/A是什麼意思？
CMCC測試用例中的N/A，是指沒有條件或者環境去測這一條CASE，比如某一條case需要某種輔助工具去測試，而這種輔助工具沒有，那就是N/A。總之是不用測或者是沒有測的意思
測試用例在軟體測試中的作用是什麼？
1、指導測試的實施測試用例主要適用於集成測試、系統測試和回歸測試。在實施測試時測試用例作為測試的標准，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。並對測試情況記錄在測試用例管理軟體中，以便自動生成測試結果文檔。根據測試用例的測試等級，集成測試應測試那些用例，系統測試和回歸測試又該測試那些用例，在設計測試用例時都已作明確規定，實施測試時測試人員不能隨意作變動。2、規劃測試數據的准備在我們的實踐中測試數據是與測試用例分離的。按照測試用例配套准備一組或若干組測試原始數據，以及標准測試結果。尤其象測試報表之類數據集的正確性，按照測試用例規劃准備測試數據是十分必須的。除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。3、編寫測試腳本的」設計規格說明書」為提高測試效率，軟體測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。如果說軟體工程中軟體編程必須有設計規格說明書，那麼測試腳本的設計規格說明書就是測試用例。4、評估測試結果的度量基準完成測試實施後需要對測試結果進行評估，並且編制測試報告。判斷軟體測試是否完成、衡量測試質量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟體模塊或功能點，顯得過於粗糙。採用測試用例作度量基準更加准確、有效。5、分析缺陷的標准通過收集缺陷，對比測試用例和缺陷資料庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟體質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。

『玖』 面試題: 如何對一個游戲進行設計測試用例.

一、游戲軟體與通用軟體的區別 a) 通用軟體的需求明確，游戲軟體需求理想化 i. 通用軟體中用戶每步操作的預期結果都是明確且有規范可參考的，而網游中並 不是所有的需求都有一個明確的預期結果，拿技能平衡性來說，我們所謂的平衡也只是相對的平衡，而非絕對的平衡。沒有什麼明確的參考參數。只能根據以往游戲的經驗獲得一個感知的結果。 ii. 網路游戲中的某些功能是有預期結果可參考的。例如組隊、交易，而另外一些 帶有策劃創意的功能，卻是根據策劃個人的理解，來確定其預期結果的。人的思考力都是有限的，所以不能保證在他的創意中會考慮到各種各樣復雜的細節。也不能夠保證這個創意就可以完全被用戶所接受。 當你作為游戲測試人員時，很多時候你需要做的不僅僅是驗證功能。也需要幫助開發者和用戶找到一個互相容忍的平衡點。游戲軟體的測試員帶有對策劃需求的懷疑，力求通過自己的努力在玩家和開發者之間將可能產生的矛盾減小。 b) 通用軟體開發過程中需求變更少，游戲軟體開發過程中需求便更快 i. 通用軟體的使用人群和軟體的功能針對性，決定軟體從開始製作就很少再有新 的需求變更。而游戲軟體，為了滿足玩家對游戲的認可度，策劃需要不斷的揣摩玩家的喜好，進行游戲功能的改進。加之網游製作本身就是一個龐大復雜的工程，開發者不可能做到在開發的前期，就對游戲架構及擴展性做出最好的評估。所以導致為了滿足用戶的需求而不斷的進行一些基礎架構的修改，基礎架構的修改必然導致某些功能的顛覆。所以就出現了，游戲開發過程中的一個惡性循環，當基礎架構修改到滿意了，玩家的需求又有了新的變化，隨之而來的又要進行新的調整，再進行新的修改。最終導致了游戲軟體的開發周期不斷加長。任何一個有經驗的團隊，對於每一個影響基礎的改動都應該做出正確的評估。 二、網游有哪些測試內容 a) 性能 i. 客戶端性能 ii. 伺服器端性能 1. 伺服器 2. 資料庫 iii. 網路 b) 功能 i. 從運行完game.exe打開游戲界面後可進行的各種操作、玩法 ii. 界面 iii. 音樂 c) 自動化 i. 測試工作組織實施中需要的工具、軟體、平台的開發 ii. 自動化的回歸測試作用：游戲中基礎的、變動不大的、出錯率高的、可進行 checklist重復測試的功能、性能等自動化是一個好方法 iii. 任何時候自動化都取代不了人腦，它只是將一些重復性的勞動從我們測試人員 身上去掉，讓我們有更多的時間做更有意義的事情，如果你覺得你做一件事情是重復的，且有規律可行的，不防考慮自動化 三、游戲中針對功能性測試測試用例編寫淺談
國際體驗設計協會IXDC 歷屆大會精彩集錦
游戲用戶體驗大會 互聯網產品大會 交互設計體驗周
作者：sunli 製作時間：2008年10月份 個人空間地址：
[url]http://www.51testing.com/?89706[/url] 本文檔僅供學習參考，請誤擅自轉載
2 / 3 先了解下游戲中有哪些功能： 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) 場景測試法協助功能點細分 游戲測試中，場景測試方法是經常用到的一種方法，什麼是場景測試法，及按照功能設計要求，在腦中模擬出來的一個功能使用時的操作流程。按照每步操作的針對點，將針對點劃分為所用例設計時的小功能點。劃分時需每步針對點的各種檢查點分到該功能點內設計為該功能點的檢查點。再根據檢查點進行測試輸入（及操作過程）的編寫。用例編寫過程中的思考方式就如上了。講起來比較抽象，希望對
作者：sunli 製作時間：2008年10月份 個人空間地址：
[url]http://www.51testing.com/?89706[/url] 本文檔僅供學習參考，請誤擅自轉載
3 / 3 大家有所幫助。 f) 用例的設計原則——一直有人問到底要詳細到什麼程度 i. 我們不期待用例編寫到任何人都可以執行，也沒有這個必要 ii. 我們針對的是網游的測試人員，至少是玩過網游的人，這些人對於游戲中的基 礎設定都有認識，我們不可能對著一個不知道任務界面是什麼的人大講怎麼測試任務。所以我們用例編寫的原則就是針對我們測試組內的測試人員。 iii. 但是，請不要簡略到別的測試人員看不懂，特別是當你是專職的用例編寫人員 時，編寫時請多考慮下語言描述的方式。請讓你的同伴可以看懂，你所要表達的意思。 iv. 用例是沒有固定格式的，它的主要原則就是，測試中所需所有信息，我通過你 的文檔都能夠獲取到。所以不要再執著的像別人要模板。模板你自己都可以設計，發揮你的創意。 四、編寫過程注意事項 與設計人員的溝通 拿到一份文檔時請不要急於編寫，在這之前很多事情需要做，請先將文檔閱讀至少三遍，然後思考下，你自己大腦中是否有你所看文檔功能點的一個流程圖，當確認已經准備好了。開始設計用例，用例設計的過程就是與設計人員不斷溝通，深入了解功能的過程。你會發現，或許跟你之前流程圖中想像的並不完全一樣。這個時候不必驚訝，去找他們核對就好。不怕發現問題，就怕沒有發現問題，最終做了很多無用功。編寫過程中發現的沒有預期結果的內容，請及時與策劃人員、程序人員核對，必須三方核對。核對完畢提醒策劃人員及時更新設計案，提醒程序人員設計案新修改內容。這樣你會發現，設計測試用例過程的本身就是發現策劃案不完善的過程。 請運用你的思維，採用邊界法、等價類劃分法、錯誤推斷法、以及以往的經驗，將每一個測試點的所有需檢查點進行充分的設計。發揮你的主動性，和測試組內其它人探討你認為可能存在風險的測試點，以便得到更多有價值的信息