標簽：
隨著(zhù)智能設備的普及和移動(dòng)互聯(lián)網(wǎng)的興起，各家互聯(lián)網(wǎng)巨頭紛紛在往移動(dòng)端布局和轉型，同時(shí)初創(chuàng )的移動(dòng)互聯(lián)網(wǎng)公司也都盯著(zhù)這個(gè)市場(chǎng)希望分一杯羹。在這個(gè)大環(huán)境下，互聯(lián)網(wǎng)的重心已經(jīng)慢慢從Web端轉向了移動(dòng)端，而移動(dòng)端的軟件測試也變得越來(lái)越重要了。
在移動(dòng)端的軟件里，手游又是其中非常大的一塊。從下面的圖可以看出，智能手機的普及和手游玩家的增長(cháng)是密切相關(guān)的：
加入鵝廠(chǎng)前，筆者曾經(jīng)長(cháng)期從事手機App的測試開(kāi)發(fā)工作。1年前加入鵝廠(chǎng)后轉行做了手游測試工作，通過(guò)摸索實(shí)踐，發(fā)現兩者在相同的測試理論基礎之上，其實(shí)有著(zhù)非常不同的測試場(chǎng)景和測試需求。下面就為大家整理一下其中的基礎部分，涵蓋了兩者在手工和自動(dòng)化測試方面的不同，希望能幫到想從App測試轉到手游測試的朋友們。
手機App和手游的開(kāi)發(fā)技術(shù)不同，這導致了兩者的自動(dòng)化測試技術(shù)是截然不同的。
以安卓開(kāi)發(fā)舉例，手機App一般使用Android SDK開(kāi)發(fā)，使用Java編寫(xiě)。通過(guò)Android提供的服務(wù)，我們可以獲取App當前窗口的視圖信息，進(jìn)而查找和操作按鈕等控件，以完成自動(dòng)化測試，如Uiautomator。這個(gè)過(guò)程是標準化的，從技術(shù)上來(lái)說(shuō)沒(méi)有任何難度，因此各個(gè)公司各個(gè)App自動(dòng)化測試的方法都大同小異。
但手游的開(kāi)發(fā)卻不是這樣。手游一般使用引擎開(kāi)發(fā)，現在著(zhù)名的有cocos2d和unity3d。兩者都是使用引擎自帶的語(yǔ)言進(jìn)行開(kāi)發(fā)，主流的分別是c++和c#，雖然在開(kāi)發(fā)過(guò)程中也有按鈕等控件的概念，但當運行時(shí)由引擎渲染后就變成了一副簡(jiǎn)單的圖片：
圖：游戲中看到的只是一副簡(jiǎn)單的圖片，按鈕已經(jīng)不是控件了
因此，我們就無(wú)法通過(guò)Android自帶的服務(wù)來(lái)找出游戲中的按鈕了，也就沒(méi)法進(jìn)行常規的自動(dòng)化測試。
如果有人說(shuō)自己的技術(shù)是基于A(yíng)ndroid原生控件識別的，那就一定做不了手游自動(dòng)化測試。這個(gè)問(wèn)題大家都在探索解決方案，我們現在通過(guò)注入引擎SDK到安裝包反射出引擎層控件的方法進(jìn)行自動(dòng)化測試，實(shí)踐下來(lái)具有很好的效果。
游戲的場(chǎng)景和過(guò)程是動(dòng)態(tài)并且伴有隨機要素的，這體現在兩點(diǎn)。
這兩點(diǎn)對自動(dòng)化測試帶來(lái)了極大的挑戰，如果測試腳本寫(xiě)的不夠靈活，很容易導致上一次運行成功的腳本這一次就無(wú)法運行了。我們需要在測試腳本里適當的加入探索和自適應的功能。
App測試就沒(méi)有這個(gè)問(wèn)題，大部分App的使用方式都是靜態(tài)且可以重復的。因此自動(dòng)化測試可以完全按照測試腳本進(jìn)行編寫(xiě)并執行。
手游和App的第二個(gè)玩法不同在于探索性。App一般都是功能性的，好的App需要把它的功能簡(jiǎn)單明了地告訴用戶(hù)。而游戲重在娛樂(lè )性，需要給玩家一定的探索要素。因此在做手游測試的時(shí)候，我們需要測試游戲的用戶(hù)幫助說(shuō)明是否清晰，同時(shí)后續的游玩和探索過(guò)程和前面給出的說(shuō)明之間是否有合理聯(lián)系，規則的指示是否有足夠的提示性。
App希望做的越簡(jiǎn)單，用戶(hù)的使用成本越低越好。而手游是有難度設置的。我們在做手游功能測試的時(shí)候，會(huì )把資源和等級調到最大以方便后期功能的執行，但當所有的功能測試都做完后，我們需要把自己的資源初始化，以“回歸”一個(gè)普通玩家的水平，通過(guò)普通玩家的視角來(lái)查看游戲的難度提升是否合理，資源分配是否均勻。
App的使用是功能性的，一個(gè)功能的重復使用總是一樣的。而手游具有關(guān)卡的概念，即便是同一種玩法，關(guān)卡和關(guān)卡之間也有細微的差別，前面的關(guān)卡測試正確了，并不表示后面的關(guān)卡一定是正確的。作者曾經(jīng)碰到過(guò)一個(gè)手游的Bug，當游戲進(jìn)行到某個(gè)后期關(guān)卡時(shí)，游戲一定會(huì )崩潰。而導致這個(gè)Bug的原因也很簡(jiǎn)單：這個(gè)關(guān)卡的圖片資源在打包客戶(hù)端的時(shí)候沒(méi)有加入。因此當我們玩前面的關(guān)卡時(shí)并不會(huì )觸發(fā)這個(gè)Bug，但一到后面的關(guān)卡就出錯了。
這類(lèi)Bug雖然原因簡(jiǎn)單，但確實(shí)非常難測試到。因為各個(gè)關(guān)卡的玩法雖然都一致，但一個(gè)游戲的關(guān)卡數卻是非常多。如果我們要遍歷所有的關(guān)卡走一遍，那耗費的人力成本將是非常大的。對于這類(lèi)重復性的關(guān)卡測試，建議使用自動(dòng)化腳本進(jìn)行遍歷。
App的使用普遍是單人的，而手游往往有玩家對戰的PvP模式，好的手游更是具有實(shí)時(shí)的PvP模式。由于兩個(gè)玩家實(shí)時(shí)進(jìn)行游戲合作或者對戰，因此網(wǎng)絡(luò )延遲的測試就變得非常關(guān)鍵了。我們在測試中需要模擬不同的網(wǎng)絡(luò )對游戲延遲的影響，觀(guān)察兩個(gè)玩家的狀態(tài)和數據是否一致，同時(shí)體驗網(wǎng)絡(luò )延遲對游戲手感的影響，這在傳統的App測試中是完全不需要的。
現在的手機App基本上以廣告收入為主，并不會(huì )直接向用戶(hù)收取費用。而手游的直接消費群體就是玩家，在游戲過(guò)程中伴隨著(zhù)玩家大量的支付操作。由于這類(lèi)操作和玩家的金錢(qián)密切相關(guān)，因此支付類(lèi)的測試在任何游戲中都要做最高優(yōu)先級的保證。
我們需要在各種嚴格的環(huán)境下保證玩家的支付操作被正確執行或者得到了正確的失敗提醒。例如當網(wǎng)絡(luò )狀況很差的時(shí)候，用戶(hù)在支付界面的多次確認操作必須只能被執行一次。當用戶(hù)在支付過(guò)程中斷網(wǎng)，未收到貨物時(shí)，游戲需要在玩家的網(wǎng)絡(luò )恢復后第一時(shí)間補發(fā)貨物，并作出明顯的提示。另外支付操作需要在大量不同系統、不同型號的手機上進(jìn)行適配操作，以降低出錯的可能性。
對于大多數非支付類(lèi)App來(lái)說(shuō)，安全并不是一個(gè)特別大的問(wèn)題，只需要保證登錄鑒權的安全性即可。App是一個(gè)方便用戶(hù)的工具，沒(méi)有人會(huì )在用自己的計算器App時(shí)候鎖定內存，或者把加法操作變?yōu)槌朔ú僮鳌?/p>
手游在這點(diǎn)上很不一樣，手游與玩家在某種程度上具有“對抗”要素，玩家要戰勝游戲關(guān)卡獲得獎勵，而游戲關(guān)卡要設置一定的難度阻止玩家。如果游戲的外掛橫行，玩家不需要任何對抗就能獲得勝利，一方面會(huì )對游戲的平衡性造成影響，使得某些玩家的資源大大超過(guò)別的玩家；另一方面從長(cháng)遠看會(huì )使得這個(gè)游戲變得無(wú)趣，從而造成玩家的離開(kāi)。
對游戲進(jìn)行安全測試的普遍方法為通過(guò)鎖定/修改內存來(lái)鎖定和修改游戲資源、通過(guò)修改游戲內存來(lái)改變游戲邏輯簡(jiǎn)化游戲流程等。
一般的手游App沒(méi)有付費用戶(hù)的概念，所有的用戶(hù)都是使用同一個(gè)功能。即便有付費用戶(hù)，他們和普通用戶(hù)的區別也非常明顯：付費用戶(hù)可以使用一些額外功能。手游的付費用戶(hù)和非付費用戶(hù)的界線(xiàn)并沒(méi)有這么明顯。手游里根據用戶(hù)付費的多少分為非R用戶(hù)，小R用戶(hù)，大R用戶(hù)等。我們需要在策劃的時(shí)候就計算好這些付費用戶(hù)的投入和回報，并在測試的過(guò)程中驗證這些。舉兩個(gè)例子，如果一個(gè)大R用戶(hù)獲得的回報，非R用戶(hù)只用很少的時(shí)間就能獲得，那大R用戶(hù)一定不滿(mǎn)意，這個(gè)收費項目的設置就是不合理的；如果兩個(gè)購買(mǎi)項的金額相同，而收益明顯不同，那也會(huì )造成玩家的不滿(mǎn)。
雖然我們這里討論App和手游主要是前端客戶(hù)端，但其實(shí)兩者的后臺性能也有區別。相比一般的App，手游的在線(xiàn)人數明顯更有規律性且更集中，一般在中午12點(diǎn)和晚上8點(diǎn)是兩個(gè)明顯的高峰。因此手游的性能測試就要貼合這種用戶(hù)模型，能夠處理極值情況下的服務(wù)器性能負載。當然，兩者都會(huì )受到節假日較大的影響，這個(gè)對于A(yíng)pp和手游來(lái)說(shuō)是一致的。
除了上面提到的這么多手游測試和App測試的不同點(diǎn)，其實(shí)兩者也有很多相似之處，在測試的時(shí)候都不能遺忘，例如手機來(lái)電、短信的中斷測試，碎片化的兼容性測試（尤其是安卓），客戶(hù)端運行在手機上的性能測試，網(wǎng)絡(luò )較差或者網(wǎng)絡(luò )頻繁切換的弱網(wǎng)絡(luò )測試，已經(jīng)用戶(hù)體驗和UI測試等。
手游與App測試如何快速轉型？ —— 過(guò)來(lái)人科普手游與App測試四大區別
標簽：
聯(lián)系客服
