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

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

實(shí)現(xiàn)角度—— 基于程序的實(shí)現(xiàn)機(jī)制針對(duì)性的補(bǔ)充或刪除

測試角度—— 基于常見的用例設(shè)計(jì)方法進(jìn)行細(xì)節(jié)設(shè)計(jì)

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

錯(cuò)題本—— 基于日常積累的易錯(cuò)點(diǎn)和踩坑點(diǎn)進(jìn)行查漏補(bǔ)缺

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

01 UI界面向游戲介紹

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

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

02 用例設(shè)計(jì)思路

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

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

指服務(wù)器起服或者某個(gè)特定時(shí)間點(diǎn)（比如功能開啟的時(shí)間點(diǎn)），對(duì)該功能所做的一些處理邏輯。

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

2. 入口

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

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

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

限時(shí)開放的入口，這種一般是指限時(shí)活動(dòng)的入口，也是擺放位置固定，但只在指定時(shí)間范圍內(nèi)開放。這種入口需要注意上一節(jié)中所說的時(shí)間觸發(fā)功能創(chuàng)建的測試點(diǎn)。

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

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

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

3. 界面交互驅(qū)動(dòng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 玩法流程驅(qū)動(dòng)

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

1. 進(jìn)入玩法

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

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

（2）正常進(jìn)入玩法后的處理，這里要分服務(wù)器端處理和客戶端的處理兩個(gè)維度來考慮。

服務(wù)器端處理，一般包括：扣消耗、初始化個(gè)人的玩法數(shù)據(jù)（一些玩法全局需要用到的數(shù)據(jù)）、準(zhǔn)備玩法第一環(huán)節(jié)表現(xiàn)需要用到的數(shù)據(jù)并同步給相關(guān)客戶端、設(shè)置好玩法狀態(tài)、記錄相關(guān)log。

客戶端處理，接受服務(wù)器同步過來的數(shù)據(jù)、界面跳轉(zhuǎn)進(jìn)玩法界面并展示相關(guān)初始化數(shù)據(jù)。

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

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

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

3. 結(jié)算玩法

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

5. 填表驅(qū)動(dòng)

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

03 用例完善

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

老賬號(hào)數(shù)據(jù)兼容

開新服時(shí)空數(shù)據(jù)狀態(tài)相關(guān)考慮

合服時(shí)可能帶來的數(shù)據(jù)沖突、時(shí)間不同步等相關(guān)考慮

弱網(wǎng)測試（網(wǎng)絡(luò)延遲下連續(xù)多次給服務(wù)器發(fā)同一請(qǐng)求、丟包情況下數(shù)據(jù)表現(xiàn)、回包亂序情況下客戶端表現(xiàn)）

斷線重連、頂號(hào)、切換賬號(hào)

兼容測試（平臺(tái)相關(guān)性的功能、第三方實(shí)現(xiàn)的功能）

性能測試（客戶端性能、服務(wù)端壓力）

用戶體驗(yàn)相關(guān)（考慮玩家的理解成本）

日志完善

配表檢查

RPC相關(guān)測試（完善測試服務(wù)器端接口實(shí)現(xiàn)的嚴(yán)謹(jǐn)性）

04 小結(jié)

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

現(xiàn)在我邀請(qǐng)你進(jìn)入我們的軟件測試學(xué)習(xí)交流群：【746506216】，備注“入群”， 大家可以一起探討交流軟件測試，共同學(xué)習(xí)軟件測試技術(shù)、面試等軟件測試方方面面，還會(huì)有免費(fèi)直播課，收獲更多測試技巧，我們一起進(jìn)階Python自動(dòng)化測試/測試開發(fā)，走向高薪之路。

喜歡軟件測試的小伙伴們，如果我的博客對(duì)你有幫助、如果你喜歡我的博客內(nèi)容，請(qǐng) “點(diǎn)贊” “評(píng)論” “收藏” 一 鍵三連哦！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。