我觉得还有一个很重要的能力，说服别人或者推动事情的能力。

比如一些开发觉得不是 bug 的 bug ，需要有技巧地快速沟通解决。

OK，理解。确实要做完整平台还有比较多配套的东西，而且不见得通用。

建议可以先按 3 的，分享下案例，这样后续大家使用的时候可以少走弯路。

vue3 里，computed 也可以加 setter 了：

https://v3.cn.vuejs.org/guide/computed.html#%E8%AE%A1%E7%AE%97%E5%B1%9E%E6%80%A7%E7%BC%93%E5%AD%98-vs-%E6%96%B9%E6%B3%95

如果你的场景下，计算出来的新属性和原有属性之间并不是强关联（任意一边变了，都需要另一边立即响应产生相应改变），那用 watch 更好，提供的操作会更自由。

挺不错的工具，思路上我觉得很认可，通过工具协助大家熟悉代码细节，挺不错的，而且解决了 jacoco 无法区分调用者，以及远程调试加断点会影响其他人使用的问题。

有几个疑问，想确认下：
1、标题提到有 影子数据库 ，这个正文好像没见到，具体大概是怎么用，原理是怎样的？
2、目前提供的数据，如果不进行二次加工（比如结合代码编辑器着色），其实用起来体验会比较差。楼主有计划后续进一步完善查看数据这部分体验么？
3、楼主在实际项目中应该有进行实践落地吧，后续是否可以分享下这方面的一些案例，方便大家学习下？

从你用过的技能点来说，基本上测开需要掌握的你大部分都有掌握。但在技能点之外，测开的软能力方面没有看到相关的体现。

建议：
1、“丰富的测试经验”!=“很久的测试经历”，可能 1-2 个大型复杂项目的测试经历，就可以给你带来丰富的经验了。

2、代码能力并不是只能用来做开发，也可以用来理解被测应用的实现逻辑。不知道你在测试前是否有花时间去先看看开发整体技术方案是怎么实现的，然后根据你的代码经验，评估什么地方风险比较大需要重点测，什么地方风险不大过一下流程即可，来提高测试效率？有代码能力的前提下去看开发代码，既能帮你熟悉开发逻辑，也能让你了解别人的好代码怎么写的，性价比很高。

3、遇到问题，不要给自己设限。像火影里面的鼬说的 “并不是成为火影的人就会被大家所认可，而是被大家所认可的人才能成为火影。” ，不是因为是测试领导所以可以打通整体测试开发，而是能打通整体测试开发所以能当上领导。可能具体工作上确实不需要你去做打通整体测试开发的事情（这里面会有利益问题在，有时候水会比较深），但在视野和思考上，不需要给自己加这些限制。

比如查验证码、redis 等中间件常用查询语句（如查当前用户的相关数据）的一键查询、异常场景数据/场景的构造。

不过相比做成小工具，更建议直接内嵌到被测应用中，作为一个独立的调试设置相关模块（类似于 android 的开发者选项这种），这样开发测试都可以很方便地去使用，避免分开维护不同步。

没那么简单，规模比较大的内容类社区，一旦被发现内容违规，会被网警先直接关站的。

去年已经折腾了一遍，社区停止服务了 1 个多月，折腾不起了。

bug 已修复

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

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

这个要看具体情况吧。

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

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

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

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

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

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 了再做完整回归。