怎麼進行游戲測試
⑴ 游戲黑盒測試方法有哪些
常用的黑盒測試技術有劃分等價類、邊界值分析法、錯誤推測法、因果圖法、判定表組成法、正交試驗設計、場景法。
黑盒測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序介面進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試著眼於程序外部結構，不考慮內部邏輯結構，主要針對軟體界面和軟體功能進行測試。
(1)怎麼進行游戲測試擴展閱讀：
黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關系出發進行測試的。很明顯，如果外部特性本身設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。
採用這種測試方法，測試工程師把測試對象看作一個黑盒子，完全不考慮程序內部的邏輯結構和內部特性，只依據程序的《需求規格說明書》，檢查程序的功能是否符合它的功能說明。測試工程師無需了解程序代碼的內部構造，完全模擬軟體產品的最終用戶使用該軟體，檢查軟體產品是否達到了用戶的需求。黑盒測試方法能更好、更真實地從用戶角度來考察被測系統的功能性需求實現情況。在軟體測試的各個階段，如單元測試、集成測試、系統測試及驗收測試等階段中，黑盒測試都發揮著重要作用，尤其在系統測試和確認測試中，其作用是其他測試方法無法取代的。
⑵ 游戲測試需要怎麼設計測試方案
同游戲行業從業人員（不過現在不做游戲了），嘗試回答一下：
測試用例在整個測試行業很普遍，並不只是測試游戲。
測試用例也沒有什麼高上大的地方，只是把你的測試過程寫下來而已。而為什麼要寫下來，是為了方便存檔，一是為了讓每次測試都能保證覆蓋到了全部的測試項，二是為了讓執行者知道需要測試那些地方（用例執行者和編寫者並不是同一個人的情況很常見）
打個最簡單的比方：
啟動游戲
輸入正確的用戶名密碼
點擊登陸
查看登陸結果</li></ol>
預期結果：可以正確登陸游戲
以上就是一條最簡單的測試用例，每次執行的時候按照步驟跑一遍即可。相信你一點都不陌生，這不是我每天做的事情么。
我們假設，今天要測試完一個登錄模塊，但測試該模塊的人今天請假，其他人對該模塊又不了解，如果沒有測試用例，不了解該模塊的肯定測試過程中會有非常多的遺漏。那麼之前如果寫過測試用例的話就會很簡單，換個人把所有用例執行一遍即可。
當然測試用例在進階過程中有非常多的書寫技巧和手法，不是一天兩天就能學會的，這也是老測試人員和新測試人員的區別之一
⑶ 手機游戲的測試過程最好要詳細一點的
首先：游戲的安裝卸載，升級覆蓋安裝這些最基本的測試是一定要做的。
然後：游戲登陸、注冊、記住密碼、斷網自動重連測試
之後：游戲內容測試。UI風格，游戲技能，演算法的正確測試。
一個產品的測試就是要找bug，完善它就好。過程無所謂只要提交了bug修復了產品這才是測試的目的。
⑷ 手機游戲怎麼做性能測試
如何做手游性能測試，首先要了解手游性能測試指標，大概分為以下幾個：包體大小、CPU佔用率、內存佔用率、電量流量耗用量、FPS（每秒傳輸幀數）
這里推薦你一個自動化測試平台WeTest性能測試平台網頁鏈接（騰訊游戲官方推出的）
⑸ 游戲性能測試如何開展
首先解釋游戲性能測試含義：
性能（performance）：是系統實現其功能的能力。例如，響應時間、吞吐能力、事務處理數；
性能測試：是指在特定負載情況下，確定系統的響應速度和穩定性的表現。它也可以研究、測量、驗證系統的其他特徵，比如可擴展性、可靠性和資源使用率。通俗的講：通過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否滿足生成性能要求，即在特定的運行條件下驗證系統的能力狀況。
按手游構成特點，將性能測試分為客戶端性能、伺服器性能兩大塊。
性能測試的關鍵指標
客戶端性能的關鍵指標有：CPU佔用率、內存佔用率、流量耗用量、FPS（每秒傳輸幀數）
伺服器端性能的關鍵指標有：響應時間、並發用戶數、吞吐量等；
如何做性能測試
明確測試目標；
了解性能測試需求；
編寫性能測試計劃；
分析性能測試需求；
編寫性能測試方案、設計測試場景；
相關資源准備(人力資源、硬體資源、軟體資源)；
測試程序開發；腳本維護、測試數據准備、測試監控准備；
執行性能測試並收集測試結果；
分析結果；
系統調優及再測試；性能測試五大誤區
4.性能測試工具推薦
簡單推薦2款工具，分別給玩家和開發者。
1. 玩家：安兔兔等跑分軟體
可以快速將app性能跑出一個整體分。但有個致命問題，無法單獨查看單獨某個功能、某個時間點的具體數值。缺點是無法定位問題。
2. 開發者：WeTest性能測試（騰訊WeTest官方出品）
提供Android版本和雲端版本2種性能測試方案，這里著重介紹下本地版本，使用3步即可：
1)打開WeTest性能測試頁面下載WeTest App，並安裝；
2)運行手機上的WeTestApp，選擇游戲後點「開始測試」；
3)上傳並查看報告
結束測試後，打開WeTest App點擊「上傳」按鈕。
登錄wetest.qq.com點擊「我的主頁」裡面，左側的「手游測試報告」，在頁面中就會出現「性能測試」結果報告，點擊查看，就可以查看完整的測試報告；
⑹ 游戲測聽要怎麼進行呢
游戲測聽是一種適用於小兒的主觀聽力學評估方法之一，可用於測試小兒的裸耳聽力和助聽聽閾，結果對後續助聽器驗配和調試至關重要。在該測試過程中讓兒童參與一個簡單、有趣的游戲，教會兒童對刺激聲做出明確可靠的反應，被測試的兒童必須能理解和執行這個游戲，並且在反應之前可以等待刺激聲的出現。通常情況下，對2.5-6歲的小兒採用該測試方法。
建議家長在家裡開展游戲測聽家庭訓練，以獲得准確的游戲測聽結果
家長首先需要讓小兒明白游戲規則：①聽到刺激聲就把手中的玩具放入玩具桶（或其它游戲相關器具中），特別小的聲音也要放；②沒有聽到刺激聲不能放玩具；③在刺激聲出現前要等待刺激聲的出現。
開展家庭訓練時選擇的玩具或玩法建議：要根據小兒的精細運動發育、認知能力、興趣等選擇玩具。對於年齡較小尚不能完成精細拼插動作的小兒，可以選擇體積較大的玩具，讓小兒握住放入較大口徑的玩具桶內，如乒乓球、大積木塊等；隨著小兒能力的發展，需要增加玩具的難度，變化玩具的玩法，如讓小兒放玩具時將玩具按照形狀、顏色、大小等特性歸類；對於精細運動有較好發育的小兒，可以增加玩具的趣味性，如為男孩選擇玩具飛機等拼插形狀的玩具，為女孩選擇冰激凌、娃娃等拼插形狀的玩具；另外選擇玩具時也不能讓小兒太感興趣，這樣會使其在好奇心的驅使下即使聽不到聲音也會把手中的玩具放下，出現假陽性反應。
家庭訓練給聲信號建議：①不同頻率范圍的響聲玩具給聲；②家長自己發音。
最後，在家庭訓練時需要家長特別注意讓小兒學會等待刺激聲出現。我們建議家長發出刺激聲的時間間隔毫無規律，給聲間隔可以長達10秒，也要有讓小兒拿起玩具就出現的刺激聲。如果給聲間隔時小兒沒有等待，家長要用誇張的動作和表情阻止小兒的動作。
⑺ 游戲測試都干什麼怎麼干詳細點
要看是那方面的測試，一般的游戲製作公司都有自己的測試團隊的，現在也有專業的測試團隊，一些小游戲都是委託此類團隊來測試的，測試的類型有很多，一般包括硬體，bug（漏洞），游戲性幾個方面。
⑻ 電腦怎麼測試游戲
您好，方法
網路搜索游戲加加，記住是選擇後面帶有官方標識的。
選擇到下載界面。
選擇Windows PC 端下載。
找到自己下載安裝包的地方，打開安裝包。
選擇簡體中文並點擊下一步。
選擇你要下載的磁碟，然後點下一步完成即可。
打開軟體之後他會自動掃描你的系統和硬體但是絕對不會給你安裝任何垃圾軟體
如何測試自己的電腦能玩什麼游戲
游戲跑分就可以查看自己的電腦能不能玩大型的3D游戲了。
跑完之後他會給你一個合理的結果，有一些小白都可以用這個軟體去測試一下自己有沒有被坑。
⑼ 怎麼對一個游戲進行測試
他們測試時只開放一部分的帳號,只有有內測帳號的擦可以進去玩,玩的過程中你會碰到一些問題,而後他們把問題給解決掉,等他們內測的差不多沒什麼缺陷了他們就開始公測,開始正式運營,一般內測等級都清零的.
⑽ 面試題: 如何對一個游戲進行設計測試用例.
一、游戲軟體與通用軟體的區別 a) 通用軟體的需求明確，游戲軟體需求理想化 i. 通用軟體中用戶每步操作的預期結果都是明確且有規范可參考的，而網游中並 不是所有的需求都有一個明確的預期結果，拿技能平衡性來說，我們所謂的平衡也只是相對的平衡，而非絕對的平衡。沒有什麼明確的參考參數。只能根據以往游戲的經驗獲得一個感知的結果。 ii. 網路游戲中的某些功能是有預期結果可參考的。例如組隊、交易，而另外一些 帶有策劃創意的功能，卻是根據策劃個人的理解，來確定其預期結果的。人的思考力都是有限的，所以不能保證在他的創意中會考慮到各種各樣復雜的細節。也不能夠保證這個創意就可以完全被用戶所接受。 當你作為游戲測試人員時，很多時候你需要做的不僅僅是驗證功能。也需要幫助開發者和用戶找到一個互相容忍的平衡點。游戲軟體的測試員帶有對策劃需求的懷疑，力求通過自己的努力在玩家和開發者之間將可能產生的矛盾減小。 b) 通用軟體開發過程中需求變更少，游戲軟體開發過程中需求便更快 i. 通用軟體的使用人群和軟體的功能針對性，決定軟體從開始製作就很少再有新 的需求變更。而游戲軟體，為了滿足玩家對游戲的認可度，策劃需要不斷的揣摩玩家的喜好，進行游戲功能的改進。加之網游製作本身就是一個龐大復雜的工程，開發者不可能做到在開發的前期，就對游戲架構及擴展性做出最好的評估。所以導致為了滿足用戶的需求而不斷的進行一些基礎架構的修改，基礎架構的修改必然導致某些功能的顛覆。所以就出現了，游戲開發過程中的一個惡性循環，當基礎架構修改到滿意了，玩家的需求又有了新的變化，隨之而來的又要進行新的調整，再進行新的修改。最終導致了游戲軟體的開發周期不斷加長。任何一個有經驗的團隊，對於每一個影響基礎的改動都應該做出正確的評估。 二、網游有哪些測試內容 a) 性能 i. 客戶端性能 ii. 伺服器端性能 1. 伺服器 2. 資料庫 iii. 網路 b) 功能 i. 從運行完game.exe打開游戲界面後可進行的各種操作、玩法 ii. 界面 iii. 音樂 c) 自動化 i. 測試工作組織實施中需要的工具、軟體、平台的開發 ii. 自動化的回歸測試作用：游戲中基礎的、變動不大的、出錯率高的、可進行 checklist重復測試的功能、性能等自動化是一個好方法 iii. 任何時候自動化都取代不了人腦，它只是將一些重復性的勞動從我們測試人員 身上去掉，讓我們有更多的時間做更有意義的事情，如果你覺得你做一件事情是重復的，且有規律可行的，不防考慮自動化 三、游戲中針對功能性測試測試用例編寫淺談
國際體驗設計協會IXDC 歷屆大會精彩集錦
游戲用戶體驗大會 互聯網產品大會 交互設計體驗周
作者：sunli 製作時間：2008年10月份 個人空間地址：
[url]http://www.51testing.com/?89706[/url] 本文檔僅供學習參考，請誤擅自轉載
2 / 3 先了解下游戲中有哪些功能： a) 游戲發開中的功能有哪些 i. 不同的游戲對於功能的劃分不同，但是目前主流一些功能劃分中有以下內容： 1. 基礎操作 2. Npc 3. 地圖 4. 裝備 5. 劇情 6. 技能 7. 人際 8. PVP 9. …… 這樣我們很簡單的將整個游戲的功能進行了劃分，劃分完畢，下來的工作就是針對某個功能的測試了。很多人都問過一個問題，游戲測試中測試用例到底有什麼用。下面繼續~ b) 游戲測試的測試用例有什麼作用 i. 測試執行過程中，按照用例指示的操作檢查操作結果是否正確，記錄測試過程 中發現的bug ii. 按照用例的執行結果確認功能的通過與否，也有的按照用例的覆蓋率來確定單 服測試的通過與否 iii. 便於回歸測試的執行 這樣講應該比較明白了吧。 c) 測試用例應該包括什麼——測試執行過程中所需的所有信息，舉例說明下。例如： i. 表頭：功能名稱、案例編寫人員、編寫時間、測試人員、測試時間 ii. 正文：功能點、測試點、測試輸入、預期結果、實際結果 iii. 用例執行結果統計 d) 功能點模塊化理念 都知道一個復雜龐大的系統，程序在實現時會將其分成若干模塊按照模塊功能優先順序進行實現。我們測試過程中也採用這種方法，將復雜的功能點按照實現功能進行分類，分類後的測試點，再進行分類，直至細分成為一條條用例。就像庖丁解牛那樣。 按照等價類劃分法，將同一判斷條件的測試點組成一個集，在這個條件基礎上再次判斷的條件，我們假設它已經成立。這樣在用例設計過程中就需要測試人員清楚的知道，哪些條件是一類需優先確認的，哪些是以這類條件為基礎的。我們最終形成的測試用例一定確保的是一條用例只檢查一個測試點。 這樣設計也有另外一個好處，如果一條用例不能走通，其它的還可以繼續檢測，經常會遇到測試過程中由於一個bug，導致測試工作停滯。現在這樣子我們就可以採取腳本調試，或者其它方法跳過有bug的測試內容，繼續進行其它測試點的測試了。 e) 場景測試法協助功能點細分 游戲測試中，場景測試方法是經常用到的一種方法，什麼是場景測試法，及按照功能設計要求，在腦中模擬出來的一個功能使用時的操作流程。按照每步操作的針對點，將針對點劃分為所用例設計時的小功能點。劃分時需每步針對點的各種檢查點分到該功能點內設計為該功能點的檢查點。再根據檢查點進行測試輸入（及操作過程）的編寫。用例編寫過程中的思考方式就如上了。講起來比較抽象，希望對
作者：sunli 製作時間：2008年10月份 個人空間地址：
[url]http://www.51testing.com/?89706[/url] 本文檔僅供學習參考，請誤擅自轉載
3 / 3 大家有所幫助。 f) 用例的設計原則——一直有人問到底要詳細到什麼程度 i. 我們不期待用例編寫到任何人都可以執行，也沒有這個必要 ii. 我們針對的是網游的測試人員，至少是玩過網游的人，這些人對於游戲中的基 礎設定都有認識，我們不可能對著一個不知道任務界面是什麼的人大講怎麼測試任務。所以我們用例編寫的原則就是針對我們測試組內的測試人員。 iii. 但是，請不要簡略到別的測試人員看不懂，特別是當你是專職的用例編寫人員 時，編寫時請多考慮下語言描述的方式。請讓你的同伴可以看懂，你所要表達的意思。 iv. 用例是沒有固定格式的，它的主要原則就是，測試中所需所有信息，我通過你 的文檔都能夠獲取到。所以不要再執著的像別人要模板。模板你自己都可以設計，發揮你的創意。 四、編寫過程注意事項 與設計人員的溝通 拿到一份文檔時請不要急於編寫，在這之前很多事情需要做，請先將文檔閱讀至少三遍，然後思考下，你自己大腦中是否有你所看文檔功能點的一個流程圖，當確認已經准備好了。開始設計用例，用例設計的過程就是與設計人員不斷溝通，深入了解功能的過程。你會發現，或許跟你之前流程圖中想像的並不完全一樣。這個時候不必驚訝，去找他們核對就好。不怕發現問題，就怕沒有發現問題，最終做了很多無用功。編寫過程中發現的沒有預期結果的內容，請及時與策劃人員、程序人員核對，必須三方核對。核對完畢提醒策劃人員及時更新設計案，提醒程序人員設計案新修改內容。這樣你會發現，設計測試用例過程的本身就是發現策劃案不完善的過程。 請運用你的思維，採用邊界法、等價類劃分法、錯誤推斷法、以及以往的經驗，將每一個測試點的所有需檢查點進行充分的設計。發揮你的主動性，和測試組內其它人探討你認為可能存在風險的測試點，以便得到更多有價值的信息