软件测试高频面试题总共有45道，因为篇幅问题，本篇只介绍22道面试题，如需要更多面试题，可后台私信我。
01.性能测试关注的指标是什么？
从外部看，性能测试主要关注如下三个指标：
吞吐量：每秒钟系统能够处理的请求数、任务数
响应时间：服务处理一个请求或一个任务的耗时
错误率：一批请求中结果出错的请求所占比例
从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、 络、磁盘IO等。
02.性能测试怎么做的？/ 如果你要进行性能测试，你是如何展开操作的？
1.确定关键业务，关键路径；
2.确定测试的关键数据。比如并发量，响应时间，循环次数等；
3.准备测试环境，完成脚本录制或脚本开发；
4.执行测试，观察或监控输出参数，比如吞吐量，响应时间，资源占有率等；
5.对执行结果进行分析，分析性能问题。
03.你认为性能测试的目的是什么？
性能测试的目的： 评估系统的能力—-测试中得到的负荷和响应时间数据可被用于验证所计划的模型的能力，并帮助作出决策。
识别体系中的弱点—-受控的负荷被增加到一个极端水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
系统调优—重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。检测软件中的问题，长时间的测试执行可导致程序发生由于内存泄漏引起的失败，揭示程序中的隐含问题或冲突。
验证稳定性，可靠性—在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
04.做好性能测试的工作的关键是什么?
做好性能测试工作的关键是强度测试（Stress Test）： 强度测试
1、性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
2、性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在 络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
3、应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能性能测试图像测试是重点。
4、并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。
05.怎样分析性能测试结果？
1.查看聚合 告和服务器的资源使用图，检查响应时间，事务成功率，CPU，内存和IO使用率是否达到要求，如果出错率达到了总请求的3%，我们会检查是什么原因导致的，修改好后，重新测试；
2.如果出现了性能瓶颈，比如响应时间，或者CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致响应时间过长，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给代发修复，修复好了就进行回归测试。
06.如何判断 络是否存在瓶颈？
查看在整个性能测试过程中， 络的吞吐量是多少，如果 络的吞吐量占到了服务器的70%以上，我们就认为 络存在瓶颈，通常会增加带宽或者压缩传输数据。
07.如何判断响应时间不达标？
根据性能测试结果先检查看下是否是服务器带宽存在问题，如果带宽存在瓶颈，则会考虑增加带宽或者压缩传输数据，如果带宽没有问题的话，我们会从服务器上导出日志，开发一起讨论分析是哪个地方导致响应时间过长，确定问题后，就提单给开发修复，修复好了就进行回归测试。
08.如何判断CPU使用率不达标？
CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致CPU使用率不达标，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给开发修复，修复好了就进行回归测试。
09.app的性能测试怎么做的？
APP的性能测试分为服务器端的性能和手机端的性能。
服务器端的性能：jmeter工具进行测试的，和web端性能测试的方法一样的。
手机端APP的稳定测试：使用monkey做。
10.用monkey做app测试，怎么做的？如果有问题的话怎么定位？
1.先使用 adb logcat -c 清空手机的logcat日志；
2.接下来使用 adb logcat -v time 获取logcat 日志，并导入本地文件使用 monkey 运行被测应用 adb shell monkey -p 包名 -v 3.100000 并将执行结果导入到本地测试；
4.如果中途失败了就要去看monkey日志中有没有crash或者anr的关键字；
5.如果还需要定位到是什么原因导致的anr或者crash的问题，将相关日志和logcat日志与进程 提交给开发定位；
6.如果是anr的问题，还需要从安卓中获取/data/anr/traces.txt文件提交给开发定位。
11.app出现ANR的原因？
线程阻塞，内存不足，CPU满负荷（现在手机基本都是8核CPU，基本不会出现CPU满负荷的情况）
12.app出现CRASH的原因？
空指针值，数组越界，内存不足，CPU满负荷（现在手机基本都是8核CPU，基本不会出现CPU满负荷的情况）
13.APP常见崩溃原因？
1.设备碎片化：由于设备极具多样性，App在不同的设备上可能有不同表现形式；
2.宽带限制：宽带不佳的 络对App所需的快速响应时间不够；
3. 络的变化：不同 络的切换可能会影响App的稳定性；
4.内存管理：可能内存过低，或者是授权的内存位置的使用可能会导致App失败；
5.用户过多：连续数量过多可能会导致App崩溃；
6.代码错误：没有经过测试的新功能，可能会导致App在生产环境中失败；
7.第三方服务：广告或弹出屏幕可能会导致App崩溃。
14.说几个常用的adb指令？
adb install（apk的文件路径） 安装软件到手机或者模拟器
adb uninstall（包名） 卸载手机或模拟器上的某款软件
adb devices 查看与当前电脑连接的移动设备
adb ,adb start-server 启动
adb,adb kill-server 杀死
adb logcat 查看日志
adb logcat -v time process >
15.软件覆盖安装的adb命令？
adb install -r xx.apk 覆盖低版本的
adb install -r -d 覆盖高版本的
16.性能测试的adb命令？
adb shell dumpsys cpuinfo 查看手机cpu的使用情况
adb shell getprop|findstr dalvik 手机系统自己运行的内存使用
17.说几个monkey指令？
Adb shell monkey -p 包名
Adb-shell–ignore-crashes 忽略崩溃
Adb-shell–ignore-timeouts 忽略延时
Adb-shell–ignore-throttle 延时毫秒值
Adb-shell–pct-touch–pct-motion 触摸与滑动事件的比例
18.弱 情况下你是如何测试的？
1.2G的 速150kbps，折合下载速度15-20k/s
2.3G的 速1-6mbps，折合下载速度120k/s-600k/s
3.4G的 速10-100mbps，折合下载速度1.5m/s-10m/s
4.使用真实的SIM卡，运营商 络来进行测试
5.通过代理的方式模拟弱 环境下进行测试（Charles延迟）
6.链接模拟弱 的热点进行测试（如360WiFi助手可以设置）
19.接口测试流程？
1.后端完成开发，输出接口文档；
2.前端开发和后端开发进行前后端联调，结束后后端开发人员提测接口；
3.测试人员进行接口测试；
4.进行验收测试；
5.利用持续集成技术进行持续的校验。
20.进行接口测试，你是如何进行去测试的？
1.通过性验证：保证接口好使，能正常传入且返回正确的结果；
参数组合：有必传项时检查必传项；
接口安全：
a.验证（比如商品价格不能被外部修改）
b.身份授权（商品必须商家本人才能修改）
c.是否加密（用户名密码加密）
d.复杂程度校验
2.根据业务逻辑来设计用例
3.工具：postman和jmeter。一般用postman测接口，jmeter也能侧，但一般不用。
21.举例说一下你的接口测试是怎么做的？
先看接口文档，根据接口文档进行测试，包含接口的URL，请求参数，响应结果。
如果没有接口文档，就自己抓包。我们是用jmeter来做接口测试的，首先，要新建一个线程组，在线程组下面添加一个http请求，然后填写好服务器地址，接口路径，请求方式，请求参数。
如果需要参数化，先在本地创建一个TXT文档，把参数填写到文档里面，在jmeter中添加一个csv文件设置，填写好TXT文档的路径，然后在请求参数中使用json提取器把token值关联出来
然后在下单接口中使用${参数名}的方式引用；接下来添加断言，检查服务器返回的结果和预期结果是不是一致的。最后，添加查看结果数查看测试结果。
22.请描述下接口测试与UI测试是如何协同测试的？
1.有一部分是重叠的，UI测试是通过前端写的界面，是来调用接口的，而接口测试是直接调用接口；
2.排除前端的处理逻辑与调用的正确性，在理论上接口测试是可以覆盖所有的UI测试，但实际中，如几口层覆盖所有的业务流，在UI上只测试前端的逻辑
而最终的结果会忽视很多原有的功能点，导致了UI测试的不充分，那么会存在人多分工且实践充分的时候可以尝试接口去做业务流的全覆盖，否则不要轻易地去尝试。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！