看业务情况，一般 1-2 周一个迭代，最长的不超过 2 周。迭代过程基本也和楼主说的瀑布差不多，不过这个我理解是个软件开发流程都得这么走吧，顺序大部分情况下无法调整，因为相互依赖。

另外，不知道楼主这里提的敏捷，和这里提的传统瀑布有啥差别？
敏捷的具体落地不同公司有很多不同差异的，有的地方小型瀑布（就是需求拆到 1 周内能搞完的粒度）也会认为是敏捷。

不用懵，说明你开始一步一步接触细节和深水区了。这些是成为专家的必经之路，也是差距所在。

selenium 打开的 chrome 用的模式和手动打开有点差异的，有点接近于无痕模式，可以搜索引擎详细查一下。

至于左下角这个，一般是表示焦点所在按钮对应的 url ，js 事件跳转的一般也是会这么显示。你可以对比下看普通模式下如果用 tab 选中登录按钮，左下角的提示是不是也一样是这样？

这个不是议题，是主题，也就是 slogan 哦。我现在改为 slogan 避免大家误解了。

别这样。。。受不起。。。

赞一下考古的态度。人云亦云实在太多了，里面还夹杂着别有用心的引用和传播，有很多东西其实考古一下才能真正理解前因后果。

android 的话，通过打开 https://debugx5.qq.com 应该可以看到调试菜单。

ios 没试过，不清楚。

如果你自己没找到特别需要用到 mac 的地方，不需要买。买了只会觉得没有想象中好用而已。

我自己也是用 mac 主力，windows 打游戏啥的，以前也有做过类似修电脑、重装 windows 等东西，对 windows 命令行也用得比较多。我说说我用 mac 而非 windows 的几个核心原因，你可以看看你是否有类似的需要

1. 支持全屏应用，可以专注写代码不受到各种弹窗干扰（windows 弹窗特别是一闪一闪的，真的特别干扰）
2. 不能装游戏，可以解决自己老是想打游戏的冲动
3. 续航长。不过好久没用 windows 本了，貌似现在也有不少续航很长的 windows 本
4. 基于 unix ，各种习惯更接近 linux ，比如目录结构、命令安装等。当然 windows 装个 cgywin 或者 git bash 也可以用 linux 上的各种命令，但总归有点别扭。
5. ios 开发及自动化支持。当年移动端能跑 ios 的 ui 自动化是很牛逼的一件事，而且没有现在这么完善的逆向工程能做到类似 tidevice 这样在 windows 上也可以跑自动化，加上这方面的自动化工具也优先支持 mac（有一段时间内 appium desktop 这个项目只有 mac 是全功能，windows 版被阉割了不少功能），所以当年买 mac 一大原因就是为了这个。
6. 能装逼。嗯嗯，能买苹果说明你还是有很不错的财力的，当年买了 macbook air 后有段时间开启了到处骑车去咖啡厅用电脑的习惯，后面懒得出去而且低头看电脑久了脖子疼才逐渐放弃。

PS：初入门暂时不建议 m1 ，兼容性坑还是有点大，比如 docker 虽然支持了 m1 ，且内置了 x86_64 指令的虚拟机，可以支持绝大部分镜像才有的 x86_64 指令集，但也有一些不兼容直接 core dump 启动失败。比如有些命令行软件，没法用苹果的自动转译，intel 的直接下载编译好的二进制包就能跑，m1 的还得自己编译而且处理各种编译报错。intel 就基本没这些问题。

额，你百度下怎么采集 android logcat 日志？这个日志收集并不复杂。

从耗时分布看，从发出请求给 WD Proxy 到收到返回值，基本都需要 20 秒左右，占据了绝大部分耗时：

...
2022-01-08 01:35:26:879 - [debug] [WD Proxy] Proxying [GET /element/00000000-0000-1371-ffff-ffff0000014f/attribute/enabled] to [GET http://127.0.0.1:8201/wd/hub/session/74b2d304-3843-4dba-98c2-fc0f9438be52/element/00000000-0000-1371-ffff-ffff0000014f/attribute/enabled] with no body
2022-01-08 01:35:46:924 - [debug] [WD Proxy] Got response with status 200: {"sessionId":"74b2d304-3843-4dba-98c2-fc0f9438be52","value":"true"}
...

这个耗时有点久，可以结合 logcat 日志看看到底这 20 秒在干嘛。

建议先看看你们的直播视频流的架构？

拉流是一对多（对应的是听众），一般生产环境会弄个 CDN 来提升性能和降低系统负荷。这种情况下你压拉流本质上就是压 CDN，意义不大（一般 CDN 都有单 ip 限流策略，你还没压到极限就被限流了）。

搜索 django_apscheduler 相关信息时找到的，可以参考下：https://juejin.cn/post/6844903885400702989。

好久没关注 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 是啥，把它删掉吧。