polelink面试（一面过）

01 对于JMeter接口测试，如何做接口关联？

接口关联的定义

关联的概念： 请求之间有依赖关系，一个请求响应数据作为另一个的请求参数来传递。
示例: 登录接口-下单接口
首先，登录接口返回包含用户身份认证信息的token，后续的接口需要附带上这个token才能被服务器识别身份。

JMeter关联方法

• 正则表达式提取器：提取任意格式的响应数据
• Xpath提取器：提取HTML格式的响应数据
• JSON提取器： 提取JSON格式的响应数据

正则表达式介绍

正则表达式：就是一个公式，或者说一套规则，使用这套规则可以从任意字符串中提取出想要的数据内容

公式格式：左边界(匹配符号)右边界：可以提取出想要获取的数据内
.：是通配符，可以代表任意字符（除换行回车）
.：是通配符，可以代表任意字符（除换行回车）
*: 代表前面的字符出现0次或者多次
.*匹配规则：找到左边界值后，往右查找有边界，找到最后面的右边界，中间的所有数据都被记录下来
?: 代表非贪婪匹配，找到左边界后，往右查找匹配右边界，只要有匹配的右边界就停止继续查找；再次查找
左边界和右边界

贪婪匹配和非贪婪匹配

假设我们有一个字符串 “abcde”，并且我们要使用正则表达式 a.e 进行匹配，首先是贪婪匹配，然后是非贪婪匹配。
1.贪婪匹配 (a.e)：
在贪婪匹配中，. 将尽可能多地匹配字符，直到最后一个 ‘e’。
2.非贪婪匹配 (a.?e)
在非贪婪匹配中，.*? 将尽可能少地匹配字符，直到第一个 ‘e’。

在这个例子中，无论是贪婪匹配还是非贪婪匹配，最终结果都是相同的，因为字符串中只有一个 ‘e’。但在包含多个 ‘e’ 的字符串中，贪婪匹配和非贪婪匹配的结果可能会不同。

案例分析

原始文本：
021-1234-1234
022-1234-1235
023-1234-1236
024-1234-1237
025-1234-1238
026-1234-1239
027-1234-1230
要求：匹配出 城市号、地区号、个人号码三组

正则表达式匹配：

(.*?)-(.*?)-(.*?)\n

通过一个正则表达式可以提取出多组数据，每组数据设置对应的左边界和右边界即可
每一组数据都可以有一个或者多个值

正则表达式提取器步骤

操作步骤：

1.添加线程组
2.添加http请求-传智播客
3.添加正则表达式提取器

• 引用名称：存在提取之的参数名称，比如title
• 正则表达式：左边界(.*?)右边界
• 模板：用$$引用起来，表示解析出第几个值
• 匹配数组：0表示随机取值，-1表示全部取值，1代表取第一个值

4.添加http请求-百度

• 引用正则表达式中的引用的名称。

• 线程组下添加http请求

• http请求下添加正则表达式提取器

• 配置http请求（传智）
  

• 配置正则表达式提取器（传智）
  

• 配置http请求（百度）
  

02 是否会写shell脚本，能对shell进行编程？

shell的定义

• shell

shell是一种编程语言，只是比较古老
liunx底层支持shell语言

• 脚本

本质就是一个文本文件，除了读写外，还可以执行
shell脚本就是shell语言编写的脚本，格式是.sh

• shell脚本的编辑和运行环境
  • 编辑：vim xx.sh
  • 脚本解释：高级语言需要被解释为二进制才能运行

# 如何指定shell脚本的解释器
#!/bin/bash 开头 表示使用Bash shell解释器##!/usr/bin/python3 表示使用python3解释器

写一个shell

shell脚本使用场景

开发小工具（重复性高）

服务器指标监控（cpu和内存）

#!/bin/bash# 获取当前时间
current_time=$(date "+%Y-%m-%d %H:%M:%S")# 监控 CPU 使用情况
cpu_info=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1}')
echo "[$current_time] CPU Usage: $cpu_info%"# 监控内存使用情况
mem_info=$(free | grep Mem | awk '{print $3/$2 * 100}')
echo "[$current_time] Memory Usage: $mem_info%"

1.获取当前时间：使用 date 命令获取当前的日期和时间。
2.监控 CPU 使用情况：使用 top 命令获取 CPU 使用情况，并通过 grep、sed 和 awk 进行处理，最终输出 CPU 使用百分比。
3.监控内存使用情况：使用 free 命令获取系统内存信息，并计算内存使用百分比。

将以上代码保存为一个脚本文件（比如 monitor.sh），然后给予执行权限：

chmod +x monitor.sh

然后您可以运行这个脚本来监控服务器的 CPU 和内存使用情况：

./monitor.sh

测试环境部署

#!/bin/bash# 检查依赖
echo "Checking dependencies..."
# 可以添加检查逻辑，如检查特定命令是否存在、检查文件是否存在等# 下载和安装软件
echo "Downloading and installing required packages..."
# 可以添加下载和安装软件的逻辑，如使用 apt-get、yum 等包管理工具# 配置环境
echo "Configuring environment..."
# 可以添加配置环境的逻辑，如设置环境变量、修改配置文件等# 部署应用程序
echo "Deploying application..."
# 可以添加部署应用程序的逻辑，如复制文件、解压缩文件等# 启动服务
echo "Starting services..."
# 可以添加启动服务的逻辑，如启动数据库服务、Web 服务器等# 运行测试
echo "Running tests..."
# 可以添加运行测试的逻辑，如执行测试脚本、运行测试用例等# 清理
echo "Cleaning up..."
# 可以添加清理逻辑，如删除临时文件、停止服务等echo "Deployment completed."

echo 是一个用于显示文本或变量内容的命令。它将文本或变量的内容输出到标准输出（通常是终端）。
该 Shell 脚本用于测试环境部署，包括检查依赖、下载安装软件、配置环境、部署应用程序、启动服务、运行测试以及清理工作等步骤。每个步骤都有相应的输出信息，可以根据需要添加逻辑和命令，以确保测试环境的正常部署和清理，最终输出部署完成的信息。

查看远程连接数

编写一个 Shell 脚本来查看远程连接数可以使用 netstat 命令结合一些过滤器和计数器来实现

#!/bin/bash# 使用 netstat 命令获取当前连接，并使用 grep 过滤出 ESTABLISHED 状态的连接
# 使用 wc 统计连接数，并输出结果
echo "Current number of established connections:"
netstat -an | grep -c ESTABLISHED

-a：显示所有的连接和监听端口，而不仅仅是那些处于活动状态的连接
-n：显示数字形式的 IP 地址和端口号，而不是将它们解析为主机名和服务名。
-c：用于计算匹配到的行数，并将结果输出为数字
ESTABLISHED：是要搜索的模式，这里表示搜索包含 “ESTABLISHED” 字符串的行。

将以上代码保存到一个名为 check_connections.sh 的文件中，并赋予执行权限：

chmod +x check_connections.sh

chmod: 是 Linux/Unix 中用于修改文件权限的命令。
+x: 表示为文件添加可执行权限。这使得文件可以被当作程序来执行。

然后您可以通过运行这个脚本来查看当前的远程连接数

./check_connections.sh

03 介绍一下你在测试流程各个环节的工作内容和细节？

测试流程

需求产生阶段

• 产品经理编写需求稿

会借鉴竞品是否有这样的功能，最后统计出最优设计方案。并在jira上提一个需求调研的产品任务（主任务）

• 产品经理召开产品需求评审会议

各个人员会议上要做点啥：
1、专业其他产品经理会提出哪些需求设计会更有吸引力，能让需求更好。
2、测试会提出哪些需求设计不合理，不美观等
3、开发会提出哪些需求设计是开发无法实现的技术难点，或者实现起来效果不好，或者哪些需求模棱两可，这些问题都需要产品经理重新设计。

• 需求稿交付给UI设计师和交互设计师完成设计

产品经理会画出原型图和交互稿
UI设计师和交互设计师建立自己的子任务进行设计

需求开发阶段

• 测试着手测试用例框架编写，开发召开开发方案评审会议

测试者会根据需求文档，原型图、交互稿等文档编写测试用例xmind框架，尽可能完善测试点。

• 开发着手写代码，测试着手完善测试用例并标记冒烟用例

开发评审会议结束之后，需要修改开发文档，测试则根据开发文档进一步完善测试点细节，然后在石墨上对照着xmind测试点完善测试用例，并从中间标记优先级为a的用例作为冒烟用例提供给开发提测前自测。

• 测试召开测试用例评审会议

测试召集负责本需求的开发，测试同事和负责该需求的开发要来一起在会议室评审石墨上的测试用例是否写全面，影响面是否评估全面等。

需求测试阶段

• 开发跑完冒烟用例，并提测，测试开始正式测试

开发代码已经完成，功能已经实现，在提测前需要进行冒烟用例执行，当作是自测，如果冒烟用例全部通过才能提测，提测时会在jira任务下备注已通过冒烟用例测试点，作为后续追责依据。

• 测试中可以验收bug，和继续后续其他需求的测试

验收bug，和对其他需求做测试

• 测试完后有的需求会写备份文档，有的需求会进行交叉测试，也有的需求不写备份文档和不做交叉测试

测试结束后，如果这个需求的坑比较多，或者测试数据比较多就开始写需求备份文档，记录这次需求注意点在哪里，记录核心要点和心得，记录测试数据等，一般大需求才会偶尔写写备份文档，作为后续新人的查阅资料。

• 测试通过后，自动化测试负责人执行CI进行回归测试

一些不能自动化的回归用例就需要轮流交给一两个测试来执行，最后执行通过后，有bug，就让开发修改后继续测试，没有bug就等晚上上线。

需求上线发布阶段

• 某个负责上线发布的测试，一键让测试环境的代码上线到正式环境中

由于之前开发和运维一起已经搭建好了一整套CD的系统，我们这边只需要一键部署上线即可，负责上线发布的测试一般是有着一定的CICD能力的人来负责上线发布的任务。

• 项目上线后测试依旧需要关注自己负责的模块功能

晚上九点上线后，大概十点左右，要看看自己模块的需求是否功能正常，处于对项目负责任的态度，实际上工作中很少这样去看，基本上不会出现差错，就算出现问题，也不能挽回了，就会给你头上记录一个线上bug。

总结

首先产品经理会完成需求文档，再召开需求评审会议，然后UI设计师和交互设计师会完成原型图和交互稿，后面召开迭代会议分配任务，然后开发写开发方案并评审，我去写测试计划，写测试用例再评审，开发执行通过冒烟用例就可以提测了，之后就是常规测试，发现 bug，提交 bug，开发改完 bug 后再验收bug，如果需求是大需求会进行交叉测试，当所有需求都测试通过后，会进行回归测试，最后是通过Jenkins，docker，k8s持续部署上线发布项目，上线完成后，我会再看看自己负责的需求是否有线上 bug,一切功能正常才算结束。