测试面试题库

1.请问你遇到过哪些印象深刻的bug，接口测试出现bug的原因有哪些？

做电商平台测试时，用户成功修改了含emoji表情的昵称，在登录的时候却校验不成功，临时处理就是先在数据库把用户昵称中的表情给删掉，先让用户可以正常使用 ，然后在修改资料的地方限制昵称输入内容限制，不允许输入表情符 。
接口测试常见的bug有以下几个: 特殊值处理不当导致程序异常退出或者崩溃 类型边界溢出，导致数据独处和写入不一致 取值边界外未返回正确的错误信息 权限未处理，可以访问其他用户的信息 逻辑校验不完善，可以利用漏洞获取非正当利益 状态处理不当，导致逻辑出现错误 数组类型item个数为0或者item重复时程序异常退出

2.请问你在项目中关于功能测试和接口测试是怎么做的?

功能测试： 首先制定测试计划，然后进行测试设计，将在测试计划阶段指定的测试活动分解，进而细化，为若干个可执行程序的子测试过程，然后执行测试，按照测试计划使用测试用例对待测项目进行逐一的，详细的排查分析评估，最后对测试结果进行统计和分析， 接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。 现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。 如今系统越来越复杂，传统的靠前端测试已经大大降低了效率，而且现在我们都推崇测试前移，希望测试能更早的介入测试，那接口测试就是一种及早介入的方式。例如传统测试，你是不是得等前后端都完成你才能进行测试，才能进行自动化代码编写。而如果是接口测试，只需要前后端定义好接口，那这时自动化就可以介入编写接口自动化测试代码，手工测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。 接口测试的策略 接口测试也是属于功能测试，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：1.测试接口文档（需求文档） 2.根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）3. 执行测试，查看不同的参数请求，接口的返回的数据是否达到预期。

3.请你说一下设计测试用例的方法/黑盒和白盒?

黑盒测试：
1.等价类划分 等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。
2.边界值分析法 边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。边界值分析就是假定大多数错误出现在输入条件的边界上，如果边界附件取值不会导致程序出错，那么其他取值出错的可能性也就很小。 边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。
3.正交试验法 正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。
4.状态迁移法 状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。
5.流程分析法 流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，这是从白盒测试中路径覆盖分析法借鉴过来的一种很重要的方法。
6.输入域测试法 输入域测试法是针对输入会有各种各样的输入值的一个测试，他主要考虑 极端测试、中间范围测试，特殊值测试 。
7.输出域分析法 输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，他的目的是为了达到输出域的等价类和边界值覆盖。
8.判定表分析法 判定表是分析和表达多种输入条件下系统执行不同动作的工具，他可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确； 9.因果图法 因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。
10.错误猜测法 错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法，从而设计测试用例
11.异常分析法 异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发生错误时系统对于错误的处理能力和恢复能力依此设计测试用例。
白盒测试：
白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：
1. 保证一个模块中的所有独立路径至少被测试一次；
2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；
3. 检查程序的内部数据结构，保证其结构的有效性；
4. 在上下边界及可操作范围内运行所有循环。 常用白盒测试方法： 静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。 白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。

4.请你回答一下测试的相关流程是什么？

测试最规范的过程如下 需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试 来自W模型

5.请你说一下如何写测试用例?

1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
2、如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的bug情况
3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例
4、找到需求相关的一些特性，补充测试用例
5、根据自己的经验分析遗漏的测试场景
6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
7、书写格式一定要清晰

6.请你说一说当前工作中涉及的测试问题(测试流程和测试性能)?

在测试性能中，时常会出现脚本回访卡住的问题，原因有以下几种： 1、 runtimesetting 中的continue error没有勾选 2、录制的脚本中存在冗余的代码部分，需要对脚本进行优化，去除冗余的部分（优化脚本） 例如：在用FireFox录制脚本时，脚本中会产生一个叫
”Url=http://download.cdn.mozilla.net/pub/firefox/releases/43.0.1/update/win32/zh-CN/firefox-43.0.1.complete.mar","Referer=", ENDITEM,”这样的代码（该代码出现的问题不止一处，在查找时一定要注意。），这是因为采用firefox浏览器录制时产生的压缩文件，在脚本回放时卡住的原因正是因为这个（建议：能采用IE录制尽量用IE浏览器） 解决办法：注释掉或者删除掉该段代码即可， 关联问题：在用loadrunner自带对比工具对比脚本后 找到需要关联的动态值。在关联后回放脚本时报错HTTP-status code 417（exception failed）错误时，产生的原因如下：
1、脚本中还存在没有关联或者关联失败的动态值，利用lr自带对比工具仔细对比
2、脚本中的动态值被做了加密策略，仔细查看脚本中动态值的部分，看看动态值是否被做了安全策略（随机生成或者打乱动态值顺序、在动态值中加入了特殊符号），由于在tree-response中的动态值是未被加密的状态，在client向server发送请求时，client的动态值发给服务器，这时服务器的动态值已经被做了参数化，所以服务器不认准client向服务器发送的动态值。 解决办法：去掉动态值的安全策略即可（JVM参数）

7.你在做项目中有做过压力测试吗，怎么做?

1、首先对要测试的系统进行分析，明确需要对那一部分做压力测试，比如秒杀，支付
2、如何对这些测试点进行施压 第一种方式可以通过写脚本产生压力机器人对服务器进行发包收报操作 第二点借助一些压力测试工具比如Jmeter,LoadRunner
3、如何对这些测试点进行正确的施压 需要用压力测试工具或者其他方法录制脚本，模拟用户的操作
4、对测试点设计多大的压力比较合适？ 需要明确压力测试限制的数量，即用户并发量
5、测试结束后如何通过这些数据来定位性能问题 通过测试可以得到吞吐量，平均响应时间等数据，这个数据的背后是整个后台处理逻辑综合作用的结果，这时候就可以先关注系统的CPU，内存，然后对比吞吐量，平均响应时间达到瓶颈时这些数据的情况，然后就能确认性能问题是系统的哪一块造成的

8.请你设计一个微信朋友圈点赞的测试用例?

功能测试： 点赞某条朋友圈，验证是否成功
接口测试： 点赞朋友圈，验证朋友能否收到提示信息
性能测： 点赞朋友圈，是否在规定时间显示结果，是否在规定时间在朋友手机上进行提示
兼容性测试 ：在不同的终端比如ipad,手机上点赞朋友圈，验证是否成功

9.请你回答一下TCP三次握手，以及为什么不是两次?

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
为什么不是两次： 在服务端对客户端的请求进行回应(第二次握手)后，就会理所当然的认为连接已建立，而如果客户端并没有收到服务端的回应呢？此时，客户端仍认为连接未建立，服务端会对已建立的连接保存必要的资源，如果大量的这种情况，服务端会崩溃

10.请问你怎么看待软件测试的潜力和挑战？

软件测试是正在快速发展，充满挑战的领域。尽管现在许多自动化测试软件的出现使得传统手工测试的方式被代替，但自动化测试工具的开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中仍然需要大量具有专业技能与专业素养的测试人员，并且随着云计算、物联网、大数据的发展，传统的测试技术可能不再适用，测试人员也因此面临着挑战，需要深入了解新场景并针对不同场景尝试新的测试方法，同时敏捷测试、Devops的出现也显示了软件测试的潜力。

11.请你回答一下性能测试有哪些指标，对一个登录功能做性能测试，有哪些指标，怎么测出可同时处理的最大请求数量？

性能测试常用指标：
从外部看，主要有
1、吞吐量：每秒钟系统能够处理的请求数，任务数
2、响应时间：服务处理一个请求或一个任务的耗时
3、错误率：一批请求中结果出错的请求所占比例
从服务器的角度看，性能测试关注CPU，内存，服务器负载，网络，磁盘ＩＯ
对登录功能做性能测试
单用户登陆的响应界面是否符合预期
单用户登陆时后台请求数量是否过多
高并发场景下用户登录的响应界面是否符合预期
高并发场景下服务端的监控指标是否符合预期
高集合点并发场景下是否存在资源死锁和不合理的资源等待
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏
怎么测出可同时处理的最大请求数量 可以采用性能测试工具(WeTest服务器性能)，该工具是腾讯wetest团队出品，使用起来很简单方便，但测试功能相当强大，能提供10w+以上的并发量，定位性能拐点，测出服务器模型最大并发

12.请说一下手动测试与自动化测试的优缺点？

手工测试缺点：
1、重复的手工回归测试，代价昂贵、容易出错。
2、依赖于软件测试人员的能力。
手工测试优点：
1、测试人员具有经验和对错误的猜测能力。
2、测试人员具有审美能力和心理体验。
3、测试人员具有是非判断和逻辑推理能力。 自动化测试的优点：
1、对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
2、可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
3、可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测
试模拟同时有许多用户，从而达到测试的目的。
4、更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
5、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。
6、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
7、增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。 自动化测试的缺点：
1、不能取代手工测试
2、手工测试比自动测试发现的缺陷更多
3、对测试质量的依赖性极大
4、测试自动化不能提高有效性
5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
6、工具本身并无想像力