题_通过调用接口设置1000个预置点-CSDN博客

首先，需求分析阶段，主要参与需求评审会议，阅读理解业
务需求，分析需求点。

需求确定后，进入测试计划阶段，参考软件需求规格说明书
及项目总体计划，进行测试计划编写。明确测什么，怎么
测，时间安排、人员任务分配，风险评估。准入准出规则，测试策略

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

第四，进入测试用例执行阶段。我们需要搭建测试环境，执行冒
烟测试，进入正式测试；

并且将测试缺陷进行提交及跟踪。缺陷管理
经过多轮回归测试，直到测试版本结束。

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

2.给你一个产品你是怎么开展测试的？

首先拿到项目后，要先熟悉需求、原型图，了解被测功能和
各个功能的业务逻辑；支持哪些平台，有哪些不同的应用场景，是否需要考虑到稳
定性、性能等等。

针对以上需要测试的内容进行大概的测试规划，然后逐个细
化去设计测试用例。
整个过程中存在疑问的及时跟开发产品沟通确认。
开发提测后，按照用例执行测试，提交 bug，并有效进行回
归测试完成 bug 跟踪；
测试完毕后，及时汇报测试结果，输出测试报告

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

接口测试到底测什么呢?
1、先考虑接口的正常调用
按照接口定义，传递正确的接口信息，包括地址、方
法、传输数据，然后查看返回的响应结果是否正确、
数据库数据是否正确；
1）传递的请求数据覆盖有效类、边界值
2）返回的响应结果的每个字段都需检查，例如 code、
msg 信息
3）调用接口对数据库中数据的测试，增删改业务接口
调用需确保到表字段的正确性验证
2、考虑请求参数的错误、异常情况
1）请求数据输入异常值，例如空值、长度类型异常等，
接口能否正确处理且返回响应是否合理;
2）考虑业务约束，例如订单状态必须确认收货后才能
评价，调用非该状态的订单，进行评价

3）输入错误的参数名、多一个参数、少一个参数，接
口能否正确处理且返回响应是否合理;;
3、关注接口的安全性测试:
1)敏感数据，例如密码是否加密传输;
2)返回数据是否含有敏感数据，如身份证信息、完整
的用户银行账号信息等;
3)接口是否对传入的数据做安全校验，如用户鉴权
token 校验;
4)接口是否防止恶意请求，例如大量伪造请求接口致
使服务器崩溃;
4、最后关注接口的性能测试:
1）并发请求相同的接口,查看接口的处理情况，例如
插入了相同的记录导致数据出错，引发系统故障;
2）接口响应时间在用户可接受范围内;
3）对于业务操作频繁的接口做压测，监控性能资源，
确定最大的瓶颈点是否满足当前业务需要;

为什么会产生 ANR 这种情况呢？
【参考回答】
在 Android 里, App 的响应能力是由 Activity Manager 和
Window Manager 系统服务来监控的.,通常情况下产生 ANR 有
这么三个条件：
1.只有主线程才会产生 ANR，主线程就是 UI 线程；
2.必须发生某些输入事件或特定操作，比如按键或触屏等输
入事件，在 Broadcast Receiver 或 Service 的各个生命周
期调用函数；
3.上述事件响应超时，不同的 context 规定的上限时间不同
具备了以上三个条件，那么以下两个环境，就会产生 ANR 了：
1、5 秒内无法对输入事件（按键及触摸）做出响应
2、广播接收器无法在 10 秒内结束运行

3.编写测试用例的流程

1、熟悉并分析项目业务需求
2、依据功能模块划分，使用等价类、边界值、场景法等用
例设计方法，从功能性能兼容易用可靠安全这几个角度先整理功能正常的用例，再到功能中每一个操作的异常用例的覆盖，补充业务约束，及功能交互项、数据验证项等

3、每个功能模块分别写完用例后，从项目的业务流程考虑，是否都进行了用例的覆盖，没有进行用例补充
4、另外还补充到界面测试用例
5、编写完成后，提交评审

接口测试流程

1. 需求分析（产品经理产出的需求⽂档）

2. 接⼝⽂档解析（由开发产出接⼝⽂档）

3. 编写接⼝测试⽤例（将⽤例⽤ Excel形式表现）
单接口

正向测试： 必选，全选，组合参数

反向测试：功能数据参数异常

业务场景测试，尽量用较少的测试用例，覆盖更多的接口。
4. 编写接⼝测试脚本⼯具（postman）⽣成脚本代码（python）编写，⽣成脚本

5. 执⾏脚本，跟踪缺陷

6. ⽣成接⼝测试报告

7. （可选）接⼝⾃动化持续集成

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

web 测试和 app 测试，测试流程是一样的，测试类型都需要进行功能测试、界面、兼容、甚至性能和安全包括控件点
击、跟后端交互、跟数据库交互。。

后端服务器是相同的前后端都使用HTTP协议进行交互（也有部分APP用socket来交互）

但是，他们是有区别的，web：B/S 架构，通过浏览器访问。
APP，CS 架构，通过客户端操作。因此可以从四个方面来说
它的区别。
第一，系统架构方面，Web 端，需要安装客户端，只需
要通过浏览器就能访问的软件。软件升级只需要更新服务器；APP 的
话需要安装一个客户端才能
使用的软件，修改了服务端，意味着客户端用户的所有核心版本都得
回归测试一遍。需同步升级客户
端。
第二，客户端性能方面，web 一般只需要关注响应的时间。
APP，我们还要关注流量、电量、cpu、内存等占用。
第三，兼容性方面。web 是基于浏览器的嘛，所以兼容性主
要考虑不同操作系统下不同主流浏览器的兼容。 APP，基于
手机上的应用，我们需要关注不同厂商机型、操作系统、屏
幕尺寸分辨率，网络，应用等兼容性的问题。

app还有进行一些专项测试安装卸载升级交叉事件测试用户体验测试，push消息推送

5. 你是如何做 app 兼容性测试的？

app 的兼容性主要包括硬件设备操作系统、屏幕尺寸分辨率

还有网络的兼容性。
1、硬件兼容性，我们一般需要覆盖市面上主流手机厂家及
各型号的产品。可以在一些统计类平台，例如百度流量研究
院，获取最新的设备占有率排行，一般要考虑厂家情况进行
组合挑选。如果公司资源有限，则可以选择云测平台像 Tesin、
TX 的 WeTest 做辅助测试
2、操作系统的兼容性，我们需要覆盖市面上主流的操作系
统及其各版本，我们需要做 app 的安装及卸载测试，测试 app
能否正常运行，并对核心功能进行回归。
3、分辨率的兼容性。我们需要覆盖市面上主流设备的分辨率
及屏幕尺寸。这里主要关注的是 ui 对各种分辨率、各种屏
幕尺寸的设备情况。需要测 app 的界面显示及排版是否正常。

分辨率：1080x1920、720x1280
4、网络兼容性。在不同的网络制式、运营商下，app 是否能
够正常运行，这块需要用真机环境进行测试。需要连接个主
流网络运营商提供的网络去测。

5.应用兼容性：与手机硬件兼容包含home键、电源键、音量调节等

与外部硬件设备兼容耳机、蓝牙等

与操作系统软件兼容wlan设置、系统时间调节、LBS定位等

与其他APP兼容后台在播放音乐时，进入动态页面点击动态视频的播放，系统如何处理

5. get 和 post 方法有什么区别？

1、get 请求的参数是放在 url 里面，而 post 请求的参数是
放在请求体里面的
2、get 请求呢可以被浏览器缓存，而 post 请求时不能被缓
存的。
3、get 请求参数因为放到 url 里面，而 url 的长度是受限的，
它最大就是 2048 个字符；而 post 的长度是没有限制的
4、同样是因为 get 请求的参数放在 url 里，所有安全性是
比较差的；post 请求的参数呢放在 body 里，安全性相对就
好一些了
5、get 请求可以通过浏览器直接访问，支持刷新和后退。
post 请求呢，是不能被浏览器直接访问的，刷新后台数据需
要重新传送。

get也可以提交数据

常用的元素定位方式

常用的元素定位方法有八种，分别是：id、name、class name、
tag name、link text、partial link text、xpath、css
selector。

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

第 1 种通过抓包工具，检查请求地址、参数的正确性，
1）若不正确，则为前端 bug；若正确则进一步检查服务器返
回的响应，若响应内容不正确，则是后端处理出错；
2）若请求、响应都正确，那就是前端渲染响应的数据出错，
则前端 bug

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

项目上线后发现的 bug，你们会怎么处理呢？

当发现线上的 bug，项目组应快速响应处理，先积极配合开
发重现 bug 定位问题；如果是严重 bug，则需积极解决，更
新版本；若 bug 不是那么严重，
一般会放到下一个迭代版本中处理。然后，更重要的是经验
总结，反思 bug 出现的原因和规避方案。

总结一下常见的线上 bug 原因及规避方案：
第一，测试用例覆盖不全面，尤其用户不可控的使用场景，
导致出现漏测。解决方案：优化测试用例，增加用例评审。
第二，测试的时间不充分，导致一些次要功能点在测试的过
程中被忽略。解决方案：规划充分的测试时间，严格按照时
间节点完成测试工作
第三、测试的环境或者测试的数据受限，导致了测试不到位。
解决方案：考虑 mock 测试，或者在真实环境下覆盖测试
第四，开发人员修复其他问题时，引入了新 bug。解决方案：
明确测试范围，尤其是代码修改的功能部分。回归测试时，
主流程必须回归，必须必须一个完整流程。

Group by 和 order by 区别？

增删改查基本都会用；包括单表查询多表关联查询，左连
接右链接等

Group by 是分组，一般需要进行一些数据统计的时候，比
如一个群体里最大数据、总数、数量平均数等都会用到分组；
Order by 是排序，就按照升序或者降序排列的；
两个如果要一起使用的话，先分组后排序，先 groupby，后
order by。

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

URL 地址的长短，只能算是长链接和短链接，带绞丝旁的‘链接’
长连接，其实是说的保持连接时间比较长。一个 HTTP 连接的建立需要三次握手，握手成功后，才可以建立数据包传输。为了降低握手的频率，提高数据传输效率，我们会经常在 HTTP1.1 版本的接口请求头部看到 connection为 keep-alive，保持连接，这就是典型的长连接。另外，
websocket 协议，也是典型的长连接协议。
建立了一个长连接，如果一段时间不用，服务器就会主动下发一段探测报文，看看连接状态，这就是我们常听到的‘心跳’；如果探测不通，哪服务器端就会主动断开连接。这个‘一段时间’是多长呢？是可以配置的对于功能测试，你掌握这些就够了，但是性能测试，就还需要知道，一个长连接会占用服务器一个连接数，客户端一个端口，长连接多了，就会影响整体性能的。
而短连接，可以理解为保持连接的时间很短，需要的时候，才会建立一个 tcp 连接，数据传输完成，就挥挥手，saybyebye 了。

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

linux 查看日志命令，包含 tail、head、 cat、less，more 等，
那日志内容比较多，怎么获取自己想看的日志内容呢？比如
tail -f 查看实时日志，第 1，可以加上 grep 错误关键字
来过滤。
第 2，如果操作报错，在日志中会看到有比较明显缩进，也
可以直接 ctrl+c 结束日志打印，依据操作时间找到
exception 关键字后面的报错信息，差不多就是你报错的信
息
另外，如果文件比较大，打不开，你也可以 tail -n 1000 日
志文件 > error.log，获取日志中最后的 1000 行日志到
error 文件中，然后再打开定位自己想看的日志内容

赋权命令 chmod 777，3 个数字每一个 7 代表的什么权限？

7 是表示对文件赋予读写执行权限
3 个 7 中，第 1 个 7 表示赋予文件拥有者的权限
第 2 个 7 赋予文件拥有者所在组的权限
第 3 个 7 赋予其他用户的权限

rwx421

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

1.测试计划是一个偏管理性质的文档，而测试方案是一个偏技术类型的文档；
2.测试计划通俗来讲就是解决【谁来做？】【做什么？】的问题，而测试方案是解决【怎么做？】的问题；
3.测试计划主要包含测试的目的与范围、角色与职责、资源及安排、风险与应对、测试标准等相关信息，而测试方案主要包含测试方法、测试环境与测试工具测试策略等内容。

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

常用的状态码有如下几种：
1xx（临时响应）：表示临时响应并需要请求者继续执行操作的状态代码。
2xx （成功）：表示成功处理了请求的状态代码。
3xx （重定向）：表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向。

4xx（请求错误）：这些状态代码表示请求可能出错，妨碍了服务器的处理。
5xx（服务器错误）：这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。

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

1、用的地方不一样
where 可以用于 select、update、delete 和 insert 语句中。 having 只能用于 select 语句中

2、执行的顺序不一样
where 的搜索条件是在执行语句进行分组之前应用
having 的搜索条件是在分组条件后执行的
即如果 where 和 having 一起用时，where 会先执行，
having 后执行

3、子句有区别
where 子句中的条件表达式 having 都可以跟，而 having
子句中的有些表达式 where 不可以跟；
having 子句可以用聚合函数（sum、count、avg、max 和 min），
而 where 子句不可以。

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

白盒测试就是需要知道软件的代码实现逻辑，是一种基于代
码的测试；白盒测试方法包含 6 种：
（1）语句覆盖：每条语句至少执行一次重点在语句

（2）判定覆盖:每个分支都要执行一次，即 if 为真 if 为假
都要执行一次，重点在分支
（3）条件覆盖：要使每个判断中每个条件的可能取值至少
执行一次
（4）条件判定覆盖：同时满足判定覆盖条件覆盖。设计足
够的测试用例，使得判断中每个条件的所有可能取值(true
和 false)至少执行一次，同时整个判定结果（true 和 false）
也至少执行一次。
（5）条件组合覆盖：每个判断的所有可能的条件取值组合
都至少执行一次
（6）路径覆盖：程序中每一条可能的路径至少执行一次

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

一般是通过开发给的部署文档来部署，比如：项目运用到的是 tomcat 容器、mysql 数据库，那么
1）开发会基于 mysql5.7 镜像基础上，通过 Dockerfile 将所需要基础软件 tomcat、项目代码包、数据库脚本等构建成一个新镜像，然后生成一个压缩包提交到我们这边；

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

抓包工具有哪些以及有什么区别？

【参考回答】
1.比如你讲的 Fiddler，是开源免费，但是只能再 windows下使用，不支持 mac 和 linux；
2.Charles 支持 Windows、MacOS 和 Linux 操作系统，但是不免费；
3.Wireshark 可以抓取所有协议的报文，非常适合学习和分析网络协议；但是需要具备一定的网络基础，对于初学者有一定的难度；而且无法直接查看 https 协议报文
4.F12 最简单、最轻量级，作用面和强大性和其他的抓包工具还是有一定差距；
5.TCPdump 专门作用于 Linux 命令行的抓包工具，但是需要具备 Linux 操作系统能力

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

1:下载渠道及安装卸载不同（入口）
小程序：主要通过扫二维码、用户分享推荐、搜索小程序
等获取；并且不需下载安装，清除时直接删除小程序
APP: 需要去应用市场下载；并且安装后才能使用，清除时
需卸载。在部署时还需要进行专项测试安装卸载升级（部署）
2:开发周期及发布审核不同
小程序：一个版本可兼容不同的手机平台，小程序的开发周
期约 2 周；发布审核时周期较短
APP：支持的 android 和 ios 平台需分别开发，周期较长大
约 3 个月；且在各大应用商店发布的审核周期也较长
3：登录权限不同
小程序：一般授权微信登录，无需注册；例如微信未授权/
授权登录程序，同一微信号不同手机登录查看数据是否同步
显示；
APP：需要注册登录系统，权限方面需要考虑是否可以访问
手机通讯录、相册、相机等权限；
4: 兼容性测试方面：（兼容）

小程序：基于不同的公众平台，比如微信，主要兼容不同的
微信版本
APP：考虑不同机型的兼容，不仅要看分辨率，屏幕尺寸，
还要看操作系统

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

左连接（left join）是显示左表所有数据，及右表满足条
件的数据，右表无数据则显示 null。
右连接（right join）则是显示右表的所有数据，及左表满
足条件的数据，左表无对应数据则显示 null。
内连接（inner join）是显示左右两张表连接字段相等的数
据。

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

TCP 协议要建立连接的时候，需要经历三次握手的过程：
第一次握手：是客户端向服务器发起的，用来申请建立连
接的，这个报文中的 SYN （同步序列号）标志位标记为 1，所以我们也叫作
SYN 包；
第二次握手：是服务器回复客户端的，用来确认并接受连接
请求的，这个报文中的 SYN 位和 ACK（ACKnowledgment确认）位都标记为 1，所以叫
做 SYN-ACK 报文；
第三次握手：仍然是客户端发给服务器的，用来确认服务器
的回复消息，这个报文中的 ACK 标志位标记为 1，所以我们
也叫作 ACK 包。
这就是 TCP 协议的三次握手过程。

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

首先我会判断一下这个页面的域名是都可以正常解析到，避
免域名解析的问题；

然后，可以用 ping 命令判断一下服务器是否可达；如果不
可达，可以用 tranceroute 命令，查看一下是哪个节点出的
问题；
如果不是网络的问题，再去后台服务器查看服务进程有无开
启，数据库服务有没有开启。
这样子，基本可以找到问题所在。

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

1、首先它会进行 DNS 的域名解析；
2、建立 TCP 连接；发起 tcp 的三次握手
3、发送一个 HTTP 的请求；
4、服务器处理相关的请求并返回处理后的结果；
5、关闭 TCP 连接；
6、浏览器接收到服务器处理后的结果后，开始解析；
7、浏览器将解析后的资源进行请求，并对页面进行渲染呈
现给用户。

App 出现 crash 崩溃原因有哪些？

内存存管理错误：例如可用内存过低，app 所需的内存超过
设备的限制，导致 app crash。或是内存泄漏，程序运行的
时间越长，所占用的内存用尽全部内存，导致整个系统崩溃。
亦或是非授权的内存位置的使用也可能导致 app crash
2.程序逻辑错误：数组越界，堆栈溢出，并发操作，逻辑错
误。例如 app 新添加一个未经测试的新功能，调用了一个已
释放的指针，运行的时候就会 crash
3.设备兼容：由于设备多样性，app 在不同的设备上可能会
有不同的表现
4.网络原因：可能是网速欠佳，无法达到 app 所需的快速响
应时间，导致 app crash。或者是不同网络的切换也可能会
影响 app 的稳定性

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

TCP 协议完成了数据发送之后，就会断开连接，此时就需要
经历四次挥手的过程：
第一次挥手：是客户端向服务器发起的，用来申请断开连接
的，这个报文中的 FIN 标志位标记为 1，所以我们也叫作 FIN
包；
第二次挥手：是服务器回复客户端的，用来确认客户端的上
一个断开连接请求的，所以是一个 ACK 报文；
第三次挥手：仍然是服务器发给客户端的，用来告知客户端
服务器的数据发送完毕了，需要断开连接；这个报文中的 FIN
标志位标记为 1，所以也是一个 FIN 包。
第四次挥手：是客户端回复服务器的，确认服务器的上一个
断开连接请求，所以也是一个 ACK 报文；
这就是 TCP 协议的四次挥手过程。

TCP 协议和 UDP 协议的区别？

TCP 协议和 UDP 协议都是传输层的两个协议：它们的区别主
要有如下 3 个方面：
第一：TCP 是面向连接，就像打电话要先拨号建立连接一样，而 UDP 是无连接的，即发送数据之前不需要建立连接。
第二：TCP 可以提供可靠的服务，能保证数据传输无差错，
不丢失，不重复，且按序到达；而 UDP 协议只是尽最大努力
交付，即不保证可靠交付。
第三：因为 TCP 以上两个特点，所以对应传输效率相对较低，
而 UDP 效率高，所以一些注重速度而不在乎的丢包的场景，
会选择用 UDP 协议，比如 IP 电话，流媒体等。

App 测试中 iOS 和 Android 测试的
区别?

1、多分辨率测试，Android 端 20 多种，iOS 较少；
2、操作系统版本，Android 较多，iOS 较少且不能降级，只能单向升级
3、操作习惯：Android，Back 键是否被重写，测试点击 Back键后的反馈是否正确；应用数据从内存移动到 SD 卡后能否正常运行等；
4、push 推送测试：Android：点击 home 键，程序后台运行时，此时接收到 push，点击后唤醒应用，此时是否可以正确跳转；iOS，点击 home 键关闭程序和屏幕锁屏的情况；
5、安装卸载测试：Android 的下载和安装的平台和工具和渠道比较多，iOS 主要有 app store，iTunes 下载；

共同点都需要进行界面测试、功能测试、兼容性测试、网络测试、交互性测试、易用性专项测试、异常测试、安全专项测试以及权限测试

1.安卓是开源的Ios不开源因此安卓需要进行monkey测试，安卓更复杂一点，操作系统较多，ios版本较少并且不能降级。

2.安装卸载测试，应用发布后：下载安卓包的平台和渠道很多：豌豆英、应用宝、360手机助手等; iOS 主要有 App store、 iTunes，安全性会更高点

3.功能操作：上也会有细小差别，安卓有物理返回键，ios一定要有虚拟返回键，安卓可以没有，安卓手机针对每一款手机有不一样的操作;苹果手机操作习惯单一

4.开发语言：虽然同样的业务安卓和iOS的展示形式和业务一致，但是底层全完不一样，安卓的应用是有java语言实现的，iOS用OC实现。

怎么对含有验证码的功能进行自动化
测试？

1、让开发设置一个万能验证码
2、通过 cookie 绕过登录
3、自动识别技术识别验证码

如何用 jmeter 找出某个接口的最大并
发用户数？

可以设计一个阶梯场景，使用阶梯线程组，每隔一段
时间，自动增加固定量的并发用户数，然后，通过监
听器或监控平台查看运行结果，分析运行结果判断是
否达到了性能瓶颈，从而断定是否达到了最大并发用
户数区间，然后，再取这个最大并发用户数区间，缩
小固定递增步长，从而获得最大并发用户数。

说明：
在5秒内增加10个并发用户数，并运行60秒，再继续在5秒内增加10个并发用户数，重复循环，直至并发用户数达到100后，脚本持续运行60秒。然后在每1秒内减少5个并发用户数，直到减为0，结束脚本的运行。

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

1.GET 请求，主要用来获取数据和资源
2.POST 请求，用来发送数据给服务器，也可以创建或
者更新资源
3.PUT 请求，可以用来创建或者替换目标资源
4.PATCH，用于对资源进行部分修改
5.DELETE，用来删除资源

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

我们可以从 2 个方向考虑：是当前升级的这个功能操
作很卡、还是整个 app 操作都很卡？
如果是只反馈功能很卡，那可能原因：1）反馈提交
的资源过大，导致请求过慢 2)服务器对于当前请求
的人数过多，导致卡
如果是整个 app 操作都很卡，可能原因：1）网络异常
2)app 占用内存大，导致手机内存不足 3)当前 app 与
其他软件、手机系统不兼容 4）服务器资源不足，导
致请求过慢

你能说说“抖音直播”怎么测试么？

图片展示
1、功能测试
2、中断、网络测试
3、界面易用性测试
4、兼容性测试
5、安全测试
6、性能测试

双十一抢券怎么测？

UI：
界面设计布局排版是否符合设计规范
功能：
1、抢券设置是否正确：不同时间节点（例如 8 点、10 点、
12 点、2 点.... ）、优惠券类型(折扣、满减等)、优惠券
数量等
2、查看不同抢券时间点是否正常显示该优惠券，包括优惠
券类型、数量等是否都正确

3、测试优惠券不同状态：待开抢、正在开抢、抢光了
4、验证是否准点显示“开抢”按钮，抢到券显示抢券成功
并能在我的优惠券页面查看，未抢到显示抢光了，并能正常
回退到抢券页面；抢光了显示抢券数量是否跟后台设置一致
5、后台是否记录每一位抢到券的用户相关信息，例如用户
账号
6、一个用户 id 是否同一时间点、不同时间点抢多次券
中断：
抢券中，微信语音视频通话中断、低电量中断、网络中断等
是否正常
性能：
大并发量的用户进行抢券操作，系统是否稳定无异常

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

微信聊天框的主要功能就是发送消息和接收别人发过
来的消息。
消息的分类：纯文字，图片，文件，表情，语音、视
频，文字+表情
聊天的特殊功能：@符号，撤回功能，加好友功能，消
息重发，发红包，转账，发送位置信息、发送名片、
群聊等功能

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

你讲一下登录功能，你会考虑哪些测试点呢？

格式错误包含含有特殊字符，10位12位

. 你能说说“支付功能”怎么测试么？

依赖登录状态的接口如何测试？

常见的登录鉴权方式主要是 cookie、session、token；

使用工具，比如 jmeter；1）登录成功后响
应结果中包含 token 2）通过 jmeter 的后置处理器-
正则表达式提取器或者 jsonpath 提取器，获取登录返
回的 token 值，并存为变量 3）在需要依赖到登录
才能请求的接口中，去引用该变量

第二种：使用代码，比如用 Python。1）将调用登录
接口返回的 token 值，保存为为变量 2）在需要使
用 token 的时候，直接调用变量

response.json()。get("token")

beanshell后置处理器设置全局变量

一个活动页面，要求 1 秒钟能支持 1000
个访问请求，你如何做性能测试？

1 秒钟要支持 1000 个访问请求，就是 1 秒钟处理 1000
个事务，即 TPS 等于 1000，明白了具体需求之后

如果，我们使
用的是 jmeter，可以添加一个 ArrivalsThreadGroup，
然后设置 TargetRate 为 1000/s，其他设置随意，执
行性能测试。
然后，再通过性能监控，查看性能关键指标，判断是
否满足要求。
第 1 个，我们要看错误率，如果有超过 0.1%，我们认
为服务器不能满足要求；
如果错误率低于 0.1%，第 2 个，我们看响应时间有没
有超过 1.5s，如果平均响应时间超过了 1.5s，那这个
性能指标也不能满足要求；
如果没有超过，接下来看第 3 个，也就是服务器资源
使用情况。例如 cpu、内存使用；如果服务器资源超
过 80%，我们也认为不能满足要求。如果没有超过，
这个时候才能认为是满足性能需求。

登录接口做性能测试，要怎么准备登录
账号呢？

做性能测试，一般都会需要设置并发用户数，
首先我们要清楚被测系统是否允许一个账号重复登录，

如果不允许，那就需要准备远远大于你的测试时间*
并发用户数的一个账号数据。在 Jmeter 中，一般会
采用 CSV 数据文件去设置；
那如果允许一个账号被重复登录，那就比较简单，使
用一个账号，十个账号都可以，那在 jmeter 里面直接
使用用户定义变量来设置就好了

python 中列表和字典有什么区别？

列表和字典，都是可变数据类型；也就是都可增加、删除、修改元素。List.append

dict['a']=a如果有就更新没有就添加

列表是有序的，通过索引取值，可以存储任意数据类
型。在实际编程中，列表是用来保存多个相互独立对象的数据集合，而元组设计的初衷就是为了描述一个不会改变的事物的多个属性。华测教育
字典是由键值对来描述。键名唯一且为不可变类型，
值可以是任意数据类型。在实际应用中，一般存储一
个对象的相关信息，或者描述更复杂的数据信息

python 中列表和元组有什么区别？

列表和元组都是序列类型，都可通过索引取值，元素可是任意数据类型

1.列表可以修改，元组不可以修改，列表就相当于一个动态数组，而元组是一个静态数组。

2.从设计上说，列表是用来保存多个相互独立对象的数据集合，而元组设计的初衷就是为了描述一个不会改变的事物的多个属性。

3.然后列表的声明用中括号元组的声明用小括号，并且元组只有一个元素的时候需要在后面加逗号。

你说下数据库查询中，count(*) 和count(1) 和 count(列名)的区别？

执行效果上：
count(*)包括了所有的列，相当于行数，在统计结果
的时候，不会忽略列值为 NULL
count(1)包括了忽略所有列，用 1 代表代码行，在统
计结果的时候，不会忽略列值为 NULL
count(列名)只包括列名那一列，在统计结果的时候，
会忽略列值为 NULL，不统计
执行效率上：
列名为主键，count(列名)会比 count(1)快
列名不为主键，count(1)会比 count(列名)快
如果表多个列且没有主键，则 count（1）的执行效
率优于 count（*）
如果有主键，则 select count（主键）的执行效率是
最优的
如果表只有一个字段，则 select count（*）最优。

需要先登录才能调用的接口，用 jmeter
如何进行性能测试？

先确认下两个接口间是如何关联的，如果是cookie，我就添加 cookie 管理器来
关联，如果不是，那就通过关联技术，获取登录后的关联参数，给后面的接口，调试
通过后，再把脚本转换为性能脚本。

最简单的方法是，把接口都放在同一个线程组中，但是登录接口挂载在仅一次控制器
下面，其他的接口就正常的放在线程组下面，使用json提取器提取token然后在线程组中设计线程数和持续运行时
间，进行性能测试。

性能测试、负载测试、压力测试的区别

性能测试包括了负载测试、压力测试等；

性能测试是通过测试工具，找出或验证性能指标的一种测试。
负载测试是在性能测试前期阶段，完全不知道系统并发用户数等性能指标时，通过不断增加并发用户数的方式，找出系统的最大并发用户数区间的一种测试方法。
压力测试是在做了性能测试之后，需要验证服务器稳定性时，使用一定量的并发用户数对服务器进行一个比较长时间的性能测试，查看服务器资源使用情况。这个时间，一般是以小时或天为单位

JMeter 常用的几种断言方法

3 种常用的断言：响应断言、JSON 断言、断言持续时间。
1、响应断言：主要是对响应结果中的文本内容进行断言，比如响应结果是否包含指定的值，或者是否等于指定的值。响应断言可以适用各种返回类型的响应结果，如 Test 、 html 、 application/json 、application/xml 等。
2、json 断言：一般用于断言某个字段值是否等于我
们指定的值，所以 JSON 断言只能针对响应结果为
applicaton/json 格式的进行断言操作。

3、断言持续时间：通常用于做性能测试，一般用于检
查 HTTP 请求的响应时间是否超过预期值。而这个响应
时间是性能测试中常关注的一个性能指标。

局域网中两台 PC 互 ping 不通，可能原因有哪些?

1.ip 地址弄错了
2、网线没有接好
3、防火墙挡住了 ping 请求
4、交换机坏了
5、网络配置不对，比如 ip、网关、子网掩码
6、ping 服务被禁止掉了

Jmeter 的关联，会用到哪些方法去实现？

关联主要指上一个请求的响应数据需要提取，并传递应用到
下一个请求中，通常接口响应的数据，为 HTML、JSON 格式
的数据。
主要会用到正则表达式、XPath 提取器、Json 提取器、边界值提取器、BeanShell 来提取。
对于 HTML 的响应结果的提取，通常采用正则表达式或者xpath 提取；
对于 JSON 格式的数据，通常会采用 Json 提取器

beanshell用于跨线程设置全局变量

Jmeter、postman 接口测试工具的区别?

1、用例组织方式不同，Jmeter 的组织方式相对比较扁平，它没有工作空间的概念，直接是 TestPlan；而 Postman 组织方式也更轻量级，主要针对单个 HTTP 请求
2、支持的接口类型与测试类型上，jmeter 更强大，支持 Rest、Soap 等，不支持的也可扩展，可测试功能、性能、；postman主要测试 Rest 接口，测试功能

3.都可设置全局和局部

4、流程控制方面，Jmeter 可由 Switch 控制器等一系列控制器及 Beanshell 脚本实现流程控制； Postman 通过JavaScript 脚本控制
5、还有在结果解析及展示、断言、脚本扩展能力方面也有些区别

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

vi 或者 vim，可以直接对 linux 文本进行编辑并保存；

怎么保证测试质量

首先是需求分析这块，需求分析是测试质量的源头，从需求上来讲：
1.需求吃透，
2.有哪些关联模块，数据库有哪些关联点，涉及到的显性需求，隐形需求
3.做完需求分析要评审，防止有遗漏的地方，评审比较保险
4.多站在用户的角度去考虑，存疑的地方多跟产品，开发沟通，
其次测试用例方面：
1.用例执行要仔细认真，预期结果要检查到位
2.进行交叉测试，可以多个人，覆盖不同测试考虑点。
3.并严格按照公司的流程规范去执行，且执行认真对待
4.一定要做冒烟测试
Bug 回归这块来讲：
1.根据开发修改的建议，相关联的模块要回归一遍，bug 的本身要回归一遍，还要根据自己的测试经验，考虑一下开发没有考虑的模块

如何开展项目的性能测试？

1. 性能测试需求分析

2. 性能测试计划及方案

3. 性能测试用例

4. 建立测试环境

5.测试脚本编写/录制

6. 执行测试脚本

7. 性能测试监控

8. 性能分析和调优

9. 性能测试报告总结

软件的生命周期/一个产品从研发到上下的过程

客户提需求，然后产品设计原型图，开发编写代码，测试找bug与开发紧密配合，将发现的bug及时反馈开发修复后进行回归测试，到最后部署上线

冒泡

def bubble_sort(arr):
    n = len(arr)
    for i in range(n):
        for j in range(0, n - i - 1):
            if arr[j] > arr[j + 1]:
                arr[j], arr[j + 1] = arr[j + 1], arr[j]
    return arr

对测试的了解

测试的定义和目标：测试是为了发现软件中的缺陷、错误或不符合预期的行为而对软件系统或产品进行评估的过程

目标说明：质量保证：测试的主要目标是确保软件产品的质量，风险降低

测试的类型：功能性能兼容性易用可靠安全

流程，方法

重要性强调：测试是保证软件质量的关键环节，能够减少软件上线后的故障和维护成本，提高用户满意度和企业的声誉。例如，一个经常出现错误的软件会导致用户流失，而经过充分测试的软件可以增强用户的信任和忠诚度。

测试用例包括什么8大要素

用例编号，用例标题，项目/模块，优先级，测试步骤，预置条件，测试数据，预期结果

主要的用例设计方法，写测试用例的方法

常用的：等价类、边界值、判定表、流程分析法、错误推测法。

等价类划分法：等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果，等价类划分可有两种不同的情况有效等价类和无效等价类。

边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据

接口测试和平常的Ul测试有什么区别

其实这两者测试的侧重点是不同的，接口因为没有界面，更多考虑后台服务器对请求的，处理逻辑问题，业务交互，检测的是后台“容错机制”是否完整；而ui更多会去关注页面展示，数据转换，界面排序这些功能，当然也会后台数据处理的问题，ui测试其实已经包含了接口测试。系统功能的用例更全面，不仅有界面的，也有业务功能用例，还有其他用户场景的用例功能入口用例，流程用例，而接口测试主要根据各种入参场景来设置用例。

冒烟测试是干什么

冒烟测试主要是对软件的主体功能和核心业务流程进行快速的测试，目的是确认软件的基本功能是否能够正常运行，就像在检查一个机器设备通电后是否能初步运转起来一样。简单来说，是为了保证主流程能够跑通

测试报告主要包括什么

基本信息部分

测试人员与时间：
测试环境：

测试内容部分

测试范围与目标
测试方法与工具：

测试结果部分

Bug 相关信息：Bug 率Bug 严重程度分布Bug 复现率测试覆盖率
总结

测试用例用Xmind编写

bug管理工具，用过禅道吗

测试中遇到bug怎么办

概率性bug怎么办

首先，在遇到复现率低的 bug，一定要提 bug，描述
清楚当时出现问题的步骤、操作环境、账号及测试数
据、及必要的日志信息。

b.在发现 bug 时，要分析产生的原因，尽量多尝试可
能出现的步骤，排除环境和自己电脑配置的原因，比
如浏览器的版本等。甚至可以让开发对相应地方的代
码进行检查，看一下是否可以通过代码层面检查问题

c.如果未复现，在接下来的测试中，时刻保持关注，
每次执行同样或者相近的步骤的时候，看下是否能够
复现之前的 bug。
d.那些一直未能复现的 bug，需要测试经理定期将这
些 bug 汇总，选择优先级高的缺陷，组织开发人员和
测试人员专门投入到复现问题。如果经过这样的专门
复现依然不能复现，可以降低问题的优先级。
e、另外，项目发布后，跟踪至少 3 个版本，及时关注
用户的使用反馈，如果仍然无复现，可以暂时关闭该
bug，备注说明并不是因为修复关闭，而是经过 n 个版
本后不复现了。

你认为是Bug开发认为不是怎么办

首先确认开发环境是否跟自己测试环境一致（有时候
开发是在他们已更新代码的环境上验证 bug 的，所以
bug 就没出现，但在测试环境上面会出现；还要确认
缓存有无清除），确认在测试环境能重现，并且提供日志和截图如果确认
是缺陷跟开发保持有效的沟通，阐述用户影响角度,数据安全风险，强调功能关联影响

：如果是级别较低的建
议性 bug，可以先记录到 bug 平台，先保留沟通；如
果是 bug 级别较高的问题，对应需求文档的预期结果
跟开发说明，更有说服力；耐心讲解 bug 的危害，不
行就找产品确认，确认是 bug 注明情况并再次指派给
开发

这个项目的自动化测试写了多少条测试用例全面吗

压测是同时请求1000还是总共请求1000，每秒的压测速率是多少

记住密码功能保存到了哪里那样会不会不安全，为什么不安全

这种方式存在安全风险。一方面，本地存储有被攻击的可能。如果设备感染恶意软件，它可能会突破安全机制访问加密的密码存储区域。即使加密存储，黑客也可能利用系统或浏览器漏洞获取加密后的密码，再尝试暴力破解。另一方面，若有密码同步功能，网络传输过程中密码可能被监听窃取。即使是加密传输，加密算法也有被破解或密钥被偷的风险。而且，如果使用的是弱加密算法或者密钥管理不当，比如使用有安全漏洞的旧算法或者密钥存储在易访问位置，密码也容易被破解。另外，社会工程学攻击也会带来风险，比如用户在其他场景泄露相关信息，攻击者就能借此获取存储的密码。”

(1)cookie数据存放在客户的浏览器上，session数据放在服务器上
(2)cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
(4)单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。
(5)所以：将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中

输入框（50-100）怎么测试，边界值需要几组数据测

分页测试，有10个数据一页，现在不够10个数据，怎么才能测这个分页功能

页面刷新怎么测

qps,tps是什么

数据库聚合分组，索引

虽然索引大大提高了查询速度，同时却会降低更新表的速度，，因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件，建立索引会占用磁盘空间的索引文件。

主键索引 PRIMARY KEY，唯一索引 UNIQUE，普通素引 INDEX 组合索引INDEX，全文索引 FULLTEXT

linux查看当前进程，杀死进程，修改，删除

ps -aux 所有详细包含其他使用者的行程

为什么想干测试

测试具备的能力应该

测试在产品研发当中充当的角色

最讨厌和什么人进行工作，如果遇到了这种人你会怎么办

三个词描述自己并一一解释

mysql索引种类

主键索引 PRIMARY KEY，唯一索引 UNIQUE，普通素引 INDEX 组合索引INDEX，全文索引 FULLTEXT

mysql索引是干啥的

提高查询效率

端口可以变的吗

有的可以，http80,https443,tftp6

Linux一个虚拟机要复制东西到另一个虚拟机的命令

python一个数组中去掉重复的代码

list(set(list1))

post请求体可以写在url里面吗

可以

一个类似于qq音乐的app怎么测

一个类似于百度网盘的app要发送一个压缩包格式500M的文件怎么测试

发送天气请求怎么用jmeter测试

缺陷用例包含？

类似于微信聊天界面怎么测

怎么做接口测试的，用的什么工具

postman ,jmeter创建线程组然后输入ur

需求不明确怎么办

到一个新环境，给你一个新任务，会怎么做

描述一个模块怎么进行用例测试，测试点是什么

为什么做弱网测试

模拟弱网环境

fiddler断点作用

主要是修改请求和响应的数据。
比如提交订单，金额是 200，那么我们测试时想篡改下金额，
可以通过 fiddler 对 before requests 设置断点，修改请求
数据，传一个 520 的订单金额，检查服务端是否会正常处理；
又比如测试会需要返回不同的数据前端展示，可以 after
response 设置断点，修改返回的数据查看前端显示效果

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

一条 bug 信息至少需要以下几条：
bug 标题，阐述 bug 大体的内容；
bug 产生的模块；
bug 对应的版本；
bug 严重级别，优先级；

bug 详细现象描述，包括 bug 出现的操作步骤，报错
日志信息、bug 截图等等

提交高质量的软件缺陷记录需要做到以下几点：
唯一性。一个 bug 说明一个问题或者说明一类问题可
重现。
提供这个 bug 的精确步骤，要让开发人员容易看懂一
致性。
Bug 描述及所有信息要前后一致，不可有歧义完整性。

提高质量的做法：
能附带 bug 现象截图的就带截图，有报错日志的就贴
上日志信息客观性。Bug 描述不要带有个人观点，不
要对开发人员进行评价，对事不对人

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

一般是用来定位后端 bug，尤其是服务器类问题
可以通过 tail -f 日志文件名来查看日志，如果是容
器部署，也可通过 docker cp [容器 ID]:[容器内部路
径] [linux 路径]方式导出日志到 linux，再通过 xftp
将日志导出到本地查看；或者 docker logs -tf 容器
名查看日志

接口自动化测试过程中遇到的问题

1、接口断言的准确性
2、跨系统断言验证的阻碍
3、数据加解密
4、测试数据的更新与维护
5、测试用例的维护

局域网内，一台机器不能上网，而其
他机器可以，所有的机器都安装的 windows
系统，而且电脑都可以访问局域网内电脑，
是分析原因?

(1) 是否网关设置中对部分 IP 地址进行访问限制，
导致部分用户不能通过该网关访问外网。
(2) 先查看当前连接你这台电脑的路由器 WAN 是否连
接上了，检查路由器信号灯是否有闪烁
(3) 可能是路由器没有开启 DHCP
(4) 检查 IP 地址，是否是随意分配的地址，与其他同
事冲突了，可以设置成一个固定 IP 地址

遥控器怎么做测试

项目中扮演的角色/测试在产品研发中充当的角色

sql注入怎么判断

https都说很安全，那为什么用抓包工具能抓到，那还能说他是安全的吗

一个纸杯怎么进行测试

厦门美图秀秀

jmeter里面了参数有哪些需要测试

美图里剪辑测试利用等价类划分边界值分析

数据库的增删改

python进程线程

接口测试的慢链接注意什么方面

兼容性测试

图片和视频的格式

测试中bug要三天但经理说要2天怎么办

家里有重大事情没办法，但公司产品要上线怎么办

接口测试都测过什么

app性能测试有哪些，主流工具是什么

美图秀秀里面的美妆怎么测试

美妆里面有很多种类怎么测试，里面很多版块是否与实际的相同

简述项目干什么的

目前遇到的bug是什么怎么解决的

并发和并行的理解

并发是指在一段时间内，多个任务交替执行这些任务在宏观上看起来是同时进行的，但在微观层面，实际上是通过快速切换任务执行的上下文，使得多个任务在单个处理器（CPU）上交叉执行。就好像一个人在一段时间内同时处理多项工作，一会儿做这个工作的一部分，然后切换到另一个工作，再切换回来，以此类推。

并行是指真正意义上的同时执行多个任务，要求有多个处理器（CPU）或计算单元，每个任务都有自己独立的处理资源，可以在同一时刻独立地执行。这就好比有多个工人同时在做不同的工作，每个工人都有自己的工作空间和工具，互不干扰

在创建数据库时什么条件可以使用索引

查询

where后面添加什么索引会如何

用jmeter进行一个登录请求的测试的

用到的断言有哪些

pytest框架是做什么测试的

iso7层模型

应用层：网络服务与最终用户的一个接口。协议有：HTTP FTP

TFTP DNS 协议等；
表示层：数据的表示、安全、压缩的格式；
会话层：建立、管理、终止会话。对应主机进程，指本地主
机与远程主机正在进行的会话
传输层：定义传输数据的协议端口号，以及流控和差错校验。
协议有：TCP UDP 协议。
网络层：进行逻辑地址寻址，实现不同网络之间的路径选择。
协议有：ICMP IP（IPV4 IPV6）
数据链路层：建立逻辑连接、进行硬件地址寻址功能。将比
特组合成字节进而组合成帧，用 MAC 地址访问介质，错误发
现但不能纠正。
物理层：建立、维护、断开物理连接

tcp,ip在哪层，有什么区别

一个运输层，一个网络层，TCP 是用于在不同主机之间建立可靠的通信连接，保证数据在进程（应用程序）之间准确传输；IP 是用于在网络中寻找主机，将数据包从源主机路由到目标主机。

缺陷的生命周期

1、发现缺陷。由测试人员。开发也能知道自己哪里写错了，但是不会广而告之。
2、提交缺陷。由测试人员。开发更不可能提交Bug。
3、确认缺陷。一般由测试主管。或者质量保证（QA）、由产品经理进行确认。
4、分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、也可能是UI、也可能是产品经理。
5、修复缺陷。主要由开发修复，也有可能是产品经理修复问题，也可能是UI修复问题。
6、验证缺陷。测试去验证缺陷有没有修复成功。
7、关闭缺陷。只能是测试人员进行。否则出了问题，测试一律不背锅。

我的优点

最有成就感的事情

对未来的规划

如果面试成功来到公司的期望是什么

Myqsl情景题

你认为测试用例是最重要的吗

质量保证的基石，测试执行的指导手册，沟通协作的有效工具

但别的测试策略环境人员多种因素都很重要

如果开发认为不是紧急Bug但是你认为是怎么办

在项目中印象最深刻的事情，为什么印象深刻

如果要补充说明怎么查出来的，可以这样表述： “我曾遇两个典型Bug，收获颇丰。其一，在电商支付流程里，出现用户成功扣款但后台显示未付款、无法使用商品服务的情况。当时我们先从日志入手，仔细查看支付平台回调日志，发现部分网络请求存在超时中断记录，初步锁定是支付回调环节异常。接着检查后台代码逻辑，重点聚焦支付成功后的状态更新模块，经反复调试、模拟支付流程，最终确认是因网络波动导致支付回调请求丢失，后台系统对应更新付款状态的代码未正常执行，所以才出现数据不一致。

其二，是商品标价与实际支付价不符的问题。起初是接到用户大量反馈后开展排查，先是比对前端页面代码里价格数据获取逻辑，发现其从缓存调取价格信息，再深挖缓存更新机制，结合后端数据库价格变动记录，发现后端商品价格因促销调整后，前端缓存未及时同步更新，导致展示价格与实际结算价格脱节通过抓包，对比前端请求正确，然后检查后端返回结果，也符合要求，说明后端没有错误，就是前端渲染错误可以吗

。同时，梳理了从购物车到结算全流程价格计算逻辑，排除了中间环节计算出错可能，精准定位出是数据不同步引发该Bug。这些经历让我深刻领悟到多维度排查、深挖细节在测试工作中的重要性，往后面对新任务，我也会秉持严谨态度，不放过任何蛛丝马迹。”

从项目中学到了什么

如果在我的项目中来了一个新的测试会怎么想他介绍这个项目

对于搜索搜出来的页面是像列表一样会怎么测试这个功能

常用linux命令和作用

tail-200

tail-f a.txt|grep error

Ps -aux|grep httpd java/8080查看这个进程是否启动

top(监控程序执行状况)

free-m显示内存使用情况

来查看系统资源如果服务器出现故障时我们也会用（service httpd status）看下服务器是否启动，

服务器起不来，常见的问题有端口可能被占用，用 netstat-an|grep8080查看端口是否已被占用。

sql注入有哪些类型，怎么判断有sql注入

元祖和列表去区别

元祖想要改变大小怎么写代码

拼接或连接元组来 “增加元素”

如果你想在原有元组基础上添加新元素，可以通过拼接的方式来创建一个新的、包含更多元素的元组。示例代码如下
# 定义一个原始元组
original_tuple = (1, 2, 3)
# 要添加的元素，这里可以是单个元素或者另一个元组等
new_elements = (4,)  # 注意这里要是元组形式，如果是单个元素需加逗号
# 通过拼接创建新的元组
new_tuple = original_tuple + new_elements
print(new_tuple)

监控资源命令用到哪些

查着进程ps-ef

过滤添加grep来着

杀掉进程 kill 强制杀掉-9

监控资源top vmstat

磁盘 df-h

内存 free-m

发红包

以下是微信发红包功能的详细测试点： **一、功能完整性测试** 1. **红包类型测试** - 普通红包 - 验证可以正常设置红包个数（从1个到允许的最大个数）和单个红包金额（在系统规定的最小金额和最大金额范围内）。例如，检查能否发送1个金额为0.01元的红包，以及100个金额为200元的红包（假设微信红包最大金额单个为200元等限制）。 - 确认发送后，接收方收到的红包金额和个数是否与设置一致。 - 拼手气红包 - 测试能否正确设置红包总金额（在规定范围内）和红包个数。比如，设置总金额为10元，红包个数为5个，检查是否可以成功发送。 - 检查接收方收到的红包金额是否符合拼手气规则，即金额随机分配，且总和等于总金额设置值。 2. **支付方式测试** - 零钱支付 - 当零钱充足时，验证是否可以顺利使用零钱发送红包。例如，设置一个10元红包，检查零钱扣除是否正确，且红包发送成功。 - 当零钱不足时，检查系统是否会提示余额不足，并引导用户选择其他支付方式。 - 银行卡支付 - 绑定有效的银行卡后，测试能否成功使用银行卡支付红包金额。检查支付过程中的银行卡验证、密码输入（如果需要）等环节是否正常。 - 测试银行卡支付时的安全机制，如是否有短信验证码验证（如果有此功能）等，确保支付安全。 3. **红包发送对象测试** - 个人发送 - 可以从通讯录中选择单个联系人发送红包，检查发送后对方是否能及时收到通知，红包是否能正常显示在聊天界面。 - 验证发送给非好友的用户（在允许的场景下，如通过扫描二维码添加临时聊天等）是否也能正常发送红包。 - 群发送 - 选择群组发送红包，检查红包是否能在群聊中正常显示。对于不同类型的群（如普通群、家庭群、工作群等），确认发送过程是否一致。 - 测试在群成员较多（达到群上限等情况）时，红包发送和接收是否正常。 4. **红包消息测试** - 发送红包后的聊天记录 - 检查发送红包后，聊天记录中红包消息的显示是否正确，包括红包图标、发送者名称、红包金额或类型（普通/拼手气）等信息。 - 验证聊天记录中的红包消息是否可以长期保存，方便用户查看历史红包记录。 - 接收红包后的通知 - 当接收方收到红包时，检查是否会有推送通知（在用户开启通知功能的情况下），通知内容是否包含红包发送者和大致金额等关键信息。 **二、界面测试** 1. **发红包界面测试** - 布局合理性 - 检查发红包界面中各个元素（如红包类型选择按钮、金额输入框、个数输入框、祝福语输入框、支付方式选择等）的布局是否合理，是否方便用户操作。例如，输入框是否易于点击和输入内容，按钮大小是否合适等。 - 界面元素显示 - 验证不同红包类型选择后，界面元素的相应变化是否正确。例如，选择拼手气红包时，总金额输入框和红包个数输入框是否按照规则显示和交互。 - 检查输入金额和个数时，是否有合理的限制提示。如输入金额超过最大值时，是否会弹出提示框告知用户上限金额；输入个数超过允许范围时，是否有相应错误提示。 2. **红包消息界面测试** - 红包消息显示 - 在聊天界面中，检查红包消息的外观是否符合设计要求。包括红包的颜色、大小、字体等是否美观和易于识别。 - 当红包未领取时，验证红包消息是否有明显的未领取标识（如未拆开的红包图标）；领取后，红包消息是否会更新显示为已领取状态，以及是否会显示领取金额（对于拼手气红包）。 **三、性能测试** 1. **发送速度测试** - 在网络良好（如Wi - Fi环境下，带宽充足）的情况下，测试发送红包的速度。记录从点击发送按钮到发送成功的时间，检查是否在可接受的时间范围内（如一般情况下不超过几秒）。 - 在网络较差（如2G/3G网络，信号较弱）的情况下，同样测试发送红包的速度，检查系统是否会有相应的等待提示或超时处理机制。 2. **接收速度测试** - 对于接收方，在网络良好的情况下，测试从发送方发送红包到接收方收到通知并可以领取红包的时间间隔。 - 在网络较差的情况下，检查接收方是否能够最终收到红包，以及接收过程中的延迟是否合理，是否会出现接收失败的情况，若失败是否有重试机制。 **四、安全性测试** 1. **支付安全测试** - 验证发送红包过程中的支付环节是否采用了安全加密技术，如SSL/TLS协议等，以保护用户的支付信息（银行卡号、密码等）。 - 检查在异常支付情况（如支付过程中网络中断、重复支付操作等）下，系统是否有相应的安全处理机制，如自动回滚交易、提示用户确认支付状态等。 2. **红包领取安全测试** - 防止非授权领取 - 验证只有接收方本人（通过账号认证等方式）可以领取红包，其他人无法通过非法手段获取红包金额。 - 检查是否有安全机制防止恶意软件或黑客攻击，以窃取红包信息或进行非法领取。 - 红包有效期和退款安全 - 测试红包有效期过后，未领取的红包金额是否能按照规定安全地退回到发送方账户（如零钱或银行卡），退款过程是否有记录和通知。

到一个新环境安排了一个从来没有见过的新的认为你会怎么去做

怎么做弱网测试

首先保证手机与电脑在同一个网络，然后在手机上，设置代理服务器，指定服务器为装了华测教育专属 fiddler 的电脑的ip地址，端口为8888然后就是在fiddler上设置上行，下行速率,实现对发送

在 Fiddler 中 Rules 右键 Customize Rules ，打开
CustomRules.js 文档；
2、修改文档中，每上传或下载 1kb 数据需要的时间来模拟

弱网场景(剪辑右图)
3 、然后 Rules->Performance-> 点击 Simulate Modem
Speeds，开启弱网模拟。
通过以上 3 步就可以实现弱网测试场景的构造。

（蝉大师）黑盒测试和白盒测试区别

和开发人员有冲突怎么解决

如果开发那边主程序阻塞了测试不了，要怎么和开发沟通，如果开发人员没空搭理你怎么办，在此期间你可以做什么

什么事回归测试为什么要进行回归测试

回归测试是指在软件发生变更（如代码修改、功能增强、缺陷修复等）后，对软件进行重新测试，以确保修改没有引入新的缺陷，并且原有的功能仍然正常工作。简单来说，就是要验证软件修改后的 “回归” 是否符合预期，没有对其他部分造成负面影响

（）索引的作用

测试用例有哪些标题

数据库的模糊查询

like %_

jmeter接口测试的一个流程举例

（百词斩）项目怎么解决以前遇到的bug,举例说明

软件测试的作用

黑盒白盒

遇到bug怎么做

项目怎么进行测试的

怎么写测试用例

如何抓取手机的包

、开启 Fiddler的远程连接 Fiddler 主菜单Toos- Options-> Connections>勾选 Allow remote computers to

2、重启 Fiddler，更新刚开启的远程配置

3、然后手机和电脑需要在同一个局域网，抓取http手机设置代理就可以，要抓取https包，手机需要安装一个fiddler证书

1、fder 工具生成一个证书，发送手机上面安装

2、通过手机浏览器打开安装证书界面192.168.3.197：8888 ip 地址是用 fiddler工具的电脑的ip地址，fiddler工具端口号的8888 3、点击下载证书，会提示，输入手机锁屏密码 4、给证书命名，名字随意，其他默认就ok 5、点击确定，安装成功，然后就可以抓取https的包

http和https的区别

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

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

3.http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443 4.http 的连接很简单，是无状态的;Https协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

. https 协议比 http 安全，是如何
实现的呢?

https 协议通过 SSL 协议外壳来实现它的安全性，主要体现
在三个方面：
第一：数据是加密的，SSL 协议通过非对称秘钥分发的方式
完成秘钥的协商，然后通过对称秘钥的加密方式完成数据的
加密；
第二：会验证对方身份。服务端和客户端双方会需要向 CA
机构申请证书，再 SSL 握手阶段会验证双方证书是否可信，
从而验证双方的身份，防止第三方冒充；
第三：保证数据的完整性。每次的数据都会加上 MAC 摘要并
签名，接收的数据和发送的数据这个摘要信息一致的，就表
示数据没有被篡改过。

什么叫做对称加密和非对称加
密？
【参考回答】
对称加密是指加密和解密的用的同一个密钥；所以如果消息

加密了，消息的发起者和接受者，需要共用同一个秘钥，才
可以正常通信；这种方式效率比较高，但是秘钥分发不方便，
太容易泄露，所以安全性不高；
非对称加密是指加密秘钥和解密秘钥不同，这种加密方式用
到一对密钥：加密用公钥，解密用私钥；公钥所有都可以得
到，但是私钥只有消息接收者才有，所以只有他才能解密看
到真正的消息内容。这种方式要比对称加密安全很多，但是
效率会低很多。
所以，现在很多机制会采用非对称加密方法来进行秘钥的分
发，然后采用对称加密方法进行数据加密。

如果让你单独负责一个项目，需
要注意什么呢?
【参考回答】
1.首先，评估项目的测试范围和周期，能否单独完成，若不
能，及时反馈并协调人手
2.做好测试策略和计划安排，尽量保证每个环节按时完成

3.在上手测试前，梳理大致的测试点，先做冒烟
4.测试中，尽量通过一些技术手段提升测试效率
5.项目中，若碰到自己解决不了问题，要及时向外抛出并积
极寻求解决方案
6.及时对 bug 进行追踪，推动开发尽快解决 bug
7.把控发布标准，测试报告中标明上线风险

前后端数据怎么传输的

百词斩里面哪些地方是用的web端框架

（）负载测试压力测试

在项目中遇到的最困难的bug

遇到app闪退卡顿原因

用postman怎么做接口测试

jmeter50个人同时并发怎么写这个脚本

创建一个线程组，然后在http请求下面创建同步定时器，并使用聚合报告查看结果树监听器

一条缺陷记录都包含了哪些内容，如何提交高质量的软件缺陷记录

什么是回归测试，为什么在软件开发中如此重要

jmeter中的断言是什么，在测试中的作用

断言是让程序去判断测试结果与预期结果是否一致。作用是可以在requests的返回加一层判断机制，检测是否符合预期标准，确保测试与预期效果一致

负载测试压力测试稳定性测试

负载测试：是评估系统在不同负载下性能，逐步加负载，像模拟多用户访问网页，用 JMeter 等工具，看响应时间、吞吐量等指标变化，助于找瓶颈、验容量，为优化升级把关。
压力测试：把系统推到超设计极限负载，设高强度压力点，如远超正常并发用户数，监控其崩溃前表现、恢复力，查错看资源，评估风险，让我们知晓极端情况应对能力。
稳定性测试：测系统长时间运行及不同环境稳定性，定长周期，结合多种方法，用工具监控记录，分析性能波动、异常频次，确保长期可靠运行，为发布维护供依据。

cookiesesion和token验证的区别，cookie常见应用

什么事浏览器缓存

查找用户id,倒序排列展示前10个，查找名字重复的人名

有个进程占用了8888端口怎么看

netstat -anptu|grep 8888

自动化代码怎么做

自动化什么时候去运行的（回归测试）

接口主要做单接口？

令牌在自动化框架中怎么管理的

遇到手机号去登录的情况需要接受验证的令牌怎么做的（开发给的）

支付

python，一个而且网格，每个各格子代表一个字母，从中找出csig,找到返回true,但只能水平或垂直方向相邻格子查找，不能重复查找格子

（小米）

优惠券测试点

优惠券创建
基本信息：检查优惠券名称、类型（如满减、折扣、现金券等）、金额或折扣比例是否能够正确设置。例如，创建一个满 100 减 20 的优惠券，验证设置的金额和满减条件是否准确记录。
有效期设置：测试有效期的起始时间和结束时间是否可以准确设定，包括验证是否能正确识别和限制在有效期内使用。例如，设置有效期为 2024 年 11 月 1 日 - 2024 年 11 月 30 日，检查在 10 月 31 日无法使用，在 11 月 15 日可以使用。
使用范围：查看优惠券是否可以针对特定商品、品类或全品类进行限制使用。如果是针对特定商品的优惠券，验证只有购买指定商品时才能使用。
发放数量限制：检查是否能设定优惠券的发放总量和每人限领数量。例如，设定发放总量为 1000 张，每人限领 2 张，验证发放数量不超过 1000 且单个用户最多领取 2 张。

优惠券获取
手动领取：如果用户可以手动领取优惠券，测试领取按钮是否有效，领取后是否能正确添加到用户的优惠券账户中。例如，点击领取按钮后，检查用户优惠券列表中是否新增该优惠券。
自动发放：对于满足一定条件自动发放的优惠券，如购买特定商品后发放，验证购买行为触发后优惠券是否能及时发放到用户账户。
分享获取：如果有分享获取优惠券的功能，检查分享链接是否有效，新用户通过分享链接是否能够成功获取优惠券。

优惠券使用

结算验证：在购物结算过程中，检查优惠券是否可以正常选择并应用。例如，对于满减优惠券，验证满足满减条件时是否正确扣除相应金额；对于折扣优惠券，检查折扣是否正确计算。
部分使用情况：当购买多个商品，其中部分商品符合优惠券使用条件，部分不符合时，验证是否可以正确计算优惠券的使用情况。例如，购买 A 商品（符合优惠券使用条件）和 B 商品（不符合），检查是否仅对 A 商品对应的金额应用优惠券。
叠加使用：如果优惠券可以叠加使用，验证叠加规则是否正确执行。例如，一张满 100 减 20 和一张 8 折优惠券，检查先满减后打折或先打折后满减等不同计算顺序是否正确。
使用后状态变更：检查优惠券使用后，其状态是否及时更新为已使用，并且不能再次使用

优惠券查询与展示
用户端查询：测试用户是否可以方便地在自己的账户中查询到已领取、已使用和已过期的优惠券。查询结果的显示信息是否完整，包括优惠券名称、类型、金额、有效期等。
商家端查询：如果有商家端，验证商家是否能够查询到优惠券的发放和使用情况，包括发放数量、已使用数量、剩余数量等信息，以便商家进行营销分析。

性能测试点

高并发领取：模拟多个用户同时领取优惠券的场景，检查系统的响应速度和稳定性。确保在高并发情况下，优惠券的库存数量正确更新，不会出现超发的情况。
高并发使用：同样模拟高并发使用优惠券的场景，关注结算过程的响应时间。验证在大量用户同时使用优惠券结算时，系统能够正确计算优惠金额，不会出现系统崩溃或计算错误的情况
兼容性测试点
浏览器兼容性：检查优惠券相关功能在不同浏览器（如 Chrome、Firefox、Safari、IE 等）中的表现是否一致。包括领取、使用、查询等功能在各种浏览器中的操作是否正常，页面显示是否正确。
设备兼容性：针对不同的设备类型（如桌面电脑、笔记本电脑、平板电脑、手机）和操作系统（如 Windows、iOS、Android）进行测试。确保用户在各种设备上都能够顺利地领取、使用和查询优惠券。例如，在手机上操作时，优惠券的显示和使用是否方便用户操作。

安全测试点
信息泄露风险：检查优惠券的发放、领取和使用过程中，用户的个人信息（如账号、密码、联系方式等）和优惠券信息是否会被泄露。例如，通过抓包工具查看网络请求中是否包含敏感信息。
篡改风险：验证优惠券的金额、类型、有效期等关键信息是否容易被篡改。例如，尝试修改优惠券代码对应的金额等信息，检查系统是否能够识别并阻止非法使用。

用户体验测试点
界面友好性：评估优惠券相关界面（如领取页面、使用页面、查询页面）的设计是否符合用户的操作习惯。界面布局是否合理，操作提示是否清晰，使用户能够轻松理解和操作。
使用便捷性：测试用户使用优惠券的流程是否简单快捷。例如，在结算过程中，优惠券的选择和应用是否方便，是否需要用户进行过多复杂的操作。

工作流程

印象深刻的bug怎么去排查的

工作进度把控，自己的话日志，组长关注验收

小爱去打开爱奇艺测试点

（是否安装，同时安装几个他会不会并发，蓝牙，语音，方言，打字，环境嘈杂，通过小爱自定义昵称，不同的手机版本，爱奇艺版本，弱网，中断）

打电话功能怎么去测？

界面、功能、兼容性、易用性、安全、性能、异常。

）界面我们会测试下是否跟界面原型图一致，考虑浏览器不同显示比例，屏幕分辨率。 2）功能：给不同人员打电话，不同号码打电话，不同运营商，测试每个按钮是否正常使用，拨打号码，是输入还是，复制过程，还是其他地方跳转过来，多次拨打电话，双卡选择不同电话卡。 3）兼容性：不同手机型号，厂商，不同系统版本，屏幕大小，分辨率，内存大小 4）易用性：操作是否说的越多越好

给你一个杯子怎么测？

功能测试：主要关注水杯基本功能 1、水杯是否可以正常装水 2、水杯是否可以正常喝水 3、水杯是否有盖子，盖子是否可以正常盖住 4、水杯是否有保温功能，保温功能是否正常保温 5、水杯是否会漏水，盖住盖子拧紧后是否会漏水

性能测试： 1、水杯装满水时，是否会露出来 2、水杯最大使用次数

3、水杯的保温性是否达到要求 4、水杯的耐寒性是否达到要求 5、水杯的耐热性是否达到要求 6、水杯掉落时时，是否可以正常使用 7、水杯长时间放置时，是否会发生泄露

兼容性测试：主要关注水杯是否可以装其他液体，如果汁、汽油、酒精等

易用性测试：主要关注水杯使用是否方便 1、水杯喝水时否方便 2、水杯拿起放下是否方便，这里会行注到水杯形状的测试 3、水杯装水是否方便 4、水杯携带是否方方便 5、水杯是否有防清功能 6、水杯装有低温或者高温水时，是否会让手感到不适

安全性测试：主要关注水杯外观和各种异常条件下是否释放有毒物质等 1、当水杯装满热水时，水杯是否会烫手 2、当水杯装上水后，是否会产生有毒物质 3、把水杯放在零下环境时，是否会产生有毒物质 4、把水杯放在高温环境时，是否会产生有毒物质

可移植性测试：主要关注水杯放置环境等 1、将水杯放在常温环境中，使用是否正常 2、将水杯放在零下的环境中，使用是否正常 3、将水杯放在高于正常温度的环境中，使用是否正常

界面测试：主要关注水杯外观、颜色、设计等方面 1、外观是否完整 2、外观是否舒适 3、颜色搭配及使用是否让人感到舒适 4、杯子外观大小是否适中 5、杯子是否有图案，图案是否易磨损

图像上传功能的测试点

1.检查图片上传路径

2.检查图像上传和修改功能

3.检查各种扩展图像文件的上传（例如JPEG、PNG、BMP等）

4.检查文件名中含有空格或其他可用特殊字符的图片的上传

5.检查重复名称图片上传华测教育专属

6.图片尺寸大于最大允许值，上传时应该显示适当的错误消息

7.检查上传的图片文件类型外的其它文件时(例如txt、doc、pdf、exe等等)，应该显示适当的错误消息。

8.检查如果上传的图片满足指定的高度和宽度(如果有定义的话)则可以成功上传，否则不能上传。

9.上传大尺寸图片时应显示上传进度条

10.检查上传过程中的取消按钮是否有效 11.检查文件选择对话框中的文件列表是否只显示支持文件类型 12.检查上传多个图像的功能 13.上传后检查图像质量，图像质量不应该改变 14.检查用户是否能够使用/查看上传的图像

搜索框的测试

1)搜索按钮功能是否能够实现，验证搜索框的功能是否与需求一致 2)点搜索后，原先的搜索条件是否清空。 3)直看比较长的名称是否能查到输入过长查询数据，看其有没判断，报错系统是否会截取允许的长度来检索结果。 4)是否有忽略空格的功能，需要有忽略前置空格和后置空格的功能，但不能把中间空格忽略 5)不输入任何内容点击搜索看查询的结果 6)查看搜索框内的默认内容是否与设置的一致，焦点放置搜索框中，搜索框默认内容是否自动被清空 7)输入系统中存在的与之匹配的条件看其的查询后数据的完整性显示记录条数正确、文字折行显示正确页面布局美观列标题项、列显示内容、排序方式符合需求定义。 8)组合中文和各种特殊符号输入查看能否正确搜索到合的内容 9)输入系统中不存在的与之匹配的条件，是否搜索出信息或者给予提示信息 10)使用复制粘贴，测试搜索框是否能执行 11)注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方 12)反复输入相同的数据(5次以上)看是否报错

13)敏感词汇，提示用户为敏感词汇 { } 语句提1； }else{ 语句提2 华测教育专属 3.某个被调用的方法中缺少某些参数的定义，在不知情的情况下，直接调用时传递了未定义过的参数 or 类型不匹配的参数到该方法，如果对应网站是处理批量的业务，则可能会导致大面积的500异常页面，对网站正常业务和SEO排名损失风险比较大。 4.新增、编辑->保存，对所提交的字段有的末作非空限制，可以直接保存成功，保存后以空内容展示，可能存在不确定性，比如操作已保存成功的空记录时，是否会影响其他正常添加的记录，是相互独立的，还是会牵连到其他所有的类型。服务器配置错误(漏配or错配)，更新后出现500 or 404：华测教育

1.服务器配置文件，如 web.config中把前端访问的url地址写错，直接发布更新之后，前端页面访问可能会出现404错误。 2.程序代码中的某些逻辑错误和服务器配置相冲突时，前端页面触发某些特定按钮or页面可能会出现500错误。数据传递过程无控制，导致数据输出到界面功能异常or样式变形： 1. 搜索功能：有的页面本身有回显所搜索关键词的功能，搜索输入框填写的keywords字符较长 (如：100字符)，直接搜索后这些长字符显示在页面中，使得页面原来的样式变形，甚至有的功能按钮被挤到页面之外而不能使用。 2.新增功能：对于新增字段的长度没有任何限制，超长字符新增可以保存成功，回到列表页也没有对显示的字符长度进行控制，所有字符长度都展示在列表，挤压其他字段的 14)不同搜所的条件之间来回选择，查看是否出现页面错误 15)测试多个搜所条件时，要注意搜所条件的组合测试，可能不同组合的测试会报错 16)点击搜索框，看能否在搜索栏下方显示提供设置好的最近热门搜索词，点击任一可以直达搜索结果页 17)点击搜索框时，到有搜所历史时，能显示历史搜所内容，历史搜所内容应从上到下按时间排序，点击清空历史清空所有搜索记录 18)直看搜索框最大输入字符数