网易游戏游戏开发工程师与游戏测试面试题.doc

网易游戏游戏开发工程师1.一次考试,有25人参与,有ABC三题,每人至少会做一题,在不会做A的人中,会做B的人是会做C的人的两倍,在会做A的人中,只会做A的人比其他的少一人,不会做A的人和只会做A的人数相等,问只会做B的有几人?解:设绿色加白色为X紫色加白色为X/2 白色为Z 红色为Y 蓝色为Y+1所以由条件可得X+0.5X-Z+2Y+1=25 X+0.5X-Z=Y故3X=16+2Z 当且仅当Z=4,X=8时为整数解,故题目答案为X-Z=4人或以下三组解: Z=1,X=6;Z=7,X=10; Z=10,X=12;2.李氏夫妇请4对夫妇来家吃饭,已知每人不和自己和配偶握手,每人至少握手一次,不反复和人握手,李先生最后一问每人握手次数都不同样,问李太太握手几次.解:既然每人次数不同,就说明有1到8八种次数,每人一种.初始:87654321(00)括号内为李氏夫妇的次数从8看起,那个人肯定和此外的8人握手,否则没有8次,并且他的配偶肯定是7次,否则不也许有8次握手的人.(X表达已计算的握手)第一次:X7543210(11)第二次:XX432100(22)第三次:XXX31000(33)第四次:XXXX0000(44)所以李先生和李太太都握手了4次.3.几何题如图,两圆交于AB两点,由A作直线交于两圆于CD,问CD何时最长?并证明.提醒:相同弧段的圆周角是圆心角一半感谢影子情人提供解法答案是让AB和CD垂直,这样BD和CB是两个直角三角形的斜边提醒可知道是直径得整.4.假设一副扑克牌只有A,2,3,4,5,6六张,且每张有任意多张,没有不同花型(即没有桃心梅方),用PQRST表达不同的牌面,计算下列概率,并排顺序PQRST,PPQRS,PPQQR,PPPQR,PPPPR,PPPPP,PPPQQ大约解法:概率里面的什么分子分母实在懒得打,我还用几次方和阶乘表达了相对关系,这样比较容易看,不要用大学的概率记录公式,直接用高中生想法,很容易求解.注意,每种牌的数量不限制,所以去除某种特定牌的概率是1/6,但是取出第一张任意牌的概率是6/6,同理第二张不同牌的概率是5/6,所以第一个概率是6!/65然后乘以6,由于有六种取法,C65嘛等于C61,也就是6!/64后面的也差不多,顺便说一下,5张同样的好难啊,居然只有6/65,也就是1/1296,呵呵,要爱惜炸弹啊.然后乘以C61,也就是6/645已知二叉树的先序和中序遍历字符串,编程实现输出后序遍历字符串,假如没有成功输出Failed,最后分析时间和空间复杂度解:这是标准的ACM 2255题,NOIp和NOI中也有同样的题目,很经典的.我也提供一下网上的标准答案,懒得打了.时间复杂度是2的n次方吧我感觉是的,没有空间消耗,除了栈的开辟消耗空间.#include #include using namespace std;void PrintPostOrder(const string & preorder, const string & inorder, int start1, int start2, int size)if(size = 1)cout preorderstart1;return;if(size = 0)return;int i = inorder.find(preorderstart1);PrintPostOrder(preorder, inorder, start1+1, start2, i-start2);PrintPostOrder(preorder, inorder, start1+1+i-start2, start2+1+i-start2, size-i+start2-1);cout preorder inorder)PrintPostOrder(preorder, inorder, 0, 0, preorder.size();cout endl;游戏测试一位游戏业HR给出了一份招聘游戏测试的题，觉得挺有趣，有必要拿来分享一下。顺便让各位看观了解一下游戏测试是个什么活。测试面试题程序部门按照如下需求文档，设计了一个游戏程序：用面向对象的思想，设计一个简朴的游戏框架。程序需求如下：1. 用命令行模式实现，不需要界面2. 游戏世界中，存在5个房间：A、B、C、D、E。有些房间之间存在连通性（从一个房间所能到达的另一个房间），而有些房间之间则不存在。具体如下： 双向：AB、AC、CD、单向：D-A、D-E、E-B3. 玩家可以控制角色从一个房间走到另一个房间（敲入命令goto A，则进入A房间），每次只能走一步途径。起始房间为A每次进入房间，需要列出下一步可进入的房间。 例如：在房间C敲入：goto D，会列出： A E C4. 每个房间里存在不同的NPC，NPC具有名称，玩家进入一个房间后，需要列出该房间的所有NPC名称。具体如下：A房间：无B房间：杂货商、渔民C房间：武器商D房间：防具商E房间：大海龟、海猫猫5. NPC具有简朴的对话功能，敲入talk NPC名称，则可以看到NPC所说的话。对话内容可自行设计。扩展需求1玩家拥有金钱和背包，初始金钱为100，背包中有5个格子，每个格子中可以放下一个物品。初始物品为“回城符”、“小刀”扩展需求2其中的一些NPC具有交易功能，玩家可以将自己身上的物品交易给NPC以获得金钱、或者通过身上的金钱购买物品。具体如下：杂货商：出售 蜡烛（20）、小刀（30）、回城符（10） 渔民： 出售 鱼肉（10） 武器商：出售 乌木剑（50） 防具商：出售 木盾（40） 括号里的表达出售价格，同时也是收购价格。打命令“shop NPC名称”可以列出该NPC所出售的物品和价格打命令“buy NPC名称 物品名称”可购买物品打命令“sell NPC名称 物品名称”可出售物品打命令item可以列出自己背包中的物品。背包满的情况下，不允许再买入物品，并提醒“背包满”。阅读文档时间为1小时，阅读文档完毕后请在2小时内完毕如下题目：1， 请为按照文档画出五个房间和他们之间的途径和方向；2， 按照文档说明和，填写下表Start roomInputOutput示例AGoto AB,CAGoto BAGoto CAGoto DAGoto EBGotoABGoto BBGoto CBGoto DBGoto ECGoto ACGoto BCGoto CCGoto DCGoto EDGoto ADGoto BDGoto CDGoto DDGoto EEGoto AEGoto BEGoto CEGoto DEGoto E 3， 针对扩展需求1和2，测试背包功能，描述你的测试思绪和方法。一道AS3面试题的解答题目：对一批编号为1-100所有开关朝上（开）的灯进行以下操作：开关编号凡是1的倍数反方向拨一次开关；若该编号也是2的倍数反方向又拨一次开关；若该编号又是3的倍数反方向又拨一次开关以此类推一直计算到100为止。目的：请trace出通过反复开关操作后所有关闭的灯的开关编号。这是我写给大家看的易懂版本：varn:int,m:int; varrange:int=100; for(vari:int=1;ii/n) break; if(i%n=0) if(i/n=n) trace(结果,i); break; n+; 下面是写着玩的缩写版本，但是正常写项目代码，我不会这样干的，在这儿只是娱乐一下而已。下面这段代码想玩就看看，不想玩的看上面就行了，判断原理是同样，没区别！varn:int=1,range:int=1000; for(vari:int=1;i0)n=ni/n?0:!(i%n)?i/n=n?-1:n+1:n+1; if(n=-1)trace(结果,i); 我将range都改成100000后，第一种方法耗时7233毫秒，第二种缩减的写法耗时1840毫秒。对于易读易懂，你会选择那种方法呢？对于暗泪同学的回复，下面增长一点内容：其实上面写的是正常算法，假如2亿次，通过度析题目，可以得出只要该数能被开平方时，就是关闭状态，因此这道题目假如是写在项目里面，可以这样写：varrange:int=; varnum:int=Math.pow(range,0.5); for(vari:int=1;i=num;i+) trace(结果,i*i) 我测试过10亿次的效率，仅需要6毫秒何其快啊！游戏软件功能测试测试用例的编写方法浅谈 一、 游戏软件与通用软件的区别 a) 通用软件的需求明确，游戏软件需求抱负化 i. 通用软件中用户每步操作的预期结果都是明确且有规范可参考的，而网游中并不是所有的需求都有一个明确的预期结果，拿技能平衡性来说，我们所谓的平衡也只是相对的平衡，而非绝对的平衡。没有什么明确的参考参数。只能根据以往游戏的经验获得一个感知的结果。 ii. 网络游戏中的某些功能是有预期结果可参考的。例如组队、交易，而此外一些带有策划创意的功能，却是根据策划个人的理解，来拟定其预期结果的。人的思考力都是有限的，所以不能保证在他的创意中会考虑到各种各样复杂的细节。也不可以保证这个创意就可以完全被用户所接受。 当你作为游戏测试人员时，很多时候你需要做的不仅仅是验证功能。也需要帮助开发者和用户找到一个互相容忍的平衡点。游戏软件的测试员带有对策划需求的怀疑，力求通过自己的努力在玩家和开发者之间将也许产生的矛盾减小。 b) 通用软件开发过程中需求变更少，游戏软件开发过程中需求便更快 i. 通用软件的使用人群和软件的功能针对性，决定软件从开始制作就很少再有新的需求变更。而游戏软件，为了满足玩家对游戏的认可度，策划需要不断的揣摩玩家的喜好，进行游戏功能的改善。加之网游制作自身就是一个庞大复杂的工程，开发者不也许做到在开发的前期，就对游戏架构及扩展性做出最佳的评估。所以导致为了满足用户的需求而不断的进行一些基础架构的修改，基础架构的修改必然导致某些功能的颠覆。所以就出现了，游戏开发过程中的一个恶性循环，当基础架构修改到满意了，玩家的需求又有了新的变化，随之而来的又要进行新的调整，再进行新的修改。最终导致了游戏软件的开发周期不断加长。任何一个有经验的团队，对于每一个影响基础的改动都应当做出对的的评估。 二、 网游有哪些测试内容 a) 性能 i. 客户端性能 ii. 服务器端性能 1. 服务器 2. 数据库 iii. 网络 b) 功能 i. 从运营完 game.exe 打开游戏界面后可进行的各种操作、玩法 ii. 界面 iii. 音乐 c) 自动化 i. 测试工作组织实行中需要的工具、软件、平台的开发 ii. 自动化的回归测试作用：游戏中基础的、变动不大的、犯错率高的、可进行 checklist 反复测试的功能、性能等自动化是一个好方法 iii. 任何时候自动化都取代不了人脑，它只是将一些反复性的劳动从我们测试人员身上去掉，让我们有更多的时间做更故意义的事情，假如你觉得你做一件事情是反复的，且有规律可行的，不防考虑自动化 三、 游戏中针对功能性测试测试用例编写浅谈 先了解下游戏中有哪些功能： 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) 场景测试法协助功能点细分 游戏测试中，场景测试方法是经常用到的一种方法，什么是场景测试法，及按照功能设计规定，在脑中模拟出来的一个功能使用时的操作流程。按照每步操作的针对点，将针对点划分为所用例设计时的小功能点。划分时需每步针对点的各种检查点分到该功能点内设计为该功能点的检查点。再根据检查点进行测试输入（及操作过程）的编写。用例编写过程中的思考方式就如上了。讲起来比较抽象，希望对大家有所帮助。 f) 用例的设计原则一直有人问到底要具体到什么限度 i. 我们不期待用例编写到任何人都可以执行，也没有这个必要 ii. 我们针对的是网游的测试人员，至少是玩过网游的人，这些人对于游戏中的基础设定都有结识，我们不也许对着一个不知道任务界面是什么的人大讲怎么测试任务。所以我们用例编写的原则就是针对我们测试组内的测试人员。 iii. 但是，请不要简略到别的测试人员看不懂，特别是当你是专职的用例编写人员时，编写时请多考虑下语言描述的方式。请让你的同伴可以看懂，你所要表达的意思。 iv. 用例是没有固定格式的，它的重要原则就是，测试中所需所有信息，我通过你的文档都可以获取到。所以不要再执着的像别人要模板。模板你自己都可以设计，发挥你的创意。 四、 编写过程注意事项 与设计人员的沟通 拿到一份文档时请不要急于编写，在这之前很多事情需要做，请先将文档阅读至少三遍，然后思考下，你自己大脑中是否有你所看文档功能点的一个流程图，当确认已经准备好了。开始设计用例，用例设计的过程就是与设计人员不断沟通，进一步了解功能的过程。你会发现，或许跟你之前流程图中想像的并不完全同样。这个时候不必惊讶，去找他们核对就好。不怕发现问题，就怕没有发现问题，最终做了很多无用功。编写过程中发现的没有预期结果的内容，请及时与策划人员、程序人员核对，必须三方核对。核对完毕提醒策划人员及时更新设计案，提醒程序人员设计案新修改内容。这样你会发现，设计测试用例过程的自身就是发现策划方案不完善的过程。 请运用你的思维，采用边界法、等价类划分法、错误推断法、以及以往的经验，将每一个测试点的所有需检查点进行充足的设计。发挥你的积极性，和测试组内其它人探讨你认为也许存在风险的测试点，以便得到更多有价值的信息。 Over