人比人容易逼死人。

说句不好听的，楼主现在应该就是挑战太少，公司工作上需要做的事情都已经游刃有余，所以才会觉得焦虑。如果是忙到飞起，或者工作上的事情已经要绞尽脑汁解决，一般都不会太焦虑这个。

建议楼主可以遵循自己的梦，先不要一下子给自己太大压力，给自己放个小假，放松一下。然后再逐步想下自己后续想怎么进一步发展，3 年后的自己想成为一个怎样的人，给自己定个明确的目标（比如要进 xx 大厂，或者达到 Px 级别的水平），然后专注地去达成它。

也推荐读一本书：《被讨厌的勇气》，能让你在被外界压得喘不过气的时候，意识到其实自己才是自己的掌控者。

这几天各种忙，周五终于早点下班了。我作为最近几届大会的议题主编，全程参与了议题的投递、审核过程，也在这里回复一下吧。

其实脉脉这个帖子，发出来当天社区小伙伴就有留意到了，只是考虑到脉脉匿名区本身的调性，去回复澄清也没啥意义，就没有太去管。后面看到有小伙伴也在社区匿名发帖了，说明社区小伙伴也比较关注这个，也借这个机会回复一下。

关于 “落地不靠谱”

落地这个问题，其实从前几届我们就有开始关注。有很多时候大厂创新性很强的东西，基本都是基于内部已经比较完善的基础设施来做的，确实落地成本对大部分公司来说都比较高。

针对这个问题，我们核心做了两个事情：

1、在议题评审标准中，除了创新性，也增大了可落地性比较不错的议题的比重。大家有留意的话，会发现最近几年中小厂议题数量是在增加的，里面也有不少基于开源项目二次开发而来的实践分享，落地成本相对低。
2、持续开展开源场，并邀请优秀的开源项目来分享。开源项目的东西基本大家都是拿回去可以直接用的（当然怎么用这个还得靠大家），落地性也会比其他只能听思路的强。

但诚如楼上其它同学所言，很多议题背后的实践能落地，其实都是和所在公司、业务、团队息息相关的。很多创新性比较强的实践，背后基本是一个团队持续投入半年以上时间才能得到。如果想着参加后 3 个月左右就能落地出类似成果，实在太难。更建议大家取其精华，选其中 1-2 个适合自己的所在业务和团队的，尝试实践落地，其他的，加入到自己的知识库中，和团队同学分享就好。

关于议题质量

议题的质量是大会的核心，所以我们一直都不敢懈怠。

我们组建了大会的技术委员会，邀请了 30 多位业内有丰富经验的同行加入。然后针对每个发过来的议题材料，大会的技术委员会都有做严格评审，并反馈修改意见，大部分最终能上大会的讲师，ppt 都改过 1 遍 2 遍，甚至 3 遍以上。此外也专门邀请了曾在 QCon 做过不少分享的资深讲师，给讲师们做怎么做好技术分享的培训，让大家能在大会上收获更多。

至于说像述职报告，其实我们评审中也有发现，最近几届大会收集到的议题 ppt，初稿中有不少是类似风格，像是内部 ppt 直接拿出来用。针对这类问题，我们也一直在和讲师沟通优化，不断调优 ppt，尽可能保障内容有干货、能闭环，大家听完能有所收获和获得启发。

关于大会规模

今年确实是有点失策了。原想着借助双十之际，能好好让大家聚一聚，而且前期征集收到的议题投递也比较多，所以想着保持 2 天规模。没想到上半年上海疫情严重，然后深圳最近也不稳，只能无奈延期。

至于线上分享，社区其实现在也有在陆续做线上的沙龙分享。但我们也发现，大部分讲师其实还是更希望能做线下分享，和观众能有更好的互动，所以我们今年还是坚持要办一次线下的大会（其实规模已经不大了，大概 800 人左右）

楼上大家提的减小规模、改为线上，都是非常好的建议，后面我们会结合这些意见持续优化。

关于大会未来

15 年第一届大会的时候，社区大伙都是凭着一腔热血把大会从零到一办起来。开始不易，但坚持更难。随着行业技术逐步成熟，目前基本上已经没有什么特别新的完全创新的技术出现了。相信很多楼上的同学反馈 18 年后新东西减少，应该也主要是这个原因。实际不是大会新东西少了，而是整个行业新东西都少了。

但个人觉得，这个 “少了” 并不代表就到天花板了，只是那种非常眼前一亮且通用性比较强的东西减少了。现在其实还是持续有很多新东西的。服务端领域服务网格，客户端领域类似 flutter 的跨端开发技术，都在持续出现，并持续提高研发的效率。而对应质量保障手段是否能同步提升，避免 “拖后腿”，将是未来大家面临的重大挑战。

从我个人来说，还是很希望能继续坚持办大会，让行业里面各种优秀的实践能有一个平台进行扩散，大家也能有一个平台相互交流学习。当然，未来大会也会尝试扩展更多方向的议题加入，帮助大家获得更多启发和收获。

最后

感谢大家给大会提出的各种意见。我们无法取悦所有人，只能坚持自己所想所做，让更多人能获得收益，实现共赢。未来欢迎大家有好的实践，继续投递大会，如果对于大会有什么更好的想法，也欢迎在社区开贴提出。

从应用角度，这两个原理在实际应用上用得相对不多。AOP 可能在某些需要打点的场景会用到，IOC 基本上用到得比较少。

但对于面试这个场景来说，很多时候不只是看你现在已经掌握的东西，还会看你的未来潜力。看潜力的其中一种方式，就是看对相关知识的探究了解情况。只知道怎么用，和知道背后的原理，在潜力上会有明显的差别。

不过我个人角度，不大喜欢这类偏八股的知识，很多都只是看了别人的文章然后复述，实际上其实也不大懂。我一般更多会问他掌握的某项技能是怎么学的，从学习方式等行为角度，来评估潜力。

微信小程序的自动化测试框架，越来越完善了，赞！

这个问题有点太直接了吧。。。对于回帖人来说，是纯输出，没有收获，回帖兴趣会不高。

建议楼主可以先分享下自己的，抛砖引玉？

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

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

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

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

背景：金融类业务，数据库需要校验的字段很多，手写效率太低，所以想自动生成。
手段：
增加录制/校验两种模式。录制模式时，把数据库查询到的数据统一存到用例对应的 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 日志中从收到请求开始（-->开头），到返回结果（<--开头）中间的具体操作，并加上日志时间戳，便于分析哪两个操作之间耗时长。