在 UI 自动化过程中开启代理，并对指定 base_url 下的接口进行简单断言，比如：状态码：200；"success":"true"等
如果您想在 UI 自动化过程中仅对代理请求的接口进行记录并断言，可以使用 mitmproxy 库。mitmproxy 是一个强大的交互式 HTTPS 代理工具，它可以拦截、检查和修改 HTTP 请求和响应。

以下是一个简单示例，演示如何使用 mitmproxy 对请求进行拦截并进行简单断言：

首先，安装 mitmproxy：

pip install mitmproxy

然后，创建一个名为 myaddon.py 的 Python 脚本，包含用于拦截和断言的代码：

from mitmproxy import http

def request(flow: http.HTTPFlow) -> None:
    # 设置目标 base_url 和要断言的路径
    base_url = "https://api.example.com"
    endpoint = "/some_endpoint"

    # 检查请求的 URL 是否匹配指定的 base_url 和 endpoint
    if base_url in flow.request.pretty_url and endpoint in flow.request.pretty_url:
        print(f"Intercepted request to: {flow.request.pretty_url}")

        # 断言状态码是否为 200
        assert flow.response.status_code == 200, "Status code is not 200"

        # 读取响应内容并转换为 JSON 格式
        data = flow.response.get_text()
        json_data = flow.response.get_text(as_bytes=False)

        # 断言返回值中是否包含 "success": true
        assert "success\": true" in json_data, "Success key not found in response"

接下来，在终端中启动 mitmproxy，并加载上面定义的脚本：

mitmproxy -s myaddon.py

现在，当您运行代理时，它会拦截符合指定 base_url 和 endpoint 的请求，并进行简单的断言。您可以根据需要调整断言逻辑以满足特定需求。

基本上都是外包，拿到简历后也没约面试，公司招聘感觉很少，也没啥面试机会，坐标上海，不知道其他地方情况怎么样

1. 一方面可能因为个人的学历不太好，导致简历投了石沉大海
2. 另一方面可能今年确实没那么多需求了，去年大裁员，今年还撑得住估计不会这么快招人吧

跟五楼的意见一致，放在单独的线程组中才可以并发请求
测试计划中取消勾选独立运行每个线程组

那用例和缺陷不是得关联起来，有点好奇是手动关联的还是关键字匹配的呢
我理解的：
手动关联：比如在测试用例增加一列 bugid 之类的
关键字匹配：通过功能、模块名称分类（禅道里面可以区分，但是我们用的版本没法关联测试用例）

项目的甲方来验收的，也会有第三方的验收公司、监理之类的协助验收，验收不用一条条对，应该只是看个大概，毕竟 word 的测试用例可能得几百页

$__{setProperty(,auth_token,${auth_token})}
$__{setProperty(auth_token,${auth_token},)}
是不是这个函数入参错了，但是看下面两个是对的
三个参数：属性名、属性值、是否返回原始值（可忽略）

提供一个思路，可以看下是否能够符合你们的场景：参数随机生成不是很可靠，可以尝试从数据库方面对数据进行分析，了解下参数对应的数据库字段，在数据库里面分析历史的数据长度、类型，不同表的主外键，我们公司的测试数据都是从数据库中获取的，通过关联多张表拿到相关数据，提取到放到参数里面进行请求

Grafana 里面加一个服务器的性能监控，我用的 Prometheus 做的，可以一边压测一边看服务器的情况，应该稍微好分析问题

如果接口返回的数据是按照上传顺序排序的，可以考虑下面这个方案是否能够实现
创建一个线程组，放入上传图片接口，请求后提取返回结果，如果图片上传失败，通过 if 逻辑控制器进入 if 条件，if 条件执行：1）删除上传失败的图片；2）重新上传并再次提取返回结果；不满足的话一直执行，满足就跳出循环，然后整个线程组做一个大的循环，上传多少图片就循环多少次

这是不是意味着在生成百万级数据时，生成的数据放到文件中上传更好一点；如果更大量级的话，文件的读取可能会存在瓶颈，就需要使用其他办法了

以下回答来自 gpt3.5：
插入速度的快慢取决于多个因素，包括硬件性能、数据库引擎、网络延迟等。然而，根据常见的情况和经验来看，一般来说，插入速度从快到慢的顺序可能是：

文件导入：将数据存储在文件中，然后使用数据库提供的导入工具将文件导入到数据库中。这种方法通常是最快的，因为它直接将数据加载到数据库中，避免了一些额外的开销。
Python 批量插入：使用 Python 编写脚本，通过数据库连接库（如 MySQLdb、psycopg2 等）批量插入数据。这种方法通常比存储过程更快，因为 Python 可以通过批量操作减少与数据库的交互次数。
存储过程：使用数据库提供的存储过程功能，将数据逐条插入到数据库中。这种方法通常是最慢的，因为每次插入都需要与数据库进行交互，增加了额外的开销。
需要注意的是，以上只是一种常见的情况，具体的插入速度还受到其他因素的影响，如数据量的大小、数据库的配置等。在实际应用中，可以根据具体情况选择最适合的方法。

因为没有连接禅道数据库的权限 ，如果可以的话连接数据库获取数据确实是很高效的方法

多谢大佬建议，下次会尝试一下

json 解析效果还是不错的，日常基本够用；数据生成还是原汁原味的 faker，地址生成过于随机了，之前自己用的 faker 生成的数据也是这样，这个如果要改的话估计得自己单独写一个生成地址的函数
json 解析可以尝试下增加一个复制按钮，另外切换的时候不清除数据，生成身份证可以设置年龄区间，区间内随机
感觉有点搞头，加油

之前遇到过因为分辨率导致组件错位、界面变形、组件遮挡导致无法点击的问题

跟我的经历十分相似，我是 21 年 6 月份毕业后离开实习单位入职到现在这家公司，马上快两年了，从刚开始的功能到现在功能、性能、自动化都做，性能这块构建了规范的流程和相对完善的技术，负责过几个重点项目，自动化是跟着大佬学习的，跟领导同事关系也都不错，领导一直说提调薪，但是每次跟楼主情况差不多

微信小程序的 vconsole 可以尝试下
https://developers.weixin.qq.com/miniprogram/dev/framework/usability/vConsole.html

1. 字符型输入框：

（1）字符型输入框：英文全半角、数字、空或者空格、特殊字符 “~！@#￥%……&*？[]{}” 特别要注意单引号和&符号。禁止直接输入特殊字符时，使用 “粘贴、拷贝” 功能尝试输入。

（2）长度检查：最小长度、最大长度、最小长度-1、最大长度 +1、输入超长字符比如把整个文章拷贝过去。

（3）空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格

（4）多行文本框输入：允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）

1. 数值型输入框：

（1）边界值：最大值、最小值、最大值 +1、最小值-1

（2）位数：最小位数、最大位数、最小位数-1、最大位数 +1、输入超长值、输入整数

（3）异常值、特殊字符：输入空白（NULL）、空格或"~!@#$% 等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交。输入负整数、负小数、分数、输入字母或汉字、小数、科学计数法是否支持 1.0E2、全角数字与半角数字、数字与字母混合

（4）安全性检查：不能直接输入就 copy、SQL 注入

（5）对于必填项，先录入再删除是否可以提交成功；或者先录入错误数据再改为正确数据是否可提交成功 。

（6）录入小数然后全选，直接录入新值，是否可正常录入；（可能出现小数全选后无法直接填写新值）

1. 日期型输入框：

（1）合法性检查：输入 0 月，13 月，32 日等，闰年 2 月的处理方式等

（2）异常值、特殊字符：输入空格或空、输入~！@#￥%……&*（）{}[] 等可能导致系统错误的字符

（3）安全性检查：不能直接输入，就 copy，是否数据检验出错

1. 信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或 ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

2. 生僻字支持

3. 必填项校验

目前在使用的日报模板，数据统计模块只取需要的即可，希望有所帮助

项目名称：XXXXX 系统
项目任务：

1. 测试用例 XXXX 编写；
2. XXXX； 数据统计：
3. 系统提测功能：XX 个，已完成：个；测试进度：X%
4. XX 项目禅道 bug 总数：，已解决：个；未解决：个，bug 解决率：%
5. 今日提交 bug：个；已解决：个；未解决：个；bug 解决率：%
6. 今日回测 bug：个；已通过：个；未通过：个；未通过原因：
7. 今日需求测试：
   • 总共：个需求，已完成需求：个；未完成需求：个；需求完成率：%
   • 已测试：个；待测试：个；测试进度：%
   • 今日测试：个，通过：个；未通过：个，需求测试通过率：%
8. 测试用例编写（XX 项目）：
   • 共 __ 个模块，已完成 __ 个模块，测试用例编写进度：%
   • 编写测试用例：条
9. XX 项目禅道 bug 总数：个；已修复：个；修复进度：% 项目风险：
10. XX 功能冒烟测试不通过....
11. XXXX

文字有点错位，附图参考

1 个请求：
单机情况下：
并发：3000，持续运行 1 分钟，接口请求平均时间：238ms，发送请求：71707
循环：71707÷3000≈23.9 次，一次循环耗时 2.5s 左右

分布式情况下：4 台（假设分布式设置没有问题，4 台负载机压力均匀分布）
并发：750，持续运行 1 分钟，接口请求平均时间：155ms，发送请求：16906
循环：16906÷4÷750≈5.6 次，一次循环耗时 10.7s 左右

两者循环相差 8.2s，与同步定时器超时差 1.2s，考虑其他误差的话基本上问题就在同步定时器设置。但是如果分布式的同步定时器都设置成 750，就很难保证运行时做到 3000 并发，这个需要考虑下

不确定这种计算是否是正确的，可以试下