(注：文章內圖片均為項目內部資源，請勿隨意轉載)

模塊簡介

L18，倩女幽魂隱世錄這款游戲，在我加入項目后，以19.5.30測試為分界線，經歷過一次幾乎是整體規模的迭代。由傳統武俠式MMO轉變為賽博風的ARPG的過程，游戲的核心戰斗部分經歷了一次翻天覆地的變化。

2018.1230版本

游戲的核心戰斗方式由“法術卡牌 + 隨從卡牌 + 職業機制”偏策略的玩法轉變為“主角戰斗動作(擬態式) + 隨從戰斗控制(執行式)”這樣更具動作性的體驗。項目組在盡可能的在不觸動戰斗底層邏輯的基礎上，進行了以上的調整。目前的效果也是非常可觀的。

最新版的戰斗測試場景

而這篇文章，目的是為了闡述，作為執行式負責人，我針對具體到單個執行式測試各個細節的測試心得，以及結合項目開發過程，關于模塊整體把控的個人理解。

執行式，以更通俗的話來介紹，就是玩家的隨從。在游戲核心戰斗定位于“擬態式 + 執行式”的戰斗機制的前提下，執行式，也就是隨從，對于戰斗的重要性可謂是占據了半壁江山。

執行式作為玩家的隨從，其主要的戰斗方式是通過玩家的召喚行為，在場景中根據配置的AI進行戰斗。玩家可以通過一定的方式控制執行式的戰斗行為和戰斗邏輯，配合擬態式(主角自身的戰斗方式)，進行一系列的副本戰斗。

目前已經確定制作完成的執行式已經超過了60個，遠遠大于目前規劃的擬態式數量(5個)，單個執行式的測試條目本身就數量龐大，測試的工作量是巨大的。

Checklist追加

執行式測試量大，實際的測試內容分配給了多個測試小伙伴。作為測試負責人，總結測試方法，指導相關測試人員，以及幫助對執行式有興趣的人員了解相關模塊， 制作一個完備的Checklist，是很有必要的。

從checklist條目也可得知，執行式的測試內容巨大

用例框架

以執行式為中心，縱觀整個戰斗系統，以下是關于執行式的用例設計框架的思維導圖：

用例思維導圖

用例設計可以基本分為：與執行式有關的戰斗基本功能、與其他玩法模塊交叉、技能實現和技能表現、數值平衡類測試四塊大測試點。

所以在實際編寫用例時，每個執行式會基于一個由負責人提前編寫完成的用例模板的基礎上去編寫各自的用例。再由于快速迭代的背景，保持用例模板的及時更新也是非常重要的。易協作和用例平臺對此幫助很大，在驗新需求時，可以通過需求單的特殊字段去自動生成一條用例，協助我們驗單后及時的維護更新用例。

測試人員可以再根據每個執行式具體的游戲設計需求以及實現的細節，在模板的基礎上展開，設計具體的測試用例。一切的出發點都是為了更加優良的游戲表現和游戲質量。

(用例就不給看了)

通用·交叉測試點也是執行式負責人(我)進行維護，主要是所有執行式通用的功能， 基本包含了所有與執行式有關的戰斗基本功能、與其他玩法模塊交叉的測試用例。無需針對單個執行式去分別執行用例，造成不必要的效率低下。

交叉測試點

抽卡、配卡、培養界面

抽卡、配卡、培養界面等模塊，實際上有其他QA負責功能測試，但執行式作為模塊的重要組成，執行式測試時也需要注意交叉測試內容。對應模塊的QA對執行式的具體設計很可能是不清晰的，會遺漏與執行式相關的測試點，這就需要執行式與其交叉模塊的負責人員妥善的溝通，同步信息，確保質量。

抽卡、配卡、培養這塊，針對執行式本身，更多的是顯示check。立繪、模型、執行式基本屬性、技能描述、各種交互玩法的表現等等。邏輯簡單，重在細節。

值得注意的是我們需要了解在各個場景下，模型的顯示規格。不同的場景，策劃和美術通過需求確定使用不同規格的模型prefab。在培養界面，展示用的執行式模型使用的是gm_ui規格(高模+UI展示)的prefab。我們完全可以在unity環境下去檢查，不僅僅是通過肉眼，主觀的判斷這個模型的精度是否符合需求。

針對抽卡的表現，也做了對應的GM指令，自動化輔助測試。輸入不同的指令和參數，可以選擇檢查所有執行式的抽卡表現，并且提供多種跑查方式，方便回歸。

可以輸出圖片結果提供參考，穩定后也可以直接做圖片比對

---

配卡、培養相關的展示界面牽涉到多個界面，需要保證界面以及界面細節的覆蓋度。在整體上協助對應模塊的負責人保證模塊質量。

執行式負責人員更多的是保證展示內容的正確性功能上更多的可以依靠對應模塊負責人，我們進行輔助

---

部分界面的交互和展示內容較多，此時就要細心了。

此前出現過一個漏測的問題：

某個執行式點擊對應的交互按鈕，彈出了一個錯誤的界面。原因是因為這個交互按鈕功能是新加的，對應功能負責人沒有溝通告知，即使肉眼清晰可見，執行式測試人員也想當然的沒有針對新增的按鈕進行任何的測試。導致部分策劃配置錯誤的執行式，在點擊交互按鈕后彈出了錯誤的界面。

整個界面的展示內容和可交互內容非常多
不能放過任何一個測試細節

在模塊交叉測試中，本身的測試難度并不大， 更重要的就是細心和溝通，盡善盡美。

與執行式有關的戰斗基本功能

戰斗面板·執行式相關(不給看)

戰斗基本功能，主要是戰斗面板功能的測試。例如自動戰斗功能、執行式召喚、使用技能等等相對于戰斗面板的表現。具體到單個執行式的一些戰斗表現，并不會放在交叉測試的用例中，而是針對對應執行式增加用例。

測試前要對戰斗系統有充分的了解，也要對與執行式有關的戰斗功能和設定有明確的認識。測試的難度其實不大，重點是對項目的理解，以及積極的溝通。

針對單個執行式的整體測試

具體到單個執行式內容，測試的重點在于整體的戰斗表現。按照整個戰斗流程，可以分為：出場表現、戰斗中表現、死亡表現以及死亡后殘留的表現。戰斗中的表現是測試的重中之重，也是執行式測試工作量最大的內容，更是測試的難點。

執行式的投放內容，隨著不斷地迭代，版本穩定后，已經基本上做到了完全通過策劃配置去控制。

在測試執行式前，完整地了解策劃的設計各個執行式的需求，以及配置的方式、規則，并且保持和策劃的溝通。對提升測試執行式的效率會有明顯的幫助，也能通過思考需求本身，結合配置表和策劃代碼的情況發現一些游戲內測試時難以發現或復現的問題。

出場、死亡相關表現

出場、死亡表現包括出場動畫、出場語音、死亡動畫、死亡語音。目前完全通過策劃配置控制，迭代穩定后問題很少，問題出現也多是迭代導致動畫爛了的易檢查問題。

值得注意的是，測試時可以結合實際玩法測試一系列特殊操作后的表現。

比方說召喚執行式后，快速釋放技能，動作銜接以及語音表現是否正常。

之前就出現過一個比較整體性的問題：

因為沒有限制召喚后釋放技能的時間，召喚執行式后玩家可以立即使用主動技能，出場動畫和技能動作的銜接表現非常差。之后策劃就做了需求，保證出場動畫播放完成后玩家才能使用主動技能，優化了執行式的整體表現。

基于執行式切換的基本規則，游戲的出場語音和死亡語音出現了沖突情況。及時和策劃溝通確認現象是否符合實際需求，保證游戲表現邏輯。這個案例，雖然沒有開bug單處理，是一個后期可優化點。

AI相關

執行式被召喚后，玩家可以通過主動技或絕技釋放按鈕，控制執行式的戰斗行為。在其他時間，執行式的行為由策劃配置好的AI進行托管。

執行式AI一共有兩種模式，可以分為主動進攻模式和跟隨模式。戰斗面板處提供了切換模式的按鈕。

每一個執行式AI的細節會根據執行式自身的特性各有不同，但其基本上是基于同一個AI模板進行編輯的。所以在發現AI問題時，需要注意AI問題造成的影響范圍。AI的bug通常不僅僅是單個執行式特有的問題。

執行式AI的問題在程序底層不進行迭代的前提下，更多的是出現在策劃配置層面。因為執行式配置關聯的配置表很多，結合了AI流程圖、策劃代碼、策劃配置表等等一系列的操作。容易出現許多細節上的誤差。

下例是一個很典型的AI整體邏輯表現型問題：

跟隨模式在初期制作完成后，策劃未考慮跟隨模式下執行式與敵方單位的戰斗表現。導致跟隨模式下的執行式進入了一種完全的跟隨狀態，就戰斗表現來說有些過于笨重了。

在BUG修復后，執行式能夠在跟隨模式下，對進入射程范圍內的敵人做出鎖定并發動進攻的行為，但在主角保持移動時，還是會優先跟隨著主人。這樣的戰斗表現就會自然得多。

還有一個配置普遍容易出現問題的例子：

出現問題的原因是，AI判斷的可釋放距離和傷害結算的距離，是分開配置數值的。所以在數值配置不準確的情況下，會出現執行式原地釋放技能或使用普攻，但是無法造成傷害的情況。

這種錯誤配置在執行式制作初期時有發生，測試的難度雖然不大，但是經常會被忽略，因為要采取一些比較特殊的測試手段才能夠復現這樣的問題。

目前基本上是通過游戲內的操作去測試AI的合理性，但這樣的問題在理論上是能夠通過靜態檢查去保證AI配置和技能配置的配合是正確的，可以在后面嘗試去補充這塊的檢查方式。

AI經常是整體性問題或調整，負責人一定要兜底，以及和相關測試人員同步信息

AI對執行式的整體戰斗表現起著至關重要的作用，作為負責人要做到整體的質量把控，并把AI的機制和迭代情況同步給所有測試人員。讓測試人員了解模塊整體情況，也了解到BUG原因，提升測試的效率。說到底就是要對游戲實際需求有充分的理解。在某種層面上，你甚至要比策劃更了解更理解你的項目。

技能測試

執行式的技能類型較多，包括：普攻、AI技能、被動技能、主動技能、大招等等類型。每個執行式的每種技能類型至少都有1個技能，數量較多。

首先需要保證的是每個技能類型的觸發方式：普攻、AI技能是鑲嵌在策劃配置的AI當中的；主動技能、大招、閃避技能有各自特殊的觸發以及使用的方式。不過整體的技能使用邏輯，各個執行式是一致的，可以由負責人做整體性的測試保證基本功能。

技能的細節，實際各有各的配置，但之前有提到執行式絕大部分內容目前都可以用配置去控制。所以我們能從中找到一定的規則，與策劃確認規則后，針對穩定的模塊，固定的規則，進行一系列的靜態檢查內容。例如技能類型的檢查、技能CD符合需求、技能的描述文本內容在限制內不會超框等等最基本的表現，目前已經用整體的靜態檢查進行兜底，使用的一年多時間里，相當的穩定，幫助QA快速解決了許多基礎配置上出現的問題。

通過靜態檢查保證執行式、執行式技能基本配置的正確性

至于配置更加復雜的技能動作和特效、技能傷害、技能特殊效果等等。我們首先還是在游戲內去確認整體表現的效果(技能動作和特效) ，此時要注意技能在低配畫質和高配畫質，以及開發環境與真機環境下是否會有差異。

游戲設置和游戲環境可能會影響到技能的實際表現，曾經也出現過低配環境下執行式技能集體特效報錯的尷尬情況，也出現了許多在其他玩家視角中表現異常的BUG。這樣的問題，實際上都是因為沒有完整的覆蓋測試到游戲內所有不同畫面質量的模型或動作或特效所導致的。

針對各畫質游戲表現的測試，測試方法有多種：多開客戶端、選擇不同真機環境、修改游戲內設置等。

這些都是同一測試階段集中出現的低模問題，這只是一部分

技能的表現邏輯，需要關注技能本身的施放條件、技能釋放時間節點前后的、以及執行式狀態(生、死、還有各種特殊狀態)等等情況下，各個技能的表現情況。整體測試可以基于測試用例模板去實施，實際也需要結合執行式技能的特點以及執行式本身的特性，針對性的做專項的，更加細節性的測試。

技能傷害、特殊效果等結算相關的測試。首先是確保結算實現的效果。包括結算的目標或范圍符合預期、結算時的傷害確認、技能關聯的buff或debuff的掛接等等。

就功能測試而言，主要是利用戰斗測試場景去一一檢查技能。但我們完全能通過策劃配置以及策劃代碼去檢查更多的細節，發現一些功能測試過程中不能輕易發現的問題，提升測試的效率，且進一步保證測試質量。

下面是一個經典的例子：

功能測試過程想要測試出這個bug是需要一些特殊步驟的。

因為游戲默認會使用鎖定模式，且鎖定與否對于技能使用來說，正常情況下是不會有影響的，測試過程中容易忽略這樣的狀況。

但在這個案例中，策劃比較騷氣的用了一個判斷：如果主角沒有鎖定任何人時，使用技能后只會播放兩個特效就結束了技能的流程。這個判斷本身是比較多余的，且造成了一個比較嚴重的技能實現問題。如果不通過review策劃代碼的方式，在游戲中去檢查技能，這個風險點是容易被遺漏的。

對配置的了解也能讓我們明確出現問題的原因，例如：

大招的配置中，策劃在對應配置行都會給大招添加一個buff，去規避玩家主動釋放的技能造成打斷大招的異常現象。策劃修bug時只需要給對應skill添加上所需的bug即可修復。

這是個制作初期就能測出來的bug，但當時發現的時間比較晚了。原因便是當時測試人員對配置規則不熟悉，且沒有測試覆蓋完整的漏測。

作為功能測試，關注游戲內表現是最基本的測試原則。而去了解策劃配置方式，并且能夠理解策劃的接口調用代碼，乃至嘗試理解程序底層代碼。無論對問題原因的理解還是測試的效率上都會有很大的提升。并且可以嘗試指導策劃人員之后不會讓問題反復，也能夠進一步明確模塊的風險點在哪。

數值相關

數值測試最直接的方式就是對比飄字的數值

L18的技能數值配置在了技能實現的過程之中。所以在迭代穩定的前提下，僅僅只是通過戰斗測試場景肉眼觀察數值跳字的話，測試的效率和準確性其實都不能得到保證。

充分了解屬性成長公式、傷害結算代碼、技能加成公式等等，能夠充分的提升數值測試的效率。也讓數值測試有據可依，不僅僅是單純的看飄字，通過主觀感受和粗略的計算去確認數值是否符合預期。

在實際檢查技能實現的測試過程中，通過review策劃代碼，完全可以做到將技能數值一并檢查的操作。加上記錄戰斗測試場景中實際的數值，數值測試得到了雙保險。在個人層面上，我認為自己還可以將大量的相關公式做一次整合，讓數值測試更加系統化，進一步加強效率。

技能數值測試目前主要保證技能的加成數值與對應培養等級的預期加成值對應一致，沒有針對數值平衡性做一些針對性的測試方法。待戰斗系統徹底穩定后，技能數值平衡性是一個可以進行拓展的測試模塊。

傷害寫在了技能實現流程中

特殊機制相關

變身

某些執行式的技能加入了變身的機制。變身在L18中是一個獨立的模塊。在模塊交叉的前提下，涉及變身的技能，風險相比其他技能更高。

在測試變身技能時，我們不僅僅要思考關于技能本身，更要結合變身前后的時間節點進行分析，細化測試用例。還要通過策劃代碼去了解策劃是通過怎樣的方式進行變身的操作的，錯誤的邏輯會導致游戲內許多讓人匪夷所思的現象。

變身接觸時的AI切換和自動技能暫停AI的邏輯沖突變身后配置的死亡方式不對，導致整個戰斗邏輯都爛了策劃在配置時，沒有考慮變身和戰斗面板邏輯的配合

皮膚

L18的高品質執行式擁有皮膚的拓展功能。一個執行式擁有多個形象。而每一個形象實際實現的方式其實是配置一個新的執行式。

所以在測試皮膚時，除了測試解鎖皮膚的條件、流程、方式，還需要將解鎖的皮膚當做一個全新的執行式進行一次完整的測試。

在430測試節點時，不乏有執行式普通形態沒有異常，但是執行式皮膚的技能表現出現異常的情況。

皮膚系統本身有模塊的負責人，和其他交叉模塊一樣。執行式測試人員也需要協助測試。

自走棋玩法

自走棋玩法是一個無主角玩法，是將各個執行式當做棋子進行戰斗的一個玩法。

此時的執行式AI又配置了一套新的，且部分執行式的技能由于無主角的機制，實際上是無法正常使用的，需要做特殊的處理。

所以執行式測試人員需要針對特殊的玩法，明確玩法規則，確認技能是否需要屏蔽，或是技能是否需要允許特殊的處理或表現。

整體質量把控的心得

作為執行式測試的負責人，我比較享受的是自己能夠參與到戰斗系統的開發過程中，并且能通過自己的能力，對戰斗系統，特別是自己負責的執行式模塊進行游戲品質的保證和優化。

執行式的測試內容多，交叉系統復雜。加之快速迭代，開發周期緊湊，對每一位測試人員都是不小的考驗。在目前多次大版本的上線測試中，包括大改版前的靈系統，執行式模塊和戰斗系統一直表現穩定。

針對測試量大的模塊，首先是合理分配測試的人力資源。目前執行式測試主要通過執行式的職階進行分配，五個職階分別分配給了五位測試人員進行測試，相對穩定的執行式繼而再交接給外包測試人員進行后期的維護；

其次是即使更新執行式整體的迭代情況，向各個負責人員告知一些整體性的迭代內容，一些經典的BUG分享，BUG原因普及。保證讓每一位測試人員都能獲得最新最快的信息；

交叉模塊注意細節，保持良好溝通。在版本回歸的過程中我們也有吃過溝通怠惰的虧，導致一些很弱智的問題沒有及時的發現。交叉模塊的風險無須贅述，避免問題的關鍵就在于測試人員的責任心以及溝通積極性；

最后就是保持學習的態度，功能測試不僅僅是發現bug，更要學會發掘bug的原因。這樣不僅能提高測試的效率，提升自身對游戲開發流程各個階段內容的理解，也可以積極的影響到策劃、程序的工作，引導他們去規避已經犯過的錯誤和漏洞。

測試也許是一個比較被動的職能崗位，但一定要提醒自己保持著積極的心態和行動力去推動模塊，乃至整個游戲的開發進程和產品質量。

總結

以上是生活随笔為你收集整理的atm系统的用例模型_战斗系统执行式测试经验汇总的全部內容，希望文章能夠幫你解決所遇到的問題。

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