好久没关注 appium 最新的文档了，没法给很具体的操作建议，只能说下可以参考的排查思路：

1、日志加时间戳，appium server 启动参数里有给日志统一加时间戳的设定的，可以加上。先把时间做下拆分

2、打印 uiautomator 内部日志。之前排查 ios 问题有见到过打印 wda 日志的开关，你可以找找 uiautomator 有没有，有的话把它打开，看 2 分钟内有什么日志，通过日志查看过程中都在干嘛。甚至你打印 logcat 也可以。把 appium 日志里面耗时比较长的 request->response 过程的日志，通过这个地方进一步拆细。

3、查看源码。如果前两步获取的信息都不够充足，无法定位，就去看源码吧，可以重点看 uiautomator driver 部分，

这段日志没有时间戳，看不出每一段的耗时呀，不好给建议。加上时间戳再打印一次？

我理解这个数据论证，想表达的意思是这个至少不是毫无根据天马行空的。数据论证不一定是做实验那种自己采集数据，也包括同行的参照数据（比如阿里的 361）、别的专家的意见等。

我倒是觉得，这个点没啥好纠结的，毕竟这个大部分管理者都很难去推动改变。反倒怎么执行好的同时不至于给团队带来太大的影响，这个才是管理者最需要花精力的。

目前是人肉，人肉审核最靠谱。

对，一切发的东西都要审核。再来一个违规就真的要关站了，宁慢勿错。

简单总结，就是不要在最末尾真的开始搞绩效的时候才来关注绩效，日常各种早会、周会等都要保持好沟通，让员工自己知道自己绩效是好还是不好。

特别是里面提到的 “在主管心里，无论怎样都是有排名的” ，深有感触。刚开始只是带小组感觉不那么明显，当带一个 15 人以上甚至更大团队时，这个会很明显。同时基于这个排名其实也可以定期自己模拟一下给团队的同学做绩效评定，这样更清晰知道自己想培养的人现在有没有培养到位（比如能不能找得到真的比较不错的项目或事迹佐证他拿到好绩效），落后的人是否有及时沟通和给予机会，有没有人自己关注太少没啥印象需要关注下的。

看下整个磁盘的空间？运行过程中需要使用的不仅仅是 docker root 的空间。

也可以参考下这个：https://stackoverflow.com/questions/44634346/failed-to-write-all-bytes-for-bisect-so

就是一眼就能看出来的垃圾信息，比如可以帮开发票这些。

这个其实已经超出测试环节的范畴了。

毕竟准确识别违规内容，这玩意相比普通的测试，更接近于机器学习里面的分类问题了，而且进一步说，因为有商业利益在（SEO 权重高，就会被利用作为推广手段），对方很可能使用到安全攻防相关手段（比如直接木马注入，跳过所有的程序写逻辑防护），这已经不是单单测试可以搞定的了。测试用例防范的是普通用户的不规范操作或者程序可能出现的异常，但很难防范别有用心用户的精心操作。比如 Log4j 这个漏洞，估计 99% 用 log4j 的人都想不到这个使用姿势。

PS：最近学习了一个冷知识 零宽字符 ，有兴趣可以去看看，很可能公司自家的敏感词屏蔽没防护到这个。

对，堵住所有漏洞。

违规内容这个是红线，不能再碰了

是的，避免再出现违规内容。

我们一般是性能测试的时候需要对比竞品的性能数据，这样才知道自己在竞品中的水平情况。单纯一个绝对值看不出是好是坏。

不知道你说的是不是这个？不是的话可以说下是要测竞品的啥呢？

我用 macbook ，直接拷贝你正文里面的代码到 pycharm 文件里，直接运行，没有你这个编码的错误，只是有另外的语法错误，说明不是你可以看得到的字符问题，应该是你文件的字符问题。

coding 的声明你从哪里抄的？* 号前后应该是英文中划线，不是下划线。
可以看看这个：https://blog.csdn.net/zhongbeida_xue/article/details/81736671

另外，从报错上看，已经识别到 utf-8 编码了，但里面有的字符无法正常 decode 。建议你拿个 16 进制编辑器，看看到底这个在第 4 个字符的 0x92 是啥，把它删掉吧。

具体在 pycharm 里怎么跑的 pytest ，截图说清晰点？

https://cn.bing.com/search?q=UnicodeDecodeError%3A+%27utf-8%27+codec+can%27t+decode+byte+0x87&form=QBLH&sp=-1&pq=&sc=0-0&qs=n&sk=&cvid=1F5BB1D1958C420894799ECA8647F618

末尾的错误，搜索引擎一查就有很多说明了。猜测你的 0x87 是文件头信息，估计是你新建文件的编辑器自己加的，属于不可见字符，得用可以显示不可见字符的编辑器（如支持看 16 进制编码的）才能看到。

因为没有具体的问题，只能泛泛而谈一下。个人觉得总体的大方向是先在可掌控范围内（简单点说就是纯测试团队就能做的），控制住影响比较大的问题的出现（测试防护网）获得成效、得到认可；然后再逐步推动做根因解决/预防性工作，巩固成效同时，提高整体团队质量意识。

1、先了解现在主要有哪些问题，哪些严重影响业务，急需解决。列个优先级，并和上级、兄弟团队 leader 达成共识。
2、针对优先级达到最高级别的几个问题，先测试团队内部建立对应的防护网，确保不再把问题漏到线上（比如建立上线 checklist 保证这个检查点检查到位，这阶段追求质量先牺牲部分效率）。
3、根据防护网捕捉到问题的情况，复盘了解根因，从根本上解决/预防问题的再次出现。这部分的先聚焦解决已有问题，会涉及推动非测试团队配合，但只做最必要的，避免负荷调大兄弟团队不接受。
4、几个问题根因解决见效后，就可以把上述套路扩散到优先级稍微低一些的问题里了。同时也可以抽离里面的共性，逐步开始建设有梯度的质量体系，比如左移（需求质量把控、代码质量把控、代码逻辑 review 等）、自动化测试、右移（线上核心业务指标的监控及预警、核心接口巡检等）

会做自主优化是好事，长期可以持续保障代码的质量，毕竟赶需求很容易导致代码写得比较临时（比如各个配置项没抽离，各种 if 嵌套等），也叫做欠技术债。听楼主的描述，问题不是出在自主优化，而是出在临时插入不好安排，以及改动点模糊不好评估测试范围。

其实这个核心还是缺少流程规范导致信息不够透明，沟通不通畅。这类优化开发会觉得小 case 想简单处理，简单过头就变成无计划无规律了。如果说频率很低那还好，频率高还是有个流程规范统一一下，否则容易开发觉得测试效率低，测试觉得开发计划乱，双方都不满意。

建议你们的需求里增加一种类型，叫做技术优化类需求，提出者就是开发方。让开发这类调整都作为这类需求进行提出（注意不是提测时提出，而是在开始进行时就提出，和普通需求一样进入开发阶段前就明确提出并同步测试），并且提测时描述清楚改动点（直接附带 MR 更好，代码是最好的文档），这样整体测试的排期和资源安排就可以合理纳入，测试也可以有足够的时间根据改动点进行评估，如果改动风险低的甚至可以直接开发演示自测结果后，直接给予测试通过，减少测试投入时间。

大佬这个名字受不起，我的水平离真大佬还远着呢。。。

8 楼正解。你这个批量添加用户的场景应该是一个线程循环 200 次，而不是 200 个线程并行执行。

线程组的设定，直接截个图吧，200-0-1 没看懂具体每个数值的含义。

另外，你的截图只看到了 if 控制器，没见到哪个是仅一次控制器，也标识清楚吧。

可惜人没在上海，上海的同学不要错过啦。

没看懂讨论啥？讨论有啥框架能做，还是怎么设计框架让它能做到？

从做需求里也可以找点价值，比如需求做得更快了，有些流程比之前规范了之类的。

5 年的时候倒没什么困惑，当时还在持续上升期，在专注应对带团队、建设平台的挑战，没太多精力分散到 “下一个方向往哪走” 这个问题上。