软件测试面试宝典【吸薪大法】帮你独步武林
目录
-
- 前言：
- 听懂职场暗语，读懂职场人心！
- 职场面试总结
- 面试题集合
- 吸薪大法助你独步武林
前言：
自古深情留不住，总是套路得人心！
可以说在我们的生活中，处处充满套路，事事都有潜规则。对于一切以利益为中心的职场来说，更是如此，为了避免你被继续套路，下面为你分享职场招聘中话术圈套，不告诉你，你永远都无法摸透！
听懂职场暗语，读懂职场人心！
如今套路横行，涉世未深的你，岂会甘心出身未捷身先死。接下来咱就来重点说招聘过程HR中的各种套路了，各位开始接招了吧。正式开启装B模式：
当然职场没有绝对！就看你自己怎么去对待了!!!
职场面试总结
了解了这些套路和暗语后我们就能够正确的审视这家企业，审视自己。这样你才能准确的判断出你适不适合这家企业，同时作为测试工程师你还需要了解如下问题：
这家企业做什么产品，我是否有兴趣
2.这家企业目前有多少测试，分别是负责做什么的，目前整体的测试的深度大概达到多少
3.自己进入这家企业具体是做什么测试，是功能测试，还是压力测试，还是各种都会接触
企业管理层对于测试人员的职业规划以及将来的发展是怎么考虑的
只有知己知彼才能百战百胜，祝愿看到此文的测试小伙伴们都能纵横职场，逍遥人生！
面试题集合
01、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
答：有黑盒和白盒两种测试种类，黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。
例子：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价划分法，可以一个或多个结果是OK的测试用例，然后确认多个NG的测试用例，然后利用边界值分析法，可以对结果分别是OK和NG的测试用例进行扩展和补充。
02、您认为做好测试用例设计工作的关键是什么？
答：测试用例设计工作的关键是对可行的和不可行的都要考虑。
1，输入 2，详细的操作步骤 3，预期输出 4，实际输出。
03、您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
答：有使用过LoadRunner，该工具能够录制测试人员的操作步骤，然后对这个操作步骤模拟出多个用户来播放出来。
1、Visural User Genertor 创建脚本，选择协议，录制操作，编辑操作。
2、中央控制器（Controller）调度虚拟用户，创建场景，选择脚本，建立虚拟用户，设计shedual，设置ip spoofer。
3、运行脚本。分析shedual。
4、分析测试结果。
04、您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
答：性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能，性能测试常常需要和强度测试结合起来，并常常要求同时进行软件和硬件的检测。
性能测试主要的关注对象是响应时间，吞吐量，占用内存大小（辅助存储区），处理精度等。
05、在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
答：检测时间，系统环境，硬件环境，严重程度，程式版本，确认人，功能模板，问题描述，详细操作步骤，是否会重现。
问题描述和详细操作步骤要尽可能详细。Bug应该尽量用书面语，对于严重程度比较高的缺陷要在相同环境下测试一遍。
在C\S模式下，如果条件满足可以使用替换法来确认是client端的问题还是server端的问题。
06、你对测试最大的兴趣在哪里？为什么？
答：最大的兴趣就是具有挑战性。
因为我并不知道哪里会出现bug，在找到一个bug后会很高兴。并且测试需要很强的耐心和细心。我可以很容易的找到一些细节问题。
07、测试活动中，如果发现需要文档不完善或者不准确，怎么处理？
答：要及时的与项目经理进行沟通协调。要在邮件中详细的把不完善不准确的地方描述出来，并提出自己的意见。
08、你认为做好测试计划工作的关键是什么？
答：首先，要有一个明确的目标，详细的阅读需求文档说明。
其次，要对整个测试人员、测试时间、测试进度进行一个预估，并预先进行管理。
最后，要对整个测试流程设定一个规范，所有测试人员都按着规范做事，不能随心所欲的测试。
09、软件配置管理工作开展的情况和认识？
拿到一台裸机过后要安装客户需要的操作系统，并且安装一些所必须的软件。
10、你觉得软件测试通过的标准应该是什么样的？
答：测试用例完全执行，测试用例覆盖到所有的测试点，并且缺陷的密度达到客户的需求。
11、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。那么软件系统的用户文档包括哪些？
答：用户安装文档、用户配置文档、用户使用手册、联机指导等。
12、简述软件系统中用户文档的测试要点？
完整性：用户文档中功能的描述要完整的。不能让用户产生疑问。
一致性：用户文档中的功能描述要与实际软件中的功能一致。不能描述过盛。
易使用性：用户文档描述的内容要方便用户阅读并且能够让用户很清楚的知道如何操作。
图表：有的时候用图表描述会很明了。
13、什么是系统瓶颈？
系统瓶颈就是软件在一定的并发量、访问量下无法达到用户的需求。
比如说用户需要在10s内完成一个访问，但是每一次都要12s才能完成，这个就是性能瓶颈，有可能是程序本身的问题，也有可能和操作系统、软件相关。
14、没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
可以。
这个情况下我们就要进行探索性测试，把软件当成用户需求，一步步进行测试。凭借经验判断功能正确与否，有的时候还可以与项目经理、开发人员一起进行交流沟通，从而进行更好的测试。
15、为什么尽量不要让时间富裕的员工去做一些测试？
首先，专业的测试人员是有一定的技能和耐心对软件一步一步进行测试。如果让时间充裕的员工去测试的话，他可能心思并不在测试上面。会很随意的、没有目标的进行测试。这样子的话测试并不完整，有的时候甚至很重要的bug都没法找出。所以还是需要专业的测试人员来进行测试的。
16、完全测试程序是可能的吗？
不可能
测试人员对程序进行测试，只能找出程序中的bug，但是并不能保证程序是没有bug的。
完全的测试要花费很多的人力财力，并且测试的数据量过大，很浪费时间。测试的结果还很多，有的都是类似的，没有必要进行相同的测试。所以完全测试是不可能的。
18、软件测试的风险主要体现在哪里？
主要体现在没法完全测试。有些问题可能隐藏在没有测到的地方。这样子就被忽略了。客户使用的时候并不熟悉软件是如何操作的。可能有的时候会误点点出问题。这样子的话我们就要承担很大的风险了。
发现的缺陷越多，说明软件缺陷越多吗？
是的，通常如果发现一个缺陷的话，有的时候会发现很多类似的缺陷，因为由于开发人员的习惯，可能一个地方有错误，另外一个地方就会有相同的错误。
19、所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
从理论上来说所有的缺陷都是可以修复的，但是并不是所有的缺陷都要修复。
一些对于软件没有影响的、不影响使用的缺陷我们可以不用修复。因为修复些细小的缺陷也是需要花费很多时间。项目上面可能会因为时间问题而先忽略这些小缺陷。
正交表的测试思想特点：
1）使用每个控件的每个取值参与组合的次数是基本相等的（均匀的）
2）在所有的组合数据中，选取数据时，应该均匀的选取，而不能从局部选取。
3）如果时间允许，尽可能的多测一些组合
正交表:主要针对一个输入框里面可能有多个值,而且数量巨大
年龄 体重 省 市 县
比如:输入年龄 18,体重45,山西 大同 阳高
E:测试大纲法
适用场合：程序包含多个窗口，每个窗口中又有多个功能，这些功能之间又有一定的联系。为了梳理清楚窗口之间以及窗口不同功能之间的联系，使用测试大纲法。
F:场景法
适用场合：大多数的业务比较复杂的软件系统都适合使用场景法（便于将各个功能点串起来，便于形成完整的业务感觉）是一种基于软件业务的测试方法，把自己当成最终用户，尽可能的模拟用户在使用此软件的操作
案例:
场景一:比如买东西:输入袜子,点击查询,出现列表,点击七匹狼,点击进入详情,点击加入购物车,点击去购物车结算,点击收获地址,点击支付,支付成功
场景二:比如买东西:输入袜子,点击查询,出现列表,点击七匹狼,点击进入详情,点击加入购物车,点击去购物车结算,点击收获地址,点击取消支付
G: 错误推断法
基于经验和直觉推测程序中所有可能存在的各种错误 , 从而有针对性的设 计测试用例的方法
在进行灰盒测试的时候经常用到此方法
H:随机测试
随意测试，不考虑任何用例和需求，完全站在一个用户或者的角度对产品进行使用。
适用场景：
1） 所有之前设定的用例已经 执行完毕
2）海量的条件组合无法一遍 历的时候
吸薪大法助你独步武林
下面这些是我的收集和整理，这些秘籍，对于【软件测试】的朋友来说应该是最全面的仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你
我的学习群：644956177 群里有技术大牛一起交流分享~
关注【程序媛木子】微信公众号里海量资源免费获取，