这个简历，把内容控制在一页这个挺好的，如果能优化下重点，以及解决掉一些错别字或者不通顺的地方，效果会更好一些：

1、工作经历里，佐恩佐这段只有 1 个月时间的经历，写了 4 个项目，这是 1 个月就做 4 个项目，还是工作起止时间写错了？

2、简历重点应该是 “你做了什么、取得了什么样的成果”，而不是讲项目是什么（这个和你没啥关系，也不是你可以决定的）。而你简历工作经历部分，项目介绍篇幅占了一半，你做的工作被挤到密密麻麻，阅读体验差。没耐心的估计直接忽略了

3、自己的工作，要归纳得更精炼一些，并且尽量数字化说明。比如 佐恩佐 这段的主要工作，列了 10 个点，太多了，而且有些没啥写进去的必要（比如 “在无测试任务时，对软件进行探索性测试” ，这个真心没啥意义），尽量控制在 3-5 个内，并且尽量写亮点（比如自动化脚本、测试中用到什么比较特别的测试方法或者技术），而不是人人都在做的事情。

4、存在一些错别字或者术语错误。比如 “冒泡测试”（正确应该叫冒烟测试）、“与部分开用例审查例会”（不知道是不是少了字，读起来很不顺）。这个真不应该。

测试本身就是很善于找错误的，上面提到的第一点（假设工作时间真的写错了，不是一个月，而是一年）和第四点真的不应该出现，一出现，会显得非常不专业，造成 “这个人很粗心” 的第一印象，直接没有约面的欲望。

你这个地图炮，范围很大。而且除了标题说开发外，其他文中内容基本都是在自我反思，并没有在诋毁开发。

请不要断章取义。

为二楼点赞！

自己以前初次带团队，最难的是心态的转变，从自己大部分事情都亲力亲为，改为多依靠团队内外的力量解决问题，这个确实会比较难（特别是大部分情况下，团队内成员能力不一定非常强，有时候会觉得指导他的功夫自己都搞定了）。

可以把老板的质问作为警钟敲响起来，后面逐步去转变吧。

PS：真的建议标题改一下，这个故事里，核心问题还是在 leader 身上，和开发没啥关系（可能只是因为技术 leader 刚好是开发出身？）。

技术 leader 说输出和效率，leader 却一直在说自动化怎么怎么样，明显是把输出和效率和自动化画等号了。其实老板视角关注的输出和效率，核心是测试是否可以快速完成需求的测试（这个一般看 开发测试时间比），并且保障上线后质量没大问题（这个直接就看客户反馈或者线上问题数量）。至于是否通过自动化解决，这个属于细节，相对关注度没那么高。而且说实话，一个需求过程中都会经常改的项目，自动化做得再好又有啥意义呢？

标题 “永远不要和开发做朋友” ，会不会有点过了？

看日志，应该是在获取 appium driver 的 timeout 配置信息。至于为啥会持续轮询，可能得查 appium client 部分的源码了。

不过这个应该不影响运行时间吧？服务端都是可以并行处理多个请求的，就算一直被获取 timeout ，应该也不会导致你的自动化变慢。如果你觉得慢，更建议去分析 appium server 日志中从收到请求开始（-->开头），到返回结果（<--开头）中间的具体操作，并加上日志时间戳，便于分析哪两个操作之间耗时长。

以前好像有一些众测平台，可以接任务。不过不知道现在还有没有还活着的。

最简单直接的，比不会 go 的多一门语言技能，哈哈。

按照我个人理解，go 语言本身的优势是语法相对简单，而且性能比较高（比 python 之类的解释型语言高），打包产物为一个独立文件，部署也简单。目前用 go 比较多的应该是 运维开发、服务端开发。

对测试来说，如果你这个脚本想让别人更快速地部署起来（直接下载编译后的可执行文件->运行，不用装环境），go 是个不错的选择。我看到的其中一个例子就是 sonic 平台，改为用 go 写的 sib 取代 tidevice ，这样就不用让用户特意装 python 环境来运行 tidevice 了。

不过，貌似 go 领域的测试工具框架相比 java、python ，相对比较少，所以可能有很多轮子不一定有现成的用，得自己造。

2 个建议：

1、尝试下通过人脉找内推，至少他能帮你找到简历直接不通过的原因，方便你针对性优化。如果不介意的话，也可以考虑把简历隐去敏感信息后发出来，大家给些意见建议。

2、既然已经裸辞了，那就多点耐心吧，也降低一下预期。广州机会不多的话，也可以考虑找下广东其他地方的，比如深圳。

这个编写时间，一般你的评估是多久？一般是怎么估法？

可以以社区帖子的回贴功能作为被测对象来估一下。

@TH_tester 看看？

比如一个商城的迭代，有商品管理页面，里面有搜索框、高级搜索、商品状态、商品的操作之类的，应该首先从哪开始写起呢，怎么搭建一个系统的有结构的用例呢

可以自己找个顺序，比如先按页面分大类，然后里面再按页面从上到下或者从左到右控件的顺序，去细化测试点。只要顺序得当，至少从界面功能角度，都可以过一遍。

还有那种 b 端和 c 端有场景交互的功能，这种又什么时候写出来呢 ？

不知道你的 b 端和 c 端具体是怎么交互的。个人习惯，一般这种复杂场景交互的，先看是哪些功能涉及，然后往功能里面加这方面的测试点。

如何合理评估一个功能迭代的测试用例时间呢？

不知道你说的是用例编写时间，还是用例执行时间。一般评估时间最常用的方式就是拆解，把整体需要测试的内容拆到一个每个部分你都可以快速评估出需要测多久的程度后，把这些时间加起来，再乘以 1.2（留 20% 风险时间），会是一个相对靠谱的排期。

google 了一下关键字 api test platform ，找到了这篇：10 Best API Testing Tools In 2022 (SOAP And REST API Testing Tools) 。里面也有挺多的呀。

只是，国内的平台大部分情况下，会更符合国人的习惯（光是有中文这个，就比国外很多纯英文的受众面广了），加上宣传比较多，自然你会接触到的，大部分都是国内的。

你的信息还是不够全面。命令的正常输出是啥，程序返回内容里缺了啥呢？

另外，channel.recv(-1) ，这里参数传入 -1 确认是没问题的吗？我看其他文档都是传具体最大长度值的。

你三楼找到的这篇，是完全脱离 docker 的，这么装没问题，因为 linux 主机本身是有状态的（所有改动不会消失），不会像容器那样设计时就是很低的销毁成本。

然后我意思是，进入 docker 容器一般只建议做调试查错类工作（比如测试下某条命令是否可以正常执行之类的），不要做环境配置类工作（如装新软件）。
环境配置类的东西，尽量在镜像里就配置好，这样才更接近 docker 的理念：拿着镜像直接部署使用。

另外，随手查了下这个库的用法，好像不能 send 完立马 receive 的，需要稍等一下？

我看的这个：https://pyneng.readthedocs.io/en/latest/book/18_ssh_telnet/paramiko.html

稍微吐槽下，官方文档好像没有 quickstart 这类快速上手文档，只有怎么装，以及很详细的每个函数的说明。对于想要快速知道典型用法的人来说，看得有点蒙

没看懂这个问题。

代码里的关键命令内容 cmd 内容是啥？
完整的返回值是啥，和截图里有啥不同，缺了啥？

可能原因：

1、重连的容器不是原来的容器。比如你通过类似 docker run -it jenkins:latest /bin/bash 命令启动容器并自动进入命令行，然后退出命令行，这时候容器会一并被关闭。重新 run 就会从镜像新建容器，而非启动原有容器。

2、你虽然装了，但相关路径没有加到 PATH 环境变量，所以还是找不到

建议排查一下。

PS：不是很建议在容器里面手动装软件或环境。容器最好应该是无状态的（可以理解为啥都不存，只是单纯一个有处理逻辑的程序），随时可以重建。需要有状态的部分（比如数据），可以通过路径映射之类的方式存到容器外，或者直接自定义一个镜像构建脚本，把要装的东西加到镜像里，让每次启动就自动带上。

嗯嗯，这个确实是需要修复的。

不行，这样实际还是向大量人员公开的，起不到内容审核作用。而且如果被发现，可能会被认为故意蒙骗监管部门有做内容审核，风险更大。。。

你上面提的，我理解已经挺全了。大部分情况下，不同环境的核心差异是 url 不同、数据不同，以及少量的被测系统逻辑差异（一般是被测系统配置项差异带来的）。

url 这个，抽离到环境配置文件里就好。
数据不同这个，如果可以重复用，就也抽离到环境配置；如果不能重复用，那就补充每个环境从零进行数据构造的逻辑，到用例的 setUp 里面。
被测系统配置项不同引发的差异（比如某些逻辑开关可能会有差异），这块就不建议脚本去适配了，直接弄个单独的检查脚本，让测试执行前，检查确认这些被测系统配置项尽可能一致就好。

可以加点达梦数据库介绍？第一次听这个数据库，搜了下，是个国产数据库。

大概看了下，有几个点想交流下，谈不上建议哈：

1. 从实现逻辑看，没太理解为何必须拉代码后，还得编译成 jar 包再解析？我理解静态的调用链信息获取，应该用 java 文件结合抽象语法树解析，就足够了。
2. 拼接 class 和 method 的 Mapping 注解 url 时，条件是 classUrl!=null&&methodUrl!=null ，而 controller 并不一定有 class 级别的 mapping 声明，如果没有的话，不知道会不会引起遗漏？（从下面逻辑大致来看，好像如果 class 没有 mapping 声明，是不会产生对应的数据的，即 classUrl 可能为 null ？）因为没有本地跑，所以只是一个猜测哈，如果有说错请见谅。
3. 从实际使用角度，光拿到 url 其实还不大够，可能会存在单个 url 有多个 http method 的情况，加上 http method 会更佳。
4. 建议项目加个 readme ，否则大家都不知道怎么用。

补充下，如果你只是要手工拿数据，不需要自动化或者转换为数据记录到独立平台，那直接用 chrome 的 devTools 就好了，有图形化的展示，数据也齐全。

Performance insights 应该可以直接获取到你提的白屏时间等指标：

详细的，你看看 chrome devTools 自己的相关文档研究下吧。

我看你给的参考连接里，第一个社区 360 团队的文章，你上面提到的几个问题，都有很详细的说明了。

对于白屏时间、首屏加载时间这块，大致原理我的理解是：

1、在 webview 启动上加料，让它注入监控相关的 api 调用，获取数据。这个就是 https://github.com/jwcqc/WebViewMonitor 这个项目干的活。
2、解析数据获取到的数据，就可以得到你提到的几个指标了。

然后文章里还提到的 pacap、pacap2har、harviewer 之类的，主要是分析资源请求情况用的（类似浏览器里的 network 标签内容），用于辅助定位为何白屏时间长这类问题。和获取白屏时间本身是不同的东西。

然后你提到编程语言，建议你先不要受制于语言，现在哪个工具比较适合，就去快速上手这个工具，别纠结自己不懂这个语言，非得找自己懂的那个语言的。

基本两个大方向：
1、如果只是测试有些配置限制是否生效，那改下判断逻辑里获取的那个数据值就好。比如改点赞数这个字段的值为 9999。
2、如果是要测试大数据量下性能是否会下降之类的，可以用接口自动化之类的自动触发用户行为。