坚持分享文章，并且文章质量持续提升。

然后达到一定水平后，到沙龙/大会之类的做分享。

如果有一个不错的开源项目在手，并且持续经营维护，出名会更快。

上家公司有同学做了个自动生成数据库几乎全字段校验的功能，分享下思路，楼主看看有没有帮助？

背景：金融类业务，数据库需要校验的字段很多，手写效率太低，所以想自动生成。
手段：
增加录制/校验两种模式。录制模式时，把数据库查询到的数据统一存到用例对应的 csv 文件中；校验模式（默认）时，校验查询到的数据和 csv 文件是否一致。
由于有少量字段是无需校验的（比如时间相关的字段、某些自增的 id 字段），因此 csv 中提供了白名单机制，可以人工在里面配置需忽略校验的字段。
后期也优化为录制模式时每条用例会重复执行 2 次，并自动把两次执行不一致字段加入 csv 的白名单。

优点：
节省了很多数据库校验相关断言的编写成本
不足：
仅能校验等于，对于校验条件为不等于、某个范围内之类的，无法校验。（不过对于我们当时来说，已经够用了）

这个思路，理论上对于接口 response 也是适用的，只是可能存放格式要从 csv 改为别的格式（对象可能有多层，所以 csv 格式不一定适用）

这个和团队文化有关。

你有这个意识是挺不错的，如果实在施展不开且难以改变现状，可以考虑换到一些对这些方面更为重视，而非单纯按需求测试的团队里吧。

是的，对能力要求会比较高。

看代码其实不一定会很花时间，在了解整体技术方案的前提下，直接看分支间代码变更情况，有个半天基本能看完开发写了两三天的代码了。不过这个确实看团队文化，如果大家都不重视这个（比如开发可能连技术方案都不设计，就直接动手写代码，或者团队觉得测试不懂技术，技术方案不会给测试看），那基本是不会给你时间做这个事情的。

最后代码能力很强的，是否会在一线，这个我觉得还是会有的吧。毕竟一线也有分初中高级别，到了高级甚至资深，这个能力应该是会有的。

话说，想问下它这里的组件化，和 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 看看？