手機遊戲怎麼測試？

01-31

手機遊戲測試：

1 性能測試

2 功能測試

3 用戶體驗

那個模型不全面，現在更多是敏捷測試，或者雙v模型測試。

然而在實際過程中，很難完全符合這樣的測試規則。

大公司還好，分工明確，工作起來比較順暢；

小公司通常都是測試要干各種工作，所以打雜的事都是測試幹了。

實際上遊戲測試在性能測試這一塊占很小的比重，覺得部分還是功能測試。

從我的工作經驗來看，具體的執行測試一般包括：資源測試，數值測試，功能玩法測試，頁面測試，體驗測試······大概就是這些。

測試模型我了解的有2種：1是瀑布模型，2是V模型。

因為V模型在將測試更好的整合進了整個遊戲開發過程中，所以是較優的模型。

測試分類方式有很多，在這裡按「黑盒，白盒，灰盒」分類。我只接觸過黑盒測試，沒有接觸過白盒，所以按我自己的經驗來說。

大體有以下幾個階段的測試：

Function QA1:α/Base Function

Function QA2：β/Fulltest

Function QA3：Semi-public線上測試

QA1嘛，就是平地建高樓、從無到有的過程，所以通常有開發人員自己就搞定啦，邊做邊修，大概是這樣。通常在QA1階段過後就會出一個版本在sandbox環境下做QA2，主要是包含功能、語言內容、UI，可能會有性能、安全性方面內容。過程中出現問題會和開發進行溝通，提交bug修改bug打包版本balabala。在QA2通過後，會和PM確認，提交CQC（接入測試）。再次通過後，會進入半公開測試，切到production環境進行快速測試，確認無誤後提交審核，再然後遊戲就正式上線啦，然後會線上測試，保證沒有嚴重問題出現。

總的來說QA1階段是問題多多的，主要是要保證遊戲整體功能上的完整沒有嚴重問題，小的什麼文字錯誤啦、圖片模糊啦都是可以先忽略的；到了QA2版本時候遊戲功能已經蠻全的了，這時候需要耐心和細心進行完善；CQC主要是跟SDK有關；QA3階段版本其實基本就是正式版本了。

要去忙了，就先寫到這裡。之後再根據情況補充說明吧。

第一次在知乎上回答問題，希望能提供給大家一點乾貨。下面的內容是從自己的個人訂閱號中的一篇文章中截取的。

筆者以前主要從事端游的自動化測試工作，沒有深入了解過功能測試相關的知識，但最近一年，因為工作變動，需要進行手游相關的測試工作，所以功能測試的研究被提上了議程。

和所有的新人或者外行人一樣，原本我也以為功能測試不會太難，只要耐心、細心就可以做好。但當我不斷深入研究後，發現其實這是個非常具有難度的工作，原因如下：

1：目前針對遊戲功能測試，尤其是手游功能測試，沒有明確的方法論，各個項目基本都是按照自己的想法隨意進行，測試用例的編寫和維護也沒有非常硬性的要求。

2：手游開發基於敏捷，傳統軟體行業和端游的測試方法很難適應手游的測試工作。

既然沒有現成的一些方法論和指導思想，那怎麼辦呢？只能擼起袖子自己幹了。但在創造之前，研讀傳統的測試方法肯定是非常必要的，於是google了一些資料，也購買了一些經典測試書籍，經過了一通亂讀後，對於測試工作，特別是手游的測試工作有了較為清晰的、嶄新的認識！

測試的棘手問題：

1：漫無目的：軟體測試不是簡單的拿起來就做的事情。它要求有計劃、有準備、有策略和有多變的戰術，這是成功進行軟體測試的前提。但是，太多的軟體企業因偏愛「想干就干」而忽略適當的準備。

2：決定需要測試什麼

3：決定何時測試

4：決定如何測試

本文研究的初衷就是為了解決這些問題。在最後，我們也找到了這些問題的答案，後面我們將通過對測試用例這一塊的詳細描述，來進行說明。

手工測試和自動化測試：

測試分為手工測試和自動化測試，但大部分人的思想觀念都覺得自動化測試比手動測試高級、重要。以前我也是這種想法，現在我充分認識到，這是一種無知的、片面的、可笑的想法！

自動化測試的缺點源自一個事實，即測試本身是以代碼的形式存在的，編寫測試用例意味著測試人員也必然是開發人員。如果從測試運行數量上判斷，自動化測試肯定每一次都會贏。如果是從測試質量上來說，那就根本是另外一回事了。

並且，由於自動化測試本身也是軟體，這往往意味著那些錯誤可能是測試用例本身而不是目標軟體產生的。

那麼在哪種環境下，手工測試會優於自動化測試，反之亦然。一般來說，自動化測試適合穩定的回歸環境，它只能做重複的邏輯驗證工作，只是測試人員替代勞動的工具，就像紙和筆。但兩者沒有孰優孰劣的界定，只是如何測試的選擇問題。手工測試也可以檢測到崩潰、掛起、不正確的返回值、突發異常、內存使用情況等，自動化測試也可以比較好的覆蓋邏輯業務檢測。

但是，注意但是！兩者的一個大區別是在於自動化代碼是靜態的，是由需求方也就是手工測試驅動的。好的手工測試人員，能夠及時的驅動自動化測試。自動化測試的靈魂，也就是需求，還是在手工（功能）測試這裡。優秀的手工測試，是好的自動化測試的前提，也是沒有代碼可以替代的。人類無法更快的測試，但是能夠更聰明的測試。

如何編寫和運行測試用例：

測試用例是測試人員的勞動成果，它應該是充滿智慧的，具有可復用性，啟發性，能充分體現一個測試人員的水平！

最終確定的方法是：分模塊的基於場景的探索式測試方法。

這個測試方法是在深入研究了《探索式軟體測試》一書的基礎上得來的。

好處：探索式測試的思維與傳統的基於場景的測試方法結合起來，打破了腳本測試法所固有的那種死板，提供了更多靈活性。基於場景的探索式測試能夠覆蓋單一場景測試所無法覆蓋的情況，並能更準確地模擬真實用戶。

場景測試方法是遊戲測試中經常用到的一種方法，即按照功能設計要求，在腦中模擬出來功能使用時的操作流程。按照每步操作的針對點，將針對點劃分為所用例設計時的小功能點。

測試主管預先將各個模塊分配到對應QA，QA利用場景測試法編寫測試用例。那麼探索式在哪裡體現呢？這裡就是重點了，就是在測試用例運行的過程中，我們通過探索式（場景操作和漫遊測試）來給場景注入變化，從而達到我們預期的目的。那麼什麼是場景操作和漫遊測試呢？首先來介紹第一個方法，場景操作。

場景操作包括：

1：插入步驟

給場景增加額外的步驟可以使它們更加多樣化，從而測試更多的功能。

? 增加更多數據

?使用附加輸入

?訪問新的界面

2：刪除步驟

我們可以去掉冗餘和可選的步驟，這個操作的想法是使場景的步驟儘可能地減少。也許因此而衍生出的場景會缺乏那些設置初始條件的步驟，這種場景可以用來測試應用程序是否可以識別出現在缺少信息或者缺乏一些從屬功能。

3：替換步驟

如果場景中某些步驟可以有多種方法完成，就可以用替換步驟的場景操作來修改這個場景。替換步驟實際上是前面兩個操作的組合，就是先刪除步驟，然後再插入步驟。

4：重複步驟

場景經常包含非常明確的動作順序。重複步驟的場景操作通過重複單獨的步驟或重複一組步驟來改變這個順序，以創建額外的變化。

5：替換數據

6：替換環境

?替換硬體，比如ios和android相互替換。

這裡需要注意的是，在使用上述任何操作來創建衍生場景時，我們都會盡量使它接近原始場景。如果操作過多或者操作使衍生場景與原始場景的差別巨大，通常沒什麼益處。

第二種方法是，漫遊測試。

可以把漫遊測試的方法想像成順路游。其想法很簡單：測試人員査看測試用例，找到需要測試人員做決定的地方或者找到可能產生邏輯分支的地方，先往完全不同的方向走，然後再返回到腳本描述的主要路徑。

場景操作和漫遊的關鍵不同是漫遊通常比場景操作產生更長的順路游。操作側重於場景中小的、逐漸增加的變化以及可有可的步驟，而漫遊實際上可以創建出相當長的和範圍更廣的衍生場景。就像有些順路游的目的地本身就可以變成最終結果，也就是說漫遊超越了原有的場景，這樣的效果也是我們希望看到的。要知道，探索式測試追求變化，將漫遊和場景相結合可以帶來相當多的變化。

這兩種方法，都能起到對測試用例做出改動的目的，從而發現更多可能的缺陷，因為未經改動的手動測試很少能檢測到新問題。當然了，這對測試人員提出了更好的要求，只有經驗豐富的測試人員，才能最大程度的發揮探索式測試的優勢。

測試用例的詳細程度：

我們不期待用例編寫到任何人都可以執行，也沒有這個必要。我們針對的是遊戲的測試人員，至少是玩過遊戲的人，這些人對於遊戲中的基礎設定都有認識，我們不可能對著一個不知道任務界面是什麼的人大講怎麼測試任務。所以我們用例編寫的原則就是針對我們測試組內的測試人員。但是，請不要簡略到別的測試人員看不懂。

測試用例也不要求固定格式的，它的主要原則就是，測試中所需所有信息，我通過你的文檔都能夠獲取到。所以不要再執著的像別人要模板。模板你自己都可以設計，發揮你的創意。

另外，比如某個功能是對話框中輸入字元串，此時我們不需要利用極限值等方便編寫n個測試用例，而是簡單用一句輸入字元串代替。可能你會有疑問，這樣不是非常不好，違背測試用例的編寫目的嗎？起初我也有類似的疑問，但後來研讀了《探索式軟體測試》一書後，我覺得這樣是正確的。這裡不寫具體的n個測試用例不是說不用測試，而是當執行到這個用例的時候，利用局部探索式測試去展開。

局部探索式測試的重點是把測試經驗、專業知識、軟體在操作環境下如何構建和運行的知識結合在一起，使我們在測試中做出正確決定。根據軟體的各種屬性，我將決策分為5個部分：輸入、狀態、代碼路徑、用戶數據、執行環境。這些都是探索型測試人員在測試必須關注的。

反思：

一定是要反思缺陷的產生，思考為什麼現在的流程沒有測出來這個問題！這是非常非常重要的一步！在思考的基礎上，更新現有的測試用例，提高產品的整體質量！

我建議測試人員暫緩尋找軟體缺陷，抽出時間來總結已知的軟體缺陷。研究一下它，你是如何找到它的？你是怎麼注意到這個bug的，應用程序里發生了什麼使得這個軟體缺陷彈了出來？發現這個軟體缺陷的測試用例能否通過，讓它能夠發現更多類似於這個bug？你是否有一些建議，可以向其他測試人員提出，來幫助他們找出類似的代碼漏洞。

推薦使用 TestBird手機遊戲測試工具

專註於手游開發者、手游發行商和手游渠道商提供自動化雲測試服務的專業平台。

主要測試三方面：終端的兼容性測試，手游性能測試，功能測試

與200部中國主流終端的兼容性測試；
手游性能測試，包括幀速率、流量、溫度、啟動時延、安裝時間、CPU、內存等指標；
手游功能測試，包括新手引導、任務、活動、充值、商城、好友、團戰等。

快速測試，反饋多達百頁的詳細專業手游測試報告。

其一幫助快速發現問題，找出影響用戶體驗的具體性能指標和功能模塊問題，全面提升手游質量

其二減少因終端不兼容問題導致的用戶流失

希望有用哦~

功能單元用V，混合模塊用線性（瀑布） W模式用於版本，另外W可能需要有1個測試伺服器，可以虛一個出來。

缺陷收斂有很多策略可以用。對於模塊密度和時間人力可以精準算出。

手機的測試種類和其他的差別不大，都有兼容性和真機測試，端游也有硬體顯卡測試。

1.功能，條件邏輯，行為邏輯，ui邏輯，容錯測試。

2.協議層測試，資料庫對於一些排行榜測試。

3.性能基於引擎客戶端的測試，服務端監聽壓力測試數據。

4.內存物品定址防禦測試，內存泄露（客戶端GUI和調用測試）安卓上可以連接真機。

5.腳本測試。

等等等。代碼混淆這部分編譯版本時可勾選，這點比網頁遊戲簡單。

我是小白，我只是說說自己的觀點，不喜勿噴

手游的話一般3方面：遊戲的兼容性，遊戲的功能，遊戲的性能；

如果是黑盒測試的話，那保障遊戲的功能，是最為重要的，功能不行，其他的都不用說了。其次兼容性，跟性能也挺重要的，兼容性，至少要讓市面上的主流手機都能玩，可以在友盟這個網址看當前主流手機；性能：如果是灰盒，白盒的話，那性能一般是測試自己做的，但其實測試黑盒還是比較多的，一般性能，比如壓力測試，負載測試，可以用 LR 或者 Jmeter 等等，最好的話，讓程序那邊做工具測，這樣省事很多！最後，對於遊戲的兼容性的話，現在有一個 Testin雲測試的平台，有免費，也有收費，但是免費的很少機子，這個你懂的

遊戲上線需要用到的工具

遊戲測試：TestBird是國內最早突破遊戲引擎的手游測試工具，TestBird可以深入到遊戲內部進行包括：安裝、啟動、新手引導等自動化遊戲測試任務。國內還有一款測試工具叫做TestIn，最早做的是應用測試，後來也開始做手游測試了。

數據追蹤：友盟、TalkingData和最近風頭正勁的DataEye都是國內主流的數據追蹤產品，隨著近年來大數據的逐漸火爆。甚至有一些廠商開始提供免費的數據追蹤產品，但在選擇產品時還是要考慮產品本身是否適合。

安全加固：據了解目前這個市場並不是很受CP們重視，但是如果你不希望用戶因為使用到了被他人惡意篡改的過程序的遊戲遭受損失，那麼可以嘗試梆梆安全。

移動廣告營銷：YeahMobi是國內從事移動廣告營銷的新銳，產品已經在國內外擁有了巨大的用戶基數。對於一些急需流量變現或需要導入流量的遊戲來說YeahMobi是非常不錯的營銷工具。此外在國外還有諸如inmobi等洋產品可供選擇。

遊戲測試：TestBird是國內最早突破遊戲引擎的手游測試工具，TestBird可以深入到遊戲內部進行包括：安裝、啟動、新手引導等自動化手游測試任務。此外基於真人的評估的眾測業務能夠幫助開發者了對遊戲玩法進行改進，是幫助開發者打磨遊戲品質的重要利器。