1、你说的第一点，“线程数已经没有变化了”（这里我不太明白，因为 jmeter 是在开始的时候就要设置指定的线程数吗，这里设置了 30 个并发线程那肯定只能看到 30 的线程数）

jmeter 一样可以通过插件设定线程数上升策略的。一般压测策略，线程数应该是逐步上升，而不是一上来就达到最大值，这样更接近真实场景。

2、至于样本数的 failture，就是报的 connection time out

说明网络连接存在问题。

4、还有应用的 jvm 参数已经改过，相应增大到 2048m 没什么不一样，还是会出现这样 “暂停” 情况。所以当时就排除是应用 JVM 的问题。

你这个只是改了内存，jvm 还有很多参数的。比较明显影响并发性能的还有最大线程数。

5、后面做了测试，如果不使用域名进行压测的话，是不会出现样本数 “暂停” 的情况。直接对 IP 进行压测，不走 nginx 域名，直接压 ip，没什么问题。所以定位到 nginx 相关的一些配置问题，但修改 nginx 的性能配置还是没生效。目前还在调试排查中...

hmm，这方面信息超出你正文内容范畴了，没法给更好的建议，和运维保持沟通吧。

可以找下你所在城市的测试圈子问问，一般对质量比较关注的公司或者大厂，会有这些。

线上问题刨根问底这个你自己也可以做，不见得要找实现过的团队才能做。

从这 3 个图看：
1、出现这个情况的时候，线程数已经没有变化了，说明压测工具在全负荷运行，且每个线程都是收到返回后再会产生新的请求，即新的样本
2、从 tps 看，有出现 failture（原因图里没看到，不清楚），同时 response time 也挺大的（有不少在 3s 以上）。
3、没看到具体脚本内容，不确定有没有集合点之类的东西。

根据上面的信息分析：
1、样本数没增大说明存在等待，而结合上面说的第一点，等待的原因有可能是在等待服务端的返回，也有可能是脚本本身有等待类逻辑（常见的有集合点）
2、如果是服务端在等待，且楼主说了物理资源消耗不大（CPU、disk 不大，内存和网络未知但一般不至于出问题），可以排除是服务器本身物理资源不足，但有可能是分配给程序的资源不足。这个可以看程序相关的监控（如 java 应用的话，看 jvm 参数）
3、楼主图一有提到当样本增加停止时，被测服务的 cpu、tomcat 也下降，如果确实如此的话，说明样本增加停止时压力是降低了，有可能不是服务端处理慢（这种情况下资源消耗不应该下降），而是压测工具自己在等待。这个需要具体分析脚本里有没有什么 wait 相关逻辑（比如集合点之类的）

如果上面的分析思路都发现走不通，建议补充一些数据：
1、tps 图里面失败的具体原因贴一下
2、压测过程里，同一时间被测系统的相关监控指标曲线也给一下
3、整个脚本参数脱敏后发一下，看有没有什么和等待有关的配置

FluentWait 这个第一次知道，学习了。

这个看团队的代码规范要求吧。我们一般要求保持 set 方法的纯粹（毕竟没多少人会想到你在对象的 set 方法里做固定的数据转换操作），这类数据转换逻辑可以通过私有方法封装来避免和业务逻辑揉在一块，但不会直接改写 set 方法做转换。这种写法藏得太深了。

很有条理的总结，看得出楼主是个逻辑思维很强的人。提点小建议，感觉楼主的目标还是比较多的，而且 21 年基本都没达到。建议再聚合一下（比如 java 学习体系里加上一些 java 经典书籍的阅读；学习输出的文档也可以直接发布到自己公众号等地方），降低每个目标任务的完成成本？

另外，一个人独立完成特别容易因为情绪波动、工作压力太大等原因 “给自己放个假”，然后就不了了之。看楼主刚好也在带团队，可以看有没有志同道合的组个小群，每个周期要发自己的成果总结，这样倒推给自己每个任务一个周期性的小 deadline ，强制输出总结文档，避免自己松懈。

这个主要还是习惯问题。override 别人的方法前，要先了解清楚这个方法是干嘛的，override 是不是最佳实现方式，特别是 override 后原来已有的功能是否有重新提供，没有的话是否要通过调用原来父类方法来提供原有的能力。

看楼主这个 setattr 方法的最终实现，实际就是插入了个如果是密码就哈希后再写入的动作。这个动作为何要放在 orm 对象的 set 内部这么深的位置，而非在业务逻辑代码里写 account.password = hashlib.md5(password.encode(encoding='UTF-8')).hexdigest() ？

你可以看看 AgileTC ，开源的 xmind 用例管理平台。当时做得和这个差不多。

学习了。

不过，这个感觉还是指标不治本，只能更及时发现网络断开然后自动重连，但还是会低概率影响自动化执行？建议可以找运维沟通下看为啥 wifi 会连不上，解决一下，或者改为用有线网络。

很实用的功能，赞！

大致看了下，你说的这些问题，其实技术上都可以解决，只是需要多一些额外的兼容处理而已。

其实难点倒不是这些兼容处理，而是你的写法是不是团队的统一写法。如果每个人都有自己的习惯写法且差异较大很难统一，这个才是最难的。xmind 是很自由的，而很多传统的用例管理系统格式并没有这么自由，习惯 xmind 的团队很容易由于 xmind 的自由各自形成自己的写用例风格或者叫思维风格。这种风格本身和规范冲突还是比较大的，而且说实话，只要这种自由风格不会引起协作问题，其实也没太大必要去统一规范增加协作成本。

我之前呆过的一家公司，1.0 版本的用例管理是走 xmind 转传统用例格式的方式的，结果因为每个人风格差异太大且转换后没法类似 xmind 那样超级自由地编辑（互联网公司，执行用例的时候需求调整所以用例需要对应调整，非常常见），基本除了上传后自动统计用例数量和通过率数据有点用外，基本没人在上面直接写/执行用例。最后 2.0 版本直接改成在线 xmind 编辑，让大家基本不怎么需要调整习惯，才真正落地。

没在项目里用，因为 google 官方是用于 c++ 这类语言的，我们用 java 差异比较大，所以没有用。

学习了。

很详细的说明，感谢！

以前曾经做过类似的，规范 xmind 写法实现 xmind 转传统用例格式。但实际使用发现，要让大家的 xmind 格式统一非常困难。大家用 xmind 的目的是通过脑图减少用例中的重复编写成本，提高编写效率，xmind 更多是思路的体现，而非固定按传统用例的 前置条件 - 操作步骤 - 预期结果 这种写法。

好奇问下贵司这种强格式规范要求，实际推行的时候测试人员接受度高吗？

充满挑战的一年呀，加油！

自己试了一下，如果是在 venv 里面刚安装完 pandas ，直接用 pytest 运行，是会这样的。

解决方法：安装完后，通过 deactivate && source venv/bin/activate 退出并重新进入一次，就没问题了。

解决方法查找方式：用 bing 搜索 virtualenv pytest ，第一个 stackoverflow 的回答就是（虽然内容不大能对上，但原理基本一样，应该都是要重新进入后重新初始化一些环境配置）

你可以试试这个解决方法？

几个建议：

1、不是只有写平台才是技术，功能测试里面，多看看开发的代码怎么实现，项目用到的一些技术是什么，多了解各种线上疑难杂症背后的技术原因，也能得到一些技术上的提升（偏广度和视野）。

2、技术提升最快的不是你有更多的空余时间学习，而是你在工作中就在使用技术。可以看看团队里有没有类似这样的机会，尽量争取一下，这样深度会更好。如果团队限制实在没这样的机会，也可以考虑通过换工作获取这样的机会。

我重新看了下你前面 pip freeze 命令运行环境，命令行最前面没有 (venv) ，说明并不是在 venv 环境中执行。

你按上一层的步骤，在运行 source venv/bin/activate 进入 venv 环境后，再执行 pip freeze 命令看到底有没有装到依赖？没有的话在这个环境内用 pip 命令安装你所需要的依赖就好

那你得看看这个 app 的滑动解锁识别原理是啥，看是不是有什么特殊配置（比如要求每个点要停留一定时间之类的）。

那看来确实有依赖。把你完整的怎么启动 pytest 的方式发一下？详细到手把手级别，看是不是实际执行环境用的不大一样。

这个应该和新写法没太大关系。你这个滑动解锁人工滑动是要怎么滑的，正常滑完是什么样？你的坐标确认都有对到每个点上了么？

没看出哪里失败了？日志没有报错，左边截图也没提示解锁成功/失败什么的。

麻烦附上一个正确的结果，有对比才能看出哪里不对。

你是怎么调用 tidevice 的呢，一般这种情况发个 kill <进程id> 命令发送中断信号给进程，就可以关闭了。

电脑 ctrl+c、ctrl+d 这些本质上也是发送信号给进程。关于信号的详细信息，可以参考 https://www.jianshu.com/p/d7b96562d6ed

这个场景用 V*i 是不是更正规一些？看起来有点像是一些暴露内网端口给公网访问的招，容易有安全风险。