话说，想问下它这里的组件化，和 UI 自动化常见的 Page Object 模式，差别大么？

PageObject 模式里，把 page 从页面级别改为组件级别，理论上也可以做到和开发的组件一一对应。每个 page 自带有属性（控件对象）和操作方法（自定义 action ）。

学习了。

后面如果有更多的调研，可以发帖分享下。感觉现在前端的 UI 自动化工具，有点跟不上现在开发领域的组件化开发大趋势，虽然功能上还是可用（毕竟底层还是 html+js），但效率上落后不少。

行情差这个，也不只是测试，整个互联网行情都不大好。如果行情不好就迷茫，那你会很被动。

然后工作 2-3 年这期间会迷茫是很正常的，我当年也迷茫过。基本上迷茫的原因是毕业时计划学习的/工作中需要掌握的，基本都差不多了，日常工作也基本游刃有余，所以会开始考虑未来。

而这刚好基本是自己工作后，第一次认真考虑未来发展，而且此时视野其实还不够广（一般 2-3 年基本只经历过 1-2 家公司，接触的业务类型也比较有限，而且大多和公司外的同行交流相对少），所以会觉得自己视野之内的东西都掌握了，也都会用了，不知道自己要何去何从，属于认知阶段的 “不知道自己不知道”。

这个时候，建议可以做 2 方面的事情：

1、复盘自己过去 2 年的做过的事情，写下总结。总结文章也可以来社区分享一下，造福其他人。写的过程中，可能就会发现，自己某些方面的掌握其实还不够熟练，很多地方说不清楚，这样就能变为 “知道自己不知道”

2、参加下一些行业的分享交流活动，比如社区公众号不定期有线上分享，线下也有 MTSC 大会、各地沙龙等活动，看看别人是怎么做的。除了测试领域，也可以看看开发、运维领域的（比如掘金、简书、QCon 等），了解下新的东西，帮助变为 “知道自己不知道”

建议楼主贴下具体的 html 和 xpath ？原理上只要是 html dom 树存在的东西，xpath 就可以定位到。

不过有一点个人是同意的，那就是现在前端组件化后，selenium 这种基本上基于原生 js + html 来写脚本的工具，用起来会越来越不方便。

由于组件基本不再需要 id 这类唯一标识来给 js 调用，对于开发人员来说也基本看不到被组件封装后的原始 dom 树信息，所以基于 html 去做控件定位变得越来越麻烦。同时由于逻辑上也基本向着双向绑定的方向走，所以有时候想改变控件的值，还不能就直接去输入框里 setValue（有可能背后是监听 onChange 事件来做数据同步，而非直接读取 value 属性）。

可以开个帖子，介绍下这个工具，以及它在控件定位上比 selenium 先进的地方么？想了解学习下。

个人建议，这种时候更要找 leader ，体现你想要进一步发展的态度，留下个好印象。而且听你这么说，继续留在这个公司还是有一定的前途的，这条路对你来说比出去另外找要稳很多。

如果你一直不找，而是 leader 自己发现的话，他会觉得你一直在摸鱼而且安于现状，持续躺平，反而印象不好，大概率直接干掉。

基本上每半个月只需要半天时间测试，其他时间都是闲着

有尝试过找 leader ，看有什么有挑战性一点的任务给你做么？你这个工作量确实太少了。

另外，今年校招确实 hc 都比较少，而且已经 9 月，新的面向 23 届的校招都已经开始了，这个时间点你很难以应届生身份找工作了。

建议：
1、继续投递简历，也多些耐心。现在形势不大好，得骑驴找马慢慢找。
2、在现有公司也想办法找些有挑战性的工作做。一般技术比较不错的，可以从提高效率这个方向来入手。提高效率不只有接口自动化，比如测试工作量这么少，是不是说明开发效率很低？是否能找到/造一些工具来提高开发的效率（比如 web 领域很常见的 mybatis-plus generator ，自动基于表结构生成相关的 MVC 各层代码；或者测试环境的部署和维护，是否可以结合 jenkins + docker/k8s 进行提效）？

比之前好一些，但还不是很亮眼。

“我的工作” 里，每家做法都差不多的常规工作基本上就汇聚到一条就好了，重点放到非常规里面。

比如 Web 音乐下载器 PC 版，“我的工作” 部分可以优化下（有部分内容脑补了下，可能和事实不符，仅供参考）：

1、通过对需求进行分析，编写测试用例，完成测试任务。所经手的项目线上质量问题数量为零 ，质量良好。（第一个为常规项，简单写下就好。如果有其它更突出的亮点，这项不写也可以）
2、针对产品核心功能依赖于第三方音乐网站的特点，制定定期检测第三方音乐网站更新后兼容情况机制，保障问题出现后 xx 小时内即被捕获。（如果这里有做成自动化定时任务的话，也可以补充说一下，这样成果的效果会更明显）
3、针对线上下载出现小概率失败的情况，和开发、运营协作，通过整合程序事件埋点 + 用户反馈信息，帮助开发有效重现/定位到其中 xx% 的问题并进行解决，最终下载失败率从 xx% 下降到 xx%。

上面说的这些东西，不知道有没有项目中真正落地，且持续出效果呢？

前 3 年建议专精一个领域（比如客户端/服务端？），把相关的开发技术、测试技术都了解清楚，并在项目中有一些落地应用，产出成果。3 年后有深度后再去扩散广度，有了第一个深度的基础后再去扩展，会顺畅很多（至少如何上手->如何使用->如何落地->如何出成果这套流程，都很熟练了）。

伪造经历这个倒不至于，和培训机构弄的简历还是有差别的。培训出来伪造的简历，其实看起来还是不错的，重点会比较突出，用到的一些技能点会更为突出。只是成果上一般会比较弱（毕竟没来得及实践）。

至于专业理论和深度思考，一般简历上很难体现（除非说做过什么行业分享之类的），更多需要通过附上博客、公众号文章或者 github 项目来佐证，所以就不用在简历上强求了吧。

补充一个：如何提炼重点这个，可以参考 STAR 法则，也可以上网找一些说怎么写好自己简历的文章，看看人家给的示例。

找工作，简历是很重要的，而且写简历的技巧以后你写汇报、写绩效都用的上，很值得多花点时间在上面。

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

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 的理念：拿着镜像直接部署使用。