1、表示不同的牌面 , 计算下列概率 , 并排顺序PQRST,PPQRS,PPQQR,PPPQR,PPPPR,PPPPP,PPPQQ大概解法 : 概率里面的什么分子分母实在懒得打, 我还用几次方和阶乘表示了相对关系,这样比较容易看 , 不要用大学的概率统计公式, 直接用高中生想法 , 很容易求解 .注意 , 每种牌的数量不限制, 所以去除某种特定牌的概率是1/6, 但是取出第一张任意牌的概率是6/6, 同理第二张不同牌的概率是 5/6, 所以第一个概率是6!/65然后乘以 6, 因为有六种取法 ,C65 嘛等于 C61, 也就是 6!/64后面的也差不多 , 顺便说一下 ,5 张一样的好难啊 ,
2、竟然只有 6/65, 也就是 1/1296,呵呵 , 要珍惜炸弹啊 . 然后乘以 C61, 也就是 6/645 已知二叉树的先序和中序遍历字符串 , 编程实现输出后序遍历字符串 , 如果没有成功输出 Failed, 最后分析时间和空间复杂度 这是标准的 ACM 2255懒得打了 . 时间复杂度是 2题,NOIp 和 NOI 中也有一样的题目 , 很经典的 . 我也提供一下网上的标准答案的 n 次方吧 我感觉是的 , 没有空间消耗 , 除了栈的开辟消耗空间 .,#include #include std;void1,intPrintPostOrder（start2, intconst size）
3、string& preorder,const inorder,startif （size =1）cout preorder inorder）PrintPostOrder（preorder, inorder, endl;0 , 0, preorder.size（）;游戏测试一位游戏业 HR给出了一份招聘游戏测试的题，觉得挺有趣， 有必要拿来分享一下。 顺便让各位看观了解一下游戏测试是个什么活。测试面试题程序部门按照如下需求文档，设计了一个游戏程序：用面向对象的思想，设计一个简单的游戏框架。程序需求如下：1. 用命令行模式实现，不需要界面2. 游戏世界中，存在 5 个房间： A、B、C、 D、 E
4、。有些房间之间存在连通性（从一个房间所能到达的另一个房间），而有些房间之间则不存在。具体如下：双向： AB、AC、CA、D-E、E-B3. 玩家可以控制角色从一个房间走到另一个房间（敲入命令 goto A ，则进入 A 房间），每次只能走一步路径。起始房间为 A每次进入房间，需要列出下一步可进入的房间。例如：在房间 C 敲入：goto D ，会列出：AEC4. 每个房间里存在不同的 NPC，NPC 具有名称，玩家进入一个房间后，需要列出该房间的所有 NPC名称。A 房间：无B 房间：杂货商、渔民C 房间：武器商D 房间：防具商E 房间：大海龟、海猫猫5. NPC具有简单的对话功能，敲入 tal
5、k NPC 名称，则可以看到 NPC所说的话。对话内容可自行设计。扩展需求 1玩家拥有金钱和背包，初始金钱为 100 ，背包中有 5 个格子，每个格子中可以放下一个物品。初始物品为“回城符”、“小刀”扩展需求 2其中的一些 NPC 具有交易功能， 玩家可以将自己身上的物品交易给购买物品。NPC以获得金钱、 或者通过身上的金钱杂货商：出售 蜡烛（ 20）、小刀（ 30）、回城符（ 10）渔民： 出售 鱼肉（ 10）武器商：出售 乌木剑（ 50）防具商：出售 木盾（40）括号里的表示出售价格，同时也是收购价格。打命令“ shop NPC名称”可以列出该 NPC所出售的物品和价格打命令“ buy N
6、PC名称 物品名称”可购买物品打命令“ sell NPC名称 物品名称”可出售物品打命令 item 可以列出自己背包中的物品。背包满的情况下，不允许再买入物品，并提示“背包满”。阅读文档时间为 1 小时，阅读文档完毕后请在 2 小时内完成如下题目：1， 请为按照文档画出五个房间和他们之间的路径和方向；2，按照文档说明和，填写下表Start roomInputOutput示例 AGoto AB,CGoto BGoto CGoto DGoto EGotoAD3， 针对扩展需求 1 和 2，测试背包功能，描述你的测试思路和方法。一道 AS3 面试题的解答题目：对一批编号为 1-100 全部开关朝上（
7、开）的灯进行以下操作：开关编号凡是 1 的倍数反方向拨一次开关；若该编号也是 2 的倍数反方向又拨一次开关；若该编号又是的倍数反方向又拨一次开关 以此类推一直计算到 100 为止。3目的：请 trace 出经过反复开关操作后所有关闭的灯的开关编号。这是我写给大家看的易懂版本：var n:int, m:int;var range:int = 100;for（var i:int = 1; i i / n）break;if（i % n = 0）if（i / n = n）trace（ 结果 ,i）;n +;下面是写着玩的缩写版本，不过正常写项目代码，我不会这样干的，在这儿只是娱乐一下而已。下面这段代码
8、想玩就看看，不想玩的看上面就行了，判断原理是一样，没区别！int = 1, range:int = 1000; i += n = 1）while（n 0） n = n i / n ? 0 : !（i % n） ? i / n = n ? -1 : n + 1 : n + 1;if（n = -1） trace（我将 range 都改成 100000 后，第一种方法耗时 7233 毫秒，第二种缩减的写法耗时 1840 毫秒。对于易读易懂，你会选择那种方法呢？对于暗泪同学的回复，下面增加一点内容：其实上面写的是正常算法，如果 2 亿次，通过分析题目，可以得出只要该数能被开平方时，就是关闭状态，因此这
9、道题目如果是写在项目里面，可以这样写：int = 1000000000;var num:int = Math.pow（range,0.5）;= num;,i * i）我测试过 10 亿次的效率，仅需要 6 毫秒 何其快啊！游戏软件功能测试 测试用例的编写方法浅谈一、 游戏软件与通用软件的区别a） 通用软件的需求明确，游戏软件需求理想化i. 通用软件中用户每步操作的预期结果都是明确且有规范可参考的， 而网游中并不是所有的需求都有一个明确的预期结果，拿技能平衡性来说，我们所谓的平衡也只是相对的平衡，而非绝对的平衡。没有什么明确的参考参数。只能根据以往游戏的经验获得一个感知的结果。ii. 网络游戏中
10、的某些功能是有预期结果可参考的。例如组队、交易，而另外一些带有策划创意的功能，却是根据策划个人的理解，来确定其预期结果的。人的思考力都是有限的，所以不能保证在他的创意中会考虑到各种各样复杂的细节。也不能够保证这个创意就可以完全被用户所接受。当你作为游戏测试人员时，很多时候你需要做的不仅仅是验证功能。也需要帮助开发者和用户找到一个互相容忍的平衡点。游戏软件的测试员带有对策划需求的怀疑，力求通过自己的努力在玩家和开发者之间将可能产生的矛盾减小。b） 通用软件开发过程中需求变更少，游戏软件开发过程中需求便更快i. 通用软件的使用人群和软件的功能针对性， 决定软件从开始制作就很少再有新的需求变更。 而
11、游戏软件，为了满足玩家对游戏的认可度，策划需要不断的揣摩玩家的喜好，进行游戏功能的改进。加之网游制作本身就是一个庞大复杂的工程，开发者不可能做到在开发的前期，就对游戏架构及扩展性做出最好的评估。所以导致为了满足用户的需求而不断的进行一些基础架构的修改，基础架构的修改必然导致某些功能的颠覆。所以就出现了，游戏开发过程中的一个恶性循环，当基础架构修改到满意了，玩家的需求又有了新的变化，随之而来的又要进行新的调整，再进行新的修改。最终导致了游戏软件的开发周期不断加长。任何一个有经验的团队，对于每一个影响基础的改动都应该做出正确的评估。二、 网游有哪些测试内容a） 性能i. 客户端性能ii. 服务器端
12、性能1. 服务器2. 数据库iii. 网络b） 功能i. 从运行完 game.exe 打开游戏界面后可进行的各种操作、玩法ii. 界面iii. 音乐c） 自动化i. 测试工作组织实施中需要的工具、软件、平台的开发ii. 自动化的回归测试作用：游戏中基础的、变动不大的、出错率高的、可进行 checklist 重复测试的功能、性能等自动化是一个好方法iii. 任何时候自动化都取代不了人脑，它只是将一些重复性的劳动从我们测试人员身上去掉，让我们有更多的时间做更有意义的事情， 如果你觉得你做一件事情是重复的，且有规律可行的， 不防考虑自动化三、 游戏中针对功能性测试测试用例编写浅谈先了解下游戏中有哪些
13、功能：a） 游戏发开中的功能有哪些i. 不同的游戏对于功能的划分不同，但是目前主流一些功能划分中有以下内容：1. 基础操作2. Npc3. 地图4. 装备5. 剧情6. 技能7. 人际8. PVP9.这样我们很简单的将整个游戏的功能进行了划分，划分完毕，下来的工作就是针对某个功能的测试了。很多人都问过一个问题，游戏测试中测试用例到底有什么用。下面继续 b） 游戏测试的测试用例有什么作用i. 测试执行过程中，按照用例指示的操作检查操作结果是否正确，记录测试过程中发现的 bugii. 按照用例的执行结果确认功能的通过与否，也有的按照用例的覆盖率来确定单服测试的通过与否iii. 便于回归测试的执行这
14、样讲应该比较明白了吧。c） 测试用例应该包括什么 测试执行过程中所需的所有信息，举例说明下。i. 表头：功能名称、案例编写人员、编写时间、测试人员、测试时间ii. 正文：功能点、测试点、测试输入、预期结果、实际结果iii. 用例执行结果统计d） 功能点模块化理念都知道一个复杂庞大的系统，程序在实现时会将其分成若干模块按照模块功能优先级进行实现。我们测试过程中也采用这种方法，将复杂的功能点按照实现功能进行分类，分类后的测试点，再进行分类，直至细分成为一条条用例。就像庖丁解牛那样。按照等价类划分法，将同一判断条件的测试点组成一个集，在这个条件基础上再次判断的条件，我们假设它已经成立。这样在用例设计
15、过程中就需要测试人员清楚的知道，哪些条件是一类需优先确认的，哪些是以这类条件为基础的。我们最终形成的测试用例一定确保的是一条用例只检查一个测试点。这样设计也有另外一个好处，如果一条用例不能走通，其它的还可以继续检测，经常会遇到测试过程中由于一个 bug ，导致测试工作停滞。现在这样子我们就可以采取脚本调试，或者其它方法跳过有 bug 的测试内容，继续进行其它测试点的测试了。e） 场景测试法协助功能点细分游戏测试中，场景测试方法是经常用到的一种方法，什么是场景测试法，及按照功能设计要求，在脑中模拟出来的一个功能使用时的操作流程。 按照每步操作的针对点， 将针对点划分为所用例设计时的小功能点。划分
16、时需每步针对点的各种检查点分到该功能点内设计为该功能点的检查点。再根据检查点进行测试输入（及操作过程）的编写。用例编写过程中的思考方式就如上了。讲起来比较抽象，希望对大家有所帮助。f） 用例的设计原则 一直有人问到底要详细到什么程度i. 我们不期待用例编写到任何人都可以执行，也没有这个必要ii. 我们针对的是网游的测试人员，至少是玩过网游的人，这些人对于游戏中的基础设定都有认识，我们不可能对着一个不知道任务界面是什么的人大讲怎么测试任务。所以我们用例编写的原则就是针对我们测试组内的测试人员。iii. 但是，请不要简略到别的测试人员看不懂，特别是当你是专职的用例编写人员时，编写时请多考虑下语言描
17、述的方式。请让你的同伴可以看懂，你所要表达的意思。iv. 用例是没有固定格式的， 它的主要原则就是， 测试中所需所有信息， 我通过你的文档都能够获取到。所以不要再执着的像别人要模板。模板你自己都可以设计，发挥你的创意。四、 编写过程注意事项与设计人员的沟通拿到一份文档时请不要急于编写，在这之前很多事情需要做，请先将文档阅读至少三遍，然后思考下，你自己大脑中是否有你所看文档功能点的一个流程图，当确认已经准备好了。开始设计用例，用例设计的过程就是与设计人员不断沟通，深入了解功能的过程。你会发现，或许跟你之前流程图中想像的并不完全一样。这个时候不必惊讶，去找他们核对就好。不怕发现问题，就怕没有发现问题，最终做了很多无用功。编写过程中发现的没有预期结果的内容，请及时与策划人员、程序人员核对，必须三方核对。核对完毕提醒策划人员及时更新设计案，提醒程序人员设计案新修改内容。这样你会发现，设计测试用例过程的本身就是发现策划案不完善的过程。请运用你的思维，采用边界法、等价类划分法、错误推断法、以及以往的经验，将每一个测试点的所有需检查点进行充分的设计。发挥你的主动性，和测试组内其它人探讨你认为可能存在风险的测试点，以便得到更多有价值的信息。 Over
