测试工程师面试题目总结

业务相关的测试流程是怎样的？

测试流程主要有三个阶段：需求了解分析，测试准备和测试执行

１需求了解分析阶段

产品同学主持需求评审会议，我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等，产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致

２测试准备阶段

会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块，然后我们就根据自己负责的模块用xmind（思维导图）进行测试需求分析，分析测试点，以及编写测试用例。之后我们会在自己的组内评审，评审修改之后在项目组评审。评审完后进行修改测试用例再同步到项目组群

３测试执行阶段

在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测。在执行测试的过程中，我们如果重现有bug就会用禅道记录并且提交bug ，也会进行回归测试，一直到没有重现bug达到上线为止，每一轮测试结束之后我们都会写一个测试报告。一般情况下，测试2-3轮之后会达到上线要求。上线前我们会做UAT（验收测试）测试，当达到上线的标准后，测试报告会认为测试通过，由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告，总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进。产品迭代几次后，我们会跑自动化用例来测试所有的功能模块

产品是上线流程和上线标准

上线流程：

1）一般我们会选择晚上上线，开发测试还有客户产品全部到场，进行上线测试
2）首先，开发将代码打包到生产环境的服务器中，把代码包替换到服务器的目录中。如果数据表有变化，开发就会运行sql脚本，创建表，修改表的操作；
3）接着，我们测试就开始先测试主体业务功能以及新增的功能模块；测试通过之后，我们会在界面上把上线测试的数据删除，在规定的日期正常上线。
4）如果发现bug，开发人员当场修复bug，修复成功之后我们测试再复测，通过就可以正常上线。
5）如果发现了bug开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性，如果严重就延期上线，或者迭代到下一个版本中。如果我们是迭代版本的话我们还需要版本回滚。如果不严重，产品跟客户觉得可以上线，就正常上线。

上线标准：

功能完备性：产品的主要功能必须全部实现并且经过充分测试，确保能够正常运行并满足用户需求。
稳定性和可靠性：产品在各种使用场景下都能够稳定运行，不出现崩溃、卡顿等问题，并且能够处理异常情况，保证数据的安全性和可靠性。
性能优化：产品需要经过性能测试，确保在用户量较大或者复杂场景下仍能保持良好的响应速度和稳定性。
安全性：产品需要具备一定的安全机制，保护用户的隐私和数据安全，防止恶意攻击和非法访问。
用户体验：产品界面设计合理，操作简单易懂，符合用户习惯，提供良好的用户体验。
兼容性：产品需要在不同的操作系统、浏览器或设备上都能够正常运行，并且适配不同的屏幕尺寸和分辨率。
文档和培训：产品需要提供详细的用户文档和操作指南，以及培训材料，帮助用户快速上手和解决问题。
上线准备：产品上线前需要进行全面的测试和验证，确保各项功能正常运行，并且进行备份和灾备方案的准备。

你提交的BUG，开发不认可怎么处理

首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug，如果是bug再去让身边的同看看听下他们的意见，然后自己先再三确去复测，并且保存好截图和日志，确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志。如果开发还是不认可的话我就跟产品或项目经理说明白情况

对于无法重现的BUG，如何应对

a)多次尝试进行重现，连接手机看log，如有复现提供复现步骤和日志、视频等辅助开发复现
b)如无法重现，将bug的产生条件和出现的问题做一个记录，可以跟开发配合探讨下出现问题的情况，建议开发根据问题的描述来进行原因定位；
c)查看系统日志，从信息中分析出问题的条件，并尝试重现；
d)提交给测试组长并进行沟通，是否需要处理该bug，看下这个bug是否严重，如果严重的bug一定要想办法找到原因，而优先级别低的问题可以考虑搁置，以后重现的时候再让开发处理。
 

之前项目中遇到哪些经典的BUG？怎么发现的？后续如何解决和避免措施？

手管项目的小火箭弹窗偶现崩溃

是在集成阶段发现的。根因是不同业务线的合作，触发优先级不熟悉，遗漏了优先级别更高的弹窗逻辑。后续解决方案：首先自身要去合作业务线寻求帮助，争取拿到对应模块的业务逻辑文档，再结合自身业务进行用例编写，其次用例评审可拉上对应业务同学参加，完善用例覆盖度。最后和leader反馈做一个工具在测试环境，如果触发崩溃信息，APP上会出现toast提示，上报到后台。办公软件会提醒有崩溃用imei去后台查看崩溃信息。

Linux你是怎么使用的尼

（1）发现bug帮助开发提取日志的时候：
         在linux里通过命令（tail -200 需查看日志的文件名）或tail -500查看当天的日志的后面多少行或者前面多少行定位bug
         通过tail -f来查看日志里的关键字exception(异常)、error(错误)或用重定向（ls -la > ls.txt）把信息保存起来
         再用vi命令进入信息里然后打开搜索命令shift + ：/进入文件定位模式搜索error,fatal（致命）,或者exception等
（2）后台程序运行久了会对系统造成卡顿等诸多隐患或我们做性能测试的时候。我们都会通过linux的命令Ps -ef(显示所有进程)、top(监控程序执行状况)、free -m(显示内存使用情况)来查看系统资源，如果服务器出现故障时我们也会用(service httpd status)看下服务器是否启动,用ps -ef|grep httpd 查看apache进程是否启动，用ps -ef | grep java查看jdk进程是否启动。如果服务器起不来，常见的问题有端口可能被占用，用netstat -an | grep 8080 查看端口是否已被占用。
（3）搭建测试环境的时候我们在是在linux下进行的，搭建LAMP时在线用命令yum install安装apache，php以及mysql；或通过xshell来导入需要的环境包来搭建LTMJ（Tomcat、Mysql、jdk）

在之前的项目中你是如何使用数据库？

数据库用的比较多的，就是数据结果检查，测试一些数据准备，性能测试造大量数据，验证数据是否成功入库。我们需要通过sql语句select来查找数据库对应的表
其次就是做一些测试数据准备，我们就用insert into输入数据或（者 update set 修改数据），我们需要到数据库查看有没有相关记录保存，保存的数据跟我们输入或者修改的记录是否一致

接口测试怎么做？平常你是怎么测试接口的？

一般的接口文档包含：请求参数、返回参数、URL、请求方式
接口用例表明：用例标题，优先级，所属模块，资源路径，请求参数，请求方式，测试数据，预期结果，实际结果

接口测试关注点：参数测试、返回值验证、业务数据、接口之间、DB验证
1）参数测试
针对输入参数和输出参数的测试，包括多参、少参、异常参、组合参、空参等
异常参数：参数不合法输入，考虑接口内部逻辑错误的异常提示，这些体现在完备的responsecode错误代码中。
2）返回值是否符合预期
正确返回：返回的code是否正确，返回的数据是否和DB一致
异常返回：是否定义全面，存在遗漏
3）业务数据要符合业务数据属性或定义
4）多个接口之间的数据是否存在关联
5）有依赖关联的接口
比如B接口的请求参数是A接口的响应数据
我们需要请求A接口，拿到数据后，把需要的数据提取出来，放入B接口进行请求
具体实现的话使用我们常用的那些工具都可以，像postman：请求A接口，在Tests脚本里面写js代码，将数据解析后提取想要的数据，存为全局/环境变量，在B接口请求的时候关联使用（{{id}}）

自动化测试时，怎么执行单挑用例？

Unittest中：在pycharm中，选择需要执行的用例运行即可。

Pytest中：进入指定的文件目录中，直接通过命令方式：pytest  -s  文件名::类名::函数名

给你一个APP，应该如何展开测试尼

我们app测试有Android app、鸿蒙和ios app三种。Android&鸿蒙 app主要是从以下几点进行测试
（1）界面测试，我们测试界面跟需求文档中界面原图是否一致，使用不同的手机界面分辨率，以及界面大小等方面进行测试。
（2）功能测试，功能测试和web测试差不多，主要测试app对其他相关功能模块的影响。
（3）兼容性测试，我们也会用真机来测试一下兼容性像用的三星Android版本6.0.1、红米Android版本5.1、小米5Android版本7.0,华为mate10Android版本8.0，IPhone5、IPhonex、IPhone6s puls对应的IOS为8.4.1-11，也可以借助阿里云测试；还要测试手机是否方便好用，以及跟手机自带的软件是否有冲突，和市场上排名前100的主流软件是否有冲突来进行交互性测试，防止被当成病毒不允许安装。
（4）网络测试，在不同的网络中进行测试，比如：2G，3G，4G，移动，电信，联通，还有网络之间切换，用fiddler进行弱网测试。
（5）交互性测试，（6）易用性测试，
（7）异常测试，异常测试手机关机、重启以及断网的一些异常情况
（8）安全测试，安全测试的话，我们会使用xss脚本和sql注入来进行代码攻击，一般使用扫描工具Appscan来进行攻击，然后还会用fiddler进行抓包，查看关键信息有没有进行加密，查看日志中有没有加密，数据库有没有加密，以及界面上的展示和输入是否加密了，会在fiddler抓包的时候设置断点，篡改数据，看能不能篡改成功。
（9）权限测试，
（10）稳定性测试，还会使用monkey测试App的稳定性，一般运行100W次，大概八个小时，查看日志文件，如果出现crash，anr，exception这些单词，则是出现bug，我们会将bug提交给开发，开发修复之后，我们会用种子数来进行回归复测
（11）性能测试，是为了提高用户的体验感，我们一般是用emaggee来测试监控App的cpu、内存、fps等性能指标，监控完之后编写性能测试报告，然后再对比性能指标，看是否达标。

monkey工具怎么使用的？

 Monkey这个工具是针对Andriod系统来测试稳定性。一般我们是在功能测试完成的情况下，再用monkey对其稳定性进行测试，主要是晚上下班前进行测试。一般我们主要是检查软件长时间运行，看看会不会出现崩溃（crash）、超时无响应（anr）、异常（exception）。原则上是monkey的工具，可实际上就是一条命令。一般情况下我们都是在下班时运行，我们一般设置的事件数是100W次，大概八小时这样，一般间隔时间25毫秒，等到第二天早上去看结果。然后分析monkey运行的日志看是否包含 crash，anr，exception，找出问题，问题给开发去修复解决。提交bug，等开发修复完成之后我们会根据上次运行的种子数 -s ，进行回归测试。执行命令例如：

命令中包含几个点：事件数、打印日志级别（-v -v -v）、忽略机制、指定事件比例（--pct-touch 50）以及设置间隔事件（--throttle 25）(25表示25毫秒)。
adb shell monkey -p app安装包名 --throttle 25 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 执行事件次数 >保存在pc的路径\日志名.log

回归测试命令：adb shell monkey -p app 安装包名 --throttle 25 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v -s 种子数 执行事件次数 >保存在pc的路径\日志名.log
 

浅谈下你在工作中使用到的adb命令

测试前如果没有搭建环境要我们自己搭建的话，会用adb install 安装包，卸载的话用adb uninstall 包名。这个包名可以通过adb -s 设备ID uninstall com.taobao.taobao(包名)去查询到。平常用到最多的是adb devices，查到当前连接的设备，以防掉线了执行命令会报错。找到bug时，我会去分析查找bug的原因，要去查日志的话会用到adb logcat -d，或者用adb logcat <tag>:I *:S,通过信息错误等级去查找。查找到的结果为了方便查看我会导出到windows里查看会用adb logcat -d > 路径\文件名。

Adb命令是监控手机资源在Android里使用
命令如下：
查看设备号      adb devices
安装            adb -s  设备号 install 包名
卸载软件        adb -s 设备名 uninstall 软件包名(以com开始的例如：com.qqmusic)
查看安装的软件包名   adb shell pm list package 查看所有的手机软件包名
查看第三方的手机软件包名  adb shell pm list -3 
查看手机当前使用的内存情况，各个线程的内存占用情况    adb shell dumpsys meminfo
查看手机的电池信息     adb shell dumpsys batteryinfo
查看系统资源状态       adb shell top

手机日志        adb logcat 产看手机日志
                adb logcat -c 清除手机日志 
                adb logcat -v time 显示时间
                将日志导入一个文件中 adb logcat > mobile.log
将手机的图片导入到PC端    adb pull 手机文件的路径  电脑路径
例如：Adb pull /storage/emulated/legacy/Pictures/Screenshots/Screenshot_2019-02-21-17-48-55.png F:\
进入手机linux系统  adb shell monkey -p app安装包名 --throttle 25 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 执行事件次数 >保存在pc的路径\日志名.log

设置时间的比率  --pct-touch(percent touch)
adb shell monkey -p app 安装包名 --throttle 25  --pct-touch 50 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v -s 种子数 执行事件次数 >保存在pc的路径\日志名.log(一般不设置，都选择默认的事件处理事项)

adb 命令录屏： 
 adb shell screenrecord  --time-limit 10 /sdcard/demo.mp4  （10表示录制10秒，默认是180s）
 

APP和WEB的测试有什么相同点和区别？

他们在功能上测试是一样的。因为功能是基础，功能没过关其他的扯淡。web是B/S架构，app是C/S架构，所以web端的前端和后代代码都在服务器上，web端是不需要升级的，就是展示它请求返回来的数据。而app的前端代码是在手机上，需要安装，更新，后台代码是在服务器上。所以app测试相比web测试更加注重专项测试。比如app的安装，卸载，升级或者更新，还有兼容性测试，性能，交互性，稳定性，弱网测试。拿兼容性来说，web端主要测试五大浏览器的兼容性和操作系统的兼容性，而app的安卓测试得测试不同的机型测试，华为，小米，vivo等，还有不同的版本，比如华为的就有7.0,8.0,9.0等版本。也要考虑屏幕的大小，分辨率等。

抓包工具了解吗？如何使用？fiddler抓包用来做什么

我原来的公司对于抓包这块，在App的测试用得比较多。我们会使用fiddler抓取数据检查结果，定位问题，测试安全，制造弱网环境；
如：抓取数据通过查看请求数据，请求行，请求报头，请求正文，信息是否正确去检查结果，如果是以4开头的话就有可能是前端问题一般我会到前端排查，以5开头就有可能是后端问题我就会到后端排查；如果是200的话，就需要检查请求参数是否正确，然后定位问题所在如果错误：前端问题，查看请求url，js有没写入，没有错误：后端问题，看后端具体返回的数据，如代码问题，看运行日志 ，是否包含 exception，error或根据时间点去看日志。
  
   测试安全，抓取数据查看用户的感敏信息有没有进行加密显示，还有就是把发送请求的数据篡改是否成功。

   弱网环境，通过fiddler工具选择Customize Ruels...（Ctrl+R）调出定义脚本编辑器找到“if (m_SimulateModem)”设置上行下行网速，然后把Rules->Performance->Simulate Modem Speeds选中生效
 

web测试中，如何判断是前端或者后端的bug

通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口，传参数，响应。

1.请求接口url是否正确,如果请求的接口url错误，为前端的bug

2.传参是否正确,如果传参不正确，为前端的bug
3.请求接口url和传参都正确，查看响应是否正确,如果响应内容不正确，为后端bug
4.也可以在浏览器控制台输入js代码调试进行分析.

为什么要判断？

因为开发工程师有前端还有后端，不能提交bug给错人了

对于没有数据交互的bug一般是属于前端的，比如：安装卸载问题、页面排版问题以及兼容性的问题都是前端问题；

如果有数据交互需要通过抓包工具fiddler/Charles来查看请求和响应，看上面答案

三次握手，四次挥手

Tcp协议：TCP协议又称传输控制协议，是面向连接的可靠传输。udp协议是用户数据报协议，是面向非连接快速度的传输。

tcp协议： 传输控制协议

    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连接成功）状态，完成三次握手。

    再进行数据传输

为什么需要三次握手呢？为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

http跟https的区别

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

get跟post请求的区别

GET请求在URL中传送的参数是有长度限制的，而POST没有。

GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。GET参数通过URL传递，POST放在Request body中。

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok

http协议包含哪些内容

（1）请求信息

1.请求行：请求方式、请求地址、http版本1.1

2.请求头：

HTTP消息报头包括普通报头、请求报头、响应报头、实体报头

Cache-Control??：no-cache  缓存

Connection ：close/keep-alive 是否关闭或者保持连接

Accept-Charset ：iso-8859-1  字符集

Accept-Encoding:gzip.deflate 编码格式

Accept-Language:zh-cn  语言

Authorization：服务器授权验证

Host ：主机

User-Agent ：

Location ：重定向

Server ：服务器版本信息

Content-Encoding ： 实体报头的编码格式  

请求正文

Data

（2）响应信息

1.状态行：http版本 、 状态码、状态信息

2.响应头：跟请求头一样

3.响应正文：
 

http常见的状态码有哪些？

        200 OK      //客户端请求成功         

        401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 

        403 Forbidden    //服务器收到请求，但是拒绝提供服务

        404 Not Found    //请求资源不存在，eg：输入了错误的URL

        500 Internal Server Error //服务器发生不可预期的错误

        503 Server Unavailable    //服务器当前不能处理客户端的请求

       

       数字；2开头的表示请求成功 ; 3开头，重定向，4开头的一般都是客户端的问题 ;5开头的一般都是服务器的问题 

小程序怎么测试

小程序本质上是一个js应用，测试中需要通过微信开发者工具生成二维码进行测试的。测试小程序时要注意和微信的数据交互，比如通知服务就是采用的微信通知；在登录时，也是微信赋给这个小程序一个用户id，是根据用户id进行登录。在测试时：一些支付是采用的微信的支付api进行支付的，一些权限获取位置的也是通过微信获取的，其他方面的功能测试和一般的app测试一样。

如果版本到了deadline，依然有未解的bug，应该如何处理这种情况

面对即将截止的版本期限而仍有未解决的bug，可以采取以下几种策略：

如果是普通一线测试建议只答前3点，首先要按照优先级来修复bug，2.拉上产研三方对未接的bug是否必解，3.实际项目中会往往会出现倒排的情况，所以答一下加班追进度也无可厚非。

1. 紧急修复优先级：识别最紧急、对系统性能影响最大的bug，并优先级解决这些bug。优先级高的bug应该优先被解决，以确保系统基本功能的稳定性和性能。

2. 权衡修复与特性实现：评估未解决的bug对当前版本的重要性，与新功能或改进的重要性进行权衡。如果bug对当前版本的发布至关重要，可能需要暂停或推迟一些新功能的实现，集中资源修复bug。

3. 采用临时解决方案：对于一些不影响主要功能的bug，可以考虑使用临时解决方案，比如设置一个明显的警告提示，让用户知道系统存在未解决的问题。这可以确保版本按时发布，并在后续版本中解决这些bug。

4. 增加测试时间：如果发现测试覆盖不足是导致bug未被及时发现的原因，可以考虑增加测试时间或加强测试策略，确保新功能和代码修改后能够更好地被测试覆盖。

5. 沟通和协作：与项目团队成员、利益相关者进行沟通，确保所有人都了解当前的情况和优先级。协作寻找解决方案，必要时可以寻求外部专家的帮助。

6. 调整发布计划：如果以上策略都不能在截止日期前解决问题，可能需要考虑调整发布计划，比如延期发布或者发布一个包含了已知问题的版本，然后在后续版本中解决这些问题。

执行测试用例的时候，你有几种方式验证用例执行通过？

在执行测试用例时，有几种方式可以验证用例是否通过：

1. 视觉验证（Manual Verification）：通过直接观察系统或应用的输出，判断其是否与预期相符。这种方法适合于简单的UI测试和功能验证。

2. 自动化测试工具验证：使用自动化测试工具（如Selenium、JMeter等）来执行测试用例，并根据预设的断言（assertions）来验证测试结果。自动化测试可以提高测试效率和一致性。

3. 日志分析：通过分析系统运行时的日志文件，检查系统的行为和响应是否符合预期。这种方法特别适用于追踪内部系统流程和错误信息。

4. 比较文件：对于系统生成的文件（如数据库备份、报表等），可以设置一个预期文件，然后比较实际生成的文件与预期文件是否一致。这种方法适合于验证系统输出的正确性和一致性。

5. 第三方工具验证：利用专门的验证工具（如性能测试工具、安全扫描工具等）来验证特定的系统功能或性能指标。

每种验证方式都有其适用场景和优势，选择合适的验证方式可以提高测试的有效性和效率。