鸿蒙现在可以说还是个红海，或者说 APP 开发本身还是有机会的

1、爬虫的话用 python，会点 js 逆向就差不多可以接单了，记住爬虫写得好，牢房进的早，别乱搞；
2、网站开发，会 html js css 或者 vue，后端 django 或者 springboot 就可以了，功能复杂点的 redis mq,不过能用上消息队列的也不算简单功能，mysql 平时工作常用的就不说了；
3、如果你会 vue 的话，还可以开发微信小程序 uniapp 就可以搞定，不过呢如果你想多端兼容，比如 uniapp rn 去开发的话有点难搞，不是多年的开发有点架不住；
4、前面 123 说的都是功能，现在说部署，部署的话都是 docker，不过个人独立开发者能接单的项目都是单体应用，流量不是很大，都用不到 K8S，如果真正需要用到集群部署的项目，这个项目的价格也是很客观的，画个 1 周时间去学习下问题不大；
写在最后：在 AI 工具泛滥的时代，充满这各种机遇与挑战，在没有 chatgpt 时候去百度一些代码实现都要找半天，现在能自动给你写出代码，CURD 会用就行了，抓紧这个机会

完蛋了，一个都答不上

牛马何必骂牛马，还爆粗口 我一直提倡的是测试工程师就是 “医生”，你既然说软件没有达到预期，有 “病”，你就拿出 “证据”（1、针对业务功能直接回溯需求文档，把需求截图贴上；2、针对需求含糊不清，当前可以找产品和项目其他人一起确认，确认后等项目结束开回顾会议，要求下次迭代要求产品经理需求文档出专业点；3、很多测试同学很喜欢研究用户体验的问题，关于用户体验这块比如 UI 和交互这些可以形成公司统一的风格规范，10 个人就有 10 种用户体验，这种 BUG 不影响使用，提上去改不改再说）
最后再说一点，小命是自己的，工作没有可以再找，干的不开心就趁早走~

我再多说点，当然这个和公司项目管理流程也有很大的关系，很多公司项目管理混乱，没有具体的 PMO 岗位来专门监督项目开发过程中管理的乱想
我们现在为了减少 BUG 和线上事故，每次版本开发计划排好之后，给开发 1 到 2 个工作日看需求，利用 1 个小时候的时间开需求反讲会议，会议有产品经理、项目经理、参与的研发和测试，每个开发都有去把需求讲一遍，讲自己对需求的理解和基本的设计思路，有问题产品经理当场指出，测试同学也要明白开发的设计，不明白的当场确认讨论

这次 11 月继续啊

没有任何证书，互联网技术是日新月异的，证书的教材考纲都是 10 年左右才更新一版，书中设计到的东西基本都已经落后了。

集成属于中级，不需要写论文，高级要写论文，会经常性的卡通过率。具体考哪个看你的需求，如果想巩固下软件测试的基础理论知识可以报考软件评测师，很多的软件测试方面的理论，如果想了解项目管理方面的可以系统集成和高项

论文一直是个玄学

已考，这玩意某些地区是可以落户，除了这个作用貌似没有发现其他作用，你说事业单位评职称吧，但是都是高级起步了，中级也起不了什么作用。
但是呢，这个考试入门 0 要求，只要是个人都可以报，如果你平时时间比较多，也可以试试，报名费也不是很贵，吃顿海底捞都不够，而且吧，没有什么难度，闭着眼睛都可以考过的那种

1、如果当前项目比较稳定，在此项目上扩展 APP 的话，可以考虑自动化，把不同的功能抽象出来。这种我理解的是类似于定制化开发，针对那些有特俗需求的用户群体；
2、如果当前项目不太稳定，自动化就不太适用了，此时又要保证当前项目的稳定 同时还要兼顾 扩展项目，再接入自动化不太符合，成本也很高，只能练手速了

allure 生成报告其实就是个本地的静态 html，使用 allure 原生报告改造成本最低
方案：
1、可以把每次执行生成 allure 生成报告传到指定文件服务器，并在数据库设置张表记录报告的文件服务器路径，执行等信息
2、然后提供一个集中的入口可以展示所有执行的报告记录，比如 XXX 功能 2024-10-18 14:00:00 报告，点击报告可以在线预览报告
PS：个人觉得把报告用邮件的发送方式是最愚蠢的行为，为什么呢？作为一个管理者每天的邮件是很多的，你难道还要我每天去翻看吗？年底汇报时候要能够直观的数据，说我今年总共执行了这么多次，一目了然

1、提出的问题都是在 “点点点” 阶段就可以发现，和是否开展自动化没有关系
2、搞清楚开展自动化的前提是什么，提出的 3 个问题都是常见 BUG，自动化无法解决
3、你提出问题的困扰应该是怎么避免这类 BUG 的发生：
一、一个版本里程碑完了，可以把这类 BUG 拉出来拉上开发一起进行当前里程碑阶段回顾会议，着重提出这类 BUG 怎么避免，制定措施，比如用例先行，用例给到开发自测；要求开发代码规范；实在不行换个有能力的开发；
二、在前面说的措施都是针对开发的，但是推动还是比较困难的，既然不能解决别人身上的问题，就要从自身解决：
针对这类 BUG 进行分析，这些 BUG 出现最高的频率在哪些功能模块；这些 BUG 经常由哪些开发人员写的，以后针对这些模块和这些开发人员重点验证；
其次是要提高自身发现 BUG 的手段，怎么样才能快速发现这类 BUG，平时日积月累，丰富用例库，看到这类 BUG 相似的功能就应该马上检索出相应的场景去验证

1、循环控制器次数应该是个整形，你弄个成这个格式【1,1】,肯定是不合法的

2、不知道你具体的目的是什么？如果你想把循环控制器次数控制成 JDBC 查询出来的记录条数，你可以再增加一个 JDBC 请求，这个 JDBC 请求 写 select count(1) from table A，count 设置变量，计数器最大值也设置这个，就可以实现循环控制器次数按照 SQL 查询记录处理了
3、jmeter 运行是有日志查看，报错建议先看运行日志

源码都给了，可以自己在上面开发就行了

这是我见过最良心的开源项目，没有之一，希望能一直长久下去，祝越来越好！

哎 ~ 不是工作就是在带娃中，奉劝还没有结婚的同学好好把握现在的美好自由时光

你遇到的问题与使用 ByteBuddy 这样的字节码操作库有关。ByteBuddy 在尝试用 SuperMethodCall 动态地调用超类（或接口）中的方法时遇到了问题。错误信息表明你正在尝试覆盖一个方法，但该方法没有超类实现，因此无法调用 super 或默认方法。

在 Java 中，如果一个方法是最终的 (final)、静态的 (static)、私有的 (private) 或者是构造器 (constructor)，那么它不能被子类重写，也就意味着你不能从子类中调用其 super 方法版本。

解决此问题的一种可能方案是：

避免直接覆盖最终或静态方法。如果方法是最终的或静态的，你不能在子类中调用其 super 版本。你需要考虑重新设计你的类层次结构，或者使用其他技术来达到你的目的，例如代理或装饰模式。
使用接口和默认方法。如果可以的话，将方法移动到接口中并提供默认实现，然后让目标类实现这个接口。这将允许你使用 SuperMethodCall 调用默认方法。
手动重写方法。在子类中手动实现方法，而不使用 SuperMethodCall，你可以直接调用超类的实现，例如通过反射或直接调用类的非私有方法（如果适用）。
使用 ByteBuddy 的其他特性。例如，你可以使用 MethodDelegation 或 MethodInterception 来拦截方法调用，而不需要直接调用超类方法。
如果你不能改变现有的类结构并且必须在没有父类的情况下工作，你可能需要考虑使用不同的字节码操作策略，比如使用拦截器（interceptor）来修改方法的行为。

如果你愿意分享更多的代码细节，我可以提供更具体的建议。不过，既然你提到源码不便分享，你可以尝试描述一下你的具体需求或目标，也许我能给出一些通用的解决方案或建议。

月供 5900 对于你们这种测试界的扛把子，待遇的零头，岂不是洒洒水啊

接私活开发项目

除了落户有点用，其他一点用都没有

跑的是众包，想跑就跑不想跑就关闭，只是在附近跑跑，最好的情况下班后 100 来块吧，用的是自己的电动车，奈何外地牌早高峰线下，私家车只能停在地库，每天上下班骑电动车上下班，利用下资源而已

有个代步的纯油车，跑滴滴成本太高，情愿停在车库吃灰都不能干亏本买卖啊

才 6 天而已

效果杠杆滴

testerhome 是给不了温暖么？