软件测试面试题-自测

标签：面试题 请求 是否 测试 自测 服务器 日志 bug 软件测试

一、测试流程 

1.项目测试流程你是怎么开展的？

①首先，需求分析阶段，分析需求点，需求确定以后进入测试计划阶段，参考需求规格说明书进行测试计划编写

②接着，进入测试设计阶段，依据需求文档及原型图编写测试用例，并进行用例评审

③进入测试执行阶段，需要搭建测试环境，执行冒烟测试之后进入正式测试，并且将测试缺陷进行提交及跟踪，经过多轮回归测试，直到测试版本结束

④最后，进入测试评估阶段，对软件版本质量进行评估，输出测试报告，确认是否上线。

单独负责一个项目，需 要注意什么呢?

 （1）首先，评估项目的测试范围盒周期，是否能够单独完成

（2）做好测试策略和计划安排，保证每个环节按时完成

（3）在上手测试前，树立大致的测试点，先做冒烟测试

（4）测试中，尽量通过一些技术手段提升测试效率

（5）项目中，如果碰到解决不了的问题，要及时寻求解决方案

（6）及时对bug进行追踪，推动开发尽快解决bug

（7）把控发布标准，测试报告中标明上线风险

测试文档

测试计划和测试方案的区别？

（1）测试计划是偏管理性质的文档（通俗来说就是解决【谁来做？】【做什么？】的问题），测试方案是偏技术类型的文档（解决【怎么做？】的问题） （2）测试计划主要包含测试的目的与范围，角色与职责，资源及安排，风险与乐队，测试标准等信息；测试方案主要包含测试方法，测试环境与测试工具等内容

测试计划要素有哪些？

 （1）测试目的（Why）

（2）测试范围（What）

（3）测试时间安排（When）

（4）人员任务分配（Who）

（5）测试环境（Where）

（6）测试方法和策略（How）

测试用例

 编写测试用例的流程

（1）熟悉并分析项目业务需求

（2）依据功能模块划分，使用等价类、边界值等黑盒测试方法进行用例设计，先整理功能正常的用例，再进行每一个操作的异常用例的覆盖，补充业务约束，功能交互项，数据验证项等

（3）每个功能模块分别写完用例以后，从项目的业务流程考虑，是否都进行了用例的覆盖

（4）编写完成后，提交评审

测试方法

你知道白盒测试么? 有哪些白盒测 试的方法？

（1）白盒测试是基于代码的测试

（2）方法：语句覆盖，判定覆盖，条件覆盖，条件判定覆盖，条件组合覆盖，路径覆盖

协议 

常见的 HTTP 接口请求方法有哪些

 （1）GET：获取数据和资源

（2）POST：发送数据给服务器，创建或者更新资源

（3）PUT请求：用来创建或者替换目标资源

（4）PATCH，对资源进行部分修改

（5）DELET，删除资源

http 和 https 协议的区别？

 （1）安全性：HTTP明文传输，易受攻击，HTTPS安全性更高

（2）端口：HTTP：80，HTTPS：443

（3）灵活性：HTTP简单快速，https门槛较高

OSI 七层模型有哪些层以及有哪些代表协议？

（1）应用层：网络服务于用户的一个接口 （2）表示层：数据的表示 （3）会话层：建立、管理、终止会话 （4）传输层：定义传输数据的协议端口号 （5）网络层：进行逻辑地址寻找，实现不同网络之间的路径选择 （6）数据链路层：建立逻辑连接，进行硬件地址寻址功能 （7）物理层：建立、维护、断开物理连接

说一下 TCP 协议的三次握手过程？

（1）第一次握手:客户端向服务器发起，用来申请建立连接

（2）第二次握手：服务器回复客户端，用来确定并接受连接请求

（3）第三次握手：依旧是客户端发给服务器，用来确认服务器的回复消息

说一下 TCP 协议的 4 次挥手过程

 （1）第一次挥手：客户端向服务器发起，用来申请断开连接

（2）第二次挥手：服务器回复客户端，用来确定客户端上一个断开连接请求的

（3）第三次挥手：服务器 发给客户端，告知客户端服务器的数据发送完毕了，需要断开连接

（4）第四次挥手，客户端回复服务器，确认服务器的上一个断开连接请求

在浏览器中输入一个网页会发生什么？

（1）进行DNS域名解析 （2）建立TCP连接，发起三次握手 （3）发送一个HTTP请求 （4）服务器处理相关的请求并返回处理后的结果 （5）关闭TCP连接 （6）浏览器接受到服务器处理后的结果后，开始解析 （7）浏览器将解析后的资源进行请求，并对页面进行渲染展示

TCP 协议和 UDP 协议的区别？

 （1）TCP面向连接，UDP无连接

（2）TCP可靠，能保证数据传输无差错，UDP尽最大努力交付，不可靠

 （3）TCP传输效率较低，UDP效率高，适合注重速度不在意丢包的场景

b/s 和 c/s 架构有什么区别？

 （1）B/S架构：浏览器-服务器，不需要安装客户端，只需要通过浏览器就能访问，升级只需要更新服务器，需要考虑浏览器兼容性

（2）C/S架构:客户端-服务器端，需要安装一个客户端才能使用，需要考虑安装卸载

接口测试

接口测试用例的编写要点有哪些？

①考虑接口的正常使用

②业务约束规则验证：包括鉴权、逻辑约束

③考虑请求参数必填字段：

（1）参数长度边界值验证

（2）类型异常、null

（3）参数名错误、参数个数

（4）参数组合验证

④容错能力，大量数据，频繁请求，重复请求（如订单）

接口测试到底测什么呢?

 （1）考虑接口正常调用

①按照接口定义，传递正确的接口信息，然后查看返回的响应结果和数据库数据是否正确

②传递的请求数据覆盖有效类，边界值

③返回的响应结果的每个字段都需检查

（2）考虑请求参数的错误、异常情况

①请求数据异常值：空值，长度类型异常

②业务约束：订单状态必须确认收货后才能评价

③输入错误的参数名：多一个参数，少一个参数，看接口是否正确处理

（3）安全性测试

①敏感数据，是否加密传输

②返回数据是否含有敏感数据

③接口是否防止恶意请求：如大量伪造请求接口致使服务器崩溃

（4）性能测试

①并发请求相同的接口，查看接口的处理情况

②接口响应时间在用户可接受范围内

③对于业务操纵频繁的接口做压力测试，监控性能资源

做了接口测试，后面还需要进行系统 功能测试吗？

 （1）需要，接口测试主要是为了尽早发现问题提前介入，可以返现页面上发现不了的bug，还可以提高系统的稳定性

（2）虽然接口测试覆盖了所有功能层面的逻辑测试，但跟前端界面进行集成的时候，依然会出现问题，所以我们依旧需要所有功能在前端界面的测试验证

get 和 post 方法有什么区别？

（1）请求参数：get请求参数是放在url里面，长度收到限制，安全性较差，而post请求参数是放在请求体里面的，长度没有限制，安全性相对较高

（2）访问：get请求可以通过浏览器直接访问，支持刷新和后退。post请求，不能直接被浏览器访问，刷新后台需要重新传送

怎么判断一个接口是否有 bug

 （1）先确认自己传参时的接口地址，请求方式，请求头和请求体是否正确

（2）如果正确，查看返回结果和接口文档进行对比，如果一致

（3）则判断数据库中的数据是否有问题

APP 测试和 Web 测试有什么区别？

web测试：B/S架构，通过浏览器访问

App测试: C/S架构，通过客户端操作

（1）系统架构方面，web端，只需要更新服务器；App，服务器端和客户端都需要回归测试一遍

（2）客户端性能方面：web一般只需要关注响应的时间，App还需要关注流量，电量，cpu，内存

（3）兼容性方面：web要考虑不同操作系统下不同主流浏览器的兼容，App要考虑不同产商机型、操作系统、屏幕尺寸分辨率等兼容性问题

小程序测试和 app 测试有什么区别？

（1）安装卸载： 小程序不需要下载安装，不需要卸载；App需要下载并且安装后才能使用，清除时需要卸载

 （2）开发周期

小程序开发周期约2周，发布审核时间较短

App：需要在支持的android和ios平台分别开发，周期较长，审核时间也较长

（3）登录权限

小程序：一般微信登录，无需注册

App：需要注册登录系统，权限方面需要考虑是否可以访问手机通讯录，相册，相机

（4）兼容性

小程序：基于不同的公众平台，主要兼容不同的微信版本

App：考虑不同机型的兼容，分辨率，屏幕尺寸，操作系统等....

如何做 app 兼容性测试的

（1）硬件兼容性：需要覆盖市面上主流手机厂家及各型号的产品

（2）操作系统兼容性：对app安装及卸载测试，测试app能否正常运行

（3）分辨率的兼容性：对主流设备的分辨率及屏幕尺寸，测试app界面实现及排版是否正常

（4）网络兼容性：在不同的运营商下，app是否能够正常运行，需要真机环境进行测试

“长连接”和“短连接”有什么区别？

（1）长连接（保持连接时间比较长）

一个HTTP连接的建立需要三次握手，握手成功后，才可以建立数据包传输，为了降低握手的频率，在接口请求头部connection为keep-alive，如果一段时间不用，服务器就会主动发一段探测报文，看看连接状态，如果探测不通，服务器端就会主动断开连接

（2）短连接（连接时间很短）

需要的时候才会建立一个tcp连接，数据传输完成就结束

http 协议有哪些响应状态码？

 （1）1xx（临时响应）：表示需要请求者继续执行操作

（2）2xx（成功）：表示成功

（3）3xx（重定向）

（4）4xx（客户端请求错误）

（5）5xx（服务器错误）

测试实例 

给你一个魔盒可以实现任何愿望，作为 测试怎么设计测试用例

 （1）功能

①说出不同愿望（钱+人+精神需求），看魔盒是否都能实现

②说愿望，只说部分关键字，看是否能正常识别

③不说愿望，看魔盒是否提示人许愿

④是否会有魔盒实现不了的愿望

⑤许愿次数是否有上限

⑥是否有许愿咒语

（2）界面：外表设计是否符合审美要求

（3）兼容：声音大小，是否影响魔盒接受许愿者的愿望

（4）性能：连续多次许愿后，魔盒是否还能正常使用

用户反馈功能很卡，要从哪些方面考 虑？

 （1）功能操作卡

①反馈提交的资源过大，导致请求慢

②服务器对于当前请求的人数过多，导致卡

（2）整个app卡

①网络异常

②app占用内存大，导致手机内存不足

③当前app与其他软件、手机系统不兼容

④服务器资源不足，请求慢

在测试“抖音直播”功能时，可以从以下几个方面进行详细的测试：

功能测试

目的：确保所有功能按照设计要求正常运作。

• 直播创建：测试用户是否可以成功创建直播，包括设置标题、封面图、分类等。
• 直播推流：检查推流功能是否稳定，测试不同设备和网络条件下的推流质量。
• 实时互动：验证直播过程中聊天、弹幕、礼物等互动功能是否正常工作。
• 直播结束：测试直播结束后的处理，包括保存直播记录、直播回放的生成和展示

给你一个微信上一个聊天的窗口你是 怎么测试的？

 

双十一抢券怎么测

 （1）抢劵设置是否正确，不同时间节点、优惠券类型，优惠券数量

（2）查看不同抢券时间点是否正常显示该优惠券

（3）测试优惠券不同状态，待开抢、正在抢、抢光了

（4）验证是否准点实现“开抢”按钮；抢到券显示抢券成功并能在我的优惠券页面查看，未抢到显示抢光了，并能正确回退到我的优惠券页面查看。

（5）后台是否记录到了每位抢券的用户相关信息

（6）一个用户id是否同一时间点、不同时间点抢多次券

说一下购物车功能，怎么测试呢?

说下模块的功能测试点怎么整理的？

 手机拍照功能怎么测试？

. 给你一个 N95 口罩你要怎么编写测试用 例？ 你讲一下登录功能，你会考虑哪些测试 点呢？ 你能说说 “ 支付功能 ” 怎么测试么？

印象中最深刻的 bug 吧 

发现问题背景

在外卖下单派送功能的测试中，我们发现了一个严重的 bug：在用户选择配送时间段后，系统没有正确地将配送时间应用到订单中，导致订单的实际配送时间与用户选择的时间段不匹配。这一问题可能会影响用户体验，尤其是当用户对配送时间有明确要求时。

测试过程

1. 测试步骤：

   • 登录应用：使用测试账户登录外卖应用。
   • 选择商品：从餐厅菜单中选择几种商品，并添加到购物车中。
   • 下单流程：进入结算页面，选择配送地址和时间段。
   • 提交订单：确认订单详情并提交。

2. 验证问题：

   • 订单追踪：进入“我的订单”页面，查看刚刚提交的订单详情。
   • 时间验证：检查订单的配送时间是否与用户选择的时间段一致。

在测试过程中，我们发现订单的实际配送时间与用户选择的时间段不一致，出现了预期与实际不符的情况。

排查过程

1. 重现问题：

   • 重复测试：多次重复以上测试步骤，确认问题的存在不是偶发的。
   • 不同时间段：测试不同的时间段选项，验证是否所有时间段都出现相同的问题。

2. 查看日志：

   • 系统日志：查看服务器和客户端日志，检查订单处理的各个步骤是否有异常记录。
   • 错误日志：注意日志中的错误信息，特别是与时间相关的错误。

3. 排查代码：

   • 检查前端代码：审查时间选择器的代码，确保用户选择的时间被正确地提交到后端。
   • 后端逻辑：审查处理订单的后端代码，确认时间选择是否被正确地接收和处理。

4. 数据库验证：

   • 数据库记录：检查数据库中的订单记录，确认实际存储的配送时间是否与前端传递的时间一致。
   • 时间字段：确保数据库表中相关时间字段的格式和数据类型正确。

5. 业务逻辑分析：

   • 时间处理：分析订单时间处理的业务逻辑，确保没有逻辑错误导致时间设置不正确。
   • 时间转换：检查是否有时间格式转换错误或时区问题。

验证过程

1. 修复方案：

   • 与研发讨论：将发现的问题详细报告给研发团队，协助他们分析问题根源并提出修复方案。
   • 代码修改：研发团队根据问题排查结果修复了代码中的时间处理错误，确保用户选择的时间段能够正确应用到订单中。

2. 重新测试：

   • 功能验证：修复后，重新进行相同的测试流程，确认问题是否已经解决。
   • 边界条件测试：测试各种时间段的边界条件，确保修复后的功能在所有情况下都能正常工作。

3. 用户验证：

   • 回归测试：在其他相关功能上进行回归测试，确认修复没有引入新的问题。
   • 用户反馈：在生产环境中监控用户反馈，确保修复后的功能在实际使用中没有再出现类似问题。

帮助研发的方式

• 详细描述问题：在问题报告中提供详细的步骤、日志和截图，帮助研发团队快速定位问题。
• 协助分析：与研发团队密切合作，分析日志和代码，提供必要的技术支持。
• 验证修复：在问题修复后，进行全面的测试，确认修复的有效性，减少反复修改的时间。

 

三、缺陷，bug

项目里，bug 都有哪些类型，以及哪些 地方容易出 bug？

（1）代码错误、界面错误、设计缺陷、配置相关、性能问题 （2）参数的校验，边界值，复杂的逻辑，异常的业务场景

如何提交一个高质量的 bug？

 （1）bug标题、bug模块、bug对应的版本、bug严重级别、bug详细现象描述、复现步骤

（2）唯一性：一个bug说明一个问题

（3）bug描述要前后一致，不能有歧义

（4）附带bug现象截图、报错日志

（5）bug不能带有个人观点，对事不对人

怎么定位是前端bug还是后端bug

（1）界面排版布局错误，兼容性问题，在网络不稳定下导致的js/css未加载完全或请求超时，也是前端bug

（2）对于数据或者逻辑处理上的问题，可以通过抓包工具fiddler，或者查看日志分析

①抓包工具：

检查请求地址、参数的正确性

不正确则为前端bug；

若正确进一步检查服务器返回的响应，若响应内容不正确，则是后端处理出错

请求和响应都正确，就是前端渲染响应的数据出错

②报错日志，分析日志里面的异常报错信息，查看数据库数据判断前端还是后端问题

开发不认同你的 bug，你怎么处理？

 （1）首先确认开发环境是否和自己的测试环境一致，缓存有没有清除

（2）看bug是否能够重现，级别低的bug先记录到平台，级别高的bug对应需求文档的预期结果跟开发说明，实在不行找产品确认

偶发性 bug，作为测试该怎么处理？

 （1）复现率低的bug，要提交，描述清除问题的复现步骤，环境，测试数据和日志信息

（2）如果未复现，在接下来的测试中，时刻保持关注，每次执行同样的或者相近的步骤时候，看能否复现之前的bug

（3）如果一直未复现，可暂时关闭bug，备注说明关闭不是因为修复，而是经过多个版本后不复现了

项目页面无法访问，如何定位问题？

 （1）判断页面的域名是否可以正常解析到

（2）ping命令判断服务器是否可达，如果不可达用trance route命令，查看一下是哪个节点出现问题

（3）如果不是网络问题，再去后台服务器查看服务进程有没有开启，数据库有没有开启

项目上线后发现的 bug，怎么 处理呢

 （1）当发现线上的bug，应该快速响应处理，先积极配合开发重现bug来定位问题，如果严重bug，需要积极解决，更新版本，如果bug不是那么严重，则放到下一个迭代版本中处理。

（2）总结bug出现的原因和规避方案

①测试用例覆盖不全面---》优化测试用例，增加用例评审

②测试的时间不充分，规划充分的测试时间，严格按照时间节点完成测试工作

③测试的环境或者测试的数据受限---》在真实环境下覆盖测试

④开发人员修复其他问题时，引入了新的bug---》明确测试范围，尤其是代码修改的功能部分，回归测试时，主流程必须回归，必须是一个完整流程

fiddler

如何构造弱网测试

（1）在fiddler中result右键customize rules，打开CustomRules.js文档

（2）修改文档中，每上传或下载1kb数据需要的时间来模拟弱网场景

（3）然后点击Simulate Modem SPeeds，开启弱网模拟

fiddler 断点有什么用？

 （1）主要是修改请求和响应的数据

（2）比如提交订单，金额是200，测试时想篡改金额，可以通过fiddler对before requests设置断点，修改请求数据，传一个520金额，检查服务端是否会正常处理。

（3）测试会需要返回不同的数据前端展示，可以after response设置断点，修改返回的数据查看前端实现效果

四、数据库

Group by 和 order by 区别？

（1）Group by是分组

（2）Order by是排序 

两者如果要一起使用的话，先分组后排序

mysql 中的 where 和 having 有什么 区别？

（1）where 子句中的条件表达式having都可以跟，而having有些 不行

（2）having子句可以用聚合函数（sum、count、avg、max），而where不行

数据库中的左连接、右连接和内连 接有什么区别？

（1）左连接（left join）显示左表所有数据及右表满足条件的数据，右表无数据则显示null

（2）右连接，则是显示右表的所有数据，及左表满足条件的数据，左表无对应数据则显示null

（3）内连接（inner join）显示左右两张表连接字段相等的数据

五、Linux

linux查看日志的命令？当Linux数 据过多时，如何查看自己想看的信息？

（1）查看日志命令，包括tail。head、cat、less等

（2）如果过多，可以通过tail -f查看实时日志 ，也可以加上grep错误关键字来过滤

（3）如果操作报错，使用ctrl+c结束日志打印，依据操作时间找到exception关键字后面的报错信息

在 Linux 系统下如何部署测试环境？

（1）开发会基于部署文档构建新镜像生成一个压缩包

（2）测试把压缩包传递到测试服务器，直接加载镜像，然后docker run 运行容器，并映射tomcat端口8080，mysql端口3306，以此完成测试环境部署

linux 下编辑文件常用的命令有哪些？

（1）vi或者vim，可以直接对linux文本进行编辑并保存 （2）sed，流式编辑器，以行为单位进行文本操作 （3）awk以行为单位进行文本编辑，也可以列为单位进行文本编辑 （4）cut对文本进行切割，以行为单位进行文本处理 （5）sort，对制定的文件按照一定的规则进行排序

查看进程的命令 ps，常用参数有哪些

 （1）-A，列出所有的进程

（2）-w，显示价款可以显示较多的资讯

（3）-au，显示较纤细的资讯

（4）-aux，显示所有包含其他使用者的行程

什么时候会用liunx定位bug?定位什么 样的 bug?

（1）一般用来定位后端bug （2）tail -f 日志文件名来查看日志 （3）容器部署，docker cp 【容器ID】：【容器内部路径】【linux路径】方式导出日志到linux，再通过xftp将日志导出到本地查看

标签：面试题,请求,是否,测试,自测,服务器,日志,bug,软件测试
From： https://blog.csdn.net/m0_62388400/article/details/142212903