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

用戶角度—— 基于文檔全面鋪開所有用戶場景

實現角度—— 基于程序的實現機制針對性的補充或刪除

測試角度—— 基于常見的用例設計方法進行細節設計

通用角度—— 數據存盤、異常中斷、耦合功能交叉

錯題本—— 基于日常積累的易錯點和踩坑點進行查漏補缺

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

01 UI界面向游戲介紹

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

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

02 用例設計思路

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

1. 系統創建

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

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

2. 入口

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

常駐入口，指常駐在游戲主界面或者其他功能模塊界面上的入口，沒有任何條件限制，所以這種入口無需考慮觸發顯示相關的邏輯。

隨條件解鎖的入口，這種是指擺放位置與常駐入口一樣也是固定的，但是入口有解鎖條件，達成條件方可顯示。這種入口可以聯想到一個功能點，即圍繞解鎖條件的。

限時開放的入口，這種一般是指限時活動的入口，也是擺放位置固定，但只在指定時間范圍內開放。這種入口需要注意上一節中所說的時間觸發功能創建的測試點。

有狀態的入口，這種一般是對于一些日常玩法的入口，入口常駐開啟，但會隨玩法有多種狀態，比如未完成狀態和已完成狀態。這個就是需要常規考慮到入口兩種狀態的顯示控制邏輯和狀態切換變化涉及到的邏輯，比如從未完成變到已完成或從已完成變到未完成，從而想到玩法完成、玩法重置這兩個邏輯點。

侵入式的入口，指的是不管玩家現在打開這哪個界面，都有可能忽然出現在他當前界面中的入口。這種入口至少要考慮兩個測試點，觸發出現的條件和與當前所做事情的沖突。這其中觸發條件比較好理解，可以聯想到觸發邏輯的測試點。但是沖突一般屬于隱含需求，我們需要對整體游戲模型做分類分析，來總結出當前玩家有幾種狀態下會出現該種入口的情況，再按等價類挑選出測試點。

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

3. 界面交互驅動

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

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

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

然后對每個劃分出的元素再按照以下4個維度來聯想測試點：UI元素的靜態顯示、UI元素的動態變化、可執行操作的業務流、數據存儲。

1. UI元素的靜態顯示

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

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

2. UI元素的動態變化

動態變化是該元素幾種靜態顯示數據間的變化切換，可能是一個操作業務流觸發的，也可能是系統業務流觸發的，然后就可以聯系到業務流的相關用例點，還以上面小節的界面為例來說明下。

3. 可執行操作的業務流

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

其中操作元素的顯示狀態，可參考上述UI元素的靜態顯示，用等價類或者邊界值等設計方法來選取適當的數據。

執行操作的動態判斷和操作完畢后的處理表現可以算作一個業務流，一般遵循如下套路。

4. 數據存儲

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

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

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

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

上面這些數據有的會直接顯示在界面中，有的是通過其他表現來體現，有的只是參與計算。對于隱性的數據需要通過對文檔的理解來找到，也可以通過了解程序實現來獲取。

4. 玩法流程驅動

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

1. 進入玩法

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

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

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

服務器端處理，一般包括：扣消耗、初始化個人的玩法數據（一些玩法全局需要用到的數據）、準備玩法第一環節表現需要用到的數據并同步給相關客戶端、設置好玩法狀態、記錄相關log。

客戶端處理，接受服務器同步過來的數據、界面跳轉進玩法界面并展示相關初始化數據。

2. 玩法流程驅動

進入玩法后，接下來就開始驅動玩法流程繼續。一般分兩種，一種是服務器控制節奏來驅動，一種是客戶端操作控制節奏。回到本文主體，界面操作向的游戲都是需要玩家通過交互操作來驅動進入下一環節。所以我們需要對這一個玩法來畫一下流程圖，并做一下流程環節劃分，把每一環節作為一塊測試點來拆分設計，而每一個環節也都可以找到它自己的一個流程：入口、進入該環節交互、進入下一環節或退出。

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

3. 結算玩法

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

5. 填表驅動

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

03 用例完善

結合文檔閱讀輸出的用例腦圖結構加上上述整個用例設計思路帶來的聯想測試點，已經基本上可以覆蓋所有功能點，最終我們可以再查漏補缺、多退少補地梳理一遍，完整的用例除了功能點，還需要能包括以下幾個維度的思考：
與其他模塊交叉部分完善

老賬號數據兼容

開新服時空數據狀態相關考慮

合服時可能帶來的數據沖突、時間不同步等相關考慮

弱網測試（網絡延遲下連續多次給服務器發同一請求、丟包情況下數據表現、回包亂序情況下客戶端表現）

斷線重連、頂號、切換賬號

兼容測試（平臺相關性的功能、第三方實現的功能）

性能測試（客戶端性能、服務端壓力）

用戶體驗相關（考慮玩家的理解成本）

日志完善

配表檢查

RPC相關測試（完善測試服務器端接口實現的嚴謹性）

04 小結

以上便是筆者對此類重交互的游戲的一種用例設計思路介紹。站在玩家交互角度，一步一步鋪開用例，能確保玩家所能看到的、操作到的數據都能有始有終的被考慮到，由數據和流程串聯，最終可以涉及到所有業務流，保障業務邏輯的覆蓋度。
其實不論何種形式的游戲功能用例設計，思路都是相通的，不知道從何開始下手時，永遠都可以代入一個玩家來看這個功能，希望這篇文章可以幫助有需要的同學整理思路，也歡迎大家聯系我們提出寶貴的建議和意見。

現在我邀請你進入我們的軟件測試學習交流群：【746506216】，備注“入群”， 大家可以一起探討交流軟件測試，共同學習軟件測試技術、面試等軟件測試方方面面，還會有免費直播課，收獲更多測試技巧，我們一起進階Python自動化測試/測試開發，走向高薪之路。

喜歡軟件測試的小伙伴們，如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一 鍵三連哦！

總結

以上是生活随笔為你收集整理的基于界面交互展开的用例设计思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。