听起来有点像埋点，有多个数据入口，最终数据汇聚到少数几个出口进行查看。

然后你和开发争论的 “用例没闭环” ，具体你的用例大概是怎样的，开发期望补充的用例是怎样的？

这个要看具体情况吧。

如果流程不算复杂，但很重要，可以有少量用例去过一遍全流程，看是否能完全走通。这有点类似于单测和集成测试的区别，每个模块单独测试都没问题，但连在一起可能就会出问题。

如果流程很复杂很长，那就基于这次的改动范围设定好起点和终点的，只走一遍改动范围涉及的流程。

这么说可能比较抽象，你可以分享下你们的完整流程以及本次改动涉及的模块情况不？这样可以给到更有效的意见。

第一次听到说用例要闭环这个概念。

我觉得你们开发想表达的，是缺少联通起来的完整业务流程测试吧？只是用词可能不大准确。

Android11 获取不到屏幕流，原因是 stf 官方未维护 Android 28 以上版本的 minicap.so

解决：

1. 手动下载对应版本的 minicap.so
   https://github.com/varundtsfi/Android12Support_withso/tree/main/aosp

2. 推送到手机

   adb -s 设备id push 下载路径 /data/local/tmp/
   

俗话说抛砖引玉，楼主不先把自己的砖抛一下？

经排查，原因是因为匿名用户这个虚拟用户没有实名认证造成的。

现在已经调整逻辑了，改为验证操作人真实用户是否有实名认证，有的话就可以发布。

这些接口的请求参数也都变了

可以具体说下参数是怎么变吗？具体解决办法需要看变化规律决定。

如果变化是 1:1 的（比如 a 值变为 b 值，或者 key a 变为 key b），结构不变，可以考虑把值抽离到全局配置变量里，每次更新变量即可。
如果变化是固定 1:n 的，那也可以采用类似上面的结构，只是变量值变化会大一些
如果变化是不固定、无规律的（比如接口数量可能会变，参数结构也可能完全不一样），可能参考 2 楼的说法，基于日志或者代理进行录制，想办法降低编写成本比你拿老脚本适配更有效。

这个是语言特性造成的。

python 不是强类型语言，没有强要求指定每个变量的类型。实际上每个变量的实际数据类型都是可以随时变化的。比如可以随时把一个原来存储对象的变量改为存储 int。

这种情况下，按你图 1 里的写法， ide 是推断不出来你这个变量是什么类型的东西，自然无法做方法提示。能推断出来的方法，要不是在程序运行时（毕竟里面有具体的值了，instanceOf 一下就知道类型了），或者是熟悉变量实际类型的人。

python 3.5 开始提供了类型注解支持 来让 ide 可以推断出实际的变量类型。你这种类似字典取值的写法，实际内部调用的是 __getitem__ 这个魔法函数，要做到类型提示的话，可以试试自己想办法重写 wb 这种数据类型里的这个魔法函数，加上类型注解支持。

学习了。

看了下，这是个应用了 page object 后比较常规的写法，没啥大问题，用例数量少的情况下基本够用了。后续用例数量多了或者执行多了后，可按需补充更多的能力。比如：

错误排查相关：
1、失败允许自动重跑
2、失败时自动截图及 dump 控件树，便于排查失败原因。有全程录屏最好。

长期运行维护相关：
1、全局配置管理。比如用户名、密码、执行设备、appium capibility 参数这些。这些参数最好既支持读取配置文件，也支持命令行乃至环境变量传入，比较灵活。
2、appium 实例管理。比如后续放到 jenkins 上，可能会一个节点同时多个自动化在跑。而 appium 目前暂时不支持并行多 session ，所以需要自行管理多个 appium 实例，包括自动启动、自动分配空闲端口号、自动关闭进程、自动记录日志。
3、框架与项目分离。多个项目使用时会存在多个仓库，此时升级框架部分的公共能力会非常困难。必须要把框架的能力独立出来单独的包中，项目通过依赖的方式进行引入，这样才能具备更好的维护性。

看了下原文，感觉有点啰嗦。。。

一、如何重现 （操作步骤、预期结果、实际结果） 

二、环境说明（机型、账号、网络） 

三、现象截图或视频 

四、请上传日志附件

内容上，我觉得基本有这几个就差不多了。至于优先级、分配人、bug 状态这些，基本上大部分缺陷管理系统都有，不大需要特别强调。

我觉得最基本的，是提供足够让开发本地自行重现此问题所需的信息；进一步的可以通过日志甚至具体代码逻辑等，提供有助于开发定位及解决问题的信息；终极的话，直接附上修复 MR 给开发 review 。

最痛恨那些啥也不写，一图流的。除非有另外沟通过开发知道怎么回事，否则真的是一脸懵逼，别人想协助回归验证下，都看不懂是啥 bug 。

nginx 流量分配策略有好几种的，如果你不确定，先确认下配置的是哪种吧。weight 的话我理解只会按输入的流量去做分配，应该不涉及连接数或者请求数
你也可以查一下两个节点的日志打印情况，确认下 nginx 是不是 1:1 把流量分配到两个节点上。

最后，建议你还是具体了解下场景四的查询实现逻辑（最好直接去看代码，至少了解到能画出一个服务一个泳道这种级别的交互时序图），和前三个有什么差异点吧。不去了解具体逻辑的话，很难做原因分析定位的。

建议：
1、先通过 nginx 日志看看场景 4 里面，nginx 流量分配是不是还是均衡的。
2、放大一点 cpu 图，确认下是否同一个时间点，都是一个节点 cpu 高，另一个低。不要只看形状，得看具体时间点（前提是 2 个服务器的系统时间都是一致的）。
3、确认下场景四涉及的处理逻辑里，是否有用到分布式锁之类的控制并发的设计。如果有，可能拿到锁处理的节点 cpu 会高，其他节点在等待锁的就降下来了。

如果期望大家给到更好的建议，请补充更多的场景细节吧。现在只有个 cpu 占用情况，只能瞎猜。。。

如果是想转行软件测试，技术方面个人觉得差不多了。建议先想办法找个合适的岗位入行，去获取项目经验吧。

可以先了解清楚这个项目的目标，特别是质量目标情况。

时间特别赶的项目，一般质量要求会有所降低，甚至只要求能走通主流程便于演示。所以这种时候质量要求可以适当降低一些，只改影响主流程的 bug

只能说公司流程还有很大的提升空间。。。

问几个疑问：
1、测试用例有拉上开发和产品做评审，确保认知一致么？比如领导说主要功能能走通，哪些是主要功能，可以在用例里表确认下来，避免理解上的偏差。

2、测试之前向开发问清楚能测了吗 这个很奇怪，应该是开发确认能测了再提测给测试，测试冒烟通过就正式进入测试阶段，测试阶段发现的任何问题都当做 bug 进行记录，严重级别高的（比如阻塞流程导致无法测的）直接上升为项目进度风险告知整个项目组，一起想办法去解决。这玩意不应该测试问开发，而是应该开发主动告诉测试。

另外，进入测试阶段后，开发还会不断给新包是正常的。如果有建了 jenkins 自动打包的话，可以从 jenkins 构建信息里了解到这个包相比老包中间有什么提交，大概改了啥。回归测试时只需要测试有改动的地方就行，最后基本没啥 bug 了再做完整回归。

建议你的行动项里增加一个前置项：了解清楚压测的目的。

我说的新老对比，是假设目的已经明确是新老对比。你这里的目的至少从正文看，是不确定的。需要找给你分配任务的领导先沟通清楚这个目的，再做后面的事情。

方向不对，努力白费。在确认方向这件事情上不要含糊，不要凭自己主观推断，必须和任务分配人沟通清楚，最好是你自己按自己理解复述一遍并且分配人觉得没问题，这样来达成一致。要不后面事倍功半。

记录得挺详细的，点个赞。

关于你提的问题，按我目前了解尽量回答下：

1.梯度加压的最大并发量是根据什么设定的呢?还是 10-20-...100 递增或递减？

根据业务场景。比如秒杀场景，是一次性加压上去；如果是用户量逐渐增加的场景，一般是 10-20-30 这样增上去。梯度加压主要的目的是让系统的缓存机制能生效，这样压出来的结果相比没有梯度，会靠谱一些。

2.监控 CPU、内存使用情况：内存是一条横线，有什么意义？CPU 维持在 80%-90% 之间代表什么？

内存是一根横线，说明你这个场景里，系统资源里内存基本是一个相对恒定的值。CPU 保持在 80% 到 90% 说明 CPU 占用较高。综合看就是你这个场景下，系统进行的主要是计算密集型的逻辑。至于怎么判定这样的资源占用是否 OK，那就得结合你实际预计部署这个数据库服务的情况来判定了。

3.平均 Tps 为 7048.0%，对数据库压测来说是高还是低？（肯定比接口测试要高了）

首先，TPS 单位是没有% 的，TPS 是 Transactions per Second。至于是高还是低，需要你根据业务场景去评估，找项目组一起讨论沟通出一个基准值。没有基准值的情况下，这个很难评估。

附一个别人做得 mysql 的基准测试供参考：https://blog.csdn.net/qq_36357820/article/details/80079012

4.得到上述的压测结果后如何去进行分析？

性能分析的目标是找到什么原因导致性能没达到可满足业务需要的水平（目标值）。但你这里目标值都没有定下来，就直接去压，得到的只能是一个数据供以后参考（比如业务量增长到最后打到数据库 TPS 接近你这里的压测水平时，要考虑提前扩容啥的）。

5.我的测试场景是不是有缺失？测试步骤是否有问题？大家都是怎么做的？

首先，你的测试场景个人觉得是有点不够科学的。看似覆盖了增删改查 4 个场景，但里面没看出和这个 “数据库 mycat 分片” 的场景有什么关联。压测目的有点不大明确（到底是测试 mycat 数据库分片相比不分片性能提升的情况，还是测试新方案相比旧方案性能是否有提升，还是别的目的）。

如果是我，我会这么做：

1、先搞清楚压测的目的。个人理解应该最低要求是确认在典型业务场景中，新方案性能要高于旧方案，否则就没意义了。
2、根据压测目的设计测试方案。假如目的是上面说的新方案性能和旧方案对比，那首先需要评估实际业务使用上，数据库使用的典型场景是啥（最简单，执行频率 top10 的 sql 先拉出来看看，顺便也看看分片后 top10 的语句有多少获益），对应设计压测场景（频率高的、执行逻辑上会和分片关联比较大的，都需要纳入进来）。然后新老方案用一样的场景分别压一次，获取到两者的数据，再进行对比。

从报错信息看，报错的时候 jQuery 这个库应该还没初始化完毕，所以 jQuery 这个全局变量暂时还不存在。你可以配合增加一些等待页面加载完毕的函数（比如判断 document.readyState ）

另外，等待 ajax 结束我理解只是技术手段，因为除了 ajax 还有很多其他异步加载的手段。最终目的应该是等待某个你要操作的元素/控件加载完毕，再开始操作吧？如果是，可能对要操作的元素增加 selenium 的显式等待更合适一些。

PS：一楼这种评论让人反感，大家只是友情分享自己所知道的知识而已，没有义务或责任必须给你反馈的。而且工作忙起来没空回也很正常。既然是请教问题，请保持虚心请教的态度。

深有同感，要解决到绩效评估时评的很艰难的话，就得提前做好准备。

我的经验是不要等到评绩效的时候才关注大家的情况，而是日常就要关注，至少 1 个月自己盘一次，能梳理出一个绩效从高到低的排名。对于表现不是太符合预期的，及时进行沟通，避免到后面出 suprise 。

目前需要 @ 社区的管理员 申请，然后管理员会基于申请人的历史话题、回复情况进行审核，审核后开通建专栏的权限。

挺好的 bug 定位和思考，值得大家学习。

PS：千年虫实际上大部分系统都有做好提前防护了，也没有真正产生影响非常大的 bug 吧？

这不算卷吧，而是公司 Hold 不住了，要做精细化管理节约成本。所以光做效能不做业务的，都来做业务。

如果确实不想往业务测试负责人方向走，那就自己想办法跳呗（当然不推荐裸辞哈）。浑浑噩噩等赔偿这个，其实就是拿自己的青春前途去换那个不确定的裁员赔偿。到那个时候，你测开能力可能已经生疏了，也更难找测开的活了。

感谢支持，这其实也只是我个人的感悟，不一定绝对正确。能对大家有帮助就好。

嗯嗯，先适应点点点，然后再进一步熟悉吧。留意自己不要再进入前面这种 等着别人 的懵的状态就好。