官網(wǎng)下載和手機(jī)APP有什么區(qū)別？

一、APP自動化測試完全不同于手游自動化測試

以安卓開發(fā)舉例，手機(jī)App一般使用Android SDK開發(fā)，使用Java編寫。通過Android提供的服務(wù)，我們可以獲取App當(dāng)前窗口的視圖信息，進(jìn)而查找和操作按鈕等控件，以完成自動化測試，如Uiautomator。這個過程是標(biāo)準(zhǔn)化的，從技術(shù)上來說沒有任何難度，因此各個公司各個App自動化測試的方法都大同小異。

但手游的開發(fā)卻不是這樣。手游一般使用引擎開發(fā)，現(xiàn)在著名的有cocos2d和unity3d。兩者都是使用引擎自帶的語言進(jìn)行開發(fā)，主流的分別是c++和c#，雖然在開發(fā)過程中也有按鈕等控件的概念。

因此，我們就無法通過Android自帶的服務(wù)來找出游戲中的按鈕了，也就沒法進(jìn)行常規(guī)的自動化測試。

二、玩法不同導(dǎo)致功能測試更復(fù)雜

2.1 隨機(jī)性

游戲的場景和過程是動態(tài)并且伴有隨機(jī)要素的，這體現(xiàn)在兩點。

1. 你重復(fù)玩一個游戲關(guān)卡，很可能兩次出現(xiàn)敵人以及游戲過程是不同的。

2. 你玩一個手游的時候不進(jìn)行操作，敵人和周圍的場景也在時刻發(fā)生改變。

這兩點對自動化測試帶來了極大的挑戰(zhàn)，如果測試腳本寫的不夠靈活，很容易導(dǎo)致上一次運行成功的腳本這一次就無法運行了。我們需要在測試腳本里適當(dāng)?shù)募尤胩剿骱妥赃m應(yīng)的功能。

App測試就沒有這個問題，大部分App的使用方式都是靜態(tài)且可以重復(fù)的。因此自動化測試可以完全按照測試腳本進(jìn)行編寫并執(zhí)行。

2.2 探索性

手游和App的第二個玩法不同在于探索性。App一般都是功能性的，好的App需要把它的功能簡單明了地告訴用戶。而游戲重在娛樂性，需要給玩家一定的探索要素。因此在做手游測試的時候，我們需要測試游戲的用戶幫助說明是否清晰，同時后續(xù)的游玩和探索過程和前面給出的說明之間是否有合理聯(lián)系，規(guī)則的指示是否有足夠的提示性。

2.3 難度測試

App希望做的越簡單，用戶的使用成本越低越好。而手游是有難度設(shè)置的。我們在做手游功能測試的時候，會把資源和等級調(diào)到最大以方便后期功能的執(zhí)行，但當(dāng)所有的功能測試都做完后，我們需要把自己的資源初始化，以“回歸”一個普通玩家的水平，通過普通玩家的視角來查看游戲的難度提升是否合理，資源分配是否均勻。

2.4 關(guān)卡測試

App的使用是功能性的，一個功能的重復(fù)使用總是一樣的。而手游具有關(guān)卡的概念，即便是同一種玩法，關(guān)卡和關(guān)卡之間也有細(xì)微的差別，前面的關(guān)卡測試正確了，并不表示后面的關(guān)卡一定是正確的。作者曾經(jīng)碰到過一個手游的Bug，當(dāng)游戲進(jìn)行到某個后期關(guān)卡時，游戲一定會崩潰。而導(dǎo)致這個Bug的原因也很簡單：這個關(guān)卡的圖片資源在打包客戶端的時候沒有加入。因此當(dāng)我們玩前面的關(guān)卡時并不會觸發(fā)這個Bug，但一到后面的關(guān)卡就出錯了。

這類Bug雖然原因簡單，但確實非常難測試到。因為各個關(guān)卡的玩法雖然都一致，但一個游戲的關(guān)卡數(shù)卻是非常多。如果我們要遍歷所有的關(guān)卡走一遍，那耗費的人力成本將是非常大的。對于這類重復(fù)性的關(guān)卡測試，建議使用自動化腳本進(jìn)行遍歷。

2.5 PvP測試

App的使用普遍是單人的，而手游往往有玩家對戰(zhàn)的PvP模式，好的手游更是具有實時的PvP模式。由于兩個玩家實時進(jìn)行游戲合作或者對戰(zhàn)，因此網(wǎng)絡(luò)延遲的測試就變得非常關(guān)鍵了。我們在測試中需要模擬不同的網(wǎng)絡(luò)對游戲延遲的影響，觀察兩個玩家的狀態(tài)和數(shù)據(jù)是否一致，同時體驗網(wǎng)絡(luò)延遲對游戲手感的影響，這在傳統(tǒng)的App測試中是完全不需要的。

三、手游測試更看重商業(yè)類測試

3.1 支付測試

現(xiàn)在的手機(jī)App基本上以廣告收入為主，并不會直接向用戶收取費用。而手游的直接消費群體就是玩家，在游戲過程中伴隨著玩家大量的支付操作。由于這類操作和玩家的金錢密切相關(guān)，因此支付類的測試在任何游戲中都要做最高優(yōu)先級的保證。

我們需要在各種嚴(yán)格的環(huán)境下保證玩家的支付操作被正確執(zhí)行或者得到了正確的失敗提醒。例如當(dāng)網(wǎng)絡(luò)狀況很差的時候，用戶在支付界面的多次確認(rèn)操作必須只能被執(zhí)行一次。當(dāng)用戶在支付過程中斷網(wǎng)，未收到貨物時，游戲需要在玩家的網(wǎng)絡(luò)恢復(fù)后第一時間補(bǔ)發(fā)貨物，并作出明顯的提示。另外支付操作需要在大量不同系統(tǒng)、不同型號的手機(jī)上進(jìn)行適配操作，以降低出錯的可能性。

3.2 安全測試

對于大多數(shù)非支付類App來說，安全并不是一個特別大的問題，只需要保證登錄鑒權(quán)的安全性即可。App是一個方便用戶的工具，沒有人會在用自己的計算器App時候鎖定內(nèi)存，或者把加法操作變?yōu)槌朔ú僮鳌?/p>

手游在這點上很不一樣，手游與玩家在某種程度上具有“對抗”要素，玩家要戰(zhàn)勝游戲關(guān)卡獲得獎勵，而游戲關(guān)卡要設(shè)置一定的難度阻止玩家。如果游戲的外掛橫行，玩家不需要任何對抗就能獲得勝利，一方面會對游戲的平衡性造成影響，使得某些玩家的資源大大超過別的玩家；另一方面從長遠(yuǎn)看會使得這個游戲變得無趣，從而造成玩家的離開。

對游戲進(jìn)行安全測試的普遍方法為通過鎖定/修改內(nèi)存來鎖定和修改游戲資源、通過修改游戲內(nèi)存來改變游戲邏輯簡化游戲流程等。

3.3 收益測試

一般的手游App沒有付費用戶的概念，所有的用戶都是使用同一個功能。即便有付費用戶，他們和普通用戶的區(qū)別也非常明顯：付費用戶可以使用一些額外功能。手游的付費用戶和非付費用戶的界線并沒有這么明顯。手游里根據(jù)用戶付費的多少分為非R用戶，小R用戶，大R用戶等。我們需要在策劃的時候就計算好這些付費用戶的投入和回報，并在測試的過程中驗證這些。舉兩個例子，如果一個大R用戶獲得的回報，非R用戶只用很少的時間就能獲得，那大R用戶一定不滿意，這個收費項目的設(shè)置就是不合理的；如果兩個購買項的金額相同，而收益明顯不同，那也會造成玩家的不滿。

四、后臺性能不同

雖然我們這里討論App和手游主要是前端客戶端，但其實兩者的后臺性能也有區(qū)別。相比一般的App，手游的在線人數(shù)明顯更有規(guī)律性且更集中，一般在中午12點和晚上8點是兩個明顯的高峰。因此手游的性能測試就要貼合這種用戶模型，能夠處理極值情況下的服務(wù)器性能負(fù)載。當(dāng)然，兩者都會受到節(jié)假日較大的影響，這個對于App和手游來說是一致的。

五、測試工具

關(guān)于測試工具，這里著重推薦下WeTest質(zhì)量開放平臺。WeTest提供一站式的游戲測試服務(wù)，包括碎片化的兼容性測試（尤其是安卓），客戶端運行在手機(jī)上的性能測試，網(wǎng)絡(luò)較差或者網(wǎng)絡(luò)頻繁切換的弱網(wǎng)絡(luò)測試，以及用戶體驗和UI測試等，在游戲的全生命周期都能照顧到。