baidu面试题目

发信人:reniking(没~~),信区:Job

标题:[跟风]发百度软件质量部面经

发信站:北邮人论坛(ThuOct2514:53:022007),站内

这是我的人生第一面，还以为被鄙视了，接到电话后异常兴奋，先把笔试卷子上的题又重新

想了一遍，可惜面试一点都没用上。今天去的时候看好多人去面，新产品的是群面，大家都

西装革履的。软件质量部是单面。面试我的是一个JJ，年龄相仿的，虽然去之前比较紧张，

见到她就放松了。下面切入正题，

1，自我介绍，觉得这块不是特别重要，随便说说自己强项，性格特点，爱好啥的就行。我

说的时候她就在看我的简历，也没有记录答案。

2，项目介绍。她会在项目中找一些细节来提问，但也是和软件测试相关的，比如说到C/S结

构，她就问Server端测试性能时需要注重哪些方面。

3，问是否了解Socket编程。socket编程中，如果请求非常多，服务器承受能力有限，怎么

解决。

4，标准C中，malloc和*alloc（这个忘了）的区别，存储位置。可以用来存储变量的位置有

哪些，如果你知道变量存储在哪，你如何测试？（这道题我彻底不会，这里叙述的也不见得

准确，大家领会精神~~~）

5，如何测试电梯程序。说测试用例。

  http://www.lwyes.com/papers/p/paper_501.html

6，一个单链表，长度未知，如何快速的找出位于中间的那个元素。

link* mid(link* head)
{
  link* p1,*p2;

  p1=p2=head;

  if(head==null||head->next==null)
  {
      return head;
  }
  do
  {
      p1=p1->next;
      p2=p2->next->next;
  } while(p2&&p2->next)

      return p1;
}

7，两个人，在一个圆桌子上轮流摆硬币，每次每人摆一个，硬币不能重叠。直到桌子上再摆

不下更多的硬币了，那么最后摆的那个人获胜。问取胜方案。（注意，可以随便在桌子上的

任何位置摆，没有方格什么的限制）。

 

先放，并且放在圆桌中心。此后不管另外一个人放哪里，都放在他对立的位置。

 

8，有什么问题要问她的。

面试的JJ是照着笔记本上的题目问的，然后会把我的答案记下来。就是说面试你的题是早就

已经定好了的。看了昨天的面经，觉得重复的可能性不大，应该是每人一套新题。

教训就是忘记把手表放在旁边了，最后一道题的时候，想了很久，也没想出思路，面试JJ催

了两次，心就慌了。其实，根据经验，面试大概40分钟以内就还算可以，出来之后发现我才

面了不到半个小时。其实可以再申请3、5分钟想的。回来的路上想出了方法，可是已经来不

及了。

再就是如果没太理解题目意思，要敢于去问，从她的回答中也许可以得到一些提的再就是如果没太理解题目意思，要敢于去问，从她的回答中也许可以得到一些提示。如果实

在没思路，就直接问“能不能提示一下”，我最后一道题就是开始理解错了，浪费了时间。

就说这些吧，希望咱byr都找到好工作哈！

 

 

终于熬到了百度的offer，Date: Thu, 11 Oct 2007 15:47:56 +0800.

9月21号百度是第一个来华科开宣讲、笔试的公司，下午5点不到我们实验室几个人就跑到小吃城随便吃了点，然后立马赶到大活排起了长队，不一会儿队伍越来越长，好在自己来得早，按顺序检查了证件之后就进去了，庆幸还有位子（后面的很多人进来都只能站着了，嗯，参加宣讲会尽量早点！）。百度的宣讲很精彩，完全被吸引了，给人的感觉百度是一家充满活力、人性化管理以及快速发展的公司，有无限的可能和发展空间。很是心动呀，宣讲会完后开始笔试，笔试时间一个半小时，选择题，再就是3道程序设计题，最后是两道开放性的系统设计题（二选一），选择题感觉做的还行，后面的程序设计题做的很烂，不但要求实现还得要复杂度尽量低。考完回寝室大家稍微讨论了一下，感觉百度的笔试太有难度了，唉，16W就这么擦肩而过了！

一面：

22号上午11点左右接到百度的面试通知下午3点宏毅大酒店，中午跟实验室其他几个收到通知的同学一起拼的士过去，他们几个面试时间都是2点的，于是我一个人就在走廊的沙发上坐着等，有点紧张，终于快到3点了，我进到房间，一个“光头”的年轻人坐在房间里忙着理简历，我寒暄了两句，他就叫我进去坐着等一下，还以为是百度的工作人员（打杂的，汗），坐在那里没事跟他闲聊了几句，觉得人很nice，大概快到3点了，突然“光头”走到我面前，那我们开始吧！汗竟然他就是我的面试官，他先要求我做一个自我介绍，没想到刚张口说两句就被他打断了，你是不是第一次参加面试，自我介绍直接从大学开始就行了，学校，专业，课余活动等。当时憨憨的傻笑道“不好意思啊，第一次面试没经验”，“光头”很和蔼，安慰道没什么，那你重新开始吧，balala一堆之后，他拿出我的简历和笔试试卷，问昨天笔试感觉怎么样？心里稍微想了一下“涉及的知识很多，有的也很细，程序设计题看起来很简单，但是实际动手在纸上写，想完全正确很困难，而且还得要求实现的算法复杂度要低，还是很难的。总的来说需要很扎实的基础知识。。”吹糊了一番，开始进入正题，主要是针对三道题目是否有新的想法或者思路，然后他就不停的追问，本身数据结构、算法学的就不好，而且还没来得及准备，所以问得自己很郁闷，中间还问了一个设计一个数据结构，即要求数组的优点又要有链表的优点。思考了一下被驳斥了，又说了另外一种还是不行，这么几回合下来，也没答对。最后看到时间快到了，问了一道智力题50个红球50个蓝球，有两个篮筐足够大，请你设计一种方案能够使得一个人去篮子摸到红球的概率最大，自己脑子里琢磨着，怎么弄不都是50%啊，怎么弄呢？“光头”不断的提示我，不必说出最后的解决方案，可以谈谈你的思路，或者说你现在的想法。唉。。。被前面的算法题都问晕了，完全没思路了，心里急啊，“光头”还是面带微笑的看着我，自己越想越紧张，磨了两句之后就投降了。最后“光头”问我有什么问题想问他？我很有技巧的把百度吹嘘了一把，表现出自己对百度很有兴趣，充满了向往。再就是简单的了解了一下面试流程之后，临走前“光头”还主动和我握手（好感动啊）！

总结：一面很失败，跟面试官的交流不够，遇到问题，不知道怎么与面试官沟通获取信息，其实面试官一直想跟我交流，向主动提供一些信息，但是自己完全不知道怎么利用，很被动。其实面试官希望的不是得到你最后的结果，而是想通过看你分析问题的过程了解你解决问题的能力，过程比结果更重要。还有就是面试前必须做好充分的准备，百度对数据结构，算法要求很高，因为公司来得比较早，还没来的及复习，再就是这方面的基础也不太好，所以面得很吃力。面试前一定要做足功课，先了解一下公司侧重考察哪些方面的知识，重点复习一下，做到心中有数，心里有了谱，临阵才不会慌！所谓知己知彼，方能百战百胜！

 

      百度川大站笔试题
技术类试卷一
1、编程题
判断字符串 b 的所有字符是否都再字符串 a 中出现过，a,b都是可能包含汉字的字符串。b中重复出现的汉字，那么a中也要至少出现相同的次数。
汉字使用gbk编码（简单的所，用两个字节表示一个汉字，高字节最高位为1的代表汉字，低字节最高位可以不为1）。
int is_include(char *a  ,  char *b)
返回0 表示没有都出现过，返回1表示都出现过。
2、 算法题
   序列 seq=[a,b,…,z,aa,ab,…,az,ba,bb,…,bz,…,za,zb,…,zz,aaa,…]类似于excel的字母序排列，任意给一字符串 s=[a-z]+(由a-z字符串组成的任意长度字符串)，请问s是序列seq的第几个字符串。
3、 系统设计
   需求：需要引入用户对搜索结果相关性的评分，100分制。希望用户的打分能帮助搜索引擎排序，但又避免恶意投票、作弊等。请设计一个比较公平的评分系统。
转载请注明出自应届生求职招聘论坛 http://bbs.yingjiesheng.com/,本贴地址:http://bbs.yingjiesheng.com/thread-27520-1-1.html

 

 

http://c.chinaitlab.com/special/algorithm/Index.html

 

冒烟测试:冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。冒烟测试可以由开发人员执行，也可以由测试人员来执行。即，在版本编译后正式提交测试之前由开发人员执行；或开发发布版本后，测试人员在接受这个版本作为正式版本进一步测试前执行。

 

 

软件测试面试技巧

    常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1. 等价类划分

　　常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

2. 边界值分析法 　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3. 错误推测法

　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.

4. 因果图方法

　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 5. 正交表分析法 　　有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

6. 场景分析方法

　　指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。 　　您认为做好测试用例设计工作的关键是什么？

　　白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

　　黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题 　　详细的描述一个测试活动完整的过程。

1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

4. 测试用例完成后，测试和开发需要进行评审。

5. 测试人员搭建环境

6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

7. 开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

8. 重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。

　　以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。

　　曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，CPU/磁盘/内存等参数是否满足要求。

　　也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，CPU/磁盘/内存等参数是否满足设计要求。

　　您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

　　测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。

　　测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。 　　您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

　　主要是保障在大量用户的情况下，服务能正常使用。

　　在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

1. 在传统的BugZilla中，BUG描述应该包括以下的信息

2. 和BUG产生对应的软件版本

3. 开发的接口人员

4. BUG的优先级

5. BUG的严重程度

6. BUG可能属于的模块，如果不能确认，可以用开发人员来判断

7. BUG标题，需要清晰的描述现象

8. BUG描述，需要尽量给出重新Bug的步骤

9. BUG附件中能给出相关的日志和截图。

　　高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。