软件测试常见面试题-01

一、说下你的性能测试流程

1. 找产品沟通哪些接口需要压测，需要达到什么样的预期值(TPS和响应时间);
2. 编写测试计划，人员、时间周期、工具;
3. 环境搭建;
4. 造数据;
5. 场景测试（单接口基准测试、单接口压力测试、混合接口测试、稳定性测试）;
6. 结果分析，提交测试报告;
7. 等待开发性能调优，复测。

二、性能测试的应用领域有哪些？

1、能力验证：乙方向甲方交付项目时，声明项目的性能数据。

2、瓶颈分析：在能力验证的过程中可能会发现一些瓶颈，通过技术手段分析瓶颈，得到分析数据，为后续调优做理论依据。

3、响应超时：什么负载量的时候出现超时现象？

4、tps达到瓶颈，波动剧烈：tps瓶颈点在哪里？，在什么地方出现性能衰减？

5、性能调优：在得到瓶颈分析数据之后，做性能调优。

6、降低超时，提高tps，减少抖动。。

7、容量规划：基于未来。为将来的用户激增提前做准备

8、数据库扩容

9、服务端硬件优化（增加cpu，扩充磁盘，提升带宽，分布式，负载均衡）

能力验证

1. 能力验证是最常用，也是最容易理解的性能测试的应用领域，主要是验证“某系统能否在 A 条件下具有 B 能力”，通常要求在明确的软硬件环境下，根据明确的系统性能需求设计测试方案和用例。
2. 能力验证这个领域最常使用的测试方法，包括后端性能测试、压力测试和可靠性测试。

能力规划

1. 能力规划关注的是，如何才能使系统达到要求的性能和容量。通常情况下，会采用探索性测试的方式来了解系统的能力。
2. 能力规划解决的问题，主要包括以下几个方面：
3. 能否支持未来一段时间内的用户增长；
4. 应该如何调整系统配置，使系统能够满足不断增长的用户数需求；
5. 应用集群的可扩展性验证，以及寻找集群扩展的瓶颈点；
6. 数据库集群的可扩展性验证；
7. 缓存集群的可扩展性验证；
8. 能力规划最常使用的测试方法，主要有后端性能测试、压力测试、配置测试和可靠性测试。

性能调优

1. 其实是性能测试的延伸。性能调优主要解决性能测试过程中发现的性能瓶颈的问题，通常会涉及多个层面的调整，包括硬件设备选型、操作系统配置、应用系统配置、数据库配置和应用代码实现的优化等等。
2. 这个领域最常用的测试方法，涵盖了上面介绍的七大类测试方法，即后端性能测试、前端性能测试、代码级性能测试、压力测试、配置测试、并发测试和可靠性测试。

缺陷发现

1. 是一个比较直接的应用领域，通过性能测试的各种方法来发现诸如内存泄露、资源竞争、不合理的线程锁和死锁等问题。
2. 缺陷发现，最常用的测试方法主要有并发测试、压力测试、后端性能测试和代码级性能测试。

三、说下服务器资源监控的命令

• top: 能够实时监控系统的运行状态，并且可以按照cpu及内存等进行排序;
• vmstat: 可以监控操作系统的进程状态、内存、虚拟内存、磁盘IO、cpu;
• free: 能够监控系统的内存使用状态。其中，total：总计物理内存的大小;
• netstat: 显示本机网络链接、运行端口、路由表等信息;
• atop命令是一个终端环境的监控命令。它显示的是各种系统资源（CPU, memory, network, I/O, kernel）的综合，并且在高负载的情况下进行了彩色标注;
• iftop 命令监听指定接口（如 eth0）上的网络通信情况。它显示了一对主机的带宽使用情况。

四、tps压不上去，可能有哪些方面原因？

1、网络带宽

在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。

2、连接池

可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

3、垃圾回收机制

从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。

4、数据库配置

高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。

5、通信连接机制

串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。

6、硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

7、压力机

比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。

8、压测脚本

以jmeter举个例子，之前遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。

还有录制的脚本，需要删除一些不必要的脚本，对脚本进行优化，免得这些不必要的请求占用资源。

9、业务逻辑

业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。

10、系统架构

比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。

11、并发数

系统的TPS是确定的，当并发数设置不恰当时，tps也较低。

五、怎么设计性能场景？

• 基准测试场景：模拟少量的虚拟用户对一个或多个业务某项性能指标进行定量和可对比的测试。将测试结果作为基准数据，在系统调优或者评测的过程中，通过运行相同的业务场景比较测试结果。
• 单接口测试：通过模拟虚拟用户，通过不断增加模拟用户数持续运行测试，获取事务响应时间，tps，报错率监测测试系统的各服务器资源使用情况。每一个虚拟用户级别会对应tps，直到找到tps的拐点，说到拐点可能大家能够想到像山峰一样的高斯曲线，但其实这是一个极其理想的情况，大部分情况下是增长到一定的阈值就不再增加。
• 混合接口场景：将多个接口按照实际比例进行性能测试，这个比例就是综合场景的关键了，综合场景执行除了要观察总的tps，还有一个非常关键的因素就是接口之间的调用比例，比例不能偏离。（需要结合实际业务）
• 稳定性测试：通过给系统加载一定压力的情况下，运行较长一段时间，验证系统是否稳定。（比如：运行48小时）
• 高可用测试：有两台数据库服务，其中一台宕机了，能不能及时切换到另外一台上，且切换的时延是多少，处理能力能不能达到预期标准。

六、如何识别性能瓶颈？

① 硬件上的性能瓶颈：如CPU、内存、磁盘读写等的瓶颈，为服务器硬件瓶颈；

② 应用软件上的性能瓶颈：如服务器操作系统瓶颈（参数配置）、数据库瓶颈（参数配置）、web服务器瓶颈（参数配置）、中间件瓶颈（参数配置）等；

③ 应用程序上的性能瓶颈：应用程序上的性能瓶颈，如SQL语句、数据库设计、业务逻辑、算法等等；

④ 操作系统上的性能瓶颈：一般指的是Windows、linux等操作系统，如出现物理内存不足时，或虚拟内存设置不合理（虚拟内存设置不合理，会导致虚拟内存的交换率大大降低，从而导致行为的响应时间大大增加，可以认为在操作系统上出现了性能瓶颈）；

⑤ 网络设备上的性能瓶颈：一般是防火墙、动态负载均衡器、交换机等设备导致。

七、内存溢出和泄漏区别?

• 内存泄漏: 是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄漏似乎不会有大的影响，但内存泄漏堆积后的后果就是内存溢出。
• 内存溢出: 指程序申请内存时，没有足够的内存供申请者使用，或者说，给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据，那么结果就是内存不够用，此时就会报错OOM,即所谓的内存溢出。

UI自动化面试题

一、web自动化中常见的元素定位方式？

• id：根据id来获取元素，返回单个元素，id值一般是唯一的；
• name：根据元素的name属性定位；
• tagName：根据元素的标签名定位；
• className：根据元素的样式class值定位；
• linkText：根据超链接的文本值定位；
• partialLinkText：根据超链接的部分文本值定位；
• cssSelector：css选择器定位；
• xpath：通过元素的路径来定位。

二、简述你所知道的等待方式？

• 强制等待：也叫线程等待, 通过线程休眠的方式完成的等待,如等待5秒: sleep(5)，一般情况下不太使用强制等待。
• 隐式等待：通过implicitly Wait完成的延时等待，注意这种是针对全局设置的等待，如设置超时时间为10秒，使用了implicitlyWait后，如果第一次没有找到元素，会在10秒之内不断循环去找元素，如果超过10秒还没有找到，则抛出异常，隐式等待比较智能，它可以通过全局配置，但是只能用于元素定位。
• 显式等待：也称为智能等待，针对指定元素定位指定等待时间，在指定时间范围内进行元素查找，找到元素则直接返回，如果在超时还没有找到元素，则抛出异常，显示等待是 selenium 当中比较灵活的一种等待方式，他的实现原理其实是通过 while 循环不停的尝试需要进行的操作。

三、UI自动化测试用例如何设计？

1. UI自动化测试用例是从手工测试用例中提取出来的，跟手工测试用例相比，自动化测试用例更加注重用例的严谨性，选择用例的时候遵循以下原则：
2. 优先选取覆盖产品核心功能的用例；
3. 从成本考量，不要选择流程过于复杂的用例；
4. 选取的用例可以是重复执行，繁琐的部分，比如字段验证、提示信息验证；
5. 优先实现正向的测试用例，反向用例一般情况复杂、数量多。

四、你怎么提高UI自动化脚本的稳定性？

1. 尽量用相对路径的xpath表达式；
2. 查找元素优先用显式等待；
3. 用例与用例之间尽量避免产生依赖，用例可以独立执行；
4. 用例执行结束后对测试场景进行还原，避免影响其他用例的执行；
5. 脚本执行失败后加入重试机制，提升用例的稳定性；
6. 尽量保证单独的测试环境，避免其他的测试同步进行。

五、UI 自动化测试中，如何做集群？

1. Selenium Grid，分布式执行用例；
2. Appium 使用 STF 管理多设备；
3. Docker+K8S 管理集群。

六、如何保证页面元素一定是可以点击的？

1. 首先通过封装find方法，实现wait_for_element_ispresent，这样在对元素进行操作之前保证元素被找到，进而提高成功率。（WebDriverWait）
2. 在对页面进行click之前，先滚动到该元素（通过Js封装），避免在页面未加在完成前或是在下拉之后才能显示。

七、你的自动化用例的执行策略是什么？

1. 每日执行：比如每天晚上在主干执行一次
2. 周期执行：每隔2小时在开发分支执行一次
3. 动态执行：每次代码有提交就执行

八、元素定位失败的原因可能有哪些?

1. 元素定位方式编写错误;
2. 点击速度过快，页面没有加载出来就点击页面上的元素;
3. frame/iframe表单嵌套;
4. 页面跳转到新的标签页，未切换handle窗口;
5. 使用了动态属性进行定位元素;
6. 页面上的警告弹框;
7. 页面元素失去焦点导致脚本运行不稳定;
8. 元素被遮挡，不可用，不可见。

九、selenium调用js(execute_script),有哪些场景?

1. 移除元素隐藏、禁用、只读等限制属性;
2. 为元素添加id或高亮样式;
3. 页面滚动;
4. 富文本框输入（HTML注入);
5. 获取页面信息。