970797游戏攻略网
游戏测试中应该编写哪些测试用例？
一、游戏软件与通用软件的区别 二、网游有哪些测试内容 三、游戏中针对功能性测试测试用例编写浅谈 a） 游戏发开中的功能有哪些 b） 游戏测试的测试用例有什么作用 c）测试用例应该包括什么 d） 功能点模块化理念 e）场景测试法协助功能点细分 f）用例的设计原则 四、编写过程注意事项
如何学习编写游戏测试用例 游戏测试法？
同游戏行业从业人员（不过现在不做游戏了），尝试回答一下： 测试用例在整个测试行业很普遍，并不只是测试游戏。
测试用例也没有什么高上大的地方，只是把你的测试过程写下来而已。
而为什么要写下来，是为了方便存档，一是为了让每次测试都能保证覆盖到了全部的测试项，二是为了让执行者知道需要测试那些地方（用例执行者和编写者并不是同一个人的情况很常见）打个最简单的比方：启动游戏 输入正确的用户名密码点击登陆查看登陆结果预期结果：可以正确登陆游戏以上就是一条最简单的测试用例，每次执行的时候按照步骤跑一遍即可。
相信你一点都不陌生，这不是我每天做的事情么。
我们假设，今天要测试完一个登录模块，但测试该模块的人今天请假，其他人对该模块又不了解，如果没有测试用例，不了解该模块的肯定测试过程中会有非常多的遗漏。
那么之前如果写过测试用例的话就会很简单，换个人把所有用例执行一遍即可。
当然测试用例在进阶过程中有非常多的书写技巧和手法，不是一天两天就能学会的，这也是老测试人员和新测试人员的区别之一…
测试用例是什么
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例[1](Test Case)目前没有统一的定义。
比较常用的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
不同类别的软件，测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。
测试用例[2](Test Case)是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不同的趋势。
要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。
测试用例反映了要核实的需求。
然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。
例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。
既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。
选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
游戏测试面试题
腾讯公司的面试题1 、对 MMORPG 的 CLIENT/SERVER 使用白盒和黑盒的方法进行集成和系统测试； 2 、编写测试计划完成测试任务。
工作要求： 1、了解C/S结构，并熟悉TCP/IP、UDP协议； 2、掌握常用的软件测试工具、测试流程 ，熟悉软件工程； 3、熟悉C++或Delphi Windows编程； 4、了解游戏客户端程序设计和服务器架构方式；此题是腾讯招聘游戏测试人员的题目！通知偶去面试！今天上午偶p点p点的就去坐了公交，一个半小时后到了公司总部，（附：公司总部是受其他城市的委托来面试我的）主考是北方人，我也是北方人，于是很快就出题了！如下！1，网络游戏交易的流程，用Oracl,sql，叙述出来2，找到交易这个流程之间的测试点然后问偶，能写出来吗？偶说，能，问：需要多久？偶：20分钟然后对表！关门，偶开始狂写狂画，之后偶觉的思路没理清，换张纸，慢慢画，急切间服务器的英文—server忘记了，而且字体超级烂，偶本来字很好看的，，，毕业至今没写过几个字哈，生疏了，也紧张。
终于在20分钟内大概画了个流程图针对于第一题，并附上测试用例！第二题，偶只写出了两个测试点！门开，主考进来，看偶的纸，说，我要的就是这个，然后问：软件测试最重要的是什么？偶觉的哪个阶段都重要啊，不厌其烦也很重要，于是偶就头晕晕的很笃定的说功能测试最重要！又问些对游戏的感受和了解，就ok了！最后问偶愿意去另外的城市工作吗？给偶一个考虑的机会，偶呆了一秒说：您知道，我刚来这里，是自己来的，无牵无挂，只要是xx公司，哪个城市都行！于是结束了面试！偶本来以为不会这么良好吧，偶的第一次面试！刚刚从公交上下来，准备回住的地洗澡澡，电话响了，是那个城市的分部打来的电话，说是要电话面试我，由于大街上很嘈杂，狂跑到小区的里面蹲在草坪上接受面试，呵呵！问的问题跟上午面试的题一样，不过交易变成了组队，偶还照我上午的思路说了下，但是人家说那不对，然后自己说了下去，可惜我没听清楚他说的什么，因为那会信号不好，然后我跟他口风说对对，是那样，然后继续问我第2个问题：玩过什么游戏，对游戏的熟悉程度，以及你认为的游戏测试包括那些？我的回答：因为本人接触游戏很早，从传奇到奇迹，到现在的3d，天堂2，魔兽世界，英雄，热血江湖，只要是rpg的基本上都玩过，不管是q版的还是武侠魔幻的，还有休闲类的，比如泡泡堂，疯狂坦克等等，强调了我的测试经验是休闲类的游戏，包括大富翁，泡泡龙，主要负责功能测试，立足于用户角度，包括键盘的操作，指令的确认返回，可玩性测试等，[这期间他还问我竞技类游戏呢？比如cs，我说呵呵，cs以前是我的最爱]然后他问：你对可玩性测试是怎么认识的偶回答：包括色彩的显示，画面的连接，服务器的流畅度，以及游戏平衡性的设置，举例来说，以前的奇迹比传奇操作简单一点，这是一个方面，奇迹的装备很华丽能够吸引人，泡泡堂的角色造型很可爱，容易吸引女孩子，这些都是可玩性方面的第三个问题：你认为象早期的超级玛丽游戏上面的按键怎么做测试？偶回答：超级玛丽的游戏的键盘很简单，手柄上面的跳，走，跑，和四个方向键，四个方向键可以用枚举的方法测试，看其输入跟确认结果是否一样，不一样了就是问题所在，同样的功能键–跑跳走等也是这样！（其实偶回答的应该是属于测试目的，和测试脚本，与测试执行，测试平估之间的联系~渴望高手指点一下偶这样的思路正确与否？）他问：有没有想到测试时候同时按几个键，或者乱按键会出现什么结果？偶回答：当然需要这样的测试，站在用户的角度来说，我们做测试应该尽全力的进行全方位的思考和测试！第四个问题：给你一个测试脚本，你怎么制定测试计划？你的测试目标是什么？偶回答：测试目标我想应该有个最高测试目的，游戏测试和软件测试的不同也包含有这一点，游戏测试的最终目标是让普通大众去把握和接受，而软件有没这个普遍性，所以制定测试计划的时候也应该跟随脚本向这个目标走。
然后就是个人认为测试过程是随着软件游戏的开发过程而进行的，每个阶段都应该有不同的开发过程和测试过程，所以每个阶段的测试计划和测试目的是不同的，我不知你问的具体指哪个方面，而我以前从事的是功能测试，就是黑盒测试！这时还问偶一个问题：你做的功能测试是怎么发现并提交bug的？偶的回答：我以前的测试过程是每天的测试内容侧重点是不同的，要根据leader发布的测试计划走，提交bug一般要形成图文并茂，再现bug出现场景，有理有据，形成文档，提交！然后就是他说：那好，今天就问到这里，有其他联系了会有别的人给你其他的面试。
最后我问一点：我想问一下，我记得你们招收的学历是本科，可是我是大专，所以我想感谢你们给我面试的机会！他笑到，这个没什么的，学历我们并不看中，老总是想把你外聘的，好的，就这样，一起学习！呵呵当时我就傻了~~~外聘，，，就是打工扫地也好啊，不管是不是正式，有个工作就行！！！本人第一次面试就这样。
如何养成一套编写游戏测试用例的逻辑
整个逻辑式便为假的情况，就要求（）里的内容是真.}这个例子里边。
其实，要想让一个因式的MCDC达到100%，基本也就达到要求了吧。
至于你说的基路径测试，如：if(a讲起来不太好讲。
会不会测试工具？比如testbed之类的，简单的测试只要求让每一个分支的真、假两种情况都得到测试就行了，例如，已经有“a;b”为真；b c==d) {.、是假都得到测试，我的理解是；c==d、MCDC等达到100%;b且c==d（用例1）；能够分别决定上述逻辑式的真假，接着上面的两个测试用例，可以看到“c==d”这个因式的修正判定已经到100%了，因为它的真假在上面2个测试用例中已经直接决定了上述逻辑式的真假，在用例1中，它为真，整个逻辑式为真；在用例2中，它为假，整个逻辑式为假。
所以现在就需要让a..？我将我的理解说一下；b，让此因式唯一决定最终结果就行了..：alt;b且c==d（用例3）。
至此，只要让语句覆盖率以及分支覆盖率，但是如果要求比较高的话；b的修正判定达到100%。
用例1中，MCDC均达到100%，我不是太明确是什么意思，要想让分支覆盖达到100%，简单点儿说，这是一个测试用例；然后令a;b且c!=d（用例2）。
这样分支覆盖已经达到100%，比方说，在c==d的情况下，就要求修正条件判定覆盖（MCDC）达到100%，只要让逻辑式中的其他因式不影响最终结果，就是让每一个条件判定中的因式唯一决定逻辑值的真假，这里就是说让a，可以让a。
记住这一点就行了，多练练。
逻辑覆盖如果MCDC达到100%，这样，应该会更加直观。
加油：从逻辑覆盖来讲，你没完成一个测试用例，它都可以给你每种覆盖率的值，也可以给你展示测试用例已经走过的路径，整个逻辑式为真的情况，所以就要找出一个“a;b”为假，所谓的基路径应该不成问题了吧。
如果会用工具的话、…
传统软件测试和游戏测试在设计测试用例上的区别
重要的区别，传统软件重点是在功能方面游戏的侧重点在体验方面ü关卡设计——评价故事设定是否完整，游戏中任务、迷题安排的合理性，场景设计问题，关卡设计等 ü难度设计——评价游戏难度设计是否合理 ü游戏模式——评价游戏模式是否多样游戏操作性测试ü游戏流畅性——评价游戏运行是否流畅，按键延迟的有无 ，操作有无惯性等 ü按键位置——评价游戏主要功能键位置是否合理顺手或键位可自行设定 当然，他们都属于软件测试的范围内，可以在腾讯课堂中找海枫科技的，那里会有这方面的说明。
…
软件测试编写用例指的是什么？
编写用例 软件测试员是指根据测试计划和测试方案进行软件测试；能够针对软件需求开发测试模型，制定测试方案，安排测试计划，并对测试项目进行管理的专业人员。
每一阶段的测试都是为了减少软件的bug和提升软件的功能需求，所以测试人员必须具备良好的编程功底。
如何设计一个完整的测试用例
测试用例的设计一般从分析需求设计说明书开始，了解开发人员设计这个项目的思路、设计的要求、实现的功能等（最好有use case，这样看起来更清晰）。
软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况。
事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的。
因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现。
编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。
每个公司都有适合自己公司用例编写的模板，各有各的特点。
测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。
格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。
下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。
我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。
第一层，表单测试为最底层（最基础的）。
这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。
一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试。
这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容。
这样，我们考虑就是这个输入框的长度限制是多少？能否输入特殊字符？能否输入全角字符？当然，登陆窗口还有其他按钮，例如登陆按钮、退出按钮、界面设计等，这一层的测试用例只对他们最简单的功能的测试。
我觉得这一层的测试用例对新开发项目很重要，也必须执行，因为这些是最基本的功能保证，当项目进入维护阶段后，如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低，时间不充足的情况就不用去执行。
第二层，逻辑判断层。
根据需求的设计，各功能之间的简单逻辑联系。
以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败。
根据这一点，我们就可以从这个要求设计这一层测试用例。
例如，账号和密码不一致时；账号为空时；密码为空时；账号密码对应时等等情况。
输入这些情况时，程序是作怎么样的逻辑控制的？控制是否正确？是否有相应的提示信息？我觉得，这一层的用例时最常规的一层，平时使用这个软件用经常碰到的一些情况，在常规测试或修改这部分的功能之后，这一部分的测试用例也必须执行。
第三层，业务流程层。
这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求。
以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统。
根据不同的业务需求，就有不同的业务流程。
这样这层的测试用例，我们就只要考虑业务需求，仍然以登录窗口为例，我们就只要考虑删除的用户能否登录？停用的用户能否登录？超级用户是如何登录的？普通用户是何种方式登录的？简单的说，这层的用例只描述业务流程，不关心具体这个业务是怎么实现的，执行这部分用例时，不要考虑哪个输入框控制了多少长度，能否输入空格等其他功能，因为这部分的测试需要基于上面两层的测试用例都已经测试通过了，所以在项目维护阶段或者说时间很紧迫的阶段，我们只需要执行这部分的用例，保证业务能够通畅的完成。
其实个人觉得在执行这部分用例时，对包含了对基本功能的测试，一些明显的问题应该能被发现，虽然严格来说测试覆盖率很低，但是基本能达到要求。
这三层的组合起来才是一个完整的测试用例。
这是我个人对测试用例设计的一个思路和方法。
真正设计这个测试用例的时候，可能会使用到黑盒测试用例的方法，例如等价类划分、边界值分析、错误猜测法（主要是个人经验）、正交分解等方法针对具体情况设计测试用例。
分层测试用例的思路主要来自对自动测试实现的考虑。
因为我觉得，如果需要实现自动化测试就必须对测试用例进行细分，划分得越细就越有利于自动化的实现。
以上三层的划分也并不是很全面，需要在实践中不断完善，例如可以增加对数据库的部分功能的数据校验的分析。
总之，测试用例写的细致、全面、步骤清晰，那么无论是用手工测试的方法还是用自动化测试的方法实现，只要能完整的跑完整个测试用例，就达到了测试的目标了。
编写测试用例
测试用例的八大要素：1、用例编号： 测试用例编号是由字母和数字组合而成的，用例的编号应该具有唯一性，易识别性，比如可以采用统一的约定，产品编号_ST_系统测试项名_系统测试子项名_编号。
这样看到编号就可以知道是做的什么测试，测试的对象是什么，也方便维护。
2、测试项目： 你现在这个测试用例所测的项目名，可以是测试用例所属的大类，被测需求，被测的模块，或者是被测的单元。
例如：计算器加法功能3、测试标题： 测试标题是对测试用例的简单描述。
用概括的语言描述该测试用例的测试点。
每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。
例如：手机在没有SIM卡的情况下，拨打119.4、重要级别： 重要级别分为高中低三等： 高：保证系统基本功能、重要特性、实际使用频率比较高的用例； 中：重要程度介于高和低之间的测试用例； 低：实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例。
注：一般情况下，重要级别为高的测试用例，一个测试子项里有且仅有一个，大多数都是重要级别为中的测试用例。
因为一般我们会进行一个系统测试预测试项，如果重要级别为高的太多，则就失去了预测试的实际意义。
5、预置条件： 就是执行当前测试用例的前提描述，如果不满足这些条件，则无法进行测试6、测试输入： 测试用例执行时，需要输入的外部信息。
例如：某一个文件，数据记录等7、操作步骤： 执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行8、预期输出： 当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。
…
游戏测试怎样测试一把20级武器
看来不是玩家向的问题呢。
工作的话，其实根据不同游戏结构具体会有不一样，但是通常来说主线任务，涉及到的东西，一个是文字描述上是否有纰漏错误。
然后功能上，开启任务的条件，是否正确。
完成任务条件，是否正确验证。
任务完成后，触发的功能，奖励的物品，是否无异常。
武器，基本上是看伤害，描述，品质颜色，图标等显示是否正确。
武器相应的功能，强化，打造，淬炼什么的，应该有独立的测试才对。