怎么进行游戏测试
⑴ 游戏黑盒测试方法有哪些
常用的黑盒测试技术有划分等价类、边界值分析法、错误推测法、因果图法、判定表组成法、正交试验设计、场景法。
黑盒测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
(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. 用例是没有固定格式的，它的主要原则就是，测试中所需所有信息，我通过你 的文档都能够获取到。所以不要再执着的像别人要模板。模板你自己都可以设计，发挥你的创意。 四、编写过程注意事项 与设计人员的沟通 拿到一份文档时请不要急于编写，在这之前很多事情需要做，请先将文档阅读至少三遍，然后思考下，你自己大脑中是否有你所看文档功能点的一个流程图，当确认已经准备好了。开始设计用例，用例设计的过程就是与设计人员不断沟通，深入了解功能的过程。你会发现，或许跟你之前流程图中想象的并不完全一样。这个时候不必惊讶，去找他们核对就好。不怕发现问题，就怕没有发现问题，最终做了很多无用功。编写过程中发现的没有预期结果的内容，请及时与策划人员、程序人员核对，必须三方核对。核对完毕提醒策划人员及时更新设计案，提醒程序人员设计案新修改内容。这样你会发现，设计测试用例过程的本身就是发现策划案不完善的过程。 请运用你的思维，采用边界法、等价类划分法、错误推断法、以及以往的经验，将每一个测试点的所有需检查点进行充分的设计。发挥你的主动性，和测试组内其它人探讨你认为可能存在风险的测试点，以便得到更多有价值的信息