測試用例是測試人員日常最重要的輸出之一，對用例的評價標準一般有三個維度：結(jié)構清晰易讀、可執(zhí)行性強、覆蓋度高。站在質(zhì)量維度，最為重要的要屬高覆蓋度。如何寫出高覆蓋度的設計用例，離不開以下幾個角度的分析。

• 用戶角度—— 基于文檔全面鋪開所有用戶場景
• 實現(xiàn)角度—— 基于程序的實現(xiàn)機制針對性的補充或刪除
• 測試角度—— 基于常見的用例設計方法進行細節(jié)設計
• 通用角度—— 數(shù)據(jù)存盤、異常中斷、耦合功能交叉
• 錯題本—— 基于日常積累的易錯點和踩坑點進行查漏補缺

本文希望能給大家介紹一種從用戶交互角度來展開的設計思路。

01 UI界面向游戲介紹

在開始之前先大概介紹下什么是UI界面向游戲，該類游戲是由大量的全屏UI界面組成，所有功能流程一般都是通過界面上的交互操作來驅(qū)動，所有數(shù)據(jù)也都展示在界面上。如下圖游戲主界面，UI層就是一個一個的功能按鈕和一些玩家數(shù)據(jù)展示來組成，玩家的操作就從這里開始。

既然玩家面對的是大量的UI交互，那么我們的用例不妨也就從玩家視角入手，跟著玩家一步一步的交互開始設計展開。所有界面的交互操作都會有策劃的交互文檔來參考，但由于界面是靜態(tài)的界面，如何確保用例不會陷入到只覆蓋了界面的靜態(tài)顯示，如何確保從界面入手卻能由功能驅(qū)動下去，下面按步驟來說明我們的設計思路。

02 用例設計思路

如果把我們待測的功能比作一個房子，玩家就是一個人，那么接下來我們關注的就是人如何走進這個房子并在里邊的各個房間開始各種探索，以及他再怎么離開房子的過程。這里邊可以認為涉及到2個對象，一個是人，一個是房子，二者交互后可彼此給對方產(chǎn)生影響，這個影響其實就是數(shù)據(jù)的變化。所以我們的思路順序可以按下圖這樣：

1.

系統(tǒng)創(chuàng)建

指服務器起服或者某個特定時間點（比如功能開啟的時間點），對該功能所做的一些處理邏輯。

比如某個玩法功能開啟的時間點，系統(tǒng)創(chuàng)建玩法的一個流程，在需求文檔中可能只是一句話，甚至有時候在需求文檔中都不會明顯說明，但是實際測試點需要注意的事項還是很多的。

2.

入口

每個功能都能找到一個或多個入口，且交互文檔里也會有明確的入口顯示的界面設計。入口一般有以下幾類：

• 常駐入口，指常駐在游戲主界面或者其他功能模塊界面上的入口，沒有任何條件限制，所以這種入口無需考慮觸發(fā)顯示相關的邏輯。
• 隨條件解鎖的入口，這種是指擺放位置與常駐入口一樣也是固定的，但是入口有解鎖條件，達成條件方可顯示。這種入口可以聯(lián)想到一個功能點，即圍繞解鎖條件的。
• 限時開放的入口，這種一般是指限時活動的入口，也是擺放位置固定，但只在指定時間范圍內(nèi)開放。這種入口需要注意上一節(jié)中所說的時間觸發(fā)功能創(chuàng)建的測試點。
• 有狀態(tài)的入口，這種一般是對于一些日常玩法的入口，入口常駐開啟，但會隨玩法有多種狀態(tài)，比如未完成狀態(tài)和已完成狀態(tài)。這個就是需要常規(guī)考慮到入口兩種狀態(tài)的顯示控制邏輯和狀態(tài)切換變化涉及到的邏輯，比如從未完成變到已完成或從已完成變到未完成，從而想到玩法完成、玩法重置這兩個邏輯點。
• 侵入式的入口，指的是不管玩家現(xiàn)在打開這哪個界面，都有可能忽然出現(xiàn)在他當前界面中的入口。這種入口至少要考慮兩個測試點，觸發(fā)出現(xiàn)的條件和與當前所做事情的沖突。這其中觸發(fā)條件比較好理解，可以聯(lián)想到觸發(fā)邏輯的測試點。但是沖突一般屬于隱含需求，我們需要對整體游戲模型做分類分析，來總結(jié)出當前玩家有幾種狀態(tài)下會出現(xiàn)該種入口的情況，再按等價類挑選出測試點。

站在用例設計的角度，不管哪種入口，只要看到入口就可以聯(lián)想入口背后的邏輯：入口如何顯示出來的邏輯和點擊入口進入功能的邏輯。所以關于入口，我們可以按照3個用例塊來設計。

3.

界面交互驅(qū)動

按照思路順序，入口設計完之后，就進到了從入口點擊進入遇到的第一層界面，一般也是功能系統(tǒng)的主界面或者流程型玩法的第一環(huán)節(jié)的界面。

對于界面展開詳細測試，我們避免遺漏的最好方法是把界面按照信息分區(qū)劃分，確保界面上每一個元素控件都有所屬分區(qū)。這里劃分的粒度可以按界面元素排布位置或者按功能塊，可以先粗略分為大塊，然后對每一個大塊繼續(xù)劃分小塊，直至最后劃分到最小粒度。

比如上圖界面，第一次劃分可以按圖中所示的3大塊來分，可以按內(nèi)部信息繼續(xù)劃分，其中1就是一個tab按鈕，已是最小粒度；2作為一個整體數(shù)據(jù)單位，可以按內(nèi)部信息繼續(xù)劃分；3作為一個整體列表單位，也以其中一條數(shù)據(jù)為單位再繼續(xù)劃分。如下圖：

然后對每個劃分出的元素再按照以下4個維度來聯(lián)想測試點：UI元素的靜態(tài)顯示、UI元素的動態(tài)變化、可執(zhí)行操作的業(yè)務流、數(shù)據(jù)存儲。

1. UI元素的靜態(tài)顯示

每個UI元素要想測到完備的靜態(tài)顯示，那么需要找到它所有可能出現(xiàn)的數(shù)據(jù)狀態(tài) ，然后再采取一些測試用例設計方法，比如等價類劃分法或者邊界值法等來選取數(shù)據(jù)進行測試，甚至有些情況下還需要遍歷所有數(shù)據(jù)來測試。

如上圖所示交互文檔里可以看出等部分設計說明為例，這里挑2個UI元素來說明下靜態(tài)顯示。

2. UI元素的動態(tài)變化

動態(tài)變化是該元素幾種靜態(tài)顯示數(shù)據(jù)間的變化切換，可能是一個操作業(yè)務流觸發(fā)的，也可能是系統(tǒng)業(yè)務流觸發(fā)的，然后就可以聯(lián)系到業(yè)務流的相關用例點，還以上面小節(jié)的界面為例來說明下。

3. 可執(zhí)行操作的業(yè)務流

對于手游上的UI操作，大致分為以下五種：點擊、長按、滑動、拖動、雙指撥動。對于邏輯的話，我們不用關注操作的類型，只需要關注操作關聯(lián)的業(yè)務流就好，一個操作向的業(yè)務流一般可以提取出下面這個較為通用的流程。

其中操作元素的顯示狀態(tài)，可參考上述UI元素的靜態(tài)顯示，用等價類或者邊界值等設計方法來選取適當?shù)臄?shù)據(jù)。

執(zhí)行操作的動態(tài)判斷和操作完畢后的處理表現(xiàn)可以算作一個業(yè)務流，一般遵循如下套路。

4. 數(shù)據(jù)存儲

對于上面小節(jié)里是根據(jù)用戶交互角度找出了一些業(yè)務流并檢查了這條業(yè)務流最后帶來的界面數(shù)據(jù)變化，但這里我們測到的只是數(shù)據(jù)的即時處理表現(xiàn)，對于數(shù)據(jù)它還有一個終極歸屬——存盤。即時的客戶端刷新變化雖然說明這條業(yè)務流對數(shù)據(jù)進行了正確處理，但此時數(shù)據(jù)只在服務器的內(nèi)存里，并不能說明存盤的正確，所以存盤得需要專門的測試點補充測試。

游戲內(nèi)數(shù)據(jù)的存儲一般有四種載體：客戶端本地文件存儲、服務器數(shù)據(jù)庫存儲、服務器本地文件存儲、第三方存儲。

我們設計用例時需要能辨別出哪些數(shù)據(jù)時需要測存儲的，然后再根據(jù)存儲的這幾種實現(xiàn)來分別套用各自的用例點。存儲的數(shù)據(jù)有幾個行為主體：玩家個人、玩家組織、系統(tǒng)。

• 玩家個人屬性向的數(shù)據(jù)，比如自己的昵稱；
• 玩家個人成長向的數(shù)據(jù)，比如玩家的等級；
• 玩家個人玩法向的數(shù)據(jù)，比如玩xx玩法的進度、成績；
• 公會屬性向、成長向、玩法進度向數(shù)據(jù)；
• 系統(tǒng)，以服務器為單位的。

上面這些數(shù)據(jù)有的會直接顯示在界面中，有的是通過其他表現(xiàn)來體現(xiàn)，有的只是參與計算。對于隱性的數(shù)據(jù)需要通過對文檔的理解來找到，也可以通過了解程序?qū)崿F(xiàn)來獲取。

4.

玩法流程驅(qū)動

對于玩法，雖然客戶端表現(xiàn)上來看也是一個一個的交互界面串聯(lián)起來的，但是這里還涉及到一個邏輯流程，一般可以先按照玩家交互角度分成3大塊：進入玩法、玩法流程驅(qū)動、結(jié)算玩法。然后再以此3個節(jié)點來擴充聯(lián)想相關的用例。

1. 進入玩法

進入玩法的測試點設計與上述類似，也可以按下面兩個維度來聯(lián)想設計。

（1）進入點門檻條件判斷，比如玩法是否開啟、是否有門票、是否有資格、是否有匹配的對手、是否達到每日參加次數(shù)上限、服務器壓力過大等；

（2）正常進入玩法后的處理，這里要分服務器端處理和客戶端的處理兩個維度來考慮。

• 服務器端處理，一般包括：扣消耗、初始化個人的玩法數(shù)據(jù)（一些玩法全局需要用到的數(shù)據(jù)）、準備玩法第一環(huán)節(jié)表現(xiàn)需要用到的數(shù)據(jù)并同步給相關客戶端、設置好玩法狀態(tài)、記錄相關log。
• 客戶端處理，接受服務器同步過來的數(shù)據(jù)、界面跳轉(zhuǎn)進玩法界面并展示相關初始化數(shù)據(jù)。

2. 玩法流程驅(qū)動

進入玩法后，接下來就開始驅(qū)動玩法流程繼續(xù)。一般分兩種，一種是服務器控制節(jié)奏來驅(qū)動，一種是客戶端操作控制節(jié)奏?；氐奖疚闹黧w，界面操作向的游戲都是需要玩家通過交互操作來驅(qū)動進入下一環(huán)節(jié)。所以我們需要對這一個玩法來畫一下流程圖，并做一下流程環(huán)節(jié)劃分，把每一環(huán)節(jié)作為一塊測試點來拆分設計，而每一個環(huán)節(jié)也都可以找到它自己的一個流程：入口、進入該環(huán)節(jié)交互、進入下一環(huán)節(jié)或退出。

此外需要注意的是，除了正常的玩家主動退出，還需要考慮到實際的用戶場景，即玩家可能會被動退出或者被其他功能打擾，這些需要具體實現(xiàn)具體分析。

3. 結(jié)算玩法

這里是指玩家自己的玩法流程結(jié)束，那一般是有以下幾種處理：給玩家結(jié)算成績（這里的成績可以認為是個廣義的說法，即包括計算分數(shù)、更新排名、結(jié)算擂主之類等）、給玩家發(fā)獎勵、促使玩家離開玩法、記錄玩家的參與數(shù)據(jù)、同步其他模塊需要的數(shù)據(jù)、同步給客戶端結(jié)果、客戶端做相應表現(xiàn)等。

5.

填表驅(qū)動

除了上面的界面驅(qū)動、流程驅(qū)動，還有一類功能可能是填表向驅(qū)動，比如劇情類、技能類，這些功能外圍調(diào)用比較基本，大量邏輯是從填表開始，一般表格的列會非常多，那么用例也可以遵循設計的原理，按照配表順序來設計，最終測試也要按照表格的填法來執(zhí)行測試，對于每一條填表數(shù)據(jù)思考聯(lián)想出相應的用例點即可。

03 用例完善

結(jié)合文檔閱讀輸出的用例腦圖結(jié)構加上上述整個用例設計思路帶來的聯(lián)想測試點，已經(jīng)基本上可以覆蓋所有功能點，最終我們可以再查漏補缺、多退少補地梳理一遍，完整的用例除了功能點，還需要能包括以下幾個維度的思考：

• 與其他模塊交叉部分完善
• 老賬號數(shù)據(jù)兼容
• 開新服時空數(shù)據(jù)狀態(tài)相關考慮
• 合服時可能帶來的數(shù)據(jù)沖突、時間不同步等相關考慮
• 弱網(wǎng)測試（網(wǎng)絡延遲下連續(xù)多次給服務器發(fā)同一請求、丟包情況下數(shù)據(jù)表現(xiàn)、回包亂序情況下客戶端表現(xiàn)）
• 斷線重連、頂號、切換賬號
• 兼容測試（平臺相關性的功能、第三方實現(xiàn)的功能）
• 性能測試（客戶端性能、服務端壓力）
• 用戶體驗相關（考慮玩家的理解成本）
• 日志完善
• 配表檢查
• RPC相關測試（完善測試服務器端接口實現(xiàn)的嚴謹性）
• 
  

04 小結(jié)

以上便是筆者對此類重交互的游戲的一種用例設計思路介紹。站在玩家交互角度，一步一步鋪開用例，能確保玩家所能看到的、操作到的數(shù)據(jù)都能有始有終的被考慮到，由數(shù)據(jù)和流程串聯(lián)，最終可以涉及到所有業(yè)務流，保障業(yè)務邏輯的覆蓋度。

其實不論何種形式的游戲功能用例設計，思路都是相通的，不知道從何開始下手時，永遠都可以代入一個玩家來看這個功能，希望這篇文章可以幫助有需要的同學整理思路。

作者:測試中心小編

來源:微信公眾號:網(wǎng)易雷火測試中心

出處
:https://mp.weixin.qq.com/s/ApwwPzm9zWLvKDj3eA3UgA