目录：导读

• • 前言
  • 1、一台客户端有300个客户与300个客户端有300个客户对服务器施压，有什么区别？
  • 2、你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？
  • 3、在搜索引擎中输入汉字就可以解析到对应的域名，请问如何用LoadRunner进行测试？
  • 4、测试员在软件开发过程中的任务是什么？
  • 5、简述你在以前的工作中做过哪些事情，比较熟悉什么？
  • 6、详细的描述一个测试活动完整的过程？
  • 7、目前主要的测试用例设计方法是什么？
  • 8、测试用例和测试脚本两者的关系是什么？
  • 9、BUG管理工具的跟踪过程（用禅道为例子）
  • 10、总结

前言

软件测试这个岗位，想要找到一份高薪的工作，离不开繁杂的面试程序，这相信是很多准备应聘软件测试岗的朋友难题，很多已经在职多年的软件测试工程师对于这个岗位面试都谈虎色变。

那么我们怎么破局呢？可以先刷题，准备好测试，打好每一仗。

1、一台客户端有300个客户与300个客户端有300个客户对服务器施压，有什么区别？

300个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。

软件测试面试题（功能+接口+自动化+简历）：https://www.bilibili.com/video/BV1Lq4y137aR/

300个用户在一个客户端上，需要更大的带宽。

IP地址的问题，可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制。

所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。

2、你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？

首先，将问题提交到缺陷管理库里面进行备案。

然后，要获取判断的依据和标准：

根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不掺杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。

3、在搜索引擎中输入汉字就可以解析到对应的域名，请问如何用LoadRunner进行测试？

建立测试计划，确定测试标准和测试范围；

设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等；

根据测试用例，开发自动测试脚本和场景：

录制测试脚本：新建一个脚本（Web/HTML协议）；点击录制按钮，在弹出的对话框的URL中输入”about:blank”；在打开的浏览器中进行正常操作流程后，结束录制；调试脚本并保存，可能要注意到字符集的关联。

设置测试场景：针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标；针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃；执行测试，获取测试结果，分析测试结果。

4、测试员在软件开发过程中的任务是什么？

1、尽可能早的找出系统中的Bug；

2、避免软件开发过程中缺陷的出现；

3、衡量软件的品质，保证系统的质量；

4、关注用户的需求，并保证系统符合用户需求。

总的目标是：确保软件的质量。

5、简述你在以前的工作中做过哪些事情，比较熟悉什么？

我过去的主要工作是系统测试和自动化测试。在系统测试中，主要是对BOSS系统的业务逻辑功能，以及软交换系统的Class 5特性进行测试。性能测试中，主要是进行的压力测试，在各个不同数量请求的情况下，获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。

在测试中，我感觉对用户需求的完全准确的理解非常重要。另外，就是对BUG的管理，要以需求为依据，并不是所有BUG均需要修改。

测试工作需要耐心和细致，因为在新版本中，虽然多数原来发现的BUG得到了修复，但原来正确的功能也可能变得不正确。因此要注重迭代测试和回归测试。

6、详细的描述一个测试活动完整的过程？

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

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

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

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

测试人员搭建环境。

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

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

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

如果有客户反馈的问题，需要测试人员协助重现并重新测试。

7、目前主要的测试用例设计方法是什么？

白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖。

黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法。

8、测试用例和测试脚本两者的关系是什么？

为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。

测试脚本是为了进行自动化测试而编写的脚本。

测试脚本的编写必须对应相应的测试用例。

9、BUG管理工具的跟踪过程（用禅道为例子）

测试人员发现了BUG，提交到禅道中，状态为new，BUG的接受者为开发接口人员。

开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配，开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；

如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。

如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。

测试人员在新版本中测试，如果发现问题依然存在，则拒绝验证；如果已经修复，则关闭BUG。

10、总结

每个人的心里，都藏着一个了不起的自己，只要你不颓废，不消极，一直悄悄酝酿着乐观，培养着豁达，坚持着善良，只要在路上，就没有到达不了的远方！

永远不要沉溺在安逸里得过且过，能给你遮风挡雨的，同样能让你不见天日，只有让自己更加强大，才能真正撑起一片天。

你可以一辈子不登山，但你心中一定要有座山，它会使你总往高处爬，它会使你总有个奋斗的方向，它会使你任何一刻抬起头，都能看到自己希望。