嗯，其实我建议用正则替换是有原因的，这类空格其实都满足正则里的\s:

所以用正则替换\s 为常用的空格 (chr(32)) 比较具有普遍性

其实很简单，你打印下下这两个字符串的字符 ascii 就可以看出不同了

a = "xxxx yyyyy"
for c in a:
    print(ord(c))

如果想要相同可以用正则替换掉对应字符

使用 UTC 就不用考虑这个夏令时了

OK

嗯，这个是常见思路。
其实可以用@jerrylizilong的方法，提前下好一些版本备用。因为 “墙” 的原因，chrome 更新和 driver 下载不是那么方便

一个脚本多端运行时需要考虑到部分运行端的 chrome 还是老版本的情况：
所以建议是先获取到运行端的 chrome 的版本号（大版本号，比如 103.1.201 就是 103），然后去判断是否有满足版本的 driver，没有的话再去下载。
比如 windows 端的 chrome 版本号可以从注册表中获取reg query "HKCU\Software\Google\Chrome\BLBeacon" /v Version

看完，就这个姑娘回答得很勤劳

这个时候，这个你画个数据流向流程图用例就可应付了
http://testerhome.com/topics/33072

大部分都是对公业务，非个人的居多，而且这些第三方的真实账户申请流程、准备的资料都很复杂，测试作为业务下游去搞很麻烦。

并且这个问题的矛盾点在于：
这种线上验证的真实账户该不该由测试来提供和申请？
是不是产品人员提供更合适，毕竟他们作为需求提出者、外部对接方和验收方？

性能只受 I/O 影响？你确定指数型正则解析不影响 I/O？
具体案例见二楼回复

那你认为的性能测试是什么？用个工具压一压？
错误的代码（这里是正则），会造成服务器或浏览器异常
这种类似白盒性质测试，会提前发现性能问题

至于正则造成的性能故障，有很多现实实例，比如：
https://zhuanlan.zhihu.com/p/456349063

不确定你认为的动态 sql 是怎样的，但 flask 中一般推荐 orm 工具 SQLAlchemy 集成。
如果想实现动态 sql 也简单，如下

query=db.session.query(x1,x2,x3).filter(公共条件)
if 情况1:
    query=query.filter(条件1)
if 情况2:
    query=query.filter(条件2)
rst=query.order_by(排序).all()

他换了个字（酔->醉），知乎上再来一波
https://www.zhihu.com/people/python-xiao-bai-92

还有知乎。。

我看过 kylinPET 的 HTTP2 的说明，说是 “在处理 HTTP/2 协议的 HTTP 的请求并发模型依据请求的父子关系，按照一定的算法进行并发”。
就是不知道这个工具内部是否利用多路复用特性，还是单纯的用并发来模拟

HTTP/2 情况下，不知道这个工具仿真能力怎样
有的工具支持 HTTP/2 协议，但不一定模拟多路复用。

另外，HTTP2 的压测工具需要解决几个问题：
1、端口复用问题，否则会造成端口使用完
2、客户端在 1 个连接中创建的 stream 上限（如 nginx 的 http2_max_concurrent_streams）
3、1 个连接的请求次数上限问题（如 nginx 的 http2_max_requests），达到上限，nginx 那边会切断连接，那压测端会不会自动做一些处理

针对你想少点代码写这个 70 个接口并发想法，我有个小建议：
LocustUser 的 Tasks 是个 TaskSet 的 list，可以尝试写方法将你的 70 个接口构造对应 TaskSet 放进去

我有个建议，可参考

那个 print 只会运行 1 次

这个是在 1 个 iframe 里面吗
（随便提一下，xpath 到属性@src的目的是？）

【一】部门负责的业务还是很复杂的，尤其工作流和对接第三方系统上面，这种用例已经得到普遍使用。
1-评审时，这种流程图用例比文字型更加方便大家理解业务流程流转，因此这种用例的评审大家提出的问题要更有效
2-执行起来还是比较高效的，能更快的 “断点续测”
3-领导检查时，很快清楚执行情况 (-_-!)
【二】流程图用例编写确实要比普通的用例花的时间多些，但说成本就不好说了，因为如果将 1 个流程图清晰的画出来而且没有矛盾、冲突，说明这个测试者对测试业务理解至少已经相当 OK 了，执行效率、给其他人传达就会更有效、省时间。
【三】如果有非常庞大的业务流程，建议按模块拆成多个子流程用例。
【四】特别要注意的是：多路径汇集后再多路径扩散时，执行时要注意多覆盖些情况 (通过备注说明已经覆盖的分支)。

locust 有个参数是可以获取响应的，再对响应检查就可以了
但这样会增加压测机的消耗，得看你实际情况了

觉得测试没技术，是觉得自己业务烂熟了吗，用例覆盖执行效率很好了吗，各种脚本工具都溜了吗。。。

为啥觉得没技术含量，熟练重复的东西觉得没技术含量。
开发的东西算技术吗，他们自己也会说没技术，熟练后 copy 改改而已。
架构师的东西算技术吗，经验丰富后也会觉得自己的东西没技术。

如果觉得没技术，但就多学习，多看看其他大厂分享经验

可能的原因是 jenkin 作为服务启动时，可能角色为 system：需要使用 admin 角色去显式启动（命令方式）jenkins 才行。

......这个是你自己挖的坑呐......

(//td)[1] 表示全部 td 中的第 1 个